Before we talk about Primavera, let's talk about failure
Almost every engineer starts their career believing that project delays happen because of poor execution.
The concrete arrived late. The subcontractor failed. The weather was bad. The software wasn't updated.
After working on major industrial and infrastructure projects — including nuclear power plants, ports, and large EPC developments — I learned something very different.
Projects rarely fail because of execution. Most projects fail long before the first concrete truck enters the site. They fail during planning.
And understanding this idea is the first step toward becoming a Project Controls professional.
Imagine this
Imagine you're responsible for delivering a $2 billion industrial project.
You have experienced engineers. Qualified subcontractors. Primavera P6. Power BI dashboards. Daily reports. Weekly meetings. Enough budget.
Everything looks ready.
Six months later — the project is already behind schedule.
Everyone starts asking the same question: "Who made the mistake?"
The contractor blames procurement. Procurement blames engineering. Engineering blames design. The client blames everyone.
But almost nobody asks the real question.
Was the project ever realistically planned?
The biggest misunderstanding in construction
Many people think Project Controls is about software.
It isn't.
Primavera doesn't make good schedules. Excel doesn't prevent delays. Power BI doesn't recover lost time.
Software simply shows the consequences of the decisions made by people.
If the assumptions are wrong, the schedule will also be wrong. A beautiful Gantt chart built on unrealistic assumptions is still an unrealistic schedule.
Planning is not scheduling
This is probably the most important lesson in the entire series.
Many engineers use these two words interchangeably. They shouldn't.
Planning is thinking. Scheduling is documenting that thinking.
Planning asks questions like: What could go wrong? Which activities truly control completion? What risks haven't been considered? Which assumptions are unrealistic?
Scheduling simply transforms those answers into logic.
Without planning, scheduling becomes nothing more than typing dates into software.
Two silent killers hidden inside every schedule
1. Critical Path Blindness. Every project contains hundreds — or even thousands — of activities. But only a small number actually determine the completion date. Those activities form the Critical Path.
Unfortunately, many teams treat every activity as equally important. Resources get distributed everywhere. Meetings focus on minor issues. Meanwhile, the Critical Path quietly slips.
The project appears busy. Progress reports look healthy. But completion continues moving further away.
2. Optimism Bias. This is probably the most common planning mistake.
Everyone knows bad weather exists. Everyone knows material deliveries can be delayed. Everyone knows permits sometimes take longer.
Yet somehow, none of these uncertainties appear inside the schedule. The plan assumes everything will happen perfectly. Reality never does.
Good planning isn't predicting the future. It's preparing for uncertainty.
The five forces that attack every baseline
Even the best Baseline is under constant pressure. Every project experiences these five forces.
1 · Planning Gaps
The schedule says: Structural Steel Installation — 10,000 man-hours
Reality says:
The estimate was developed using productivity rates from projects in Türkiye, where the contractor had an experienced and well-established workforce.
But the actual project was executed with a newly mobilized multinational team, operating under different site conditions and productivity levels.
The work didn't require 10,000 man-hours. It required 15,500.
The schedule wasn't wrong. The productivity assumptions were.
2 · Scope Decomposition
The schedule says: Mechanical Installation — 30 days
Reality says:
At the planning stage, mechanical works were treated as a single activity.
Once detailed shop drawings were issued, the team discovered that HVAC ducts, cable trays, and fire protection piping all competed for the same ceiling space.
Additional coordination meetings, design revisions, and rework became unavoidable.
One activity didn't take longer because the crew was slow. It took longer because the scope was more complex than originally understood.
3 · Formal Changes
The schedule says: Façade Installation starts in August.
Reality says:
Halfway through the project, the client replaces the original aluminum composite panels with natural stone cladding.
The change affects far more than the façade itself. Structural engineers must verify the additional dead load. New shop drawings are prepared. Material procurement starts from scratch. Anchoring details are redesigned. Installation methods change.
A single client decision creates weeks — or even months — of additional work.
The schedule didn't fail. The project changed.
4 · Organizational Changes
The schedule says: Electrical Works — 45 days
Reality says:
The electrical subcontractor experiences financial difficulties and leaves the project.
A replacement contractor must be selected. Contracts must be signed. The new team needs time to mobilize and understand the existing work.
Meanwhile, ceiling installation, testing, commissioning, and finishing activities cannot proceed — because they all depend on completed electrical works.
One subcontractor didn't stop one activity. It interrupted an entire chain of dependent work.
5 · Environmental Factors
The schedule says: Excavation — 20 days
Reality says:
Excavation begins as planned. Three days later, the crew encounters an unexpected rock formation that wasn't identified in the geotechnical investigation.
Standard excavators are no longer sufficient. Rock breakers are mobilized. Production slows dramatically.
Or, during steel erection, wind speeds exceed the crane's operating limits for several consecutive days. The work stops — not because of poor planning, but because safety regulations leave no alternative.
Nature doesn't follow the schedule. Good planning prepares for it.
A schedule is a living model
This is where many people misunderstand Project Controls.
A schedule isn't a calendar. It isn't a report. It isn't a list of activities.
A schedule is a simulation.
It continuously answers one question: "If something changes today, what happens tomorrow?"
That's why a good schedule evolves throughout the project. A static schedule becomes history. A dynamic schedule supports decisions.
Key takeaways
Before moving to Week 2, remember these ideas:
✔ Projects usually fail during planning — not execution.
✔ Primavera is only a tool.
✔ Planning comes before scheduling.
✔ Every Baseline is constantly attacked by uncertainty.
✔ Project Controls exists to help managers make better decisions — not prettier reports.
What's next?
In Week 2, we'll move beyond the question of why projects fail and begin building the foundation of Project Controls itself.
We'll explore how Scope, Time, and Cost are connected — and why managing only one of them is never enough.
Because once you understand that Project Controls is an integrated management system rather than just a scheduling function, everything else in this series will start to make sense.
Continue reading — it's free
Sign in with Google to read the full article and access all content in the series.
No spam. One notification per week when new content drops.