The operating model comes after the system (it never does)

Choose the platform. Configure it. Then work out how the business runs on it.

It never happens in that order. A programme cannot skip the operating model. It can only skip designing it.

Because the moment a system goes live, an operating model exists. Somebody owns each step. Somebody approves the exception. Somebody decides what to do when the case does not fit. If nobody designed those answers, the vendor's default configuration supplies some of them and the people at the desks supply the rest.

Here is why it gets skipped.

Nobody on the programme is paid to do it. The vendor is paid to configure. The programme is paid to hit the date. The business is paid to run today's operation. Deciding how the business will run tomorrow sits between all three, so it falls into the requirements phase by default.

And requirements gathered without a designed future state describe the present. The team documents how things work now, the system is built to match, and the organisation gets its old way of working, automated. Old furniture, new house.

The bill arrives later, labelled stabilisation. Workarounds, a phase two, a second round of requirements for things the business needed all along.

An operating model is not a document. It is a set of decisions. Who owns this. Who decides that. What happens when the rule does not apply. Each one gets made either once, deliberately, before requirements, or a thousand times, quietly, after go live.

So the question is not whether your programme has an operating model. It does.

Who on your programme is paid to design it?