Project Planning and Delivery Control

A Plan Must Help the Team Control What Happens Next

A project plan can look complete while the implementation remains difficult to control.

The dates are populated. Every workstream has a color. The weekly report says configuration is nearly finished. Yet the data extract is late, the integration specialist is overallocated and the business has not protected time for acceptance testing.

The problem is not a lack of planning software. The plan does not represent the conditions under which the work can actually be completed.

Chapter 8 established mobilization readiness, Chapter 9 examined the team and Chapter 10 defined governance and decision-making. This chapter connects those foundations through an integrated plan and a practical delivery-control cycle.

A useful plan explains what must be delivered, how the work connects, who has the capacity to do it and what evidence supports the forecast.

All schedules, quantities and case examples in this chapter are fictional illustrations. They demonstrate planning logic rather than a standard duration for enterprise implementation.

11.1 Start with Deliverables and Outcomes

Begin with the approved scope, SOW, business outcomes and acceptance criteria. Break the implementation into deliverables and work packages that can be owned, estimated and reviewed.

A work breakdown structure organizes the work. A schedule adds the sequence, timing, dependencies and resources needed to perform it. Both should remain traceable to the commitment being delivered.

“Complete finance configuration” is too broad to control without supporting detail. Identify the agreed process areas, configuration packages, review activities, test evidence and approval responsibilities.

Include the customer's contribution and third-party work where these affect completion. A supplier-only activity list is not an integrated enterprise plan.

Review coverage through People, Process, Data and Technology. Training preparation, process decisions and data reconciliation should appear alongside configuration and development.

The objective is enough detail to make work executable and progress verifiable, rather than the largest possible number of task rows.

11.2 Build One Integrated Delivery View

Workstream plans are useful, but the overall project needs a shared view of how their outputs connect.

A functional design may enable an integration specification. The integration build may enable end-to-end testing. Testing evidence and business readiness may jointly support a go-live decision.

Make these handoffs explicit. Agree what the receiving team needs, when it needs it and what evidence confirms the input is usable.

Different planning levels can use different tools, provided their milestones and dependencies reconcile. A sprint board, migration tracker and executive milestone plan should not tell incompatible stories about the same release.

Identify the authoritative source for each type of information and how updates move between views. Avoid maintaining several independent completion dates through manual copying.

The integrated plan is the place to understand the delivery consequence when one workstream changes its forecast.

11.3 Give Activities Useful Definitions

Each controlled activity should have a clear output, owner, duration estimate, relevant resource demand, predecessors and completion condition.

Use action-oriented descriptions such as “Validate customer mapping with the data owner” rather than labels such as “Customer data.” The first describes work that can be assigned and completed.

Separate work from waiting where that distinction matters. Preparing a design may take three days, while customer review may require another five working days. Combining them can hide the need to obtain business availability.

An owner coordinates completion but may rely on other contributors. Confirm those contributors and their commitments instead of assuming the owner can perform every part.

Define how actual start and finish will be recorded. “Started” should mean meaningful work has begun, and “finished” should mean the agreed completion condition has been met.

For a complex package, use intermediate outputs to make progress visible without declaring the whole package complete prematurely.

11.4 Model Dependencies Before Promising Dates

A dependency explains why an activity can or cannot proceed. It may be technical, business, contractual or resource-related.

Distinguish a genuine prerequisite from a preferred sequence. Some activities can proceed in parallel; others would create rework or invalid evidence if started early.

For example, test-script preparation can begin while configuration progresses, but final validation of those scripts may depend on approved process decisions. Integrated testing requires the relevant components and data to be available together.

Use explicit dependencies where possible rather than unexplained gaps between tasks. If a third-party approval requires a lead time, show the review activity and owner.

Avoid forcing every activity to a fixed date simply to reproduce a target timeline. Hard constraints can conceal the effect of a slipping predecessor.

After sequencing the work, compare the resulting forecast with the required milestone. Any gap needs a delivery decision, not a cosmetic change to the schedule.

11.5 Distinguish Effort, Duration and Availability

As Chapter 6 established, effort measures work while duration measures elapsed working time. Resource availability connects the two, but dependencies and working calendars also matter.

An 80-hour configuration package assigned to someone who can provide 20 project hours each week represents four weeks of that person's capacity before considering additional constraints.

Assigning a second person may help only if the work can be divided and both have the necessary capability. Coordination, reviews and onboarding may add effort.

Reflect working hours, holidays, operational peaks and customer review availability. A calendar that assumes everyone is available every weekday will produce optimistic dates.

Check shared specialists across workstreams and projects. Their allocations should reconcile to realistic capacity, including the review and support work that often goes unrecorded.

Resource leveling may move activities and alter the critical path. Review the schedule again after resolving overallocation rather than presenting the original dates alongside a corrected resource plan.

11.6 Understand the Critical Path and Float

In a logically linked schedule, the critical path is the sequence of activities that determines the earliest modeled completion of the selected project or milestone.

Total float describes how long an activity can slip without delaying the relevant completion date under the schedule's current logic and constraints. It is not automatically a separate allowance owned by each activity.

Consider a simplified example in which both configuration and integration build require design approval. Integrated testing needs both branches complete.

Using working-day boundaries, design runs from day 0 to day 5. Configuration then finishes at day 13, while integration build finishes at day 17. Testing runs from day 17 to day 23, followed by readiness review to day 26.

The critical sequence is A–C–D–E, totaling 26 working days. Configuration has four working days of total float in this unconstrained example. An isolated three-day configuration delay would consume three days of that float without moving the modeled finish.

An isolated two-day integration delay would move the finish to day 28. These are separate scenarios, assuming no other changes, resource conflicts, holidays or recovery actions.

Real schedules are more complex. Review near-critical paths as well as the current critical path, because consuming float or changing resources can shift which sequence controls completion.

11.7 Establish a Baseline and Preserve the Forecast

An approved baseline records the agreed scope, schedule and relevant effort or cost reference against which performance will be assessed.

The current forecast shows what the team now expects based on actual progress, remaining work and current assumptions. It should change when evidence changes.

Keep those concepts separate. Moving a forecast date is not the same as authorizing a new baseline.

Record the reason for variance and the decision required. If an approved change alters the commitment, update the baseline through the agreed change-control process and preserve its history.

Do not reset the baseline merely to remove visible delay. Equally, do not refuse to update an unrealistic forecast because the original date remains contractual.

Leadership needs both views: what was approved and what is now expected. That comparison makes recovery decisions and commercial discussions more useful.

11.8 Plan Near-Term Work in Greater Detail

An implementation cannot always be planned at the same level of certainty from start to finish.

Use a detailed near-term plan for work the team understands and broader work packages for later activities. Refine those packages as discovery, design and testing provide better evidence.

This approach is often called rolling-wave planning. It should preserve the overall scope and major dependencies while increasing detail at the appropriate time.

For example, the next two weeks may identify individual workshops, required inputs and review deadlines. Later migration work may initially show agreed cycles and readiness milestones, with object-level tasks added as mappings become clear.

Set dates for that refinement. A future package that remains vague until the team reaches it can become an unplanned delay.

Uncertainty is a reason to identify assumptions and ranges where useful, not to omit the work or imply that every later date is equally reliable.

11.9 Connect Agile Execution with Release Commitments

A backlog and sprint plan can manage iterative delivery while an integrated schedule tracks release dependencies and business milestones.

Link backlog items to the agreed scope, acceptance criteria and relevant deliverables. Make completion definitions clear so that “done” reflects the required quality and review.

A demonstration can provide useful progress evidence, but it does not necessarily mean integration testing, business acceptance or deployment readiness is complete.

Use the team's observed delivery evidence to improve forecasting, while accounting for changes in team composition and work complexity. Story points should not be treated as currency or compared casually across teams.

Review unfinished work and dependencies when planning the next iteration. Repeatedly carrying items forward should trigger investigation of size, clarity, capacity or blockers.

Agile execution should provide a more current view of the work. It should not create a separate reporting system in which sprints appear successful while the release's business prerequisites remain unplanned.

11.10 Measure Progress Through Completion Evidence

Hours consumed, documents drafted and meetings attended describe activity. Delivery control needs evidence of completed outputs and remaining work.

Agree how progress will be measured for different work packages. A small task may use a simple not-started or complete rule. A larger deliverable may use defined intermediate milestones with agreed weighting.

Avoid assigning a convenient percentage because a task feels close to completion. “Ninety percent complete” can persist for weeks when difficult integration or acceptance work remains.

Review quality and acceptance separately where necessary. A document can be submitted but not accepted; a build can be deployed but not successfully tested.

Ensure aggregate measures do not conceal a critical dependency. Completing many minor tasks does not compensate for an unresolved interface required to execute the main business process.

The most useful progress discussion ends with a credible view of what remains and what is needed to complete it.

11.11 Run a Consistent Delivery-Control Cycle

Set a reporting cutoff and collect updates from accountable owners using consistent definitions.

For each active package, review actual start or finish, remaining duration, remaining effort where relevant, completion evidence, dependencies and new risks. Record the reason for material changes.

Recalculate the integrated schedule after updates. Examine the critical and near-critical paths, resource conflicts and changes to key milestones.

Then decide the response: continue as planned, remove a blocker, adjust sequencing, obtain a decision or assess a formal change. Assign actions with dates and verify their effect at the next review.

Use the governance routes from Chapter 10 when the response exceeds delegated authority.

The cycle should produce a current plan and specific decisions. A weekly call that collects reassuring statements without updating the forecast is reporting activity rather than controlling delivery.

11.12 Forecast Remaining Effort and Explain Variance

A practical effort forecast combines actual effort to date with a reviewed estimate of the effort required to finish.

Suppose the approved effort baseline for a work package is 1,000 hours. At the reporting cutoff, 420 hours have been consumed and the owners estimate 650 hours remaining.

The forecast at completion is 1,070 hours, which is 70 hours, or 7 percent, above the baseline. The 420 hours consumed do not prove that the package is 42 percent complete.

Investigate what changed. The difference may reflect underestimated work, defects, dependency delays, changed productivity or additional scope. Identify the cause and its treatment.

If 50 additional hours are subsequently authorized as a baseline change, the revised baseline becomes 1,050 hours. With the same 1,070-hour forecast, the variance is then 20 hours above the revised baseline. The original baseline and approved change remain visible.

These are effort calculations, not a complete financial performance model. Translate them into cost or commercial implications using the project's agreed costing and contractual rules.

11.13 Control Work in Progress and Blockers

Starting more work can create the appearance of progress while increasing the amount waiting for review, testing or a decision.

Examine queues as well as individual tasks. Ten completed builds waiting for one reviewer may indicate a constraint at review, rather than a need for more developers.

Limit concurrent work where doing so helps the team finish usable outputs. The appropriate limit depends on capability, work type and dependencies; it should be reviewed through delivery evidence.

For blocked items, record the reason, responsible resolver, date needed and impact. Link recurring blockers to the relevant issue, dependency or decision record.

Do not leave work labeled “in progress” when it is actually waiting. That distinction changes the corrective action.

Direct attention to the constraint that governs completion. Reassigning unrelated people or opening additional tasks may not improve the delivery date.

11.14 Build Recovery Plans Around Real Options

When the forecast moves beyond an agreed tolerance, develop options with the people who understand the affected work.

Possible responses include removing a dependency, resequencing independent work, adding qualified capacity, reducing an authorized release boundary or changing the date.

Some activities can be overlapped to reduce duration, but doing so may increase rework if the upstream output changes. Adding resources can shorten some work, but may increase cost and will not remove every specialist or approval constraint.

Evaluate the recovery option across quality, readiness, support and risk. Reducing test coverage or compressing training can preserve a schedule while leaving the business exposed.

A recovery plan needs an owner, the decisions required, a revised forecast and evidence that the proposed action is working.

Do not call the original date a recovery plan. Explain what changes in the delivery model make that date achievable and how the team will verify the assumption.

11.15 Keep Risks and Dependencies in the Schedule

A RAID register should connect to the work it may affect. In this book, RAID means Risks, Assumptions, Issues and Dependencies.

Link a late source extract to the migration preparation and testing activities that require it. Link an uncertain design assumption to the point at which it must be validated.

Include agreed risk responses as planned work where they require effort or time. A second rehearsal does not happen merely because it appears in a mitigation column.

Keep allowances visible and avoid double-counting the same protection across activity durations and separate buffers. Explain who controls any schedule reserve and how its use is reviewed.

For material uncertainty, consider plausible scenarios and their effect on milestones. A single forecast date should not conceal an unresolved dependency that could materially alter the outcome.

Use this information to seek decisions early, while the project still has options.

11.16 Manage Baseline Changes and Delivery Handoffs

When a change is approved, update all affected planning views: scope, work packages, dependencies, resources, milestones, test activities and readiness actions.

Record the approved change reference and effective baseline version. Communicate the effect to people receiving changed inputs, not only to the person who requested the change.

Check handoffs between stages and deployment waves. A completed build may still need technical documentation, test evidence and known-issue records before another team can use it effectively.

Use the acceptance and readiness criteria established in the SOW and governance model. A task's completion should not silently stand in for a separate business approval.

At closure, reconcile outstanding deliverables, open issues and support responsibilities. Confirm where continuous improvement work will be prioritized after the project ends.

Planning should connect the entire lifecycle rather than stop at the production deployment task.

11.17 The Delivery Leader's View

A delivery leader uses the plan to test whether the implementation remains achievable.

They ask which sequence controls completion, which assumption is weakest and what evidence supports the remaining-work forecast. They also ask whether the business can absorb the change at the planned time.

They avoid confusing a demanding target with a dependable commitment. Where the two differ, they make the gap visible and bring forward choices.

They maintain a disciplined baseline without treating the original plan as immune to new evidence. The forecast should become more informed as delivery progresses.

This chapter completes Part III. The project now has mobilization discipline, an accountable team, a governance model and a way to plan and control the work.

Part IV begins with Running Effective Discovery Workshops, where these foundations support a deeper understanding of the business and its requirements.