The Dependency We Did Not Control
A public-sector programme at Oracle, and the fallback that meant we never lost a day.
- Systems thinking
- Anticipates risks and dependencies
- Commercially aware
- Public sector
- Where
- Oracle, for a public-sector client
- When
- 2025
- My role
- Senior Service Designer and Programme Manager
- Themes
- Programme controlsRiskDependenciesDelivery
0 days
lost while the platform ran 5 weeks late
-
01Situation
Our programme depended on a new data platform being delivered by a separate team inside the client. It was critical to us and entirely outside our control.
-
02The move
I logged the risk in week 1 with a clear trigger date, and we agreed the fallback in advance: if the date slipped, we would build and test against a mocked version of the platform.
-
03Result
The platform arrived 5 weeks late. We switched to the mock the next morning and lost no time at all. We were the only workstream that never came to the programme director with a problem.
The branching timeline
20 weeks, 2 teams, 1 trigger date. And the version where we had no fallback.
0
days lost
The situation
At Oracle I was running a programme for a public-sector client that depended on a new data platform being delivered by a completely separate team inside the client’s own organisation. That is the worst kind of dependency: critical to your success, and entirely outside your control.
What I did
I logged it as a risk in week 1, which is ordinary enough. The part that mattered was the discipline around it. I gave it a clear trigger: if the platform’s test environment was not available by a certain date, the risk would become an issue. And then I asked the question nobody in the room wanted to ask, which was, what do we do if that date slips?
We agreed a fallback in advance, calmly, while there was still time to think clearly. We would build and test against a mocked version of the platform, so that our own work could continue regardless of what the other team did.
The hard part
Agreeing a mocked fallback in advance means admitting out loud that another team might miss their date. People do not love doing that in a steering meeting. I framed it as insurance, not accusation. We hope we never use it; we build it anyway.
Outcome
About 3 months in, the trigger date passed with no test environment. And because we had already agreed the fallback, there was no panic, no emergency meeting, no blame. We switched to the mocked environment the next morning and carried on. When the real platform finally arrived, 5 weeks late, we were the only part of the wider programme that had not lost any time. The client’s programme director told me afterwards that ours was the only workstream that had not come to him with a problem that month.
The lesson
Programme controls are not about producing reports. They are about making sure that when something goes wrong, and it always does, everyone already knows what to do next.
How I found out .
Each method, and why I chose it.
WhyDependencies you do not control only surface when you ask every lead the same question, "what are you waiting on from someone else?"
The people it had to work for.
Composite and anonymised. Needs and frictions kept, names removed.
Persona 1 of 3
Our delivery lead
Owns a committed date. Depends on a team in another building with its own priorities.
- Needs
- To keep building whether or not the platform turns up.
- Friction
- Every integration test blocked on an environment that does not exist yet.
Written on the
inside cover
- The platform's dates had already moved twice before we started.
- Nobody owned the interface specification between the 2 teams, so we wrote it ourselves and used it to build the mock.
- The phrase "test environment" meant 3 different things to 3 different people until we wrote down which one we needed.
- The fallback was cheap to build and expensive not to have. It absorbed 35 days of someone else's delay.
-
“Yours was the only workstream that didn't come to me with a problem this month.”
The client's programme director, as I remember it
The paper trail.
What we made along the way, and what each piece was for.
Most of this is under NDA, so each piece is described rather than shown.
-
Risk R-01
1 card. Description, trigger date, owner, agreed response. Reviewed every week until it fired.
-
Mock platform specification
The interface we would build against if the real one was late. Written in week 2, used in week 12.
-
Switch-over checklist
1 page. What changes on the morning we move to the mock, who tells whom.
-
Weekly steering note
Half a page, same shape every week. 6 of them are in the exhibit, anonymised.
What changed, and what I keep.
- 0 days
- lost by our workstream
- 5 weeks
- the platform arrived late
- Week 1
- when the risk, the trigger and the fallback were agreed
- Next morning
- time from trigger to switching to the mock
- The only workstream in the wider programme that did not lose time, and the only one that did not bring the programme director a problem that month.
- The mocked interface became the written specification between the 2 teams, which had not existed before. Integration against the real platform took days once it arrived.
- A trigger date plus a pre-agreed response is now how I run every risk register. It turns a RAID log from a report into a plan.
- 01 Programme controls exist for the day something goes wrong. If the response is not agreed in advance, the log is just paperwork.
- 02 Name the trigger. A date turns a worry into a decision.
- 03 Frame the fallback as insurance, never as a prediction that someone else will fail.
I kept the fallback to our workstream. Other workstreams were hit by the same dependency and had nothing in place. I should have offered the mock to them in week 2.