A famous quote usually credited to Bejamin Franklin says "If You Fail To Prepare You Are Preparing To Fail". I like it because it implies you always have a plan, whether you admit it, or own its consequences, is up to you.

Usually teams conceive plans with mixed feelings in any project and there are common misconceptions too.

Some believe plans are less important than execution.
Others believe they serve only the manager maintaining them – including some established management frameworks.
Most find it difficult to maintain a plan, and often when projects go into trouble, asking for the plan you’d find it hasn’t been maintained for a while.

The harsh reality is that putting a plan and following on its execution still causes grief to many projects and executive leaders every year.

On average IT projects overrun budget by 27%
(HBR 2011)

While this does not seem like an alarming number, keep in mind it’s not distributed evenly: less than 1 in 4 projects finish within the budget and time expectations. Anyway, maybe this will make it sound more terrifying:

$2 trillion are wasted every year on project deviations / failures!
(PMI Pulse Report 2018)

Another question many seek to answer is how do you know the plan will generate the desired outcome; or in other words, how do you ensure that your journey map is calibrated in the correct direction to get you to your destination?

I like to add: how do you create a plan that not only shows a series of accurate steps, but one that adds confidence with every step you take?

Think of a GPS application you use to navigate your way to new destinations. They are trusted to provide you best options to your route, and maybe more important, they can get you back on track when taking a detour or making a wrong turn.

What is a Good Plan?

Oxford dictionary defines a plan as we understand it intuitively: a detailed proposal for doing or achieving something.

The PRINCE2 framework for managing projects, which is associated with waterfall approach, defines the plan as a document describing how, when and by whom the project objectives to be achieved; based on outcomes, timelines, costs, quality and benefits.

Many take it for granted that waterfall management is about “predictive” planning where most of the planning occurs upfront and in detail. Usually the same audience believes that Agile advocates to avoid planning altogether! In reality, both advocate to plan what you know with certainty, and try to achieve certainty before you plan. Although in an Agile approach, the journey allows to gain certainty as you go and not only before you start.

In my experience, in either environments, the line between certainty and uncertainty and how much upfront planning occurs, is mostly determined by the experience and proficiency of the project manager, the team, and the decision makers.

There is a huge difference between starting an activity with inexperienced team that cannot foresee common outcomes and complications / risks, or when a subject matter expert tells you that a product’s feature has never been done before or what complications to expect, and accordingly draw a plan for an investigation activity, so this becomes the certainty in your project, until you learn about the outcomes of that investigation.

When conducting a planning activity, I recommend to teams to come up with as many activities and risks as they can think of. Not to execute all of them, but to make reasonable assumption based on as much information as possible. In this respect the more information you have the best the shortcut you can take!

Avoiding the Planning Fallacy

The planning fallacy is a cognitive bias coined by Daniel Kahneman and Amos Tversky in their 1979 article “Intuitive prediction: Biases and Corrective Procedures”. Later, in Kahenman’s book “Thinking, Fast and Slow” he elaborated on two major reasons for the planning fallacy, that could be summarised as follows:

The naïve: our tendency to focus on best-case scenarios! Even when failed in our estimations in the past, we have this tendency to still think we’ll do it faster and better this time.
The deliberate: sometime managers or vendors want to get a project approved at a lower cost; this is based on the understanding that projects are rarely abandoned unfinished merely because of overrun!

In either case it is the responsibility of the decision maker to ensure they have an outside view to make sure the plan is realistic. Here are some suggestions to get more realistic plans:

1. Use Historic data to create a baseline of realistic learning

I usually keep a record of past project’s completion figures (time, budget, etc.) and use them when estimating new projects.
If you work with tools to manage tasks, you can even elaborate and see historically what the cost of similar features was, or even the cost of integration effort, or a release.
Agile is a great advocate to this approach, some of the techniques suggest not to use time or money as an estimation currency, but an apples-to-apples comparative approach to similar tasks (such as a scale of S, M, L XL, etc.)

2. Use Checklists to avoid best-case scenario

For various projects I provide my teams checklists to consider when they estimate their work! The list balances a worst-case scenario where the team can decide what’s relevant and what’s paranoiac.
The list should consider the full cycle of completing a task including testing, review, handover, documentation, and even possible re-do for complex tasks (such as a “board spin” when designing an electronic board, or finetuning an algorithm that is still under investigation)
Another good and complementary approach is having a checklist for the “Definition of Done” and use it not only in reviewing completed tasks, but also upon planning new tasks.

3. Manage Risks and Assumptions to expect the unexpected

Assessing risks and assumptions is the most efficient way to avoid best-case thinking. This is where you’ll find the “worse” case scenarios to consider and prioritise their impact on your program and project.
Ignoring planning for risks, is usually a recipe for disasters in projects.
Addressing risks in a rigorous and methodological way cannot be overrated! You can read more in my blog managing risks in product development.

(!) Tesla is considered a leading pioneer in planning for risks on their projects

What are Bad Plans?

Plans are usually referred to as the tool that explains the “What” and “How”, as it is focused on execution. And the advice above is focused on the execution aspect as well. This can help where plans suffer from recurring deviations and oversimplified estimations.

In this respect, to summarise the discussion above, the advice is to plan what you know, and plan for what you don’t know yet.

However, problems of projects that fail the hardest don’t start with poor execution of the plans, or because of oversimplification / under-estimation of the activities. Usually the biggest runaway projects miss one or more objectives of the program – they miss the target altogether!

After weeks and months of planning, and years of execution teams find out they got it wrong, sometimes right from the start!

The issue is especially highlighted with innovation:

42% of startups fail because there is no market need.
(CB Insights 2019 report)

But the problem is not a startups issue, the history of runaway projects with billions of dollars wasted, is unfortunately too common.

At least one in six IT projects turns so bad that they can threaten the very existence of the company. (McKinsey 2012).

Plans that add confidence!

A program manager, a marketing manager, and a project manager meet in the lobby of a hotel for breakfast. Sounds like the beginning of a joke you may think!

Actually, this is the reality of a recurring scenario, I had the privilege to witness and be part of. It could be travelling to meet customers and collect feedback, or presenting a new product in a conference, and more. This is what successful organisations do when executive management understands the importance of mature delivery and great outcomes, and willing to make the investment in their greatest asset, their people, and not just talk about it.

These three roles or functions of (business, market, technical) hold three distinctive and complementary views to the product development process. They each have their own version and focus in their domains, yet they also need the complimentary views of the others. Having such a team meeting stakeholders together, each having their own first-hand experience, then discussing their perspectives with their other two colleagues is far more superior to an experience of “water-fall” communication where one manager dictates to others what those need and want, hoping they will get it right.

This approach can be applied in any team at any level of the organisation:

Software, Hardware, Mechanical teams interactions
Internal vs. External stakeholders reporting and reviews
Senior vs. New people involvement
And many more examples...

The common factor I see in successful organisations that create winning products, is that their teams are immersed in each other uncertainties and problems, they solve problems together and understand the “Why” of each other.

Successful teams create plans from the same source of information, and aim to help each other in their different problems. However, when teams work in-silo they try to achieve certainty relevant only to their domain (technical, market, business, etc.) then to cover any uncertainties they either top-up with an arbitrary buffer, a popular one is 20%, to cover their uncertainties. Or worse, just cover-up by stating assumptions and risks, as means to later justify a deviation.

To create successful plans you first need alignment of communications between the working teams, to enable them to prioritise and do the right things first; then combined with productivity tools and efficient processes they can ensure a winning execution as well.

NEXT STEPS:

Observe:
and collect historic data, learn from original estimates vs. completion figures.
Don’t:
take shortcut without looking at the big picture.
Success-oriented is unfortunately a recipe for failure!
Do:
Improve your teams estimations.
Adopt historic data, checklists, and definition of done.
READ:
I highly recommend the book
"Thinking, Fast and Slow"
It’s a great read about the choices we make,
and includes great nuggets for running projects and working with people.