Project Lessons: Focus on Completing Projects On-time, Not Completing Tasks On-time

It may seem counterintuitive, to say we shouldn’t focus on completing tasks on-time, in order to deliver our projects on-time. After all isn’t it obvious that if we complete each task in a project on-time, that the project will finish on-time? This statement is of course true, but within it hides another trap for people managing projects.

Since this method of driving timely task completions is probably the most widely used strategy for trying to bring projects in on-time, we can look at public data on project performance to evaluate its effectiveness. Various public studies (Forrester, Gartner, World Bank) illustrate the widespread problem of bringing projects in on time. Depending on the source the studies show 40% to 67% of projects miss their planned delivery date. While there are many factors at work here it’s pretty clear from the data that this method is not very effective at overcoming the challenges of bringing projects in on-time. But why?

The trap in this methodology comes from two elements of managing projects. The first element is that uncertainty on projects is very high, making it very rare and almost impossible to finish every task on-time. Unplanned events, changes, disruptions, resources not being available, etc. wreak havoc with even the best plans, resulting in many tasks sliding beyond their planned completion date. The result being that the project as a whole is delayed and misses its completion date.

The second element is the human dynamic that results from any attempts to focus on task completion dates. If an organization makes completing each task on-time important, how will people respond? We all know the validity of the statement “tell me how you measure me and I will tell you how I am going to behave.” Even if there is not a formal measurement, but just a management focus, expectation, or even the belief that management judges something to be important, it will impact how people behave. So how does making timely task completion impact people’s behavior in project environments?

The first way is pretty obvious, people will provide and negotiate for task durations that are conservative, for task durations they are confident that they can achieve. No one wants to do a bad job, and when management drives timely task completions people will respond by increasing their estimates of how long a task will take. This is not bad behavior on their part, after all the reality of projects is uncertainty. No one really knows how long a task is going to take this time, what challenges we will encounter, whether the specifications will have changed, what other work they may be required to do at the same time, etc. So in order to provide a reliable task duration people will naturally provide estimate that they believe is achievable, even if things go wrong.

This behavior is magnified if management routinely uses the practice of trimming the durations of people’s estimates to insure that project timelines meet the organization’s business needs. If people know their estimates will be trimmed anyway, they will add additional padding in their estimates. It is identical to the dynamics organizations experience with budgeting. Every manager knows that if he needs a million dollars to run his department next year, that he better ask for much more initially, in order to end up with the million he needs. The same “game” is played with task durations. And again it’s not bad behavior, it’s people trying to do the best job they can within the rules of the system.

So, one result of focusing on completing tasks on-time is that the task estimates (and therefore the project plans as a whole) get inflated. This however creates for us an apparent paradox. How can it be that our task estimates are so inflated and still we cannot meet them reliably?

Again basic human behavior is at work, but this time it is the behavior during project execution, not in the planning stage. Imagine the reality: we have a task estimate that provides us with what looks like ample safety time, because we have buffered it for uncertainty and other factors in order to be able to deliver it reliably. So when the work actually arrives, there is a clear sense that there is ample time to complete the task. In other words there is very little sense of urgency to start the task immediately, and in any event most project resources are overloaded with other things already so it might even be that there is not the ability to start the task right away. We know this dynamic from our school days. We know the test is out there, but when there is the perception that “we have plenty of time” there is really no need to start studying. Often we end up beginning only the night before, or at most a few days ahead of time.

On projects this translates to the reality that some, often most, of the safety time gets wasted at the front end of the task because of lack of urgency. Now if there is any unforeseen delay, change, or hiccup of any sort on the work, the task date will in all likelihood be missed. So even though we have put safety time into the task estimate, common human behavior will in most cases cause it to be wasted.

While this is not hard to picture in reality, a sharp mind will point out that it will not happen in all cases, and even when it does, sometimes a task will go smoothly and could be finished ahead of the planned time. This is in fact true. Unfortunately when an organization places importance on finishing tasks on-time, it is at the same time creating a strong dis-incentive for people to finish earlier than expected. Again picture the reality: what is likely to happen if someone reports finishing a task a week ahead of schedule? What will be the expectation for a similar task on the next project? Of course, finishing early will result in the task duration being cut the next time, again just as not spending all of your budget in a given year will result in your getting less the next year. It’s obvious that you padded the estimate so you can expect it to be cut even more the next time.

Similarly if a task is ready ahead of time the committed employee is also likely to spend the remaining time “improving” the work, making it even better than it was. As long as there is still time available people are likely to fill it with efforts to make the work as good as possible. We all know this behavior to the degree that it has a common name, Parkinson’s Law: the work expands to fill the time available. The result is that task rarely finish (much) ahead of their planned times, so the potential gains are typically lost in the process.

In total some tasks finishing late, while others finish on-time, and almost no tasks finish early. The sum of this is that projects will finish late in many cases, exactly what the studies and most people’s experience shows. Of course if finishing a project on-time is a mandate there are alternatives that will mask the reality with apparently good on-time performance. Organizations can turn to a reduction in the scope of a project or to increasing their spending to compensate for the delays. But while the project may finish on-time in our metrics, it often does so only at the expense of the original scope or the original budget. In reality then, even organizations with “better” than average on-time performance are being directly impacted by the methodology of focusing on completing tasks on-time.

Unfortunately a common reaction to the poor project performance is to sharpen the focus on timely task completion. It is not uncommon to see managers get more and more involved in the details of managing individual tasks in the effort to “get control” of the situation and help insure that more tasks finish on-time. Not surprisingly this only heightens the behavioral response described above. The more important it becomes for people to hit task dates, the stronger the above behaviors will be. So in their efforts to address the problem, most organizations only serve to solidify the underlying causes of it.

It may be possible to change these underlying human behaviors, but it seems to me that the better and faster way is to change the system of managing projects. For more on this see other postings in this blog on Critical Chain project management, or send you specific information request to info@tocc.com.

Breaking out of the Project Scheduling Trap

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.

New Series

Writing these long blogs has not proven easy for me and has resulted in long gaps between entries. Additionally they probably aren't read as widely as shorter entries. So in an effort to get more content "out there" and to promote wider reading and dialogue I have decided to blog in the more traditional way in smaller parcels.

Someone suggested a series of smaller entries on some of the key learnings TOC has generated over the years, so I am going to try. Let me know what you think, the first series I am going to offer is "lessons in Learned about managing Projects, Strategies for delivering more projects, faster."

I hope you enjoy it.

Kevin