Building Executable Project Plans – Part 1

The probability of Success increases with solid preparation. This is absolutely true in Project Management. Incomplete, incorrect or too detailed Project Networks simply cannot produce a good result. Read this foundational white paper on how to build good project networks. Well known authors Kathy Austin and Gerry Kendall have codified a “Best Practice” for Project Managers. Critical Chain Management Software projects are particularly successful when starting out with a great network.

Building Executable Project Plans

Introduction to Project Planning

Contribution by Kathy Austin

There seems to be two extremes to project planning:

  • “Seat of the pants” methodology: little to no documentation, possibly a list of things “to do”
  • Hundreds to thousands of tasks, at a level of detail that would make a detailed work instruction look like a high-level document (with times down to minutes or fractions of minutes).

What’s a project?

According to the Project Management Institute (PMI):

“It’s a temporary endeavor undertaken to create a unique product, service or result.

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.

The development of software for an improved business process, the construction of a building or bridge, the relief effort after a natural disaster, the expansion of sales into a new geographic market — all are projects.

And all must be expertly managed to deliver the on-time, on-budget results, learning and integration that organizations need. (

Why do we need to plan a project?

PMI includes in their definition “a specific set of operations designed to accomplish a singular goal”. Implied in the PMI definition is that a project takes more than one person to accomplish (note the “project team”).

During project planning, that set of operations must be defined and properly sequenced before team members and resources to accomplish each set of operations and time estimates for each set of operations can be defined.

Without a good project plan properly communicated and managed during project execution, no one knows what to do when (or worse, decides on their own what to do, when, and to what extent!), which adds significant risk to meeting project scope requirements, staying at or below the project budget, and finishing at or before the (original) agreed-upon project due-date.

What’s a project network?

In our book, Advanced Multi-Project Management: Achieving Outstanding Speed and Results with Predictability (Gerald I. Kendall and Kathleen M Austin, J.Ross Publishing, 2012), we defined a project network as a model of the major work needed to meet the stakeholder needs and drive some part of the organization’s goals. Regardless of whether people are using PERT networks, lists, GANTT charts or some other format, the network is the raw material of projects. In some form, it describes tasks, the correct sequence of the tasks (what must come before something else), the effort expected to complete the work, the resources, and other notes about the work that may not be understood from a simple diagram).

Some people distinguish between a network and a project plan. It is true that when you are using a particular software package or methodology, this terminology can represent two physically different things. For our generic purposes, it is sufficient to use the definition as stated above.

The project network impacts everything – the time and skill demands on the resource, the understanding of the work needed, the ability to monitor execution against a valid plan, the insulation against variability, the ability to meet the organization’s and sponsor’s goals. Therefore, like resources, project networks are at the very heart of the multi-project portfolio management system.

Good project networks are like good roadmaps. They allow you to chart a high-speed course. They provide warning signs for curves and bumps before you reach them. They clearly lay out the boundaries over which you are traveling. AND they enable the project manager to focus their energy on dealing with poor road conditions, detours, construction, instead of charting the course as they go. They will have had a chance to pre-plan alternative courses should a roadblock be encountered. In this way, they help you get to your destination safely yet at high speed.

What causes poor project networks?

The two problems that we’ve seen universally in building project networks are:

  1. No formal process is used. Just like doing pre-flight checks, network building requires a series of precise, well-executed steps. Miss one step and the project will crash.
  2. Scrutiny of the network is missing. Pilots and co-pilots cross-check each other. No one person has all the information necessary to understand all of the work of a project. Without scrutiny, a project network is a fantasy on paper.

Hmmm…sounds like we need a process – what needs to be included?

It is much easier to define the content of a task if you know who is going to use the output of the task and what they need before they can start their task. In other words, it is the input needed by the next task that defines the predecessor task’s work content. Therefore, it makes sense to construct a project network working from the end to the beginning.

However, once a network is constructed, what is the best way to scrutinize that series of tasks and milestones? For most people, the answer is in the sequence in which the work will be performed. Therefore, build the network from the end to the beginning, but check a network working from the beginning to the end.

One analogy is having an architect design a house. They start with the end in mind. How big will the house be, how many bedrooms, how many floors? Then, for each floor, how many rooms, which rooms must have windows, what view must the window have. Then for the windows, how big should they be, what insulation factor do you want, what type of material is needed? For the builder doing the construction, they work from step 1 forward. They need to know that they must first clear the lot, then put in the footings, then lay the foundation, etc.

Task estimates need to be done by people with expertise in the given collection of work. With an architect’s design and with the help of a general contractor, an electrician can estimate how much work is involved and how long it will take to wire the house. The HVAC expert can estimate the number of units required and the work and cost to lay the duct work to heat and air condition the house. Just as I would expect a general contractor to rigorously check the estimates for building a house by validating with skilled tradespeople, we need a project manager in collaboration with subject matter experts to validate each collection of project work, by skill, for both correct content and estimated time and cost.

Another key issue in planning is determining how much and what types of uncertainty to account for. Since any individual estimate can be wrong, the people building the network must understand the amount of variation possible in the work. The problem is, that at the time the network is being built, there are a lot of unknowns. However, when you remove the uncertainty about resource availability, caused by confusing priority systems and bad multitasking, you are able to focus much more on the task content. When you further remove the uncertainty of how long it will take to get help and decisions from management and other groups in the organization, it is easier to judge the unknowns.

It’s also crucial to understand where the biggest variability is likely to occur – more towards the beginning or end of a project. If the biggest variability is towards the end of the project, we must have a healthy buffer of time left at that point in the project in order to account for and absorb that potential variability.

As an example, a web designer tells me that it will likely take five days to complete the design work I’ve asked for. After discussion, we agree that it is possible to do all the work in 3 days. If I check with the designer at the end of the first day, and he/she says “10 more days to go”, I have the right and obligation to ask what happened. And if I am a skilled task manager, I can also offer to help in some way that will bring the time closer to the likely time. Has the content changed? Is the designer stuck waiting for a user decision? The original estimates framed the work in a way that we can now manage it effectively during execution.

Using the same example, if we are undertaking a project where the majority of the variability in changing a web site is at the front end, then the fact that we have used up the majority of the buffer half way through the project is not alarming. It is expected.


Why are current project planning efforts usually a waste of time?

Many project plans are not used once a project begins to execute. This means that either:

  • they were created only to satisfy some policy of the organization or
  • they are obsolete upon starting execution or
  • they were not structured in a way to facilitate execution (e.g., dependencies incorrectly mapped, not organized in a fashion that aligns with how the work will be accomplished, etc.).

If our experience is common, that over 75% of the value of a project plan only comes during execution, then no matter which above case is true, the effort to plan was almost a total waste of time.

To avoid this waste, the first thing to do is to not make the common mistakes. There are four such mistakes in building project plans and networks, which make them difficult to use during execution:

  1. Assigning named resources (i.e., specific people) to tasks at planning time. People leave companies. People get sick. People get tied up on other projects longer than expected. People get assigned to other projects. This approach simply does not work. Note that this does not absolve a manager from assigning a named resource or thinking about who can be assigned to a task as it comes ready to execute. The issue is about timing and predictability. Also, if there is only one resource in the organization who has a certain, unique skill set, then the skill set and the resource are one and the same. This is a huge red flag to an organization about their vulnerability to project delays.
  2. Using the wrong level of detail to construct the plan. A project manager must focus on the important few tasks that really govern the project outcome. It is a huge mistake for a project manager to try to manage many hundreds or thousands of tasks. Breaking work down, during a planning stage, to its lowest level of detail or work breakdown structure is unnecessary and error-prone. At the same time, a single task that is estimated to take more than two weeks probably needs to be broken down further.
  3. Not rigorously checking every task and the collection of tasks against the key stakeholder’s needs. Some tasks may not be needed because they add no value to the key stakeholder. Others that are essential to meet the needs are missing. In many cases, the stakeholder needs are simply not well understood until it is too late. The key stakeholder should have a project goal in mind which is tied to the company goals. Often, other stakeholders see the project as a way to get other needs met, and it becomes like members of congress attaching pork to a bill intended for something totally different.
  4. Not rigorously checking for additional and/or missing dependencies. A missed dependency can mean the entire schedule is wrong. For example, we have seen a product launch delayed for weeks because the Legal department due diligence was not included in the plan. Subject matter experts can catch most of these mistakes before they happen. But they often are not included in the advance scrutiny of project networks.

Why use project networks at all?

Within any organization, there are at most a handful of people that love to build project networks. For most people, building project networks seems to be too complex and gives them a headache, literally. Therefore, it is tempting to not build project networks, or to put in a token effort to be able to show a plan, even though it is not useful. Another common practice is to let the project network expert build the plan almost independently, in a way that only this person understands. For this reason, it is also common practice that networks are not rigorously checked with key stakeholders.

We have personally witnessed organizations that consistently get more than 95% of their projects completed on time, on budget and within scope. Every one of them will tell you they could not have done it without the use of networks during both planning and execution. Therefore, you must find those people in the organization who love building networks – who think of it as a hobby, e.g., solving crossword puzzles, that is a lot of fun. They must be coached to construct a plan with terminology that is easily understood by other humans who are not into the lingo of project networks. They must also be coached to communicate their assumptions behind the network and its dependencies in simple language.

In our opinion, about 25% of the value of a project network is from planning. It is almost useless for predicting short term resource loading, because projects never execute as planned. Some tasks are executed more quickly. Others take much longer. However, the plan provides an up-front prediction of the approximate workload. It is a sanity check that the work required to deliver the project results makes sense when compared to the benefits the project will deliver to the organization.

But there is another key value to the plan itself. The project plan allows the organization to know when the project can be released and approximately when the benefits will start to accrue.

We believe that 75% of the value of the plan comes during execution. During execution, it is the yardstick against which progress is measured. If a plan contains strategic buffers (blocks of time placed at the end of a project equivalent to at least a third of the total time of the project), these buffers provide the real truth about how effectively the project is being executed.

When you compare how fast a buffer is being eaten away, relative to how fast the most critical chain tasks in the project are being completed, you have a compelling and proven story about the real time status of execution. However, most organizations wait too long to act on this story. The network buffer story is only valuable if it is analyzed and acted on daily.

Therefore, we claim that it is impossible for any organization to have their projects under control (meeting their goals better than 95% of the time) without properly constructed project networks used frequently during project execution.

What’s a good project planning process to follow?

To us, a process is a series of steps that can be repeated by different people and will generate essentially the same results. This is the intent of the process that we describe, but do not detail, below. The details and associated examples and diagrams are included in an upcoming blog post. These steps must be followed in sequence. None of the steps can be omitted. The steps embed five different ways to avoid risks in the project plan – risks of missing steps, risks of missing dependencies, risks of including unnecessary scope, risks of missing key stakeholder needs, and overall risks of the project. The 10 steps we recommend are:

  1. Define the project’s measurable goals, tangible scope and sponsor criteria.
  2. Define the tasks required for the backbone of the project network (one main path), starting at the end of the project and working towards the beginning.
  3. Add the tasks required to build the skeleton (other paths), working backwards from the end, completing all other paths.
  4. Read the network forward, from the beginning, rigorously looking for additional dependencies (First risk avoidance).
  5. Check every task against project goals, scope and sponsor criteria (Second risk avoidance).
  6. Determine resources (skill level and maximum number) that could be assigned to perform the task.
  7. Scrutinize the network logic using subject matter and/or skill set experts (Third risk avoidance).
  8. Define time estimates, with range of variability (Fourth risk avoidance).
  9. Seek ways to reduce overall project duration without compromise.

10.  Complete a final overall project assessment (Fifth risk avoidance).

When the organization has such a rigorous process, and every project network is built using the process, two excellent results are achieved:

  • Templates that describe a type of project (e.g., new product development, I.T. service implementation or upgrade) can be developed and re-used, saving a lot of time in understanding the tasks involved in constructing a new project plan in the future.
  • Projects become more predictable, with the consistency of rigor and validity across all projects.

This 10-step process sounds like it takes a LONG time

Personally, we have spent up to two days working on a network. There was no pre-established template to use, and the company had not done formal project plans before. Much of the time was spent discussing scope and not adding tasks to the network. We have heard of cases where it took a week or more to finalize a project template, for a very complex project. However, the next time a similar project comes up, it typically would require between an hour and a day to customize an existing template.

Remember, even in the most complex of projects, where there may be thousands upon thousands of actual tasks performed, you are looking for ONLY the 200 tasks that the project manager must focus on. For example, in building a large ship, there are hundreds of rooms that must be finished, involving different skilled contractors – painters, plumbers, electricians, dry-wallers, etc. The project manager does not need to know when Joe, the painter, will be painting room 127. In the project plan, he needs to know that the first 30 rooms are scheduled to be painted over a period of 1 week. Before the painters arrive, he must make sure the plumbing and electrical work is complete, and the dry-wall has had time to dry.

Do not be disheartened if you already have a project plan, and you rebuild it using this process and find it requires a longer duration. All that this means is that the original plan was destined to not work, because it was missing pieces.


Project networks are the building blocks to complete a project successfully. If you don’t have enough building blocks and you have to get more during execution, the project likely fails to meet its time and cost projection. If the blocks are made of poor material (poor understanding of the work), they will crumble during execution. If we don’t understand which blocks go where, and which blocks are needed before we can put the next ones in place, we’ll have a lot of rework. From experience, it is worth the effort to have and use a formal process for both constructing and for scrutinizing networks.

We have not heard of a single case of any organization getting predictable results from projects without having a rigorous project plan, constructed using a disciplined and consistent process. This implies that the process cannot be left up to each individual project manager to determine from their own experiences. This chapter overviewed a 10-step network building process that included five risk avoidance techniques. Details for each of these steps are found in Part III of this text. To end up with a good end product, you must not only follow the process, but also have the right people involved in the network building process, as described within this chapter.

Upcoming Topics

v Ensuring the correct level of detail in the project network

v Details for each of the 10 steps to building a good, executable project network

Let's Talk

Make an Appointment Today!