Project scheduling is a difficult art as anyone who has practiced it understands. At the same time it is one of the most common reasons cited among the causes of project failures. There is great debate over the best methods for making good plans and especially over the level of detail that should be specified in any given project plan.
In most cases project planning is a time consuming activity. Even the most experienced project managers and planners find themselves having to re-plan projects as a result of unexpected events during execution, sometimes more than once. Great efforts are expended with, based on the public research, very little effect on making projects go smoothly and finish on-time, on-scope and on-budget.
But there is much more effective way for organizations to plan their projects, a way that takes less time and delivers far better results with very little re-scheduling. To reach this much better way requires answering two critical questions:
How do we plan for the inevitable uncertainty in projects?
To what level of detail should projects plan go?
Planning for uncertainty is one of the greatest challenges any project manager or executive faces. On projects uncertainty is the way of life: the specifications can change, the required needed can change, the work content can change, resources may be occupied elsewhere when needed, work can be delayed, tasks can take longer than expected, approvals can be held up, along with a host of other variables that can throw the best conceived plan into chaos.
It would be easy to plan for uncertainty if time didn’t matter. Adding lots of safety buffers would enable us to provide for any eventuality. Unfortunately, in most environments, time does matter, and it usually matters a great deal. So the challenge is how to provide for uncertainty, and still plan projects to complete as fast as possible?
The common approach of planning projects is to insert safety time into each task in the plan. If task managers are asked to estimate durations, they will typically estimate them with some degree of safety factored in. This is especially true if the organization holds them accountable to hitting their task estimates. It also makes good sense, since we cannot have a reliable project plan if every estimate is the minimum possible time to do a task. Even organizations who feel as if their task estimates are super-aggressive will find if they check that there is still considerable safety time embedded in task estimates.
Often additional safety gets added at management levels as they pass their estimates upward. Again the same motivation is at work, the need to provide realistic estimates that they can meet. There is also the awareness that often times people’s estimates will be cut anyway, so adding safety time is essential to insure that you will end up with task times that still account for uncertainty.
There are several problems with inserting safety time into tasks. The first is that it is hard to see how much of it has been used at any given point in time during execution. The second is that the safety time, once put into the task, typically gets wasted in two possible ways. The first is something we all know from school—the student syndrome. When the test is still far off there is little urgency to start to study. In projects this means that there is little urgency to start a task when it becomes available, because “we still have plenty of time.” The second way safety is wasted is through Parkinson’s Law—the work expands to fill the time available. People will continue to “polish” their work right up to the day it is due. And in most organizations there is also a strong dis-incentive to finish a task earlier than planned, because the next time management will expect the same “faster” time.
So while we definitely need to plan for safety time to cope with the uncertainty of projects, embedding this time in the tasks themselves almost insures that it will be lost. The better strategy by far is to remove the safety time from the tasks (we start by cutting all current task durations by 50%) and to place it in a buffer at the end of the project. By placing the safety time at the end of the project (after the last task) several benefits result:
The safety time is available to anyone on the project who might need it (since it’s not embedded in a task and is at the end any delay can consume the buffer).
The safety time is visible and we can tell at any given point how much of it has been consumed and how much is still available to protect against delays.
The safety time can be used to manage priorities within, and across projects (tasks whose buffers have been more fully consumed take a priority over ones whose buffers are larger as a percentage).
We neutralize the Student Syndrome and Parkinson’s Law by increasing the sense of urgency to start and reducing the time available at the end of a task to be absorbed by the work.
We actually need less safety time in total so we can trim some of it and reduce our overall project durations. (The chance that something will go wrong on any given task in the project is very high, but the chance that something will go wrong on every task is very low. So by aggregating the safety time at the end of the project, we actually do not need all of it and can reduce it—again we typically cut it by 50%)
While this answers the first question of how to plan for uncertainty, it does not address at all the second question around the proper level of detail for the project plan. In an effort to get a better handle on uncertainty, and to promote better project discipline, most project plans contain a high level of detail, at least much higher than we recommend. Another reason for putting a high level of detail into the project plans is to detail the work that needs to be done so that tasks do not get missed and will ultimately match up to the required specifications.
By putting each detailed step of the work as a task managers are almost guaranteeing that they will need to re-plan at some point during the project, if not many times. The main culprit again is uncertainty. When we try to detail every little step and there is a change (in the specifications, the features, the research, a failed test that needs to me repeated, etc.) the plan as it was originally conceived becomes invalid. We know that this uncertainty will hit us, but know one, even the best project managers, knows when or how it will hit.
There are two elements of the solution. The first is to greatly reduce the level of detail in the project plans. By specifying tasks at a much higher level we greatly dampen the likelihood that the plan will need to be re-written. In any event the buffer at the end of the plan exists to compensate for the uncertainty, so it is not at all essential that we actually hit any given task estimate. If a tasks turns out to be more work than expected, than it will consume the buffer, no re-planning is needed. From our experience the number of tasks in most plans should be cut by an order of magnitude, sometimes two. The US Navy now plans ship maintenance projects with fewer than 300 tasks, where they used to have 30,000—and they deliver on-time and on-budget where they rarely did before.
The second element is to use checklists within the tasks to account for the details of the task. This enables managers to insure that there is clear communication as to the specific elements of the work (and to see each element checked off the list) and enables them to modify the checklists as needed without having to do any re-planning or re-pipelining of the schedules. In this way the original plan can be created much faster (there are far fewer tasks to detail, and vastly fewer relationships or estimates to get) and will require little if any re-planning.
To summarize, if you want to get out of the project scheduling trap, try these three steps:
Take the safety time out the tasks and put it into a buffer at the end of the project, preferably cutting that buffer as well.
Plan tasks at a high level (never less than a day, and typically not less than a week for most tasks)
Use task checklists to manage and modify the details of the work within each task.
For more info send a request to info@tocc.com. Be sure to include the details of your question or request.
nice work
ReplyDelete