Chapter 9: Commitments, Estimates, and Honest Plans¶
The programme in Chapter 1 did not fail at month six when the delay was announced. It failed at the point when a commitment was made that was not based on an honest assessment of what the work required — and then compounded at the point when the honest assessment arrived and was not used to revise the commitment.
Every element of this chapter is a structural response to that specific failure sequence. How commitments should be made. How estimates should be produced. What a genuine plan looks like. How the gap between a commercial commitment and an honest estimate should be managed. And what accepting a commitment actually means — not just accepting the number, but accepting the conditions and risks that the number depends on.
These are not process preferences. They are the structural mechanisms by which the broken accountability loop described in Part One is closed.
What a commitment actually is¶
A commitment is a specific promise, made by a specific person or group, to deliver a specific outcome by a specific point in time, based on a genuine assessment of what that outcome requires.
Most things that are called commitments in engineering programme governance are not commitments by this definition. They are commercial gestures — dates and numbers agreed in service of a business need before the evidence required to support them exists. This is not inherently dishonest. Commercial contexts require decisions to be made under uncertainty. A client needs to know when a product will be available. A board needs a date for a strategic milestone. An investment case needs a cost and timeline to make sense.
The problem is not the existence of commercial gestures. The problem is when they are treated as commitments — when the date set before the scope was understood is treated as a binding delivery commitment that the engineering team must honour, rather than as a commercial expectation that must be tested against an honest assessment of what is actually achievable.
The distinction matters because it changes what the organisation should do when the honest assessment diverges from the commercial gesture.
When the divergence is treated as a problem with the estimate — when the engineering team is asked to find a way to close the gap rather than the gap being treated as information about the realism of the commercial gesture — the programme proceeds on a plan that everyone involved knows is not based on reality. This is the sequence that Chapter 1 described. It produces failures that are predictable, preventable, and attributed to the wrong cause.
When the divergence is treated as information — when the gap between the commercial gesture and the honest estimate is treated as a risk to be managed, a conversation to be had, a trade-off to be owned — the programme has the opportunity to proceed on a plan that reflects what is actually achievable. This is harder commercially. It is substantially cheaper operationally.
A commitment, in the Firmitas sense, cannot be made until an honest assessment exists. Everything before that is a working hypothesis that should be clearly labelled as such — a target, an expectation, a commercial position — not a commitment.
Who makes the commitment¶
Principle 3 states that a commitment not made by those who must keep it is a target with someone else’s name on it. This principle requires a specific and practical answer to the question: who should make the commitment?
The commitment should be made by the people who have both the delivery knowledge to assess what is achievable and the authority to be held accountable for the outcome. In most engineering programmes, this means the commitment requires genuine input from the engineering team and genuine ownership by the programme leadership.
It does not mean that engineers set the date unilaterally. The commercial context matters. The client’s constraints matter. The portfolio priorities matter. A date that is technically achievable but commercially unacceptable is not useful. The goal is a commitment that is both honest and commercially viable — which sometimes requires difficult conversations about what is achievable within commercial constraints, what trade-offs are available, and what the cost of maintaining a commercially convenient but technically unrealistic date will be.
What it specifically excludes is the sequence that produced the failure in Chapter 1: commercial commitment made, engineering assessment produced, gap identified, gap suppressed in favour of the commercial commitment. That sequence transfers the commercial gesture to the engineering team as if it were a genuine commitment while retaining none of the conditions that would make it achievable.
Presenting a reverse-engineered plan to an engineering team and asking if it is achievable is not making a commitment. It is asking the engineering team to validate a number that was not produced by honest assessment. The answer, in most cases, will be a qualified yes — achievable if these risks are mitigated, if these decisions are made, if these conditions are met — which will be recorded as a yes and used as the basis for holding the team to a number they never genuinely committed to.
Making a commitment means the risks are accepted, not just noted. It means the implications are acknowledged, not just recorded. It means the plan has slack, realistic foundations, and honest assumptions — not the best-case scenario dressed as a plan.
How honest estimates are produced¶
An honest estimate is produced by the people who will do the work, from a genuine understanding of the scope, the system, the context, and the risks. It is not produced by a project manager working from a high-level work breakdown structure. It is not produced by extrapolation from a previous programme without adequate consideration of what is different about this one. It is not produced under time pressure to hit a governance deadline before the scope has been adequately understood.
Three conditions are necessary for honest estimation.
The right people. Estimation by proxy is not estimation. The people estimating must be close enough to the work to understand what it actually requires — the specific technical challenges, the integration dependencies, the unknowns that will need to be resolved before certain elements can be estimated with confidence. Where that proximity does not yet exist — where the scope is not yet understood well enough to estimate reliably — the honest answer is a range estimate with explicit uncertainty bounds, not a false precision that obscures the uncertainty.
Full context. Estimates produced in isolation — without understanding of the wider system, the client’s real requirements, the regulatory obligations, the architectural constraints, the dependencies on other teams and external parties — are not estimates of what the programme requires. They are estimates of a simplified version of it. The divergence between the simplified version and the real programme is the estimation gap that reliably produces overruns. Estimates must be produced with full visibility of the scope, the constraints, and the risks that will shape the actual delivery.
A safe environment. Estimates produced under pressure to reach a specific number are not honest estimates. They are numbers calibrated to what the estimating environment rewards. When the governance culture treats estimates as negotiating positions, estimates become negotiating positions. When the governance culture treats estimates as honest assessments that will be used to make real decisions, estimates become honest assessments. The environment is the variable. The people doing the estimating are responding to it.
The three-point estimate¶
A single-point estimate is not an estimate. It is a commitment masquerading as an estimate — a specific number that contains no information about the conditions it depends on or the risks that could invalidate it.
Firmitas requires three-point estimates. Not as a bureaucratic requirement, but because a three-point estimate contains the information that a single-point estimate withholds — information that the governance layer needs to make real decisions rather than to approve numbers.
Best case is not the optimistic scenario. It is the scenario in which everything that can go well does go well — in which the specific conditions required for the fastest achievable outcome are all met. The best case estimate must state explicitly what those conditions are. Best case is twelve months if: the hardware-software interface specification is confirmed with the client by week four, the third-party component is validated against programme requirements by week six, and the test environment is procured and qualified by month three. Without those conditions, the best case is not achievable. The number without the conditions is not a best case. It is a wish.
Most likely is the genuine professional judgement of what the programme will take under realistic conditions — not optimistic conditions, not worst-case conditions, but the conditions that actually tend to prevail on programmes of this type. It incorporates the most probable outcomes for the identified risks, the realistic rather than ideal availability of dependencies, and the friction that complex programmes reliably accumulate in ways that individual task estimates do not capture. Most likely is the number the team would bet on if they were betting with their own money.
Worst case is what happens if the named risks materialise. Not all the risks — the specific ones that, if they occur, would have the most significant impact on the timeline. The worst case estimate must state explicitly which risks would produce it. Worst case is twenty-two months if: the hardware-software interface ambiguity requires a formal specification revision process with the client taking six to eight weeks, the third-party component proves unsuitable and requires replacement with a four-week architecture redesign, and the test environment qualification takes three months due to hardware availability constraints. The worst case is not a contingency buffer. It is the priced consequence of specific, named risks.
The three numbers together tell the governance layer something a single number cannot: here is the range of realistic outcomes, here are the conditions that produce each outcome, and here are the decisions you need to make to keep the programme in the best-case range rather than the worst-case one.
The risk register as part of the estimate¶
The risk register attached to a three-point estimate is not a separate document. It is the same document. The risks in the register are the conditions attached to the estimate — the specific items that connect the most likely case to the worst case and that define what actions are required to keep the programme at the better end of the range.
This is the relationship that was broken in Chapter 1. The estimate and the risk register were presented together but treated separately. The governance layer accepted the committed date — a number below the most likely estimate — while noting the risk register without generating the decisions the risks required. The two documents were decoupled. The number was used. The conditions were filed.
When the estimate and the risk register are the same document, decoupling them is not possible. Accepting the most likely estimate means accepting the conditions that produce it and the risks that could push it toward worst case. A governance layer that accepts a three-point estimate but does not act on the risks attached to it has not accepted the estimate. It has extracted the number while declining the information that gives the number its meaning.
The governance principle follows directly: accepting an estimate requires accepting the risk register. The risk register is not reviewed and noted alongside the estimate. It is the basis on which the estimate is evaluated. The decisions that the risk register requires are the decisions that the governance layer must make in response to the estimate. If those decisions are not made, the estimate that has been accepted is not the estimate that was presented — it is the best case, stripped of its conditions, presented as the plan.
What a genuine plan looks like¶
A genuine plan is built forward from an honest estimate, not backward from a desired date.
This sounds obvious. It is almost universally violated.
Building forward from an honest estimate means starting with the most likely case — the professional judgement of what the programme will take under realistic conditions — and constructing a plan that reflects that assessment. The plan identifies the specific decisions and actions that are required to achieve the best case, treats those as programme priorities, and explicitly shows the impact on the timeline if those actions are not taken by defined trigger dates.
Building backward from a desired date means starting with the date and constructing a narrative that connects it to the current state. Every task is estimated at best case. Dependencies are shown in whatever arrangement minimises the apparent duration. Risks are listed on a register and assumed to be mitigated. The plan, when complete, shows the desired date achievable — because it was constructed to do so, not because it reflects reality.
The distinction is visible in how the plan handles uncertainty. A plan built forward from an honest estimate contains explicit uncertainty — ranges rather than point estimates where confidence is low, identified decision points where the timeline will be revised based on new information, acknowledged contingency for the risks that have been priced into the worst-case estimate. A plan built backward from a desired date treats uncertainty as something to be removed from the presentation rather than managed in the execution. The uncertainty exists. The plan simply does not show it.
A genuine plan in the Firmitas sense has four properties.
It is built on honest most-likely estimates rather than best-case assumptions. Every task estimate reflects genuine professional judgement, not the number required to make the plan fit the date.
It contains explicit slack. Slack in a plan is not waste or padding. It is the capacity to absorb the variation that complex programmes reliably produce — the integration issue that takes a day longer than expected, the client response that takes a week rather than two days, the test failure that requires a design investigation. A plan with no slack is a plan that assumes everything will go right. Complex programmes do not work that way. A plan that cannot absorb routine variation is not a plan. It is a schedule waiting to overrun.
It is connected to the risk register. The plan shows what changes if each significant risk materialises — not as a separate scenario document, but as an integral part of how the plan represents the programme’s future. When risk R-007 materialises, the timeline moves by this much, for these reasons, and this is the decision point at which the revised timeline should be formally acknowledged rather than absorbed silently into an extended delay.
It is revisable without drama. A plan is a model of the future, not a contract with it. The future will diverge from the plan. When it does, the plan should be revised to reflect what is now known rather than maintained as a fiction to avoid the discomfort of acknowledging the divergence. A programme that cannot revise its plan without triggering a governance crisis has not built a plan. It has built a commitment structure that converts every unexpected event into a failure narrative.
The contract reality¶
Fixed-price contracts are a commercial fact of life. They require commitment before understanding and create financial incentives to maintain dates even when honest assessment suggests they are not achievable. This is the commercial context within which most engineering programme commitments are made, and the framework must address it directly rather than pretending it does not exist.
The honest position is this: a fixed-price contract date is a commercial commitment, not a delivery commitment. It represents the date the client needs, or the date the market requires, or the date the business case depends on. It does not represent the date that a genuine assessment of the work would produce — because the assessment does not exist at the point the contract is signed.
When the honest estimate arrives — when the engineering team produces their three-point assessment — it will often diverge from the contract date. That divergence is information. It is not a performance failure by the engineering team and it is not a reason to compress the estimate. It is the first honest view of the gap between the commercial commitment and the delivery reality.
What the organisation does with that information determines what happens next.
Suppressing the divergence — compressing the estimate toward the contract date, treating the risk register as a compliance item rather than a set of decision requests — produces the sequence of Chapter 1. The programme proceeds on the contract date. The risks materialise on schedule. The delivery date is missed by a margin that reflects the original divergence between the contract date and the honest estimate. The organisation has paid the cost of the delay plus the cost of operating in denial about it.
Managing the divergence — treating the gap as a programme risk, making the decisions required to close it where possible, having the commercial conversation with the client where necessary, and maintaining an honest plan that reflects what is achievable — is harder in the short term and substantially cheaper in the long term.
The commercial conversation at month one, when the honest estimate first reveals the gap, is a fraction of the cost of the commercial conversation at month six, when the delay is announced. It also produces better outcomes — because at month one, there is time to make trade-off decisions, to restructure scope, to agree milestone revisions, to find the additional resource that could close the gap. At month six, the options have narrowed considerably.
A plan that will breach the contract is not an engineering problem. It is commercial information that belongs at the level where the contract was made. The engineering team’s responsibility is to produce the honest estimate. The programme leadership’s responsibility is to treat that estimate as the decision input it is — and to have the commercial conversation it requires while there is still time to change the outcome.
Accepting a commitment¶
Accepting a commitment in the Firmitas sense is a specific act with specific requirements. It is not the passive acknowledgement of a number presented in a programme governance meeting. It is the active acceptance of a set of conditions — the risks that have been identified, the decisions that are required to manage them, the implications for the programme if those decisions are not made.
Accepting the most likely estimate without accepting the risk register is not commitment acceptance. It is number extraction — taking the number the programme will be governed against while declining the information that gives the number its meaning.
Acceptance, in practice, means three things.
The governance layer has read and understood the risk register — not as a list of items to be noted but as a set of conditions that the programme depends on and a set of decisions that the governance layer must make. Each red item is understood as a decision request. Each decision request has an owner with authority and a deadline by which the decision will be made.
The governance layer has confirmed what it is providing — the client conversations it will have, the resource approvals it will make, the decisions it will take — and by when. Acceptance is not passive receipt of an estimate. It is active commitment to the governance actions required to make the estimate achievable.
The governance layer has acknowledged the consequences of inaction — that if the decisions required to maintain the most likely case are not made by their trigger dates, the programme will trend toward the worst case, and that the worst case has been understood and accepted as the consequence of that inaction rather than as an unexpected failure.
When acceptance looks like this, the programme board meeting in Chapter 1 ends differently. The three red items do not leave the table until the decisions they require have owners, authority, and deadlines. The programme does not proceed on the contract date as if the honest estimate had not been produced. The gap between the two is visible, owned, and actively managed rather than noted and filed.
A worked example¶
The following shows the difference between a rubber-stamped commitment and a genuine one, using the programme from Chapter 1 as the basis.
The rubber-stamped commitment:
Programme board, week three. The lead systems engineer presents a three-point estimate: best case twelve months, most likely seventeen months, worst case twenty-two months. The risk register identifies fourteen items, three rated red. The programme board notes the estimate, confirms the contract delivery date of fourteen months, requests mitigation plans for the three red items, and moves to task status.
The commitment that has been made: deliver in fourteen months. The conditions attached to that commitment: none that have been formally accepted. The decisions the risk register requires: unassigned. The programme proceeds.
The genuine commitment:
Programme board, week three. The lead systems engineer presents the same estimate and risk register. The programme board engages with the three red items as decision requests.
Red item one — hardware-software interface ambiguity. Decision required: who will have the resolution conversation with the client, and by when? Owner assigned: the programme director. Deadline: end of week five. If resolution is not achieved by week five, the programme timeline moves to sixteen months minimum and a formal rebaseline is triggered.
Red item two — third-party component validation. Decision required: who will commission and fund the independent validation, and by when? Owner assigned: the technical director. Budget approved: specific amount for independent evaluation. Timeline: validation complete by end of month two. If validation fails, the architecture team is authorised to begin assessment of alternative approaches immediately.
Red item three — test environment procurement. Decision required: who will approve early procurement and what is the lead time? Owner assigned: the programme director. Procurement approved at the current meeting. Lead time confirmed: twelve weeks from approval. This puts the test environment available at month four. If delayed beyond month four, integration testing is impacted and the programme timeline adjusts accordingly.
The commitment that has been made: deliver to the most likely estimate of seventeen months, contingent on the three decisions being made and actioned within their defined windows. The contract date of fourteen months is noted as the commercial target. The programme will be managed against the honest estimate while active steps are taken to close the gap where possible. If the three decisions are made and the risks are resolved, the best case of twelve months remains achievable. If the risks materialise despite action, the programme will rebaseline to the worst case immediately rather than absorbing the delay silently.
The difference between these two scenarios is not the estimate. The estimate is identical. The difference is whether the governance layer treated the estimate as a decision input or as a number to be noted.
The principle restated¶
A commitment is only genuine when the people responsible for delivery have set the date, had the risks accepted, had the implications acknowledged, and had the plan built with slack, honest foundations, and realistic assumptions.
Presenting a plan to an engineering team and asking if it is achievable is not making a commitment. Working backwards from a desired date is not making a commitment. Noting a risk register and moving to task status is not accepting the conditions of an estimate.
A commitment made without those conditions is a target with someone else’s name on it. When it is missed — and it will be missed, because targets without conditions are not plans, they are aspirations — the accountability for missing it belongs with the people who made the target, not with the people who were handed it.
Closing the gap between the people who make commitments and the people who keep them is the central governance challenge of engineering programme management. This chapter has described the structural mechanisms that close it. The chapters that follow build on them.