1.3 Project Planning and Activity-Logic Development
Key Takeaways
RP 39R-06 concerns project planning, while RP 24R-03 concerns developing activity logic; they are related but different practices.
Planning develops the execution basis before and during schedule development through scope, methods, packaging, resources, phases, interfaces, and stakeholder decisions.
Logic should represent physical and technical sequence, external and contractual interfaces, and documented preferential or resource choices as appropriate to the model.
Fragnets can help evaluate discrete changes or events, but their use and contractual effect depend on purpose, governing requirements, timing, and records.
Assumptions and basis documentation improve reviewability; they do not by themselves create legal entitlement.
1.3 Project Planning and Activity-Logic Development
AACE RP 39R-06 addresses Project Planning, while RP 24R-03 addresses Developing Activity Logic. Planning establishes how the project can be executed; logic development translates that plan into dependency relationships. The work is iterative: schedule calculations may reveal an infeasible sequence or resource peak that sends the team back to refine the plan.
Develop the execution basis
Planning should integrate:
- contract requirements and owner objectives;
- scope, goals, phases, and acceptance criteria;
- engineering release and review strategy;
- procurement packaging, fabrication, logistics, and delivery;
- construction methods, work faces, access, temporary works, and constructability;
- testing, commissioning, turnover, and operational interfaces;
- organization, responsibility, labor, equipment, and material availability;
- estimate quantities, productivity, cost, and cash-flow assumptions;
- stakeholders, approvals, permits, and third-party commitments; and
- risk, opportunity, contingency, and recovery options.
The project execution plan may capture much of this basis, but document names and approval paths vary. The planner should obtain input from the people responsible for performing and accepting the work rather than create a network solely from software templates.
Translate planning into schedule inputs
Map deliverables and work packages to activities and milestones. Define durations from quantities, methods, production rates, crews, review periods, procurement data, or other defensible sources. Assign calendars that reflect working time and restrictions. Connect activities through relationships representing the planned handoffs.
Physical or technical dependencies arise from the method of work. External and contractual dependencies arise from access, approvals, permits, owner-furnished items, or required dates. Preferential logic records a chosen but changeable sequence. Resource-driven sequence may be represented explicitly when it is part of the execution plan, or through resource-constrained analysis or leveling. The model should make the chosen treatment visible so reviewers understand which relationships can change.
Avoid calling a relationship a “hard constraint.” Logic relationships and date constraints are different schedule mechanisms. A physical FS relationship may be mandatory under the selected method, while a Must Finish constraint imposes a date on the calculation. Use each term precisely.
Constructability and alternatives
Constructability review tests whether the planned sequence can be performed safely and physically with available access, workfronts, temporary works, crews, equipment, laydown, and permits. It should occur early and repeat when material scope or method changes. Alternative plans—such as modularization, different packaging, work-face resequencing, or added shifts—should include their design, procurement, approval, transport, and testing effects.
Assumptions and basis
Document material assumptions such as design maturity, quantities, production rates, crew sizes, calendars, weather treatment, review durations, access dates, procurement lead times, constraints, and exclusions. RP 38R-06 concerns documenting the schedule basis. The record helps others reproduce and challenge the plan. It does not guarantee contract acceptance or independently prove entitlement.
Change and fragnet analysis
A fragnet is a small network representing the activities and relationships associated with an event or change. It can support prospective evaluation, change planning, or time-impact analysis. Build it from defined scope, durations, calendars, predecessors, successors, and resource assumptions. Insert it into an appropriate copy of the schedule and compare relevant milestone results.
The correct schedule version, status date, method, and approval path depend on the contract and purpose. Modeling a fragnet does not itself authorize baseline revision or establish responsibility. Label potential, proposed, approved, and implemented changes separately.
Planning-to-schedule review
Before baselining, test whether:
- every material deliverable and interface is represented;
- activities and milestones are measurable;
- relationships match the selected execution method;
- durations, calendars, resources, and cost assumptions reconcile;
- major stakeholders reviewed their commitments;
- milestone paths can be traced and explained; and
- assumptions, risks, and exclusions are documented.
Planning precedes detailed schedule calculation conceptually, but it continues throughout the project. Updates, forecasts, and recovery plans should feed field evidence back into the planning assumptions.
Applied review: test the plan with a milestone trace
Choose a required completion or turnover milestone and trace backward through commissioning, installation, procurement, design, approvals, and access. At every interface, name the deliverable, owner, duration basis, calendar, and evidence that the handoff is complete. Then trace forward from a major input such as notice to proceed, owner data, or long-lead release. A gap in either direction reveals omitted work or an unsupported assumption.
Repeat the trace after resource and risk review. A technically logical sequence may still be infeasible if it needs the same crane, crew, work face, outage, or reviewer in two places at once. Document how the plan resolves the conflict and whether the solution belongs in logic, calendars, resource analysis, or a management action.
A planner creates hundreds of linked activities before defining scope, methods, procurement, work faces, or stakeholder interfaces. What is the fundamental problem?
The schedule has too few constraints.
Detailed scheduling began without a defensible execution plan and planning basis.
All activities should have been milestones.
The project must use ADM instead of PDM.
How should the relationship between two sequential elevated concrete floors be described?
As a hard date constraint in every case
As an earned-value rule
As a cost-account mapping
As physical or technical logic under the selected construction method, distinct from a date constraint
How should a proposed owner scope change be evaluated before any authorized baseline revision?
Model the defined change and tie-ins in an appropriate schedule copy, quantify effects, document assumptions, and follow the governing approval process.
Overwrite the baseline immediately.
Add only the requested finish date.
Assume the fragnet automatically proves entitlement.
Sections you finish are checked off in the contents.