Open your strategy document. Find the section that tells your Regional Operations Manager what to do differently at 14:00 on Tuesday. It is not there. Find the part that tells your Head of Service Delivery which KPIs they own, which decisions they are authorised to make, which SLAs they are accountable for, and how all of that maps onto their calendar. That is not there either.
This is where transformation programmes break. Not at the strategy stage. Not even at the diagnostic stage. They break at the point where someone needs to convert a board-level decision into a calendar entry for a specific person on a specific day. I call this the decomposition problem, and in fifteen years of leading operations I have never once walked into an organisation that had solved it before I arrived.
The gap nobody designs for
At a contractor business where I built a regional operation from four technicians to roughly a hundred staff, I had no legacy to work with. There was no inherited calendar, no existing rhythm, no management cadence to adapt. Every process, every quality gate, every reporting cycle had to be designed from first principles. The advantage of starting from nothing was that every activity I put into the calendar had to justify its existence. If it did not connect to a business objective, it did not go in.
That discipline, building the calendar backwards from the goal rather than forwards from habit, turned out to be the single most important design decision in the operation. When I later took over a £200m programme with 500 people across internal teams and partners, the opposite was true. The calendar was full. Meetings ran on schedule. Reports were produced. But when I traced each activity back to a goal, a large proportion of what people were doing every week served no current objective. It was inherited routine, carried forward because nobody had ever asked whether it still mattered.
Stripping out legacy activity and replacing it with goal-connected work produced visible results within weeks. The problem had never been effort. The problem was that effort was pointed at the wrong things, and the calendar was the mechanism that kept it pointed there.
Two streams, one calendar, and why that fails
Once you have your goals defined, the decomposition has to separate two fundamentally different types of work. The first is sustaining operations: recurring activities that keep the business running at its current standard. The second is development projects: changes, improvements, and new capabilities that move the business forward.
Most organisations run both types of work through the same calendar and the same management rhythm. When I arrived at a network operator preparing for a merger, the on-the-day delivery failure rate was roughly one in eight. Improvement initiatives existed on paper. In practice, every time operational pressure spiked, the improvement work was the first thing to slip. The daily firefight always won because the calendar gave it no competition. Sustaining work and development work were mixed together, and sustaining work has a structural advantage: it shouts louder.
Separating the streams is not an administrative exercise. It is a structural decision about how the organisation spends its time. When the two streams have separate rhythms, separate owners, and separate reporting lines into the management cadence, improvement work stops being optional. It becomes a scheduled commitment with the same visibility as the daily operation.
What a properly decomposed calendar looks like
The output of decomposition is not a strategy document or a project plan. It is a set of working tools that each person in the organisation can open on Monday morning and use.
Per-role calendars show every recurring activity, its cadence, and the goal it connects to. Not “the operations team meets weekly.” Rather: the Regional Operations Manager reviews installation quality data every Tuesday at 14:00, compares it against the monthly target set by the service improvement goal, and escalates deviations by Wednesday morning. That level of specificity is where most transformation programmes give up. It is also where the value sits.
A transformation plan maps the development projects against a timeline with dependencies and milestones. A schedule workbook populates every operational schedule the business needs to run properly. Operating documents define how each key process works, who owns it, and what the quality standard looks like.
Why one calendar is not enough
Most organisations treat their calendar as a single layer: meetings and deadlines. The decomposition produces something structurally different. It populates a set of operational schedules, each one answering a different question about how the business is run.
A KPI schedule defines which metrics matter, who owns each one, what the target is, and how often it is reviewed. An SLA schedule records what the business has committed to its customers and what happens if it misses. A decision-making schedule specifies who is authorised to decide what, and by which method. A reporting and communications schedule maps every report that flows between departments: who sends it, who receives it, what format, what frequency, whether action is required. Escalation schedules define what happens when something goes wrong. Succession and absence cover schedules answer who steps in when someone is unavailable. Remuneration, staff assessment, supplier management, client management, customer feedback, systems and documentation schedules each cover their own dimension of how the business operates.
In most organisations I have worked in, some of these schedules existed in someone’s head, a few were written down, and most were improvised. The decomposition makes all of them explicit, connects each one to the roles responsible, and maps the resulting activities onto the calendar. When every schedule is populated, the calendar stops being a list of meetings and becomes the operational system itself.
The test you can run on your own operation
Three questions will tell you whether your organisation has a decomposition problem.
Pick any manager and ask them which of their recurring activities connects to which goal. If they cannot answer, the calendar is running on inertia rather than design. That does not mean the manager is at fault. It means nobody built the connection.
Check whether sustaining operations and development work have separate rhythms or compete for the same time. If improvement projects keep slipping, the streams have not been separated and the daily operation is winning by default.
Ask how many operational schedules the business actually maintains. KPIs, SLAs, decision rights, escalation paths, succession cover, supplier reviews, customer feedback loops. If the answer is two or three, the rest are being improvised. A well-designed operation makes every schedule explicit and connects each one to the roles responsible.
These are structural problems. They do not require more effort or better people. They require a system that connects every calendar entry to a goal and every goal to a measurement point.
What sits underneath
Look at the Transformation System diagram that accompanies this article. Goals enter from the diagnostic findings, from any commercial strategy work, and from the leadership team’s own priorities. They are separated into sustaining operations and development projects. Activities are assigned to specific roles and mapped onto calendars across every operational schedule the business needs. What comes out is the operational infrastructure the organisation runs on: per-role calendars, a transformation plan, a schedule workbook, and operating documents.
The Decomposition Engine I have built handles the analytical weight: tracing every activity to a goal, checking consistency across roles, flagging gaps where the calendar does not cover the plan. I review, interpret, and make the judgement calls that require context no engine can replicate.
This is the part of transformation that rarely gets talked about. Finding the constraint is essential, and that is what the diagnostic does. But the harder discipline is converting what you found into what each person does differently, every day, in a way that compounds rather than drifts. That is what decomposition is for.
