In a recent training with executives of a Fortune 500 company, I noticed — to my astonishment — that several executives couldn’t interpret Tracking Gantt charts correctly. They had just invested $400,000 in purchasing and installing Microsoft Project Server. Now was the time that a select group of time-pressured, well-educated, and highly-paid people would try making sense of charts that their new project management information system produced straight out of the box. Unfortunately, several of them failed the test, which is the reason I’ve written this article.
To keep you interested and to allow you to determine your own level of Gantt Chart literacy, I’m going to present you with some charts and ask you to interpret them before giving you my interpretation. Before we start, lets make sure that we all use the same terms, so we all start from the same starting line, making this 100m hurdle race as fair as possible. Please, refer to Figure 1, in which you see the Tracking Gantt bars reflecting one project in the portfolio.
Figure 1
The Data Date is the date on which we report the latest status and forecasts for the project. The Actual Duration is the time that has passed in the project as per the Data Date (PMBOK), or Status Date (Microsoft Project). Remaining Duration is an estimated duration to complete for the project and is re-estimated and reviewed on each periodical data date. This remaining duration should be reviewed at each status cycle and often revised. It should include all experiences and insights collected so far in the project, such as:
- Problems with the technology, systems, equipment, facilities, etc.
- Actual skill level of the team members as opposed to promised skill level.
- Performance of suppliers, vendors and subcontractors.
- The number of times that the client changes the requirements. (The latter should also be reflected in a revised Baseline Duration.)
The Actual Duration plus the Remaining Duration is also referred to as the Duration of the project, which is also regularly revised because of revisions to the Remaining Duration. The Baseline Duration is the amount of time to which the client (or sponsor) of the project has agreed. It is the target duration of the project and therefore the yardstick against which to measure the performance of the project in terms of time. The Actual Start date is the date on which the project really started. Typically, this is the date on which the first work listed in the work breakdown structure (WBS) of your project is performed. The Baseline Start is the date on which the project was supposed to start. The Finish date is the currently forecasted date on which the project is expected to be completed. The Baseline Finish is the date on which the project was supposed to end.
Competitors, Start Your Gantt Chart Interpretations…
At this point we should all be at the same starting line. The starter raises the gun and sounds the starting shot; we will start with an easy first hurdle. What does the following chart mean?
Figure 2
The only way to interpret Figure 2 is as follows: The schedule of this project is up to date and the project is on schedule. The Actual Duration is running all the way up to the Data Date and the current forecasted Finish date is still where the baseline finish date is. I hope you and I can quickly agree on this one, because the hurdles are only going to get higher from here on.
Here’s the next one:
Figure 3
In Figure 3 we can see that the project didn’t start when it was supposed to start (Actual Start later than Baseline Start). This has an impact on our Finish date, which is now later than the Baseline Finish. A good question to ask here is: Is the project diverting from the agreed upon period, the Baseline Duration? When you compare the length of the bar Duration with the length of the bar Baseline Duration, you’ll see that they’re more or less the same size, and from that perspective there’s no problem. If you’re not sure, you can check the exact numbers in the table: Baseline Duration and Duration are both 20 days. At this point, most of my executives were still in the race. I hope you also passed this hurdle; it was still an easy one, but that will change with the next one:
Figure 4
The hurdle in Figure 4 made several of my executives trip. They stated that this project was on schedule by looking at the Actual Duration bar only. As you can see, the bar for Actual Duration is, indeed, running all the way up to the data date, which to these executives meant that the project was on schedule. Silently, I thought to myself: “These executives are overpaid for their position, because they overlooked an important detail.” Other executives who are earning their pay stated that this project was running late by looking at the Finish date, which is now later than the Baseline Finish date.
My suggestion to all executives was that the Actual Duration is just what it is and what it always should be: the Actual Duration should always run all the way up to the data date. If you don’t agree with this statement, please remember that the definition of Actual Duration was straightforward: How much time has passed by in the project? There’s no indicator of performance in an Actual Duration on the summarized level of a project. On the project level, the Actual Duration always changes with time passing by. However, there’s a measure of performance in the Remaining Duration on this aggregation level. The Remaining Duration is extending beyond the Baseline Duration, and the project is forecasted to take longer than it should. You can also glean this from the bars by comparing the Finish date with the Baseline Finish date and from comparing the Baseline Duration (20d) with the currently forecasted Duration (25d). Are you still in the hurdle race? Only half of my Fortune 500 executives were still in the race at this point; elsewhere, painfully hurt bodies were scattered along the course.
Let’s take the next hurdle, which turns out to be even more challenging. What does the following progress situation mean?
Figure 5
This is the first situation in which the actual duration doesn’t run up to the data date, a situation my executives struggled with most. This hurdle turned out to be the hardest to clear. So, how should we interpret this strange situation? How can time pass by slower than it really does? Well, it sometimes happens that project managers don’t update their schedules any longer, especially when they’re falling behind in updating plans or when progress in the project is slower than it should be according to the schedule.
Getting at the Truth of a Project
The problem is that you can’t tell from the chart what’s true without asking the project manager some clarifying questions. If the project manager isn’t available, the only conclusion you can draw from this chart alone is that the forecast Finish date is unreliable, which is true in both situations. So, what we see here is that the Actual Duration is really only an indicator for the reliability and accuracy of the forecasted Finish date. If the Actual Duration ends before the data date, there are two possibilities:
- There may be unfinished work scheduled before the data date that should be brought forward to the future. The Finish date is too soon and biased optimistically. The schedule isn’t reliable, and the forecasts are inaccurate.
- The schedule may be out-of-date and we should ask the project manager to update it.
This type of situation — which isn’t uncommon — has led, I believe, to the steep ascent in adoption of Earned Value performance measurement. Earned Value doesn’t care if the Actual Duration ends before, on, or after the data date. It always provides solid forecasts for the project. Earned Value forecasts are relentlessly revealing and reliable as early as 15% into the project duration according to authoritative empirical research (as shown in Quentin Fleming and Joel Koppelman’s book, Earned Value Project Management). However, we don’t necessarily need Earned Value to provide us with accurate forecasts as long as project managers update their schedule correctly. A correctly updated schedule has:
- all completed work scheduled in the past, i.e. before the data date (often today), when the work really happened, and
- all still-to-be completed work scheduled in the future, i.e. after the data date (often today), when it will happen (if at all).
If you make sure that the network logic in the schedule is complete and correct, your schedule by itself will always produce accurate forecasts. In fact, this is the same point I first made in 2000 with the publication of the first edition of my book, Dynamic Scheduling with Microsoft Project. If you set up your schedule properly, the schedule will give you accurate and reliable forecasts.
Back in the Executive Boardroom…
There was a telling silence among our executives; they were waiting to hear from me before they were willing to jump this oddly-shaped hurdle. I lost another couple of executives on this hurdle; more injured bodies were strewn along the course. This leads me to pose the question to you: Are your executives Gantt Chart literate? How about you?
A Gantt Chart Puzzler
Here’s a puzzler for you to test your Gantt Chart expertise on. See if you can come up with the correct explanation of the status of the following portfolio of three projects, including suggested action items for the portfolio manager. To keep it simple, you should assume that each project manager has complete and correct network logic in his or her schedule. The project management office staff did their job and thoroughly checked the completeness and correctness of the network logic in these three schedules:
Figure 6
Good luck with this challenge. Once you’ve developed your answer, you can check it. Let’s see who can clear this final hurdle and win the race.
