Building Executable Project Plans – Part 11

by Kathleen Austin & Gerald Kendall

Part 1 provided an introduction to projects and the need to plan a project. Part 2 discussed how to ensure the correct level of detail in a project network. Parts 3 – 10 detailed Steps 1 – 8 of the 10 steps to building an executable project plan. Basis for this post: Advanced Multi-Project Management: Achieving Outstanding Speed and Results with Predictability, by Gerald I. Kendall and Kathleen M Austin, J. Ross Publishing, 2012, Chapter 21.

Step 9: Seek ways to reduce overall project duration without compromise

The project planning team now thoroughly understands the total network logic (tasks, interdependencies, resources, and time estimates that enable the accomplishment of the project scope, objectives, and tangible deliverables). It’s time to determine the duration of the project to see where to focus to reduce overall project lead time. For most projects, when the time estimates that you’ve obtained in Step 8 are plugged into the network, the software provides a duration that is longer (often much longer) than the executives and other stakeholders find acceptable. Therefore, the premise of this blog is that the network building team must be prepared to go through some iterations to reduce project duration, without having to shove unrealistic estimates down people’s throats and without adding additional risk to the project.

Finding the Tasks That Will Govern Duration

There are two commonly used approaches for determining how long a project is likely to take, in elapsed time. The Critical Path process was developed in the late 1950s, and defines the longest chain of task dependencies within a project. There are several assumptions about

 

Critical Path, based on statistics, that proved useful until around 20 years ago. There are many good books written about Critical Path, and Wikipedia,¹ among other sources, has a very good explanation of the approach.

Beginning in the 1990s, as the number of projects activated in organizations exploded, many tasks found themselves waiting not on another task, but on a resource that was already working on another part of the same project. This syndrome of the project duration depending not just on task dependencies, but also on resource dependencies, was verbalized in a book called Critical Chain (Goldratt). Wikipedia also provides an excellent overview of this approach².

In our opinion, Critical Chain is a more conservative and realistic approach, since resource constraints in the multi-project environment are pervasive. Therefore, we will devote a portion of this chapter to explain it further. From our experience, this focus yields excellent results in reducing project duration. The project’s Critical Chain is the longest chain of dependent tasks through the project, where the dependency could be based on either:

• One task depending on another task finishing before it can start because it needs the result of that task in order to start or
• One task depending on a resource that must finish another task on another path of the same project

Software makes identifying the Critical Chain an easy task. Regardless of whether you decide to use Critical Chain or Critical Path, you will have the best chance of reducing a project’s elapsed time duration by focusing on that subset of all the project tasks that most likely will drive it.

Overall Project Duration Reduction

When looking to reduce overall project duration, it is necessary to do it without adding any risk to the project. That means we cannot arbitrarily begin reducing either ambitious or standard times. The steps below offer a useful process for reducing duration, without increasing the risk to the task completion criteria. There’s an old saying that changing the estimates on paper does not change reality. Do not fall into that trap. Remember during this process that it is possible to go too far – additional resources and more experienced resources are key recovery options during execution; the more you’ve used those to reduce durations, the fewer options you’ll have if/when recovery is required.

• Focus on the Critical Chain or Critical Path tasks first, since they are the primary determiners of project Since we do not know which of these approaches you are using, we will simply refer to these tasks as “Critical”. Examine the critical tasks looking first at the longest ambitious times. Note: Being able to sort the tasks by ambitious times (highest to lowest) is very useful.
  • Take a hard look at the ambitious and standard times. Given the team’s thorough understanding of the project, do they have a gut feel that any of the task estimates are over- stated? This can result from a lack of understanding of the tasks when they are estimated. Often things are caught when looking at the big picture which are missed when looking at tasks or paths in isolation. Perform a detailed review of those tasks and pencil in the new estimates.

 

In the software, make the changes and save a copy of the project file under a different name (e.g., project_name_reduction_version 1). Document the changes and validate the new assumptions with the appropriate experts. Re-run the software to identify the Critical Chain or Critical Path; it may be different!

• Examine the resulting Critical Chain or Critical Path tasks. Can any significant ambitious and/or standard task estimates be shortened by changing from the minimum skilled resource to a higher skilled resource? Does such a resource exist? Looking at the potential added cost of a higher skilled resource versus the benefit to the organization of bringing in the project earlier, does the benefit justify the cost (if any)? Note that in many cases, there is no added real money cost, when the higher skilled resource already works for the organization. I.e., you are not paying them a higher salary to work on this project! However, cost allocations by project accounting systems can drive some extremely poor decisions.
• Would the ambitious and/or standard task estimates be shortened if additional resources were added to the task? Note that this does not always reduce task estimates – nine women cannot have a baby in one month! If additional resources do make a difference, do those resources exist? See the discussion above on project cost versus benefit considerations.

 

 

• Repeat the process on all significant ambitious Critical Chain or Critical Path task
• When finished, re-run the process of identifying the Critical Chain or Critical Check to see if steps 9.1.1 – 9.1.5 should be repeated.

• Examine long feeding paths. All tasks that are not on the Critical Chain or Critical Path are considered to be on a feeding path. Every project has only one Critical Chain or Critical Path; it has multiple feeding Any path that feeds into or merges with the Critical Chain or Critical Path is considered a feeding path. For very long (a rule of thumb is 2/3 the length of the Critical Chain/Critical Path) feeding paths, follow steps 9.1.1 – 9.1.3 on these paths.
• When you are finished reducing durations, re-run identifying the Critical Chain or Critical Path a final time.
• As a final step, ensure the experts you’ve used for resourcing (Step 6) and time estimates (Step 8) validate the changes made. A double-check by people serving as senior resource manager(s) and senior project manager is also recommended.

Important Note: Scheduling is not complete. Identifying the Critical Chain or Critical Path is part of scheduling but is not all of the scheduling process. Please refer to Advanced Multi-Project Management (Kendall & Austin) for more information on project scheduling.

How Many Resources On A Task?

There is one school of thought that teaches all in a resource pool should be put on a task when planning and scheduling in order to complete the task in the shortest possible time, while

 

another school of thought teaches to put the minimum number of resources required to reach a task’s completion criteria on a task in order to save project budget costs. Which is correct?

We believe there is no hard and fast rule; it depends! What is important is to know what it depends on, so that you can properly evaluate the situation.

For example, assume that a project requires completion of 500 engineering drawings. If that work represents one or several long critical tasks, it will make sense to put as many qualified resources on it as possible in order to reduce time. However, if the project task is to wire and install measuring devices between bulkheads 234 and 246, there may be only two resources that can physically fit in the space. Yes, these are two extreme examples!

Consider also that resources will not be multi-tasking while working a project task: once a resource begins work on a task, he/she/it will work on that task until task completion criteria are met. However, resources are assigned to tasks, not entire projects. Plus, by not multi- tasking, resources are not needed as long for the same task work. These recommended execution practices are examples of key considerations when determining how many of a resource pool should be planned for a task to reduce overall project duration.

For those projects with budget constraints, experience shows (both ours and also coming from public presentations by organizations using this kind of approach who also have to meet budgets) that the shorter the project duration (driven by not multitasking and quick issue identification and resolution and full kitting projects), the less rework, the less resource time consumed and the less waste; i.e., there is both a correlation and cause-effect between shorter duration and less money spent.

Other Considerations for Reducing Task Duration

1. One of the most common mistakes in building networks is the assumption that ALL task dependencies are, for the most part, Is it possible that nowhere near all of task A must be finished before even starting task B, even though we modeled it as a 100% dependency between the two tasks in the network? In almost all cases, we find a few such cases where the model was ultra conservative, and in fact most of task A can be done in parallel with task B. When you change these assumptions, by removing these dependencies, the typical result is a shorter duration.
2. Where significant amounts of time are used up by outside dependencies (e.g., Vendors), determine what the value is of expediting delivery for critical items. For example, a project in Bangladesh was delayed for months waiting for high end generators from an outside supplier. The value of the project was several million dollars per year and was very tangible. The return on investment was less than one year. Each generator was selling around $150,000. If you figure the traditional way that a vendor values the sale, they usually expect a product gross profit contribution of 40-50%. That means that about $75,000 is their profit margin. If you were to offer them a $25,000 bonus for delivering early, that increases their profit margin by a This is one way to expedite with vendors. If you simply ask them if they can possibly deliver earlier, the answer is automatically “no”. But offer them a significant premium, and the answer can change

 

very quickly. In this case, the added cost was trivial in comparison to the value of getting early delivery from this vendor.

3. Re-examine the tasks against the scope and stakeholder needs. In many cases, we find liberal assumptions about tasks being required. When checking back with the stakeholder, we often hear responses such as, “Yes, that would be nice to have but what I’m really after is……”. You are NOT cutting scope if these kinds of tasks are trimmed before the project is even started. The key stakeholders are often the strongest supporters, if it means that they can get the most important benefits much sooner without the nice to haves.
4. Re-example the major chunks of project logic. Sometimes, we find mistakes in how the project was modeled. For example, in one product development effort with a California high tech company, there was a 15-day testing period during which no other development work could be done. 95% of the time, the result of the testing is that the product solution is proven to work, and is ready for beta testing with clients. However, being ultra-conservative, they modeled the testing under a marketing resource heading, because they did not want marketing to proceed until the product was proven. In fact, there were several time-consuming and critical marketing tasks that could proceed in parallel with the testing. When this was modeled to reflect those changes, 15 days (3 weeks!) were cut from the project duration.
5. Double check the arrows along the Critical Chain/Critical Path. Is the task to the left really required to be complete before the task to the right can begin? In reality most “must have” dependencies are one of two types:
   1. The task to the left absolutely has to be complete before the task on the right can begin; this type is the most common.
   2. The task to the left does not HAVE to be completed before the task on the right can begin, but completing it first reduces the chances for rework or delay. Think of an expensive long-lead part. The engineering drawing for that part does not have to have its final approval before ordering the part, but if the part is ordered before final engineering drawing approval and a change is made to the drawing after it’s ordered, the project can experience a very expensive delay (a double whammy!)

Conclusions

In seeking ways to reduce project duration, it is vital to not arbitrarily cut people’s time estimates. This usually proves disastrous in execution. The first focus should be on those tasks which are critical to the projects (i.e., Critical Chain or Critical Path tasks), since those tasks, more than any other, are likely to determine how long the entire project will take. The typical options to examine are time estimates that do not reflect the intuition of the team about how long they should take, the opportunity to add more resources to a task to get it done more quickly, and the opportunity to put more highly skilled resources on some tasks to reduce duration.

 

When finished scrutinizing the critical tasks, look at very long non-critical paths, with the same scrutiny.

If the project duration is still much longer than acceptable to stakeholders, then look for invalid assumptions about the network logic and dependencies, and look at long vendor lead times as avenues for reduction.

References

1. See the Wikipedia definition of Critical Path at http://en.wikipedia.org/wiki/Critical_path_method
2. See the Wikipedia definition of Critical Chain at http://en.wikipedia.org/wiki/Critical_chain_project_management

 

Next post: Step 10: Complete a final, overall project assessment (fifth risk avoidance)