The problem is not the schedule. It is that we do not understand the task
There is a dangerous trend in modern project planning: we romanticize the schedule.
We talk about methodologies, advanced software, critical paths, probabilistic simulations, and resource optimization… yet we rarely stop to ask a fundamental question:
Do we truly understand what we are planning to execute?
You cannot plan what you do not understand.
Before logic, before durations, before Monte Carlo simulations or resource models, there is a prerequisite that is often ignored: technical clarity about the real scope of the work.
If we do not know what an activity truly involves, any duration assigned to it is an elegant fiction.
Complexity is not mathematical. It is cognitive.
In many projects, activities are defined using generic labels:
Behind each of these names lies a chain of micro-processes, technical decisions, spatial constraints, implicit risks, and hidden dependencies.
When this complexity is oversimplified, the schedule appears coherent… but it is modeling an idealized version of the work.
Planning is not about ordering tasks. It is about decomposing complexity until it becomes understandable.
The structural mistake
The real mistake is not in the software.
It is in building schedules as if activities were homogeneous, repeatable, and linear, when in reality they can be:
In infrastructure projects this becomes evident.
Pile driving in uniform soil is not the same as pile driving in geotechnically variable terrain. Installing trackers with stabilized logistics is not the same as doing it under fragmented supply. Cable installation in clear corridors is not the same as working in congested multidisciplinary fronts.
If we do not understand the true nature of the task, the schedule becomes a declaration of intent, not a behavioral model.
Complexity does not disappear because we ignore it. It simply moves into execution.
And then the inevitable happens: activities that “should” take five days take nine. Not because of incompetence, but because real complexity was never modeled.
What Brockmann brings to the discussion
In Advanced Construction Project Management: The Complexity of Megaprojects, Christian Brockmann introduces a crucial idea:
Task complexity is not defined only by how difficult it is to design something, but by how uncertain it is to execute it.
This completely changes the planner’s perspective.
Recommended by LinkedIn
When a project moves from paper to the field, complexity spikes:
Complexity evolves through stages:
Duration is not purely technical. It depends on the maturity of the system.
And complexity is not only technical. It can also be:
This is where traditional schedules start to fall short.
Implications for Project Controls
Planning without understanding the real complexity of a task is merely arranging activities.
We are not modeling the project. We are narrating an intention.
If we do not understand how complex a task truly is:
We simply draw bars.
And this is one of the most repeated mistakes in planning:
Building the schedule first… and trying to understand the work later.
The correct order is the opposite.
Closing
Schedules do not fail because the logical network is poorly drawn.
They fail when the task was never understood in its true complexity.
And no mathematical model — deterministic or probabilistic — can compensate for a superficial understanding of real work.
Because before the schedule… comes the task.
Jair Aguado Quintero. I.E, MBA, PM4R®, SpS., most orgs just skip the nitty gritty tech breakdown completely, right? That gap between "here's what we want" and "here's how it actually works" is everywhere I look.