Roughly 30% of the planet’s GDP is involved with projects. The 2020 Standish Group’s Chaos report found that project success, on scope, on time, on budget, has declined 18% in the last few years. And it happened, even though the number of project planning and scheduling software tools increased 600% in the last 5 years.
The 2019 Oxford University study of 12,000 large infrastructure projects finds that only 8% finished on time and on budget. The authors concluded that:
- most effort on project improvement is focused on the ‘execution’ of the project
- overruns are not always a failure of execution but are always a failure of planning
- little has been done to improve the planning of projects
That raises an important question. What if the tools and methods for project planning and scheduling are contributing to the dilemma?
First of all, it would be incorrect to assume that Push Planning is ‘bad’ and Pull Planning is ‘good’. They are very different methods applied to different situations. However, the old adage, ‘If the only tool available is a hammer, everything looks like a nail’, could be at issue here.
It’s important to recognize that there are two distinct and different types of planning in a project. And they each require different methods and tools.
- In the early stages of a project, the first step is to determine what the current situation is and how it needs to be altered. We’re looking for better, or at least different, results. Once agreed upon, good project managers start looking for a range of solutions that are compared. Once they agree on the best solution, it needs to be broken down into its range of components which are referred to as ‘deliverables’. This design and development phase investigates and determines ‘what’ we’re going to build and create. Creating something new, or refining something that already exists into something better, is an iterative process. Lots of experimentation and creativity is required which does not ‘play well’ with rigid schedules and timelines. One of the biggest challenges is deciding when a design is ‘complete’. A classic mistake is to start building the solution while assuming the design is complete.
This is where the greatest cost and schedule overruns occur. Execution costs a lot of money and time. Fixing errors or omissions during execution escalates those costs to breathtaking heights.
There is an easier and far less expensive way to solve this. It will be addressed towards the end of this article.
But first, how long does it take to design something? That depends on what level of quality we’re looking for; how complex it is and how new or creative the design must be. The age-old answer? ‘It takes as long as it takes’.
It’s tough to hurry along the creative process, even if we’re desperate to make it happen. It’s especially tough on those paying for that design to ‘happen’. - After the design solution, or the ‘what’, is created, the next step is to plan the execution and schedule that will build that design. Figuring out ‘how’ to create the ‘what’, includes all the deliverables, all the tasks, all the resources, and all the dependencies, or logic-links that coordinates it all together. Without those links, there is no schedule. Without a schedule there is no plan and you’re left with a wish-list of intentions.
Push and Pull planning
This graphic represents the different methods and outcomes between Push and Pull planning.
Push Planning works well for design and development. It encourages ‘diffused logic’ that searches for different ideas, concepts, and options. ‘What comes next’ is an open-ended question that supports and encourages design and development.
There are disadvantages as well. It can be like ‘herding cats’ and schedules are more often ‘rolling wave’ targets. The process can be dominated by strong-willed individuals. Reluctant or quiet team members may defer or withdraw, allowing potentially better ideas to be left out.
Pull Planning asks close-ended questions. And when used well, is ideal for developing execution plans. It finds the ‘missing links’ (pun intended).
Ex. To start laying the new roof on the house, what must be true? The shingles have been delivered, the roofing installers have arrived with all their equipment, the tar-paper weather barrier has been laid and the flashing around the chimney and vent pipes is installed, etc. (Note: only ‘Finish-Start’ logic links are used in this example.)
Push planning is very effective with Kanban, Scrum and Agile tools. However, without dependency links and time scales, it is the wrong set of tools and methods to create a detailed execution plan and schedule. Although many have tried.
That brings us to Gantt, or bar, charts. They’ve been around since WW1 and are the most common tool used for creating project plans and schedules as well as the controlling of those plans.
Traditional Gantt charts create milestones, tasks, and summary bars in individual rows. They’re created in a cascade or ‘waterfall pattern’ from the upper left corner to the lower right. Some of these applications are equipped with Pull Planning capabilities; however, the vast majority continue to use Push Planning to create the execution plan. Using ‘diffused logic’ with a Gantt chart to create the execution plan is at best a compromise. At worst, it leaves projects open to those errors and omissions mentioned earlier.
Pull Planning is unequalled for discovering the correct dependencies between tasks, including the more difficult cross-dependencies between deliverables and sub-projects. The challenge is to match the methods with the appropriate tool.
The only tool that effectively uses Pull Planning is a time-scaled, dependency, or network diagram. It supports building the plan from the End milestone and works toward the Start milestone. Each new task is positioned ‘As Late As Possible’ (ALAP).
After the plan is complete, including resource loading, the plan will transition to the more familiar ‘As Soon As Possible’ (ASAP) orientation before execution begins.
And like any set of tools and methods there are some specific methods required to get the best performance. The following have been refined and proven over 30 years on thousands of projects, large and small:
- Deciding to use Pull or Push planning has nothing to do with whether you know the start date or end date of a project. Do not pre-fill the dates in the plan’s calendar. We call this ‘the willing suspension of outcome’. You want an accurate, realistic schedule built on the logical relationships between all the tasks. These include cross-dependencies between different deliverables.Once the first draft is complete, insert the calendar dates that span the plan’s total duration. Now compare these realistic Start and Finish dates to your initial expectations. Sometimes there is time to spare. Sometimes the initial idea of a deadline is woefully unrealistic. Better to know that early.
- It takes time to get used to Pull Planning. After all, we live our lives from the start to the end and old habits die hard. First-timers using Pull Planning have a natural tendency to want to look at the plan ‘normally’, from the start. They rush the process, trying to run a single path from the end to the start. That’s not how Pull Planning works. The objective is to find and verify parallel paths of logic in the plan. Every time a logic-verified, parallel path is created, an opportunity is created to shorten the overall project duration.
- This pattern is simple: the planning team works right to left, top to bottom in a counterclockwise, circular pattern. Always asking the question, ‘what must be true to start this task here and now? The results are magical. The answers to this question are enlightening, especially in comparison to the Push planning method. End first planning is unique in that it discovers both sequential and parallel work at the same time.
- Always verify each predecessor of a task before moving to the next task. And ALWAYS ensure there is consensus amongst the team. Often there’s more than one good way to work through a set of tasks. There must be agreement on which approach is being applied.
- You’ll know the process is working when multiple predecessors are discovered, producing parallel paths of simultaneous work. These are ‘aha’ moments, indeed.
And finally, how do you know when your design solution is complete? It’s easier than you think. The design must give us enough information to figure out how to build it with the resources and expertise that are available.
There are 2 ways to verify completeness of the design:
- The expensive way is to attempt to build the deliverables without fully verifying the ‘plan’. Many a tear has been shed following this approach. Think of the cartoon describing steps in a project where the final panel says, “and then a miracle happens!”
- The smart way is to verify the logic links between all the tasks, and cross-links between all the deliverables and sub-projects before building begins.
In other words, creating a completely integrated execution plan and schedule, with every link ratified, verifies the design.
There are 2 approaches to ‘testing’ the design during this process:
- Create the execution plan and schedule, and then verify the links afterwards.
- Verify each task’s link(s) every step of the way before adding another task.
Initially, the latter approach slows things down, slightly. Then an interesting transformation occurs with team members. The level of confidence and trust gains momentum. As each logic decision is ratified, greater understanding between each subject matter expert (SME’s) grows. A foundation of commitment to the plan starts early. The result is the planning process is faster than approach #1.
Verifying logic (and design) as each task is added, requires more advanced tools and methods. Pull Planning is built for this approach. Especially when combined with a time-scaled, network diagram toolset.
When asking the question, ‘what must be true to start this task here and now?’, there are 3 possible responses from the team:
- Yes, we agree, and we can move on to the next task, or
- No, we have different opinions or information and need to reconsider the decision for this logic link. Consensus must be reached on which is the best solution for this task, ‘here and now’. And then there’s the ‘wild-card’ response:
Everyone looks at each other and says, ‘haven’t a clue’. We don’t know the answer! We might have a vague idea, but the truth is, we don’t know what the predecessor(s) are, ‘here and now’.
Congratulations, your team has just discovered a ‘design gap’. This is a red flag moment that is about to save a lot of time, money and heartache. A piece, or pieces of the design are missing, and it was exposed by asking ‘how’ are we going to build this piece of the plan?
The solution is to go back to the designers and find out what is missing and what is needed to resolve it. The execution plan may have to be put on hold, depending on the size and complexity of the design gap. The initial frustration turns to celebration when you and your team realize how much time and money is being saved by not having to fix this problem during the execution of the project.
OVERGantt is a project management system that combines the refined methods of Pull Planning with what we call: a project flow diagram. It verifies the design, as the execution plan is created.