Quantum Planning - A Plan Is Not Capacity: Why Transformation Scheduling Fails When Skills Are Missing
- Kenneth Linnebjerg
- Jul 2
- 10 min read
In a large number of transformations, planning is conducted without detailed estimation of work categories and allocated skills and capacity
The plan can look reasonable and still be wrong. There may be workstreams, teams, architects, vendors, delivery leads, product owners, roadmaps, milestones, and steering committee approvals. On paper, the transformation appears to be under control.
But then the work does not move.
A program may have architects in the organization, but not the specific architecture capacity needed by the program. Enterprise architects may be unavailable at the required depth. Department architects may be spread across many initiatives. Team architects and senior developers may understand local solutions, but not the cross-program transition. Vendor architects may support delivery, but not own the client-side transformation logic.
The schedule says work can proceed. The system says it cannot. This is one of the most common planning traps in large transformations. We confuse the existence of roles with the availability of flow capacity.
And when that happens, the plan becomes a drawing of intent — not a model of what the transformation system can actually process.
When Architecture Exists, but Architecture Capacity Is Missing
In one transformation program, the issue became visible around architecture. The program needed to transform existing catalog entities into a more central catalog direction. This required more than local solution design. The as-is architecture had to be understood. Data journeys had to be traced. New technologies had to be assessed. A transition roadmap had to be shaped. The work had to be coordinated across teams, departments, and architectural ownership boundaries.
The formal response was understandable: architecture belonged in the department.
But the practical problem was equally real: the program needed architecture as a program-level flow capability.
There were enterprise architects, department architects, and team-level architectural skills. But they were fragmented and scattered. Enterprise and department architecture had broader responsibilities and limited availability. Team-level architects and senior developers had strong local understanding, but they did not automatically create cross-program transition architecture.
Part of the catalog area was even governed through an end-of-life lens, while the program needed transformation architecture for the future catalog structure. So the program could schedule work. But it could not properly move the work.
Only when a program architect was onboarded could the work begin to flow differently. The architect could start analyzing the as-is architecture, understanding data journeys, consolidating scattered knowledge, and shaping an architectural approach, roadmap, and transition path. That was not just a staffing decision. It was a flow intervention.
Capacity Is Not Headcount
Many transformation plans treat capacity as a staffing question. How many developers do we have? How many architects? How many testers? How much vendor capacity? How many people are allocated to the workstream? These questions matter, but they are not enough.
Capacity is not the number of people assigned. Capacity is the ability of the transformation system to process a specific type of work, under real constraints, at the quality and timing required.
This depends on skills, focus, authority, timing, domain knowledge, decision rights, and cross-boundary alignment.
In the architecture example, the organization had architecture roles. But the program lacked the specific architecture capability needed to move the transformation forward. The constraint was not “architecture” as a title. It was program architecture as a function.
The Theory of Constraints helps explain why this matters. A system does not move according to its average capacity. It moves according to its constraint [1]. If the constraint is program architecture, adding more delivery capacity will not solve the problem. If the constraint is business decision-making, adding more developers will not increase flow. If the constraint is data ownership, more project reporting will not create throughput.
The system does not need more capacity in general. It needs the right capacity at the constraint.
Skill Composition Determines Flow
Transformation work does not consume generic resources. It consumes specific skills in specific sequences. Business feature definition requires business ownership, process knowledge, outcome thinking, and decision authority.
Architecture runway requires system understanding, technology knowledge, data insight, integration thinking, and the authority to shape patterns that teams can follow.
Data migration requires source-system knowledge, field definitions, ownership clarification, cleansing rules, and reconciliation criteria.
Testing requires test design, environments, test data, acceptance thinking, and defect triage.
Rollout requires local process understanding, training, support design, communication, and adoption follow-up. These are not interchangeable forms of capacity.
A person can be highly skilled and still not represent the capacity the current work needs. A senior developer may have architecture experience, but not the mandate or cross-program perspective to define transition architecture. A department architect may own the architectural direction, but not have time to operate inside the program flow. A vendor architect may design a solution, but not own the client-side transition logic.
This is why planning must understand skill composition, not just resource allocation.
Chapter 9 of Transformation Patterns introduced Quantum Types because different kinds of work behave differently. Business work, architecture work, data work, testing work, rollout work, and decommissioning work each require different readiness conditions and different skills.
A portfolio is therefore not just a list of items. It is a mixed load of work types moving through a constrained system. If the skill mix does not match the work mix, flow narrows. The narrowing may look like delay, disagreement, poor estimation, unclear ownership, or delivery resistance. But underneath, the system lacks the specific capacity needed to process the work.
Schedules Hide Queues
A schedule can show when work should happen. It cannot automatically show whether the system can absorb the work. That is where many transformation plans become misleading. They show dates, dependencies, milestones, and ownership. But they often hide queues.
A queue forms around the architect who must validate the transition approach.
Another forms around the business owner who must decide global versus local process variation. Another forms around the data expert who must explain current data usage. Another forms around the test environment, the security review, or the release manager. The work is marked as “in progress.” But in reality, it is waiting.
Little’s Law explains the relationship between work in progress, throughput, and lead time [2]. In practical terms, if more work enters the system than the system can complete, work in progress grows and lead time increases. Factory Physics adds another important point: in systems with variability, high utilization creates longer queues and waiting times [3].
Transformation work is full of variability. Decisions take longer than planned. Data is worse than assumed. Architecture is less clear than expected. Vendors need clarification. Security reviews take time. Local process exceptions appear. If all scarce roles are already fully booked, every variation becomes delay. This is why a fully utilized transformation system can be slow. Everyone is busy, but the work is not flowing.
The Calendar Is Not Capacity
One of the most dangerous planning assumptions is that calendar availability equals capacity. A person has ten hours open next week. Therefore, they are available.
In transformation work, this is often false. A two-hour architecture meeting is not only two hours. It may require reading, analysis, synthesis, stakeholder alignment, documentation, follow-up, and later clarification. A transition roadmap is not created through fragmented meeting participation. It requires continuity of thought. This is especially true for scarce skills.
An architect allocated 20 percent across five initiatives may appear fully utilized in the plan, but almost unavailable in the flow. They can attend meetings, comment on documents, and join escalations. But they may not be able to carry the deep work needed to understand the as-is architecture, trace data journeys, evaluate technology options, and define a transition approach. The calendar is full. The flow is dried up.
This is why protective capacity matters. Some roles should not be planned at 100 percent utilization if they are expected to protect flow. Program architects, business owners, data specialists, integration experts, security reviewers, test leads, and release managers need space to absorb uncertainty and make decisions before the system blocks.
Unused capacity can look inefficient in a spreadsheet. In complex transformation work, it may be the condition that makes progress possible.
Milestones Can Create False Progress
Milestones are useful. They create focus, alignment, and management visibility. But they become dangerous when they push work forward before the system is ready. A milestone may say that a feature should move into delivery. But if the architecture transition path is not clear, the feature is not truly ready.
A release plan may say testing should start. But if environments, data, and acceptance criteria are not ready, the test phase will become a discovery phase. A roadmap may show when catalog transformation should progress. But if data journeys and target architecture are not understood, the work will move on assumptions. This is false progress. The plan advances, but the work has not matured.
Chapter 10 introduced Phase Contracts as the explicit conditions that must be true before work moves from one state to another. A schedule says when work should move. A Phase Contract says whether work is ready to move. That distinction is central.
A credible milestone should not only show that an activity happened. It should show that the work has reached the maturity state the milestone claims. For architecture-dependent work, this may mean that the as-is architecture is understood, key data journeys are visible, the target direction is clear enough, transition decisions are made, and alignment with department architecture is established.
Without these conditions, the milestone is only a date with a label. Not a flow control.
Quantum Planning Must Include Decision Capacity
Plans are often created in large cycles: annual budgets, quarterly roadmaps, PI planning, release calendars, vendor contracts, and steering committee approvals. But decisions are needed continuously.
A business rule must be clarified. A scope boundary must be fixed. An architecture option must be selected. A data owner must decide a correction rule. A security concern must be resolved. A release trade-off must be made.
The schedule may be fixed early, while the decisions required to support it are made later.
This creates decision latency. Decision latency is the time between the moment a decision is needed and the moment it is made, communicated, and translated into work. When decisions are late, teams have two options. They can wait. Or they can assume.
Waiting increases lead time. Assuming increases rework risk.
Under schedule pressure, teams often assume. The work appears to move, but it moves on unstable ground. Later, when the real decision is made, the work must be corrected. This is why planning must include decision capacity. A plan should show not only when tasks happen, but when decisions are needed, who owns them, what evidence is required, and which work cannot move forward without them.
In transformation systems, decisions are not administrative details. They are flow enablers.
A Better Planning Question
The planning question should not only be: Can we fit the work into the timeline?
It should be: Can the transformation system process this work?
That question changes the conversation. It forces leaders to look at work shape, Quantum Types, skills, dependencies, decision latency, Phase Contracts, work-in-progress, and constraints. It turns planning from a calendar exercise into a flow discipline. It also changes how leaders should interpret schedules.
A schedule should not only ask, “Are we on track?” It should ask, “What must be true for this track to be real?” Where are we dependent on the same scarce people? Where does architecture runway lag behind development? Where are vendors waiting for client input? Where does the schedule assume zero rework? Where are decisions needed before the decision forum meets? Where are we starting more work than we can mature?
These questions are uncomfortable because they reveal structural weakness before it becomes visible delay. That is their value.
Transformation Plans Need Flow Capacity
Transformation programs do not fail because people are not busy enough. They often fail because the structure of work, skills, decisions, and governance does not match what the transformation is trying to process.
A program may have architecture roles and still lack program architecture capacity. It may have delivery teams and still lack business readiness. It may have vendor capacity and still lack client decision capacity. It may have a schedule and still lack flow. This is the core message of Chapter 13.
A transformation plan is not credible because it has dates. It is credible only when the system has the capacity, skills, decisions, and readiness required to make work flow.
The work of transformation leadership is therefore not only to create the plan. It is to understand whether the system can actually process the plan.
That is where planning becomes governance. And that is where flow becomes visible.
References
Eliyahu M. Goldratt — The Goal
Why it matters: Goldratt’s Theory of Constraints supports the chapter’s core argument that system throughput is limited by the constraint. In transformation work, the constraint may be architecture, business ownership, data, decisions, environments, or another scarce capability.
John D. C. Little — A Proof for the Queuing Formula: L = λW
Link: https://ideas.repec.org/a/inm/oropre/v9y1961i3p383-387.html
Why it matters: Little’s Law explains why pushing more work into a constrained system increases work in progress and lead time unless throughput also increases. This is central to understanding why transformation schedules fail when capacity is overloaded.
Wallace J. Hopp and Mark L. Spearman — Factory Physics
Link: https://books.google.com/books/about/Factory_Physics.html?id=TfcWAAAAQBAJ
Why it matters: Factory Physics explains how utilization, variability, queues, and flow time are connected. It supports the argument that highly utilized transformation systems become brittle because they lack capacity to absorb uncertainty.
Frederick P. Brooks Jr. — The Mythical Man-Month
Why it matters: Brooks’ classic work supports the idea that adding people to complex knowledge work does not create linear capacity. More people can increase communication, onboarding, and coordination load instead of restoring schedule control.
Donald G. Reinertsen — The Principles of Product Development Flow
Link: https://lpd2.com/
Why it matters: Reinertsen’s work connects queues, WIP, batch size, variability, feedback, and economics in product development. It supports the chapter’s argument that transformation planning must be based on flow, not only on timelines.
Project Management Institute — Requirements Management: A Core Competency for Project and Program Success
Link: https://www.pmi.org/learning/thought-leadership/pulse/core-competency-project-program-success
Why it matters: PMI’s research shows how weak requirements and unclear upstream definition contribute to project and program failure. In Transformation Patterns language, this supports the need for stronger readiness and Phase Contracts before work moves forward.
Comments