The steering committee has a pack. It is a good pack. Someone talks through the amber status, which has been amber since roughly the middle of March, and there is a slide about mitigation with four bullets on it.
Then the Chief Information Officer asks whether we are hitting the date.
Nobody answers. The programme director looks at the delivery partner. The delivery partner looks at the plan. Eventually somebody says they will come back with a view by Friday, and everyone writes it down, and the meeting moves on.
I have watched that happen more times than I would like. The usual conclusion in the car park afterwards is that the PMO needs sorting out. Better people. Tighter grip.
My view is that the PMO in that room was set up to fail about two years earlier, and nobody noticed at the time because it looked like a sensible order to do things in.
Business case approved. Scope signed off. Procurement run, partner chosen, contract executed. Then mobilisation starts and somebody raises governance as a workstream.
By that point you have already settled who delivers this, what the contract covers, what you have promised your board, what budget you have, and where your obligations end and your partner's begin.
Those are governance decisions. You made all of them before you had anybody whose job was governance.
Which leaves your PMO with the residue. It can track a plan it inherited. It can chase people. It can build the pack. What it cannot do is change any of the things that will actually determine whether this programme works, because those are now written down and signed.
You end up with a function that makes everybody feel managed while nobody is accountable. Plenty of meetings. No grip.
Eighteen months later you find out what this cost you.
Your business has a picture of what it is getting. Your board has a slightly different picture. Your delivery partner has a contract, which is a third picture. Early on these three sit close enough together that nobody worries.
They come apart slowly. A design decision goes one way rather than another. It is minuted correctly, signed off by the right person, and written in language that means something precise to an SAP consultant and nothing much to anybody else. Multiply that by a few hundred over a year.
Then a finance manager sits down in UAT and cannot find a process she was certain was in scope. She is right that it was in scope. It stopped being in scope last October.
That gap did not open in testing. It opened the week scope was written, when three groups read one document and formed three understandings of it, and there was nobody present whose actual job was to spot the difference.
Your PMO cannot fix that. Fixing it means reopening things that are contractual now.
I spent a long time working inside systems integrators before I started Limelight, and I want to be careful here because this is where people expect SI-bashing. Most delivery partners are doing precisely what they were engaged to do. The difficulty is that the engagement was written by an organisation that had no independent governance capability at the moment it was writing it.
Finding somebody who can genuinely run one of these is hard.
You need a person who understands the technology well enough to ask an awkward question and understands the business well enough to know which awkward question is worth asking. They also need the nerve to tell a steering committee something unwelcome while the delivery partner is sitting there.
Most organisations recruit from one of two directions. Either a strong programme manager who does not know SAP, or a functional expert who has never run a programme. Both of those can work. Both of them tend to come unstuck at the same points, which are the go-live decision, the contract dispute, and the meeting where somebody has to say the unpopular thing.
So hire well. But if you hire brilliantly into a function that has no authority, you have bought yourself a very well-run administration department, and eighteen months from now you will be in the car park having the same conversation.
Stand your governance up before you choose your delivery partner.
That reads like a scheduling preference. It is the largest single lever available to you on the whole programme.
It puts the people who will carry the can in the room while scope is being written and while the business case is being built. Your decision rights, escalation routes and RAID process become inputs to the contract rather than something bolted on afterwards. And when the three pictures start coming apart, somebody is there who was present when you agreed what you meant.
Harrods worked this way. Limelight came in before there was a delivery partner. We ran the procurement and the RFP, helped choose the vendor, and then took on the workstreams where client-side control mattered most.
Plenty of firms are good at PMO. What was different at Harrods is that governance existed before there was anything to govern.
There are three answers a CIO usually gets offered.
Your systems integrator will happily run programme management. They will do a competent job of it. They are also the party being governed, and professionalism does not resolve that.
A big four firm will give you oversight and a well-argued opinion. When the go-live call arrives you will get a recommendation. You will still own the decision.
Or you build it in-house, which returns you to the talent problem and to the timing problem at the same time.
None of those three is an independent, client-side function that owns real workstreams, carries accountability for delivering them, and exists before you pick your partner. That absence is why Limelight exists. We do not implement SAP, deliberately, because it is what allows us to sit on your side of the table when the conversation turns difficult.
If you have not appointed a delivery partner yet, you are in the most valuable window this programme will offer you. It does not stay open long. RunFast Launchpad is built for exactly that window: business case, scope, governance framework, decision rights, RAID structures, partner selection, all completed before you commit to the expensive part. Eight to twelve weeks in most cases.
If your partner is already on site and some of this felt familiar, that is a different and more urgent conversation.
Something worth doing this week either way. Take the last five significant decisions your programme has made and find out where each one was actually settled. Some of them will turn out to have been settled in a room your PMO was never invited to. That is your problem, and it is a fixable one, but not by hiring another project manager.