My Schedule Keeps Slipping...
/This is a question we have heard countless times. The schedule is constantly slipping. The Project Manager (PM) is blamed for not managing the team. The team is blamed for not sticking to the schedule. The management is blamed because people are working on too many projects and there's not enough time in the day to do them all. The most important project is the one that's the latest or in crisis mode. I could go on...
But is the schedule really slipping or is just moving from an unrealistic (aggressive) schedule to a more realistic schedule, i.e. reality is catching up with the team? A PM has (sometimes, anyway) a Microsoft Project schedule that is neither technically correct (not updated, has technical errors such as tasks not being linked) nor realistic when it was developed (often alone in the PM's office and shared with the team). The schedule does not reflect what is actually going on and what the team believes at that moment in time. Even worse (and unfortunately more common), the schedule is in Excel (tasks with dates) or PowerPoint. In either case, the impact of a change in the schedule cannot be easily seen on all dependent tasks.
So how can the schedule get back on track? The fundamental problem is the the schedule is not realistic so the real gap is not known, so the first thing that needs to get established is the real schedule, i.e. a critical path schedule the team feels they can hit based on all the knowns and unknowns at that point in time. The schedule is then compared with the target (when it's needed by) - this is the gap. With a critical path schedule, you can understand what is driving the gap and then engage the team in determining how to close the gap.
There are two primary areas that determine the quality of a schedule, i.e. a schedule that is feasible given what is known at that point in time:
Have a technically correct schedule
The majority of schedules we see have errors such as not being updated, missing dependencies, date constraints in the future, negative float, etc. We have identified a total of 15 problems that could cause an incorrect schedule and hence an incorrect critical path.
Have a realistic schedule
This comes in four forms:
Not building in enough learning cycles. Most projects have to go through several iterations of learning. The number of learning cycles depends on the complexity of what you are trying to learn. If this is groundbreaking development and has never been done before, then you will need many learning cycles (5-7+). If you are tweaking something that already exists, then you will need only a few (1-2). For truly innovative projects where a proof of concept is needed first, we would build a schedule where the incremental milestones are "learning milestones". When the concept is proven, we would then develop a schedule based on product development milestones. One problem we see is teams mixing these two up.
Learning cycle duration. Even if the number of learning cycles is planned, it's critical the duration of each learning cycle is a realistic duration. Learning cycles are typically longer at the beginning as the team is learning and get shorter over time as the unknowns turn into knowns.
Accounting for Risk. It is important that major risks are identified and put into the schedule. These could be in the form of extending the duration of existing tasks or adding new tasks such as risk mitigation tasks.
Engage the team in building the schedule. This is often overlooked but is key to getting a team to take ownership of the schedule. The schedule should be the team's, not the PM's.
Of course, no planning system is perfect and will allow you to accurately predict an end date, especially in today's hi-tech world where teams are dealing with many unknowns. Over the years, we have observed the problems are getting harder to solve, so game-changer products are taking longer to develop, while at the same time the team is given completely unrealistic target dates to meet.
Following the process above (building a realistic schedule and identifying the gap) gives the team a starting point for a discussion of reality. If the gap is very large, it could mean redefining the project, redefining the targets, outsourcing, buying (vs. doing yourself) or possibly even killing the project. On the last point, this should to be seen as a failure but as a success as it saves the company spending resources and money on a project that is doomed from the start. This "reality discussion" is always best done at the beginning of a project while there is time to take corrective action (unfortunately, we are usually brought in near the end when the options for acceleration are more limited).
Even with a schedule that the team agrees is roughly aligned with the target date (there is still usually a gap), the schedule is worthless if it's not kept up to date. This means tracking it on (at least) a weekly basis, capturing actuals vs. the original estimates, and constantly walking the critical path and identifying things that can be done to pull-in the schedule (what we call refresh planning). Even though there is a gap at the beginning of a project, the goal is to close the gap over time (this is why one of the metrics we use for the health of a project is seeing how much we need to pull-in to hit target vs. how much time is remaining). The schedule should always represent what the team believes is realistic at that point in time, so as well as refreshing the schedule, the schedule has to be constantly scrubbed with the team to incorporate the latest thinking
Updating the schedule and incorporating the team's thinking on a weekly basis means the schedule will change weekly. The question now is - is the schedule slipping or is it pulling in over time? What is the trend over the past 4 weeks, 8 weeks? This is another critical piece of information that can help the team make decisions and take corrective action along the way.
Even if the schedule looks impossible to hit the target, fortunately, we have additional tools in our toolbox. One of these is called the Challenge process, and we have had a lot of success in pulling-in schedules that seem impossible to pull-in. In fact, this method works best when the team is stuck and can't find anyway to pull the schedule in further. The Challenge is a facilitated workshop (either 1/2 day, 1 day or 2 days, depending on the complexity of the problem being solved) that challenges the current thinking and assumptions about the project. It's deceptively simple but extremely powerful. We have achieved pull-ins of many months when the team was struggling to get even a day out of he schedule.
Of course there are other concepts such as schedule structure, team structure, ownership, empowerment, rapid decision making, etc. that all affect time to market. But these aside, if there is one thing that we have learnt over the years is that a team will always strive to beat their own schedule. They will rarely beat somebody else's schedule. It seems counter-intuitive, but a team that works to their own (usually late) schedule will work to hit or beat the target date because they own the problem. A team that is given an unrealistic schedule will disown the schedule and work to their own schedule anyway. Nobody will never know the real schedule and the discussions that are need to accelerate the schedule will not take place because reality is hidden.
See also When to stop dreaming.