The Difference Between Compressing a Programme and Shortening It Intelligently
Compressing a programme means squeezing the same activities into less time, and something always breaks under that squeeze. Shortening it intelligently means removing time the plan never actually needed. These are not the same exercise.
Before asking how to shorten a programme well, it is worth asking what is actually driving the pressure to shorten it in the first place, because the answer usually falls into one of two very different causes.
Where the pressure actually comes from
Sometimes the pressure is external, a client wants faster delivery, and the organisation compresses internally to please them. Sometimes the pressure is internal and arguably more dangerous, previous projects fell behind, backlogs accumulated, and now too many projects are competing for the same finite engineering capacity. Every individual project gets compressed not because anyone chose speed as a deliberate strategy, but because there simply is not enough time or people to go around. These two situations look identical from the outside, a compressed schedule, but they call for completely different responses.
How compression actually shows up in practice
Compression rarely announces itself directly. It shows up as two specific, concrete moves. The number of gate reviews gets reduced, fewer checkpoints, less frequent scrutiny. And individuals get asked to hold multiple concurrent responsibilities at once, spreading each person’s attention across more than they can actually give properly to any one of them.
Why cutting gates is the most dangerous version of this
A gate exists to stop a design from proceeding until it has genuinely satisfied the conditions of its current phase. Removing gates to save time removes exactly the mechanism that would have caught a problem before it compounded forward into the next phase. This is not a neutral efficiency saving. It is deliberately reducing the number of chances the programme has to catch something before it becomes expensive.
The cost, at two levels
This pattern produces burnout, and it is worth being precise that this happens at two distinct levels. The individual carrying multiple overlapping responsibilities burns out in the way people usually mean when they use that word, exhausted, stretched thin, unable to give proper attention to any single task. But the system as a whole burns out too, in a different and slower way. Every time this pattern repeats across another project, the organisation’s collective capacity for careful engineering degrades a little further, until fewer gates and overloaded individuals stop being an occasional emergency response and become simply how things are done.
Renegotiating the milestone honestly
Where the pressure is external, client driven, there is a genuine alternative to silently absorbing it through internal compression. The milestone itself can be renegotiated, but only through thorough discussion and honest cause and effect analysis, showing the client concretely what the original timeline actually requires, and what specifically gets lost if it is compressed instead. This is a harder conversation than simply accepting the date and hoping the team can somehow make it work. It is also the only conversation that actually protects the programme rather than quietly transferring the cost onto the people delivering it.
The real lever, developed further
Genuine speed does not come from demanding the same sequential activities happen faster. It comes from correctly identifying which activities can actually run in parallel, because neither depends on the other’s outcome, and which are sequential by nature and cannot be compressed no matter how much pressure is applied. This distinction, examined honestly at the level of the actual dependency structure rather than the schedule as originally drawn, is where real time can be found without removing anything the plan genuinely needed.
What governance actually requires
The structural answer to both causes of pressure, client driven and backlog driven, is the same. A rolling plan, actively maintained and adjusted against the client’s real programme as it evolves, rather than a fixed original schedule defended by quietly cutting whatever needs to be cut whenever reality diverges from it. Governance, in this sense, is the discipline of keeping that rolling plan honest, revisiting it deliberately rather than treating the first version as sacred and compressing everything underneath it to protect a date that may no longer make sense.
Why the plan should flex, not the people
Treating the original milestone as fixed and immovable, while compressing the gates and the people underneath it to protect that date, is precisely backwards. The plan itself should be the thing that flexes honestly, in open discussion with the client, against what has actually changed. What should never flex is the number of genuine checkpoints a design passes through, or how much any one person is actually able to hold properly at a time.