Technology Operator
The programme has been green for four months. That is the problem.
The most expensive thing a portfolio company will do in the hold is usually run by a functional lead on top of their day job, reported by the people doing the work, and challenged by nobody. We run it from your side of the table.
How these programmes actually go
Recognisable from any steering committee anybody has sat on, and none of it the fault of the people in the room.
-
It is run by somebody's deputy
The finance lead's number two, on top of their existing job, unable to say no to the business or to the vendor, and carrying none of the authority the role actually needs.
-
The status is green until it is red
Reported by the people doing the work, to a committee with no way of testing it. Nothing is wrong until a great deal is wrong.
-
Scope is priced by whoever benefits from it
Every change request arrives from the integrator and is approved by somebody with no basis on which to challenge it.
-
The date moves before the reason arrives
You learn about the slip at the steering committee, which is the last place in the organisation it should be discovered.
Your integrator has a programme office. Why have another?
Because it is theirs. That is not an accusation and it is not a reflection on their people. It is a description of who they work for.
-
Their office reports on their scope
Accurately, and to their definition of done, which is a smaller thing than your programme. Everything outside the contract is somebody else's line.
-
Change requests are their revenue
You want somebody on your side of the table whose income does not rise when the scope does. That is a structural point, not a character one.
-
Nobody on your side can mark the work
Challenging a technical plan needs somebody who has built one. A finance lead cannot do it and should never have been asked to.
-
They leave at go-live
You own what is left behind on the Monday. Somebody should have been judging that against the Monday from the beginning.
What we take on
The programme, and the reporting that tells you the truth about it.
The programme
- Plan, sequence and critical path across every workstream
- Technical challenge, by engineers who have built these
- Change control, with our own view on every request
- Data migration and cutover planning
- Testing, user acceptance and go-live readiness
- The business dependencies, not only the technical ones
The reporting
- One status the board can actually act on
- Risks named early rather than escalated late
- Vendor performance against what was contracted
- Budget against scope, with the drift shown
- A steering pack written by somebody with nothing to protect
- Stabilisation after go-live, and hand-back
What changes
One person holding the plan whose incentive is the outcome rather than the invoice. Most of this follows from that.
-
A status you can act on
Written by somebody who does not get paid more when the programme takes longer, and who will say so in the room when it is going wrong.
-
Challenge on the technical merits
The plan is tested by people who have built one, before the money is committed to it rather than after.
-
Change controlled from your side
Every request assessed by somebody who does not earn from it, and priced against the outcome rather than against the contract.
-
Somebody accountable at cutover
Go-live weekend is where programmes are lost, and it is not the moment to work out who is actually in charge.
When to bring this in
Every one of these is a moment after which the same work costs more and achieves less.
-
Before the contract is signed
Scope and plan are negotiable exactly once, and it is not after the statement of work is executed.
-
Before the first slip
A programme that has already slipped is being recovered rather than run, and recovery is the expensive mode.
-
Before cutover is scheduled
The date should be set by readiness, and readiness has to be measured by somebody who is not delivering it.
-
Whenever the reporting stops being uncomfortable
A programme whose status never carries bad news is a programme where the bad news is being held somewhere.
The rest of what we run
Where to start
A two week audit. One document. No obligation.
Fixed scope, fixed price. It reads your systems and tells you what is wrong, what each fix costs, and what to do first. You keep the report either way.
What it turns up
- Licences paid for and not used
- Firewall rules nobody has reviewed since install
- Administrator accounts with no owner
- Reports built on a source that stopped updating
- An integration failing quietly, nobody alerted
What it reads live
- Licences, systems and what they cost waiting
- Network, remote access and segmentation waiting
- Cloud tenant, identity and admin rights waiting
- Core systems and how they connect waiting
- Reporting, data quality and access waiting
One document: what is wrong, what it costs to fix, and what to fix first.