In Part I, I argued that much of what passes for project management is really coordination and firefighting. Managers and experts who should be making technical, commercial, organizational, and stakeholder decisions are instead consumed by schedule reconciliation, resource priority fights, expediting, status meetings, and recovery from yesterday's surprises.

This raises the obvious question: if coordination is the problem, why not solve it with better models, more powerful algorithms, and more sophisticated software?

That is the subject of this essay.
‍

The Myth of Complexity

The standard explanation is that project management is difficult because projects are technically complex. They have many tasks, many dependencies, many resource types, many handoffs, and many uncertainties. As projects grow, the number of activities and relationships appears to explode. Therefore, the argument goes, we need more sophisticated planning tools, more detailed schedules, more powerful algorithms, and more elaborate software systems.

This belief has a respectable origin. Kelley and Walker were addressing precisely the difficulty of representing and coordinating the many activities involved in a large engineering project. Their solution was to make the technological relationships among tasks explicit through a project network — to separate planning from scheduling, identify the order in which activities must occur, and then use that structure to produce schedules.

But there is a hidden assumption in the way this history is often understood.

The myth is that technical complexity automatically creates coordination complexity.

That sounds plausible. But it is not necessarily true. In fact, the relationship is often the opposite. The more clearly the structure of the project is defined, the less complex the coordination problem becomes.

To see why, consider a simple thought experiment.

Suppose there are three resources: R1, R2, and R3. There are also six tasks: T1, T2, T3, T4, T5, and T6. Assume first that all three resources are interchangeable. Any resource can do any task. Also assume that all six tasks are available, and that all tasks take the same amount of time.

In the first round, R1 has six choices. After R1 chooses a task, R2 has five choices. After R2 chooses, R3 has four choices. So the first round has:

6 × 5 × 4 = 120 possible assignments.

After those three tasks are completed, three tasks remain. In the second round, R1 has three choices, R2 has two choices, and R3 has one choice. So the second round has:

3 × 2 × 1 = 6 possible assignments.

Across both rounds, the total number of possible assignment sequences is:

120 × 6 = 720.

At first, this seems to support the myth. More tasks and more resources appear to create a rapidly expanding coordination problem.

But now add structure.

Assume the three resources are not interchangeable. R1 can do only T1a and T1b. R2 can do only T2a and T2b. R3 can do only T3a and T3b. There are still six tasks and three resources, but the resources are now specialized.

In the first round, R1 has two choices, R2 has two choices, and R3 has two choices. So the first round has:

2 × 2 × 2 = 8 possible assignments.

After that, each resource has only one remaining task of its own type. The second round has no real choice. The total number of possible assignment sequences is now 8.

The structure of the work has not increased the coordination problem. It has reduced it — from 720 possible assignment sequences to 8.

Now add technical dependencies.

Suppose the tasks must be done in this sequence:

T1a → T2a → T3a → T1b → T2b → T3b

Now the choices collapse completely. At the start, only T1a is available, so R1 does T1a. Then only T2a is available, so R2 does T2a. Then only T3a is available, so R3 does T3a. The sequence continues in the same way until all six tasks are complete.

The total number of possible assignment sequences has collapsed to a grand total of 1.

This is the critical point: coordination complexity is not created by the total number of tasks in the project. It is created by the number of legitimate choices available at the point of execution.

Coordination complexity exists only when resources have choices — that is, when the number of executable tasks at a given moment exceeds the number of resources available to do them. If there is only one legitimate task available for a resource, there is no coordination decision. The resource does the task. If there are no tasks available, that is a different problem: the resource is blocked or the system has failed to make work ready. The coordination problem appears when there are multiple eligible tasks competing for limited capacity.

The more clearly the technical structure is defined — dependencies, task types, resource types, sequence — the fewer legitimate choices remain. Technical structure does not necessarily increase coordination complexity. It often reduces it by eliminating false choices.

The problem arises when we treat the project as an undifferentiated pool of tasks competing for an undifferentiated pool of resources. In that abstraction, everything appears to compete with everything else. Every task seems potentially eligible. Every resource seems potentially assignable. Every priority seems negotiable. The coordination problem becomes enormous because the structure that should eliminate choices has been stripped away.

But a real project is not an undifferentiated pool of work. It is a structured system of tasks, dependencies, resource types, technical sequences, readiness conditions, and constraints. The task of management is not to coordinate every possible choice. It is to design the system so that most choices are eliminated by structure.

This is the first simplification.

The first source of coordination complexity is excess choice: more executable tasks than available resources. If we reduce the number of consequential choices at the point of execution, we reduce the need for coordination.

But this is only the first layer.

The Real Source of Coordination Complexity

Even if the technical network is well defined, organizations still experience enormous coordination problems. The meetings continue. The expediting continues. The priority fights continue. The firefighting continues. This is true even in projects where activity networks have been carefully built, dependencies mapped, resources identified, and schedules generated.

Why?

The answer is that real project execution is not just a problem of choosing tasks for individual resources. It is a problem of synchronizing the choices of multiple resource groups in an environment of variability and uncertainty.

The first source of coordination complexity is the number of choices. The second, and more difficult, source is the synchronization of those choices.

A project task is rarely performed by one resource acting alone. Even when one group appears to own the task, many other groups may be required to make it executable. Some provide external inputs: drawings, specifications, materials, approvals, information, customer decisions, or vendor responses. Some work in tandem on the task: mechanical and electrical engineering together, operations and maintenance preparing an outage, construction and inspection working side by side. Some provide enabling support: cranes, scaffolding, paperwork, test equipment, permits, access, or specialized tooling. Some solve problems when the task does not go as expected: experts, supervisors, managers, vendors, and technical authorities.

Each of these groups has its own queue of work, its own constraints, its own local priorities, and its own understanding of urgency. And because projects operate in an environment of variability and uncertainty, the right priority can change at the point of execution. A task that looked ready may not be ready. A missing input may appear. A critical resource may become unavailable. A technical problem may surface. A customer need may change. A job that was supposed to take one day may take three.

This is where coordination becomes difficult.

The problem is not merely that a resource must choose what to do next. The problem is that many resource groups must make compatible choices at the same time, in real time. The mechanical engineer, electrical engineer, crane crew, planner, procurement specialist, inspector, paperwork support, expert, and manager must all converge on the same answer.
‍

This is the work that matters now.

If they do not, the project stalls. One group is ready while another is not. One group works on a task that another group is not supporting. One group treats the task as urgent while another treats it as routine. Inputs arrive too late. Support is scheduled for the wrong work. Experts are pulled into the wrong problems. Managers spend their day reconciling mismatched priorities

That is the real coordination problem: synchronizing priority decisions across interdependent resource groups at the point of execution, under variability and uncertainty.

This also explains why technical activity networks, by themselves, do not solve the coordination problem. A network can show what should precede what. It can identify dependencies, durations, float, and critical paths. It can make the technical structure of the project visible. But it does not automatically ensure that every resource group, every day, makes the same priority decision when reality changes

The network describes the structure of the work. The coordination burden arises from keeping many independent decision-makers aligned with that structure as conditions change.

That is why well-planned projects still generate coordination overload. The problem is not that people failed to draw the network. The problem is that the organization has not solved the real-time synchronization of priorities across the resources needed to execute the network.
‍

Why Sophistication Does Not Solve the Problem

Once the problem is understood this way, the limits of sophistication become clear.

More sophisticated models and algorithms can represent more tasks, more relationships, more dates, more resource assumptions, and more scenarios. But sophistication first runs into the data problem: the data needed to run these models are often unavailable, unreliable, incomplete, or obsolete by the time decisions must be made.

Even if the data were available, the models would still not solve the synchronization problem at the point of execution. They can improve analysis, but they cannot ensure that multiple resource groups make the same priority decision in real time as conditions change. Worse, they can create the illusion that the project is under control simply because the model is detailed.

A detailed schedule can tell each group what it was supposed to do. It cannot ensure that every group makes the same priority decision when the plan collides with reality.

That collision is constant. Materials arrive late. Drawings change. Access is not available. A test fails. A vendor misses a commitment. A key person is pulled away. One task finishes early, another runs long. The schedule may be updated, but the organization still has to answer the live question: what should we do now?

In many organizations, the answer is produced through coordination and firefighting. People meet, escalate, negotiate, expedite, re-prioritize, and chase. The result may eventually be a decision, but the cost is high. Management capacity is consumed. Expert capacity is consumed. People closest to the work wait for direction. And because the decision is often made late, under pressure, and with incomplete information, it may not be a good decision.

This is why adding more sophistication to the planning system does not necessarily reduce coordination. It may improve visibility. It may improve reporting. It may improve analysis. But if the execution system still requires many groups to independently interpret priorities in real time, the coordination burden remains.

The real challenge is not to make the schedule more elaborate. The real challenge is to make the priority decision simpler, clearer, and more synchronized at the point of execution.
‍

‍The Simplicity Principle

A simpler project management scheme should reduce both layers of coordination complexity.

First, it should nearly eliminate the number of consequential choices at the point of execution. Resources should not face a large pool of competing work every day. And if they do have competing choices, the choice should not have a material impact on project delivery.

Second, it should not require forced synchronization of the choices that remain. When a task requires multiple resource groups, those groups should not each have to continually make separate local priority decisions and then rely on meetings, escalation, or expediting to bring those decisions back into alignment.

This is the simplicity principle:

Eliminate consequential choices at the point of execution, and eliminate the need to constantly force synchronization across resource groups.

The goal is not to eliminate judgment. It is to move judgment to where it belongs.

Management and expert judgment should be used for real management work: deciding which projects to pursue, what scope to commit to, what technical approach to take, what commercial tradeoffs to make, which relationships matter, which risks are worth taking, and which capabilities must be developed. It should not be consumed by daily priority reconciliation, expediting, and firefighting.

A good system should allow ordinary execution to proceed with minimal management intervention. Not because management is unimportant, but because management is too important to be wasted on routine coordination.

The test of a project management system, therefore, is not how much detail it can contain. It is how much coordination it eliminates.

Does it eliminate consequential choices at the point of execution, protect people from constant interruption, and remove the need for forced synchronization? Does it free managers and experts to do the work they are meant to do, and allow scarce capacity to complete more projects, faster?

If not, the system may be sophisticated, but it is not effective. In fact, if it is not simple, it is not a solution.
‍

Conclusion

The great irony of modern project management is that it began as an attempt to relieve management from coordination overload. Kelley and Walker saw that when traditional planning failed, projects were left to coordinators and expediters. The Critical Path Method was created to make the structure of work visible, to separate planning from scheduling, and to help management understand where attention was truly needed.

Yet decades later, much of project management is still consumed by the very problem it was meant to solve. Managers and experts spend their time reconciling schedules, fighting resource priorities, expediting late work, and recovering from surprises. The tools have become more sophisticated, but the burden of coordination remains.

The reason is that the core problem has been misunderstood. Coordination complexity is not simply a function of technical complexity. Technical structure, when properly defined, reduces the number of meaningful choices. The first problem is excess choice at the point of execution. The second, deeper problem is synchronizing those choices across interdependent resource groups under variability and uncertainty.

That is where project management must become simpler.

The answer is not to build ever more elaborate systems for coordinating every possible choice. The answer is to design a scheme that eliminates consequential choices at the point of execution and removes the need to constantly force synchronization across resource groups. Such a system would allow projects to flow with minimal management intervention, restore real management work, and use scarce capacity to do more projects and do them faster.

Project management does not need to become more sophisticated.

It has to become way simpler.
‍

‍

Read more articles:

Why Software Has Struggled to Deliver in the Construction Industry?

How CCPM and Little’s Law Reduced Cycle Time in Aircraft Maintenance at WR-ALC?

Reducing Cycle Time by 33% at WR-ALC: A U.S. Air Force Case

Solar Projects Don’t Miss Timelines for the Reasons You Think

Critical chain project management (CCPM): why projects remain late and how CCPM actually fixes it?

Why projects are late even when everything seems managed?

Beyond fragmentation: Toyota's cell manufacturing model offers a blueprint for construction

What if our best attempts to minimize time and cost overruns in projects are pointless?

How we can solve the late project problem?

Implementing critical chain in large infrastructure projects

Part 1: Why critical chain is not a science?

Part 2: Who said critical chain is not a science?

Part 3: Let’s make critical chain a science

‍