Lean methods and Agile principles recognize that it’s almost impossible to get anything absolutely right the first time. Testing and iterating are part of the plan. For example, in Agile, it’s not uncommon for project teams to use the first few sprints to determine project velocity; especially when there is a new team in place. In the same spirit, developing a project plan with a launch date that the team can have confidence in can take several iterations once the project is underway...
To demonstrate, here is a case in point. The graph below shows tasks across several projects, and when new tasks were added to the plans over the lifetime of the projects.
Prior to beginning each project in this study, everyone on the project team reviewed the plan and provided input. A resulting completion date was agreed. These projects were early in this companies’ use of PLAYBOOK, before they had detailed plans from the past to refer to, so they had to build their plans by relying mostly on memory.
You will note in the graph there are tasks created during the middle and later phases of the project. These tasks are largely a result of rolling wave planning where long, generalized tasks are replaced with more granular tasks a few weeks before they are executed.
In most cases, the supporting detailed tasks could not be predicted any earlier. This iterative planning to accommodate the details that cannot be seen accurately--in advance--accounts for approximately 70% of the new tasks created over the course of these projects.
But notice the big bump in the first 10% of the projects’ progressions. This bump shows a very high portion of tasks being created in the very early days of these projects. The team had already thought of every task they could, and put it into the plan. Yet as soon as people got into actually doing the projects, they thought of a lot more.
In sum, the chart shows that after only a couple of weeks of working on a project, the team had often blown their planned completion date out of the water.
Once we start a project, we think of more things we need to do!
It seems when we engage in early project activities such as conceptual design, draft test, regulatory approval, production planning or other similar activities, we think of several required tasks we didn’t think of before. Some we just didn’t remember earlier, while others we simply couldn’t know about earlier.
Even if there are other causes, such as people not really thinking thoroughly enough about the original plan (which I don’t believe is a primary cause of this) or failing memories, the point is a more accurate project baseline is often achieved shortly after project kick-off.
Baselining too early creates more risk
If the target/due-date is set before the project is started, and it does not leave room for tasks we didn’t think of earlier, it's almost guaranteed that the team will be tracking behind their initial planned end date.
In this scenario, we find teams too often start taking risks in order to recover lost ground. This creates a bigger problem, as some of these risks are realized, the team gets even further behind.
Fortunately, the teams on these projects have been practicing risk management for years and did a great job of mitigating risk. Poor risk management would be visible in this graph with large bumps of new tasks later in the project. We can see a little of that in these projects, but as risk is the nature of product development, we can’t mitigate every risk. In fact, if we were able to mitigate all risk, we could be very confident in our target completion date. When there are a lot of unmitigated risks, our completion date is going to move. (See our series on risk management for a more indepth discussion.)
The recommended baselining approach
The better approach is to plan and set targets and buffers iteratively, with at least 1 iteration after the project is a couple/few weeks underway. The longer the project and more uncertain the work involved, the more iterations to the target date are needed.
It is possible to acquire more certainty on the completion dates earlier in our projects, but it requires us to use more than just our memories when building plans.
Capturing and reusing past project planning data
To aid our memories, the team must have a tool in place that captures past project details and lets you easily reuse them as a template for future plans.
It’s one thing to remember global activities, however, the devil is in the detailed tasks. The ability to reuse plans is invaluable when you want to arrive at launch dates that you can have confidence in during the planning phase.
Conclusion
In some cases, you may need to delay project funding, approval, and/or kick-off until a baseline is set. However, this is all part of managing risk. The project team and management will both be much happier with a more accurate plan in place.
Do you know the number one cause of project delays? It's not what you think. Watch this 9-minute video to find out what is.
