The fundamental problem is by the time they knew they were going to be late, it was too late to recover. If only they had a crystal ball or some kind of early warning system that told them this was going to happen early on so they had time to correct the problem.
Well, we don’t have a crystal ball but we do have an early warning system. It starts by addressing the causes of why this happens, then implementing solutions so if the schedule slips, you see it early on. Here are just some of the reasons that can cause this to happen, along with corrective solutions.
Planning too aggressively at the beginning
Problem: Nobody wants to show a late schedule to management, so durations are aggressive and manufactured to show the schedule that finishes on time. Of course, nobody believes the schedule because “we’ve never done it that quickly before”, but if we push hard enough, we’ll try and get it done by then. This is our “target schedule” (though not based on any form of reality).
Solution: Show a schedule that’s late! Not intentionally, but rather we want to show a realistic schedule, and if the durations are really unknown, be conservative, not aggressive. If there’s a gap, we want to show it now rather than later. By looking at the critical path (the tasks causing the schedule to finish late), it may cause us to change our overall strategy (buy vs. make, outsource vs. hire, change product definition) that would allow us to realistically finish on time.
The schedule is not updated
Problem: By default, schedules always want to move to the right and get later. If the schedule is not updated, these slips will accumulate weekly, and at some point, becomes impossible to recover, i.e. the gap is too big to pull-in given the number of days remaining to target.
Solution: Refresh (update & pull-in) the schedule weekly (minimum). If the schedule slips, attempt to recover the slip (we’ve seen teams not leave the room until they’ve figured out how to get the lost time back). We usually push teams to get a further pull-in. This is called “banking time”, so if the schedule slips later, we have that buffer to minimize the impact on the schedule. This is a proactive rather than a reactive approach. Pulling in before the schedule slips.
Updating long duration actives
Problem: If I’m managing a multi-week or even multi-month activity, and I slip the schedule (assuming I even know it), I know I have time to recover, so I will report on schedule. This scenario is very similar to point #2 - I will report being on schedule until the last possible moment when I know the finish date will be impossible to hit, and then I have to report it.
Solution: Breakdown the near-term asks (looking out about 4-6 weeks) into 1-5 day duration. If a task doesn’t finish on time, I will see the impact on the overall schedule. If the schedule slips, I have enough detail to determine how to pull the schedule back in (if I’m only looking at a 90 day task, I can’t see the detail or see the subtasks driving that end date, so I can’t pull it in).
Missing tasks
Problem: the activity owners have not been involved in either the initial planning or/and the schedule hasn’t been continuously scrubbed. We all know work changes over time, and the more a team learns about the project, the more the work will change. However, if the changes are not entered into the schedule and tracked, we will not be able to see the impact of those tasks on the schedule. If they would end up on the critical path (but we can’t see them), then we could end up focusing on the wrong tasks. This is a double-whammy, because since the work is not in the schedule, it is not updated and therefore we se the same effect as point #2.
Solution: The activity owners should be involved in defining their schedule. The schedule should be continuously scrubbed throughput the week, so as the project and work changes, so does the schedule.
You just don’t know how long the work will take
Problem: You don’t know how long the work will take, since experiment #2 depends on experiment #1, experiment #3 depends on experiment #2, and so on. So the schedule is planned assuming one experiment (right first time), and if it doesn’t work, you will just re-plan.
Solution: Estimate how many learning cycles (experiments) are needed (realistically/conservatively), determine the duration of each learning cycle, and plan accordingly. We have a rule of thumb that easy problems (we’ve done this before and there’s a large amount of reuse) usually need 1-3 learning cycles, medium problems (we’ve done this before but there are a lot of changes) are usually 3-5 learning cycles, and hard problems (we’ve never done this before) are 5-7 learning cycles. The team usually knows whether it’s an easy, medium or hard problem.
Lying - or not telling the truth
Problem: If I’m managing my part of the program and the schedule slips, I may not want to report the slip (as this is “bad”), in which case, I will report “on time” and hope I will make it. Again, I don’t see the slips early and they accumulate until at some point I go past the point of no return and to becomes impossible to recover.
Solution: Education and training. It is important all team members understand that we are looking for honesty and transparency, Nobody will get “beat up” if a slip is reported, but the focus becomes finding a solution to recover from the slip. Breaking down the near-term, long duration tasks into 1-5 day duration will go a long way, since activity owners will have to report back each week whether they completed the task.
There are many other reasons why the schedule can appear “on time” until the end and then slips, but these are the main ones. To implement these solutions requires both training and coaching a project team.
