16 — Programme planning, cost and risk

A programme plan explains how a business will turn an uncertain engineering problem into accepted products. Dates matter because people, facilities, suppliers and money must be available together. But a date without a description of the information and authority needed to act is only an intention. A planner must be able to explain why a work package can start, what it will produce, who can accept it and which later commitments depend on it.

In the four-vehicle programme, Vehicle 01 is being built, Vehicle 02 has major equipment ordered and Vehicles 03 and 04 are being planned. There is no single meaningful percentage called “vehicle design complete” that determines whether all four can proceed. The chassis work needed for one vehicle may be ready while its cooling installation remains unresolved. Conversely, a visually complete vehicle model may still lack supplier operating limits, an agreed inspection method or permission to incur expenditure. Planning must represent these different conditions.

Plan the deliverable and its use

Start with the product outcome and work backwards through its dependencies. Delivery requires acceptance evidence for the applicable vehicle. That evidence requires completed inspections and tests. Tests require a defined configuration, available facilities, agreed methods and suitable equipment. Assembly requires materials and released manufacturing instructions. Those instructions require sufficient product definition and interface information. Engineering analysis requires requirements, assumptions and supplier data. These are causal relationships, not merely a preferred order for drawing bars on a schedule.

A deliverable is therefore more precise than “finish cooling”. It might be a released cooling-module installation package for Vehicle 01, including mounting definition, hose interfaces, electrical connections, process instructions and inspection characteristics. A later deliverable might qualify a different module for the hot-climate configuration of Vehicles 03 and 04. Both concern cooling; they support different commitments and may legitimately have different completion dates.

NASA’s technical-planning guidance links the organisation of technical work with lifecycle outcomes; its systems engineering management plan guidance also addresses contractor integration and scheduled deliverables. These provide a useful planning reference, rather than obligations automatically imposed on this vehicle programme. NASA technical planning, NASA handbook appendix.

For each significant package, establish an accountable owner, its applicable configuration, its inputs, the maturity required of those inputs, its outputs and acceptance criteria. Identify the decision that makes the output usable. A supplier’s preliminary envelope may be sufficient for a packaging study but insufficient for manufacture of a mounting fixture. Treating both as receipt of “supplier CAD” conceals the most important distinction.

The schedule should also distinguish the issue date from the need date and the review duration between them. An interface document delivered on the day that machining must start is late if it still requires engineering review, translation into manufacturing definition and material release. Where an assumption substitutes for an input, show the assumption and the date by which it must be confirmed. Otherwise the schedule presents contingent work as unconditional progress.

Dependencies include authority and capacity

Some dependencies are physical: the engine must be available before an installation trial. Others are informational: its interface definition is needed before bracket design can be completed. Others are decisions: a technical authority must disposition an unresolved mounting issue before the affected work can be released. They should not be represented as one undifferentiated “engine delivery” milestone.

Resources create another set of constraints. An analysis may be ready to start yet wait for the only available thermal engineer. A test may depend on a facility already reserved for another product. Supplier reviewers, configuration staff, inspectors and purchasing specialists also consume capacity. A plan that allocates only design effort can push unfinished decisions into procurement and manufacture, where they are more expensive to discover.

The programme manager integrates these constraints and resolves competing priorities. Engineering authorities judge whether information supports the technical commitment. Manufacturing owns the feasibility and readiness of the production method. Procurement establishes supplier commitments and commercial constraints. Finance supports assessment of funding and exposure. None of these roles should silently acquire another role’s authority because a milestone is approaching.

A critical dependency is not necessarily the longest design activity. It may be a short approval with scarce reviewers, a supplier decision about an interface, or access to a test asset. Review the dependency network whenever assumptions change. Moving a finish date without examining its causes creates a more attractive schedule but no additional ability to deliver.

Commit before everything is complete

Concurrent engineering is planned overlap. The programme need not wait for the complete vehicle design before buying standard engine equipment or making stable chassis features. It must, however, bound what each early commitment relies upon. The question is whether the remaining uncertainty can invalidate the committed work and whether that exposure is acceptable.

Consider an early release for cooling-module mounting brackets. Inputs include the mounting envelope, loads used in assessment, attachment interfaces, manufacturing material definition and the relevant vehicle applicability. If a future hot-climate assessment might require a larger radiator, the release decision must establish whether the bracket remains valid across the credible alternatives. If this cannot be shown, alternatives include deferring machining, procuring adaptable stock, releasing only unaffected features, or accepting explicitly bounded rework exposure.

The record of the decision should state the alternatives considered, assumptions, affected work, financial and schedule consequences, the decision owner and the trigger for reassessment. This is useful operational information. If the supplier later changes the module, the team can identify which early commitments relied on the old envelope rather than rediscovering the reasoning through interviews.

Permission to start one package is not permission to complete every downstream activity. A trial installation may proceed with controlled temporary arrangements while final acceptance remains prohibited. The plan must show these hold points. Otherwise a locally reasonable start decision can be misread as authority for irreversible manufacture or customer delivery.

Cost follows commitments and uncertainty

A useful cost view distinguishes money already spent, commitments that remain payable, the forecast cost of completing the accepted scope and exposure associated with unresolved decisions. An invoice total does not reveal cancellation liability on equipment already ordered for Vehicle 02. Nor does an unspent budget prove that funds remain available for additional scope.

Estimate costs against defined work and assumptions. Include engineering effort, supplier data, tooling, integration, inspection, testing and likely change implementation. Avoid counting the same risk twice in individual estimates and a central reserve. Equally, do not remove a risk allowance merely because its cause has not yet become an approved change. The uncertainty remains until evidence retires it or a decision converts it into planned work.

Risk records should connect cause, uncertain event and consequence. “Cooling risk” does not tell anyone what to do. “Supplier thermal data may arrive after bracket release, requiring a changed package envelope and rework of Vehicle 01” identifies an actionable dependency. Assign someone to obtain the data, define an alternative and recommend a decision before exposure grows. A risk owner monitors and acts; an acceptance authority decides whether the residual exposure is tolerable.

Schedule contingency also needs a purpose. A general gap at the end cannot recover an unavailable test facility or replace a long-lead transmission. Protect the specific dependencies that threaten delivery, and examine whether mitigation consumes the same scarce resource as the original plan.

Replan a customer change across four vehicles

A customer raises the payload requirement in DOORS while manufacture and purchasing are under way. This begins an impact assessment, not an automatic instruction to build differently. Systems engineering identifies affected performance and constraints. Structural, suspension, braking and powertrain specialists assess their areas and interfaces. Procurement obtains supplier implications; manufacturing identifies work already completed and work that can still change economically. Verification planning identifies the evidence needed to substantiate any changed configuration.

The plan must distinguish assessment work from implementation work. Engineers can be authorised to investigate alternatives without authorising a revised production baseline. The programme manager can then compare credible options: modify all vehicles, introduce a change only on later vehicles, retain an agreed earlier configuration for Vehicle 01, or revise delivery sequencing. These alternatives require customer and contractual disposition where they alter the agreed outcome.

Vehicle 01 needs a physical survey of build status, not an inference from the latest design revision. Vehicle 02 needs an examination of purchase commitments and supplier manufacturing progress. Vehicles 03 and 04 offer more freedom, but their planned configuration must still be explicit. A statement that “the payload change is approved” does not establish which vehicles receive which solution or what happens to stock and orders.

After a decision, update the affected requirements baseline, technical work packages, supplier actions, manufacturing plans, tests, expenditure forecast and delivery commitments. Retain the previous schedule baseline for comparison and distinguish an approved plan change from a forecast that simply reflects delay. Completion of the change requires downstream evidence; a revised drawing alone does not show that a vehicle was modified.

A separate hot-climate customer change may affect cooling, HVAC, electrical demand and verification conditions. A supplier connector substitution may affect only a narrower interface, although its implementation can still disrupt assembly. Preserve separate initiating causes and impact records even when both changes touch the same cooling-module package. Combining them into one vague “cooling update” obscures responsibility and makes later acceptance difficult to explain.

Control through evidence

A progress meeting should ask what became usable since the last review, what assumptions remain and which next commitment is at risk. Counting drawings or reporting effort expended can support workload management, but neither establishes product readiness. A package can consume its entire budget while still lacking the supplier evidence that makes it useful.

Use evidence appropriate to the milestone: an accepted interface definition, a reconciled manufacturing package, a confirmed supplier commitment or a completed vehicle-specific test record. Record exceptions and their disposition. Avoid assigning apparently precise percentages to work whose remaining technical uncertainty dominates the outcome. Forecast the unresolved work directly.

The information architecture should link plan activities to controlled deliverables and applicability. DOORS supplies the relevant customer requirements context; NX and Capital support discipline definition; Teamcenter provides the intended lifecycle context for product and manufacturing information; SAP supports the enterprise resource and commercial execution context. The programme schedule and risk-management tools must be selected and integrated deliberately. These platform names do not establish an automatic, complete planning system.

Exchange identifiers, revisions, status meanings and need dates explicitly. A schedule link to an item identity without its required revision or baseline can falsely show a dependency satisfied by obsolete information. Conversely, every harmless document edit should not invalidate a milestone. Define which changes alter the commitment and route those through the enterprise change process, using the CM-II basis without assuming that a particular scheduling workflow proves framework conformity.

Scale the decision structure

On a four-vehicle programme, a small group may review the entire dependency network together. On a defence or infrastructure programme with millions of occurrences, multi-year manufacture and thousands of people, no individual can maintain that understanding informally. Decompose the plan into accountable packages with controlled interfaces, integrate their milestones and expose assumptions that cross organisational boundaries.

Local teams need freedom to sequence low-impact tasks. Programme authority must retain visibility of shared resources, major supplier contracts, configuration transitions and commitments that can invalidate other work. Excessive central approval slows ordinary work; uncontrolled local replanning makes the integrated forecast meaningless. Allocate authority according to consequence and cross-boundary effect, then escalate exceptions rather than every routine task.

A baseline is a reference for decisions and comparison, not a promise that nothing will change. The useful programme plan remains explainable as circumstances evolve: which outcome is required, which configuration will achieve it, what information is still needed, what has already been committed and who can decide the next step.