There is a wonderfully reassuring moment in project management when you open your project plan and everything appears to be behaving itself. The milestones are still roughly where you expected them to be, the completion date hasn’t disappeared over the horizon, and there isn’t a forest of red warning symbols demanding your attention.
You take a look, perhaps make a couple of small adjustments, save the plan and think, “Good. We’re basically okay.”
Unfortunately, that may be precisely the moment when you need to look a little harder.
I’ve spent a large part of my working life managing projects, teaching project managers and showing people how to use project management software. One lesson I’ve learned over the years is that a healthy-looking project plan doesn’t necessarily mean you’ve got a healthy project.
There’s nothing wrong with the plan. The problem is that it can only tell you about the things you’ve managed to put into it, whereas some of the things most likely to hurt your project may be happening somewhere else entirely.
Why a Green Project Plan Can Give You False Confidence
Let me make one thing clear before I upset all the planning enthusiasts. I’m certainly not suggesting you throw away your project schedule and manage everything using instinct and a packet of sticky notes.
A properly constructed schedule is enormously valuable. It helps us understand the work that needs doing, how long that work should take, which activities depend upon others, where our resources are being used and whether we’re still heading towards the required completion date.
The danger comes when we begin to mistake that schedule for the project itself.
Imagine that an important activity is due to begin next Monday. Its predecessor is complete, the required resource has been allocated and there’s enough time available to complete the work. As far as your project plan is concerned, everything looks fine.
But perhaps the specialist you’ve allocated has just been dragged onto another senior manager’s emergency project.
Maybe the customer who needs to approve the output is becoming increasingly unhappy about something that hasn’t yet reached you. Perhaps a supplier has quietly warned procurement that delivery dates are getting tight, or your technical team has discovered that an assumption made three months ago may no longer be true.
None of those things necessarily makes your project plan turn red today, but any one of them could make your project turn very red next month. That’s the gap I want you to start looking for.
Your Project Is Much Bigger Than Its Schedule
This matters more than ever because projects are becoming increasingly complex, and when I say “complex”, I don’t simply mean that your schedule contains 4,000 activities instead of 400.
I’ve seen relatively straightforward schedules attached to extremely difficult projects because the real complexity wasn’t in the activities. It was in the environment surrounding them.
Your project sits inside an organisation and involves people with different priorities.
It may depend upon suppliers, customers, regulators, technology, other projects and departments that you don’t control. Somewhere above all of that you’ve probably got senior managers changing business priorities while you’re trying to keep everything moving in roughly the same direction.
That’s why experienced project managers gradually develop a different way of looking at their plans. Of course they still want to know whether the project is on schedule, but they also want to understand what’s changing around the project that might eventually make that schedule wrong.
That second question is where some of the really useful project management begins.
Trouble Often Starts Somewhere Your Gantt Chart Can’t See
Let’s imagine you’re four months into a twelve-month project and, according to the schedule, you’re doing rather well.
Over the past couple of weeks, however, you’ve noticed a few things.
One of your key stakeholders, who was enthusiastic at the beginning, has stopped turning up to meetings. A department that promised resources is becoming increasingly reluctant to release them when you need them. Your supplier keeps assuring you that delivery will be “fine”, although you’ve noticed nobody seems willing to give you a firm date.
Meanwhile, the customer has started mentioning a new requirement which isn’t part of the agreed scope. OUCH!
Individually, none of those things may be enough to move your project completion date today. Your schedule can therefore remain perfectly healthy while the project underneath it is quietly becoming less healthy.
The experienced project manager learns to recognise those changes before the project plan catches up with reality. By the time your schedule finally tells you there’s a problem, you may already have lost the cheapest and easiest opportunity to do something about it.
Dependencies Have a Nasty Habit of Hiding
Most project managers understand the obvious dependencies. Activity B can’t start until Activity A has finished. That’s easy enough to see, and your scheduling software will happily show it to you.
It’s the less obvious dependencies that tend to catch us out.
Perhaps your testing team assumes the customer will provide some data by a particular date, but nobody has actually checked whether the customer knows they’re supposed to provide it.
Maybe an external contractor needs access to a site, while somebody in another department is responsible for arranging the security clearance. Perhaps your technical team is waiting for a management decision that everybody knows needs making, but which isn’t actually shown anywhere in the schedule.
None of these is necessarily a scheduling problem yet. They’re dependencies waiting to become scheduling problems.
One of the simplest habits I’ve developed is occasionally to forget about the dates and ask the team what we’re waiting for from somebody else. I then want to know whether that person actually knows we’re waiting for it. It’s astonishing what that simple conversation can uncover.
Assumptions Can Quietly Turn Into Facts
I’ve written elsewhere about project assumptions because I think they’re one of the most underestimated sources of trouble on a project.
Every project contains assumptions. It has to, because we’re trying to plan something that hasn’t happened yet. The problem starts when something we assumed three months ago quietly becomes accepted as a fact simply because nobody has challenged it since.
Perhaps we’ve assumed the supplier will have enough capacity, the customer will approve something quickly or we’ll get the specialist resources when we need them. Maybe we’re relying upon a new system integrating happily with an old one.
There’s nothing necessarily wrong with any of those assumptions when they’re first made. They may be perfectly sensible based upon what we know at the time. But projects change, organisations change and the outside world certainly changes.
If an important part of your project plan depends upon an assumption, go back occasionally and ask whether that assumption is still reasonable. You don’t need another enormous workshop or a twenty-page document. Sometimes a five-minute conversation with the right person is all that’s required, and that five-minute conversation may save you several painful weeks later.
Listen to What People Are Telling You Between the Meetings
This is where project management becomes much more of a people job than a software job.
Some of the most useful information you’ll ever receive won’t arrive through a formal report. It will appear in an ordinary conversation when somebody says they’re not sure you’re going to get that engineer after all, or casually mentions that the customer didn’t sound very happy yesterday.
A supplier might tell you they’re “still aiming for Friday”. Someone in finance might ask why the expected benefit appears to have changed. A team member may mention that another department is suddenly asking a lot of questions about the project.
None of those comments necessarily requires you to leap out of your chair and call an emergency meeting, but they’re worth hearing.
Experienced project managers develop very sensitive antennae for comments like these because informal signals often appear before the formal project data changes. You hear something, ask another question and perhaps make a quiet phone call to find out what’s going on.
I’ve always believed that this is one of the great strengths of a good project team. Your dashboard is excellent at telling you what has already happened, but the people around your project can often tell you what is about to happen.
Don’t Confuse Reporting the Project With Managing It
This is a particularly easy trap to fall into now because our project management tools have become so sophisticated.
We can create beautiful dashboards, calculate performance indicators and automate reports. AI can summarise meetings, analyse information and help us spot patterns that would once have taken hours to uncover. I’m all for it. If technology can take some of the boring administrative work away from the project manager, bring it on.
But none of that removes the need for judgement.
Your dashboard may tell you that schedule performance is within tolerance, but it won’t necessarily understand that your sponsor is gradually losing enthusiasm for the project. It may not realise that two departments are quietly fighting over the same specialist resource, or that what appeared to be a minor regulatory change is about to affect your business case.
That’s why I don’t see modern technology replacing good project managers. I see it freeing them to spend less time compiling information and more time understanding what that information actually means.
And frankly, that’s where I’d rather have my project manager spending their time.
Try Looking Forward at Your Next Project Review
Here’s something you can try without buying anything, installing anything or changing your project management methodology.
At your next project review, don’t spend the entire meeting looking backwards at what happened last week. Once you’ve dealt with the normal progress information, turn the conversation around and ask your team what worries them about the next four weeks.
Then give them the space to answer properly.
You’re not asking them to conduct another formal risk identification exercise. You’re simply giving experienced people permission to tell you what their instincts are saying.
Someone may be worried about an upcoming technical decision. Another person may be concerned about workload. Somebody else may have noticed that a stakeholder is becoming difficult, or that a supplier isn’t sounding quite as confident as they did a month ago.
You can then investigate those things while there’s still time to do something useful about them.
For me, that’s proactive project management. You’re not waiting for the dashboard to tell you that something has gone wrong. You’re looking for the early signals that something might.
The Project Plan Is a Model of the Future, Not a Promise
Perhaps this is the most important point of all.
Your project plan isn’t a prediction carved into stone. It’s your best current model of how you believe the future will unfold, based upon the information available when you created or last updated it.
As the project progresses, you learn more. You discover that one activity is easier than expected while another is considerably harder. You understand your stakeholders better. Risks change, assumptions are confirmed or disproved, suppliers give you better information, customers change their minds and the organisation around you moves on.
A good project manager takes all that new knowledge and continually compares it with the plan.
The question isn’t simply whether the plan still says you’re going to finish on time. The more useful question is whether everything you now know about the project still gives you confidence that the plan is realistic.
That’s a much richer conversation.
What to Do the Next Time You Review Your Project
The next time you sit down with your project plan, resist the temptation to begin by staring at dates and coloured indicators. Spend a little time thinking about the actual project first.
Think about the conversations you’ve had recently, the assumptions you’re still relying upon, the things your team is waiting for and the stakeholders whose behaviour may have changed. Consider whether anything is happening outside the formal project boundary that could eventually find its way into your schedule.
Then open the plan. I suspect you’ll look at it slightly differently.
You may conclude that everything really is fine, in which case excellent. But if you spot something that deserves attention, you’ve found it while you still have choices about what to do.
Over many years of managing and teaching project management, I’ve come to believe that’s one of the biggest differences between simply monitoring a project and actually managing one.
Keep Developing Your Project Management Judgement
Processes, tools and techniques matter. I wouldn’t have spent so many years teaching them if they didn’t.
But the really good project managers learn something beyond the mechanics. They develop the judgement to recognise what matters, ask better questions and act while they still have options.
That’s the thinking I try to bring into my project management training at Projex Academy. If you’re developing your professional project management skills, preparing for a qualification such as PMP or simply trying to become better at handling real-world projects, you’ll find my training there.
Because the best time to discover that your project is in trouble isn’t when the dashboard finally turns red.
It’s while everything still looks green.
Check out our Projex Academy Project Management Masterclasses here
