Deciding where a programme's clock starts looks like a reporting convention. It is a decision about which intervals have an owner.
A board asks how long a capital investment will take, and receives a number. The number is almost always the duration of the project: from the point a team is mobilised to the point the thing is handed over. It is an honest answer to the question asked. It is also, frequently, less than half of the interval the enterprise is actually paying for.
The rest sits at the two ends. At the front is everything between the moment the organisation decided it wanted the thing and the moment somebody was appointed to build it — the case, the approvals, the financing, the queue behind three other proposals. At the back is everything between handover and the first day the asset earns money — commissioning, ramp-up, the operator learning the plant, the regulator's sign-off.
Neither end appears in the project schedule, and neither has an owner. Which is why both are where the time goes.
The Strategic Context
Kul Uppal, writing in Cost Engineering in 2002 from the engineering and construction tradition, sets the boundary further out than most schedules do. "Project cycle time," he writes, "starts with the project team formation and ends with facilities in production." [SOURCE DETAILS REQUIRED]
That second clause does more work than it first appears. It moves the finish line past handover, past acceptance, past the contractual milestone that triggers the final payment — to production. On that definition, a facility that is complete and not yet producing is not finished, and the interval between the two belongs to the cycle rather than to somebody else's problem.
He then makes an observation that undermines most benchmarking, and does it in one sentence: two projects identical in every way except one element — the site, the personnel, the system, even the season — are two uniquely different projects, and it is therefore important to take the time to recognise and plan for the differences, cycle time among them. That is a caution against the very comparison a cycle-time programme is usually built on, offered by an author advocating cycle-time reduction.
The three drivers he identifies for a delayed start are the ones that matter for this argument, because none of them is inside the project. Product research and development can delay the start, because the decision to build is often held until the research is finished. Business planning and forecasting may fail to identify the proper timing for beginning a project to meet market conditions. And external financing, joint-venture agreements and internal competition for capital affect capital availability and may create pressure to delay the start.
Research timing, market timing, capital availability. Every one of them is an enterprise decision. Not one of them is available to a project manager, who will nonetheless be measured on the segment that begins once all three have resolved.
The Measurement Boundary Is a Choice
The common misreading is to treat the project's start date as a fact rather than a decision. It is a decision, made by whoever set up the reporting, and it has three consequences.
It makes the front-end interval invisible. What is not measured is not owned, and an interval with no owner has no advocate when it lengthens. A capital paper that sat in a queue for seven months has cost the enterprise seven months, and no report will show it.
It makes the project manager accountable for the wrong distribution. Their segment is bounded by two events they did not schedule, and its duration is heavily conditioned by how much definition arrived with it. Uppal's own diagnosis of rework points straight at this: the majority of it, in his account, traces to poor definition of project requirements before the estimate was prepared, and to failure to recognise invalid assumptions behind those requirements. Both are front-end conditions, delivered to the project as an inheritance.
And it makes the back end structurally under-planned. Commissioning is scheduled as the tail of construction rather than as the head of operations, and it is staffed accordingly.
Nick Lavingia, writing a year later in the same journal, describes the front end as a formal object rather than a gap. His five-phase process runs from identifying a business opportunity, through selecting among alternatives, to developing the preferred alternative for full funding, then executing, then operating and evaluating — and he names the first three phases front-end loading, describing them as crucial in determining project success. [SOURCE DETAILS REQUIRED] The point is not the terminology. It is that the front end is a phase with deliverables and a duration, and can therefore be owned. [Related article: The Front End Owns the Outcome]
Reframing: Not a Longer Schedule, a Set of Owned Intervals
The reframing is not "measure a longer period", which most organisations will experience as an attack on the delivery function. It is: divide the whole interval into segments and give each one a name and an owner.
Four marks and three intervals. The date the enterprise decided. The date the project started. The date of first production. The date of first revenue.
The middle interval already has an owner. The other two usually do not, and appointing owners for them changes the conversation in a specific way: it stops the front-end interval being described as "governance" — a process everyone is subject to and nobody is accountable for — and it stops the back-end interval being absorbed into the project's float and then consumed by whatever ran late.
The Back End, Stated Carefully
Uppal is precise about start-up, and the precision matters because it is easy to over-read.
A successful start-up, he writes, "uses the optimal amount of time and resources to ensure that a facility is brought on-stream as quickly as possible without compromising worker safety", and it is "a balance of this invested time and resources weighted against the risks of inordinate delay". The risks he lists are safety problems, initial equipment damage, operating errors, and improper installation or design. The key to successful start-up management, he concludes, is up-front planning and early preparation during project development, and careful planning and effective execution of commissioning and start-up "can reduce the project's overall cycle time".
Read that as written: the four risks are attached to inordinate delay, not to rushing. [FACT CHECK REQUIRED] The natural executive instinct is to read them the other way — as the price of compressing commissioning — and that reading is plausible, because equipment damage and operating errors are exactly what a hurried start-up produces. But it is an inference rather than the author's claim, and it is treated as a question here rather than as evidence: for each proposed saving at the back end, which of these four risks moves, and in which direction?
What the source does support without inference is the sequencing claim. The lever on start-up duration is not effort applied during start-up; it is preparation applied during development, months earlier. An organisation that discovers commissioning as a problem during commissioning has already spent the available leverage.
The Constraint Nobody Wants to Hear
Uppal's other structural claim is the one most likely to be quietly dropped from a cycle-time programme. Recognising the root causes, he argues, leads to a second step: "true win-win relationships are key ingredients", with owner, contractor and supplier working as a team — and the reductions "can only be developed when all parties have the opportunity to enhance their performance and profitability".
That is stated as a condition, not an aspiration. Compression is available where every party can improve both performance and profitability. It is not available by squeezing a counterparty's margin, because a contractor working at a thinner return will protect it through sequence, staffing and claims — and will be right to.
This is where most acceleration initiatives fail, and they fail early. The programme is launched, the schedule is compressed, and the commercial terms are left exactly as they were. The counterparty is then asked to absorb the compression at its own cost, which it will decline to do in ways that are difficult to attribute. The compression that works is the kind that changes what a party earns as well as what it is asked to deliver. [Related article: The Terms You Cannot Buy Back]
Two Assets, Two Different Gaps
A regional airport terminal expansion, hypothetically, is decided in March, when the board accepts that passenger growth has outrun the existing pier. The project team mobilises nineteen months later. In between sit a planning approval, an aeronautical charges negotiation with the airlines, and a funding round that waited on the charges. The project then runs for two years against a schedule everybody watches closely. Reported duration: twenty-four months. Elapsed time from decision to first passenger: fifty-one. Nobody is accountable for the twenty-seven, and it is not in any report the board sees.
A data centre build, hypothetically, has the opposite shape. The front end is short, because the commercial case is straightforward and the capital is committed. The back end is where the time hides: grid connection, commissioning of the cooling and power trains, and the customer's own acceptance testing before a single rack is billable. Practical completion arrives on schedule and is announced. Revenue arrives seven months later, and the intervening period is described internally as a handover issue rather than as a quarter of the investment's payback delay. [Related article: The Work Happens Inside Functions. The Value Is Lost Between Them.]
Decision Framework
The cycle-time boundary statement. One short table on every major investment paper.
| Mark | Date | Owner |
|---|---|---|
| Enterprise decided | ||
| Project started | ||
| First production | ||
| First revenue |
Two of the three intervals will initially have no owner. Filling those two cells is the entire exercise, and it is a harder conversation than it looks — the front-end interval usually crosses strategy, finance and the approvals function, none of which is accustomed to holding a duration.
Three tests then read it.
The gap test. How long is it between decision and mobilisation, and who is accountable for that interval? Where the answer is a committee, there is no owner.
The balance test. For each proposed saving at the back end, what is being traded? Uppal's four risks are the checklist; whether they move with delay or with compression is the question to argue explicitly rather than assume.
The margin test. Does the plan require a counterparty to move faster on a thinner return? If so, the plan is a wish. Acceleration that does not appear in the commercial terms will not appear in the schedule either.
From Strategy to Execution
Immediate. Reconstruct the four marks for the last three completed investments. This is an afternoon's work from existing records, and the front-end interval it reveals is usually the single most persuasive number available for changing how the organisation reports.
Medium-term. Appoint owners for the two unowned intervals and report all three. Then move commissioning preparation into the development phase, with a named operations representative funded from the project, and treat the readiness of the receiving organisation as a deliverable rather than as an assumption. Neither change requires a new methodology; both require someone to accept a duration they previously experienced as somebody else's.
Long-term. Take the win-win condition seriously in the commercial model. Where the enterprise genuinely needs speed, structure the arrangement so the counterparty earns more by delivering it — and where it will not do that, stop describing speed as a requirement. The alternative is a portfolio of schedules that assume a compression nobody has paid for. [Related article: Which of Your Dependencies Are Real?]
Signals to Monitor
- Elapsed time from decision to mobilisation, tracked as a series. It drifts upward quietly and nobody notices because nobody reports it.
- The interval between practical completion and first revenue, and whether it is shortening across successive investments.
- The proportion of the front-end interval spent waiting rather than working — queue time, not effort.
- Whether commissioning appears in the plan before the execution phase begins.
- Counterparties declining acceleration proposals, or accepting them and then not delivering, which is the same signal in a politer form.
- Schedules being compressed while commercial terms remain unchanged.
Questions for the Leadership Team
- For our last three investments, how long was it from decision to mobilisation — and who owned that interval?
- Do we report time to first revenue, or time to handover, and which one does the business case assume?
- Who is accountable for the readiness of the receiving organisation, and is that person funded?
- When we ask a supplier to go faster, what do they earn for doing it?
- Which of our current investments is waiting on something the project team cannot influence?
- If our front-end interval has lengthened over five years, would we be able to tell?
Closing Perspective
Where a clock starts and stops looks like an administrative choice, and it is usually made once, by someone reasonable, for reporting convenience. Its effect is to distribute accountability — and it distributes it to the segment that is easiest to manage and hardest to shorten, while leaving the two segments that carry most of the elapsed time in nobody's hands.
Moving the marks does not make anything faster on its own. What it does is make two long intervals visible to people with the authority to act on them, which is the precondition for anything else. The enterprise pays for the whole duration whether or not it measures it. The only question is whether it can see the parts it is paying for. [Related article: The Estimating Loop Nobody Closes] [Related article: Value Management Is Not Cost Reduction] [Related article: How Does Work Get Into Your Enterprise Without a Decision?]
About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.