Controlling the Project Schedule
How can we make the project finishes on time? If we make it, this is not by accident. Regular project status reports are needed to monitor the actual dates against the planned ones, to measure current and forecast variances, and to take corrective actions to get back on track.
Professional project management consists basically on involving stakeholders in the problems and seek the solutions with them. The right stakeholders here could be the members of the Project Steering Committee, or the PMO, or whoever represents the governance authority the project management team have to report.
When you forecast a final delay of 10 days, how can you save 10 days through the rest of the project? You can use schedule compression techniques like crashing o fast-tracking, or you can simply recommend scope exclusions or moving some deliverables to the next phase, for instance.
Measure and adjust continually, comparing actual dates against the project schedule baseline. Take decisions when you have the time and options are still open. Those are the key elements to finish the project on time.
Having said that, it seems that meeting the time goal couldn’t be any simpler, right? You simply have to measure variances and take corrective actions, so that little by little you ensure you finish on time.
Theoretically this is simple, in practice this is quite hard. Root causes for delays are often too many, out of control, not known in advance. Corrective actions depends hardly on the expert judgment, on the social skills of the project management team, etc.
However, as project management professionals, we need to be familiar with the schedule management terminology. Stakeholders’ opinion on our professional performance will be bad if we don’t know how to control schedule. The good news is schedule control techniques are highly standardized.
Basically, you need to know that, in order to control the project schedule, you need to control at the low level. What you need to control are called activities: the lowest lines of a Ganttt chart. Precisely, you need to control 3 couples of dates for each activity:
- Baseline Start and Baseline Finish tell us the committed dates for start and finish.
- Actual Start and Actual Finish keep record for the actual start and finish dates.
- Start and Finish are used to keep our best estimation on activities start and finish. They need to be updated whenever we have better knowledge. When actual dates are updated, then you need toy copy those values here. For instance, if an activity has started then it has to have a value for Actual Start. That same value needs to be copied to Start. For instance, assume an activity has started on Monday, then it would be inconsistent if you say that your best estimate is that this activity is starting next Thursday.
Let’s see all this more in detail by means of an example. Let’s try to imagine 5 status reports for a very simple project:
1. Kick-off Meeting
Let’s imagine we have this project. For simplification purposes, let’s assume planned duration is 10 days:
It is difficult to manage a project as a whole, so we need to decompose into activities. To simplify again, let’s have only two activities A1 and A2, 5 days each, depending Finish-to-Start, that is, A1 has to be finished before A2 can start.
Now we have the dates each activity is supposed to start and finish. Logically, if we control that these activities finishes on those dates, then the project should finish on time.
This will be our reference to compare actual data. Setting the baseline is like taking a snap shot of the project dates. In the figure above you can see each Baseline Start is set to the value of Start and each Baseline Finish is set to the value of Finish.
2. First Follow-up Meeting
Let’s imagine we have our first follow-up meeting on day 2. As you can see below, we have not started the first activity, so we need to re-schedule to start on day 3. We keep duration estimate of 5 days, so it has to finish day 7: our best A1’s estimates for Start and Finish are days 3 and 7, respectively.
Comparing to baseline, you can appreciate visually the current variance of 2 days for A1. The formula of Finish Variance = Finish - Baseline Finish.
Start for Activity A2 is also delayed because it needs to start before A1 is finished, that is, on day 8, but we estimate no final delay because we update duration estimation to 3 days, instead of 5. So the project will not be delayed (Finish = 10 and Baseline Finish = 10).
3. Second Follow-up Meeting
We have our second follow-up meeting on day 5. Let’s assume activity 1 has started on day 3. We can say Actual Start = 3. The rest of the scheduling remains the same.
If we update bottom up, we can calculate the project dates Start = Actual Start = day 3, Finish = day 10.
On the other hand, when you have actual progress, this is the case for A1, which has started already, you can express %Complete for activities and also for the project. This is calculated dividing actual duration over duration. In our case, if A1 has progressed 3 days over 5, then %Complete = 60%. Regarding to the project summary, divide 3 over 8 to get 38% as shown in the figure.
%Complete should be better understood through this example:
The formula for %Complete is:
Calculating for the example:
%Complete = (50%*5+30%*7+65%*3)/(5+7+3)= 44%
Remember: When an activity is finished, it has to have a value for Actual Finish, which should be the same than Finish, and %Complete=100%.
4. Third Follow-up Meeting
Let’s move to the third follow-up meeting on day 8. We report A1 finished effectively on day 7 as promised. A2 has progressed 1 day and we keep our estimates to be finished on day 10.
The project summary does not change regarding dates. We can update project %Complete to 75%: A1 is done and A2 has progressed 1 day over 3, so %Complete = (5+1)/(5+3) = 75%.
5. Closing Meeting
Let’s go finally to the closure report: The project finished on day 9, one day earlier than planned, due another day saved one more day.
I the following video you can see a brief summary (in Spanish):