
The constraint here is almost never technical. It is a procurement calendar, a committee date and a change of minister, and a plan that cannot survive all three is not a plan. We scope every stage so it is defensible on its own, and so the next one is a decision rather than an obligation.
What we do here
The lines that matter most in this sector, and why.
Working to a calendar we do not control
Every stage stands on its own, because the next one may not be funded.
Working to a calendar we do not control
Every stage is scoped so it is independently defensible if the next one slips a cycle, because it will. A program that only makes sense once all six phases are funded is a program that stops at phase two and leaves nothing behind. Each of ours has to be worth having on its own.
What we plan around
| Constraint | How the plan absorbs it |
|---|---|
| Procurement cycle | Stages are sized to fit inside one, and to stand alone if the next is delayed |
| Committee dates | The plan is built backward from them rather than discovering them in month four |
| Staff turnover | Documentation is a deliverable at each stage, not at the end, so a departure is not a reset |
| Statutory retention | Established before anything is proposed for retirement, with legal signed off in advance |
Questions we are always asked
Four of them, answered the way we answer them on the phone.
Can you work inside our procurement framework?
Yes, and we scope to it rather than around it. Work is broken into stages that each deliver something usable, so a framework that only lets you commit to one of them still leaves you with something in production.
What happens if the funding round changes?
Nothing already in production is affected, which is the entire reason the work is cut that way. A stage that cannot be defended on its own was scoped wrongly.
What if the committee date moves?
It usually does. Dates we control are planned against dates we do not, and the sequence is built so a slip postpones the next decision rather than unwinding the last one.
Can our existing suppliers stay involved?
They generally have to. We sell no software and resell no licenses, so we have no commercial reason to displace anyone already delivering.
Case studies
Programs in this area, described by what they were rather than by who paid for us.