A clear example is Scrum and Agile certificates. Over the past year their market has suddenly grown. People sometimes change careers after university and work in unrelated fields. But getting professional certificates that have nothing to do with your actual job is strange and mostly useless. Like being a lawyer and going to get an international dentistry certificate.

I know many colleagues with 10 or even 20 years in oil and gas, power plants, construction, roads, steel. They attended classes, paid money, got Scrum Master and similar certificates, and are still doing the same work in construction, what we call traditional project management.

What is clear to me is that Agile and Scrum were never meant for these industries and will not have a role in executing these types of projects. They do not even claim that. In Agile principles, change is not only accepted but welcomed. You do not see that mindset in construction projects where continuous scope change is not acceptable.

Knowing about these topics is useful. But spending money to get certifications in Agile and Scrum, when your past work and future plan are not in that field, is mostly wasted effort. It is following the wave created by certification pressure.

In my view, the main cause is some training institutes and some instructors creating this environment.

The situation has reached a point where some people think without these certificates they have no future. That is not true. For those working in contractor companies, these certificates will not help you, your company, or your project. The only benefit goes to those training providers.

Important point. Critical path float is not always zero. It can be zero, negative, or positive.

When do we get negative float.
If the schedule has a hard finish constraint, once one or more critical activities fall behind, negative float shows up. Negative float means you are behind the schedule. It is delay.

Question. Is negative float only during control, or can it exist at the start of planning.
Yes, it can exist from the beginning.

For example, you start planning one month after contract award. A critical early package like mobilization should have been done but was not. At the same time, the project has a must finish on constraint at the end. Right away the critical path shows negative float.

If critical activities are ahead while a hard finish exists, float becomes positive.

Is negative float important.
Very. Sometimes near mid or late stages, people ask for a recovery schedule on a job with a fixed finish. Some make the mistake of forcing all negative floats to zero. That is wrong. You lose visibility. You cannot see which activities were actually driving the delay. Critical items that needed recovery get mixed with zero float work.

Where do we usually see negative float.
Projects where the finish date cannot move. Jobs tied to specific events or official openings. Stadiums for a tournament. Government milestone dates. In these cases stakeholders will not accept any delay. The planner puts a hard constraint on the finish milestone. Once critical work slips, negative float appears. Recovery effort should focus first on activities with negative float.

Priority for recovery.
Activities with negative float first.
Then zero float.
Then low positive float.
Then the rest.

Again, forcing negative float to zero in recovery is wrong unless the baseline or finish date is changed.

Does negative float mean bad planning.
Not always. Constraints reduce flexibility and are not ideal inside the schedule, but sometimes they are required. In projects where the finish date cannot move, a hard finish is unavoidable. A stadium project for a world event is a clear case.

Negative float is called a problem because it represents delay. Not because it should never exist.

No.

But without a plan.

As much as you can imagine.

Not planning means planning to fail. Moving without a plan means you are heading straight toward failure.

I put together a list of possible questions for Microsoft Project. A few points before going through them.

These are not all necessarily perfect or fully practical questions, but experience shows even some less logical ones still come up in interviews.
This list is not complete. Other questions can always be asked.
Even if you are not preparing for an interview, going through these gives you a rough idea of your level. Assume each question is half a mark and score yourself out of 20.

Questions:

Have you ever developed a WBS and a schedule in MSP. Explain the full process step by step.
How do you transfer a WBS from Excel into Microsoft Project.
Explain calendars and constraints in MSP.
Explain Task Type and Effort Driven.
How do you create a custom calendar. For example seven working days per week and ten hours per day.
How do you define and assign a baseline.
What methods do you use to update and actualize a schedule. Explain the process from start to finish.
Explain formula writing for planned progress. Explain time weighted factor calculations in MSP.
How do you extract the baseline S curve.
How do you extract the actual S curve.
How do you extract a banana curve.
Explain grouping of activities.
How do you extract cash flow from the schedule.
Explain custom fields. How to create and use them.
How do you filter and extract two week lookahead activities.
How do you filter activities that are on the critical path, not started yet, but planned to start within the next two months.
Explain filter and highlight tools.
How is project variance from baseline calculated in MSP.
How is project delay from baseline calculated.
In the middle of a project, how do you forecast the finish date.

What method do you use for delay analysis in MSP.
How do you transfer schedules between MSP, Excel, and Primavera.
Explain resource assignment and leveling. Include leveling tools, single activity leveling, full leveling, clearing leveling, settings, and related fields.
Explain cost management in Project. Cover cost definitions, methods, fixed costs, resource costs, variable costs, cost resources, budget definition, financial and work budget review.
Explain Task Usage and Resource Usage tables.
Explain linking between two projects.
How do you extract a resource histogram.
How do you identify open ended activities.
Explain differences between planned progress and actual progress fields including Physical Percent Complete, Percent Work Complete, Percent Complete, and Percent Allocation, and how each is calculated.
How do you perform EVM calculations in MSP.
How do you show multiple decimal places for Percent Complete.
Explain how to create a custom field to show rounded activity durations.
What is your familiarity with Project Server.
Explain how to identify driving activities using Inspector.
What is elapsed duration.
Explain LOE activities.
Explain using split in tasks.
Explain inactive tasks.
Explain methods to convert dates to the Persian calendar.
Which output reports from MSP have you used.

Steel is behind. Mechanical rough in hasn’t even started in two areas. But the report still shows steady progress. No one is calling it a delay yet. Just “variance.”

That’s usually where it starts going wrong.

If the schedule isn’t telling you what actually slipped, the report turns into a summary, not a control tool. And once that happens, you stop seeing cause. You just see outcome.

We had a stretch where activities were drifting but no one tied it back to responsibility. Owner pushing changes mid sequence, consultant drawings coming in late, subs reshuffling crews between jobs. All of it hitting different parts of the schedule. But nothing broken down. Just one number at the top saying we’re a few percent off.

Doesn’t help anyone.

Because not all slippage is the same. Some of it you absorb. Some of it you price. Some of it you fight.

We didn’t separate it early enough.

Access to one workface was held up for weeks. That should have been isolated right away. Instead it just blended into overall delay. Same with late approvals. RFIs sitting too long. We kept moving crews around trying to keep productivity up, which only created inefficiencies somewhere else. You fix one area, another one drops.

Sequence starts to lose shape.

On our side, we weren’t clean either. Material came in late on one package. Small miss at first. Then it pushed a prerequisite activity. Then the next trade couldn’t start. That delay didn’t get flagged properly in the update. Just showed as slow progress.

By the time we tried to pull a delay analysis together, everything was mixed.

Owner delays, consultant delays, contractor delays. No clear boundaries. No timeline of who caused what and when. Just overlapping impacts. Hard to defend, harder to recover.

And it always goes back to the same point.

If your baseline isn’t tight, logic not clean, float not real, then every update after that is just noise. You can’t measure deviation if you don’t trust the line you’re measuring against.

Seen teams try to fix delay late in the job with recovery plans, extra crews, overtime. But if you never understood where the deviation actually started, you’re just reacting.

And usually reacting in the wrong place.

Say planned progress is 70 percent and actual progress is 30 percent.
The difference between these two is variance. This job has 40 percent negative variance from the original schedule. Just having planned and actual percentages does not tell you anything about delay.

So again. Variance is the gap between planned and actual progress. Using “delay” for this gap is wrong. Variance is tied to percentage, not time. Saying a project has 100 days variance is incorrect.

What is delay?

Take a project with a six month contract. Start is July 1. Finish is December 30. That is the planned finish. Now you update the schedule at the end of September. You enter actual starts and actual progress, then reschedule. No special constraints at the end. After running the schedule, the finish date shows February 30. Now you have 60 days delay. January and February are your delay period.

Delay is the difference between the updated finish date and the original planned finish. In Primavera after scheduling, in MS Project after rescheduling. Delay is in days, not percent. Saying a project has 10 percent delay is wrong.

Relation between delay and variance

They are not necessarily connected. You cannot judge delay from variance or the other way around. A project can have no variance but still be delayed. Or have variance with no delay.

Total progress and variance are calculated without considering activity logic or critical path. That is why some teams calculate them in Excel without relationships. Delay is different. It is fully dependent on activity logic and the critical path.

Which matters more

Both matter. They need to be reviewed through the project. But from a contractor view, delay carries more weight. The more you track delay, break down responsibility between contractor, owner, and consultant, and keep analyzing during the job, the easier it gets later when you need to justify delays and handle claims. Variance still needs to be monitored and analyzed regularly.

Delay vs acceleration. Positive vs negative variance

If the updated finish is later than planned, you have delay. If it is earlier, you have acceleration. Opposite of delay.

Variance does not have an opposite term. It is either positive or negative. If actual progress is less than planned, it is negative variance. If actual is higher, it is positive variance.

Important point. Delay, acceleration, positive variance, negative variance. All need to be analyzed during the job. Just because things look ahead or positive does not mean you ignore it. Something might be off if everything looks too good.

First thing I usually tell them, nobody taught you how to walk in a classroom. You figured it out. Fell a bunch of times, got back up, kept going. Same idea here. Before you spend money on courses, try to learn something on your own. Even basic stuff. Open the software. Break it. Fix it. Do it again. That’s where it starts.

Books helped me more than any course early on. Not the translated ones that read weird, proper material written by people who actually worked in projects. I went through them slow. Line by line. Then tried to apply it on the site. Real schedule, real pressure, subs calling, inspector showing up, weather messing things up. That’s where you see if you actually learned anything or not. If you’re not working yet, fine, make your own mock project. Doesn’t matter. Just don’t keep it theoretical. That part kills people later.

Not easy though. Takes time. And patience, which nobody has when the schedule slipped and everyone’s asking for updates. You sit there late, trying to understand why your logic doesn’t match what’s happening outside. Didn’t make sense at first. Still doesn’t sometimes.

But that process builds something. You get used to digging for answers yourself. You stop waiting for someone to show you step by step. That matters. Because on the site, problems don’t come clean. No one gives you a manual. You get half information, RFIs still open, drawings not fully issued, and you still have to make a call.

Now, if you really can’t move forward on your own, then yeah, go take a course. Nothing wrong with that. Just don’t pick based on the institute name. That’s where most people go wrong.

Look at the instructor. That’s it.

If the guy actually works in projects, deals with schedules, change orders, real coordination issues, that’s who you want. Someone who makes money doing the job, not just teaching it. Big difference. You can tell pretty fast. If the course starts with opening the software and going through menus, tab by tab, you’re wasting time. That’s not how this job works.

Good instructors don’t rush to the software. They talk about how a project actually runs. Scope gaps, sequencing, what happens when the City pushes inspections, or when winter hits and you lose productivity. Then they build a sample project and walk through it from start to finish. That’s closer to reality.

Even then, don’t expect the course to carry you. I’ve seen guys spend good money on training, stack their resumes with certificates, then come to site and struggle with basic questions. Or they get hired and can’t connect the schedule to what’s happening outside. No feel for it.

End of the day, this isn’t about which course you take. It’s about whether you can actually use it when things go sideways. Because they will. Every job.

Then there’s the scope. Half the time it’s not even there. You’re being asked to plan labour and equipment when drawings are still moving or details aren’t issued. Happens a lot on fast-track jobs. You don’t know quantities, you don’t know what you’re actually building yet. Hard to assign crews when you don’t even know the size of the foundation or how much concrete is going in. You can take a rough shot at it, sure. But it’s guesswork, and everyone knows it.

And honestly, the workload is no joke. On a big job with thousands of activities, building out resources properly takes time. Not just defining them, but assigning them, checking limits, then manually adjusting because the software never really gets it right. Then you’re updating actuals every week, tying progress to real labour, tracking equipment usage. It adds up. Fast. I’ve been on jobs where even keeping the schedule updated was a fight, let alone maintaining clean resource data.

Some of it is just messy site reality. One loader running all day, bouncing between tasks. Where do you assign it? Or a skid steer jumping between ten areas in a single shift. Doesn’t sit neatly in a schedule line. Same with scaffolding crews. Half the time that work isn’t even broken out properly, but the labour is there, moving around, affecting everything. The schedule doesn’t always capture that well.

And then the owner side. Sometimes they don’t ask for resource-loaded schedules, so teams don’t bother. Other times they do, but people hold back because they know those histograms will come back later. Questions start. “You showed ten workers here, why did you only have six?” It turns into a claims issue. I’ve seen that play out. Makes people cautious.

Still, ignoring resources completely is a mistake. What worked for us on one project was starting small. We didn’t try to load everything. Just picked a few critical items. Crane time, for example. Big cost, big impact. We tracked it properly, built a realistic usage profile, adjusted it during the job, compared planned versus actual. That alone gave us better control than most of the schedule. After that, we added more. Slowly.

You don’t fix this all at once. Doesn’t work like that. But if you don’t start somewhere, the schedule stays disconnected from the site. And once that happens, it’s just a document. Not a tool.

This is about the resistant ones. Every project manager needs a clear approach for them. The goal is to move them to supportive or at least neutral. If not, they can create serious issues. Cost goes up, time goes up, or the job can stop completely.

A few examples.

Solar plant in India.
A group destroyed solar panels. Reports said a local sect believed using solar energy would upset their sun god.
Resistant stakeholder was that group.
Result was damage to equipment and likely project failure.
The PM should have checked local culture before starting. If possible, speak with community leaders, explain how the plant works and its benefits. If not accepted, the project should not have started there.

Dashtestan petrochemical project.
Authorities went for groundbreaking and faced around two thousand locals opposing the project. Concerns were environmental permits, water supply, and wastewater disposal. The project stopped at that stage and was shut down.
Resistant stakeholders were local people and environmental concerns.
The team should have completed proper environmental studies, water sourcing, and disposal plans before site selection and early works. Results needed to be shared with authorities and the community to gain acceptance. That did not happen.

Sungun copper development.
Opposition from environmental groups due to impact on forests.
Result was full توقف of the project. Same issue.

Qazvin Rasht highway.
Old road passed through towns where local businesses depended on traffic. New highway bypassed them to make travel shorter. Most sections completed but eight kilometers near Rudbar remain unfinished. Locals opposed the tunnel route because it removed passing traffic and affected their income, especially olive sales. At times it led to conflict.
Resistant stakeholders were local communities.
Result is incomplete section after years.
The team should have planned how to address local concerns before starting. Later they tried building roadside facilities to relocate vendors, but it came too late.

Qom monorail.
Part of the route passed near a religious site. That stakeholder was not properly considered.
Result was partial execution and unfinished scope. The route likely needed revision from the start.

Zayandeh Rud water transfer.
Opposition from farmers.
Result was pipeline explosion.

Yasuj corridor project.
Opposition from landowners.
Result was full توقف.

Sivand dam.
Opposition from cultural heritage groups.
Result was heavy media and political pressure.

Snapp expansion in Kerman.
Opposition from local taxi drivers.
Result was attack on office and damage.

These cases are common. With stronger project management practice, attention to resistant stakeholders needs to improve to avoid these outcomes.

Note. The term stakeholder does not always mean someone who benefits. In many of these cases, they were impacted negatively.

Most people think planning is just knowing P6 or MS Project. It’s not. That’s the easy part. Anyone can click buttons after a few weeks.

The hard part is understanding the job. Properly.

You need to be able to read a contract and actually pull scope out of it. Not guess. Not assume. Then break it down into something that makes sense for the site. WBS that actually reflects how the work is going to get built, not some textbook structure that falls apart the moment subs start moving.

Then comes the schedule. Real schedule. Not something you build once and forget. You build it, resource it, level it, and then you fight with it every week. Because the job never follows it clean. Never.

We’ve had schedules that looked great on paper. Then winter hit, productivity dropped, a couple RFIs sat too long, steel was late, and suddenly everything shifted. Now you’re updating, reforecasting, putting together recovery plans that the site can actually follow. Not fantasy.

Cost matters too. If you don’t understand cost, you’re just half a planner. You need to see how schedule ties into money, how delays turn into overhead, how small slips become big problems. Same with risk. You don’t need fancy words. You need to see issues coming before they hit the site.

And reporting. This is where a lot of people lose it. Either too much fluff or not enough substance. A good planner tells you what’s actually going on. Clear. Straight. Where we are, what slipped, why, and what we’re doing about it.

Then there’s the delay side. Claims, time extensions, all that. If you can’t back up delays with logic and records, you’ve got nothing. You need to track properly, understand cause and effect, and be ready when things get tight with the owner or consultant.

Photos help more than people think. Same with keeping records clean. You don’t realize how valuable that is until you’re trying to prove something six months later.

Communication is a big one. You’re dealing with everyone. Site super, PM, subs, consultant, sometimes the City. If you can’t talk to people or you don’t follow up, the schedule starts drifting. Quietly.

And yeah, you still need the tools. P6, MS Project, Excel. Especially Excel. Most of the real work happens there anyway.

End of the day, this role takes time. Years. You don’t become a solid planner after a course or two. You learn it on the job, through mistakes, missed dates, pressure from management, jobs that didn’t go as planned.

I’ve seen people chase this role thinking it’s clean office work. It’s not. It’s tied to the site whether you like it or not.

And when someone actually gets good at it, really good, you don’t need to look for work. People start calling you.