Getting Started with Project Planning

Welcome to my LinkedIn newsletter! In each issue of Breaking the Build, I'll share my thoughts on software development through the looking glass of behavioural sciences. Subscribe to stay updated.

Human behaviours like optimism bias and anchoring can explain why we still struggle to plan and deliver complex software projects; despite the progress made by popular frameworks (like SAFe), that aim to scale software development to multiple teams working on different products.

The first task in any new software project is planning and yet it is one of the most misunderstood aspect of software development. I have personally spent a lot of time doing PI planning every quarter with 30+ SCRUM teams while building a multiple product platform. Somehow, every time we did the two day planning meeting, it was never enough to understand all the dependencies and challenges the teams would face once they got back to working off their own individual backlogs during the quarter.

In fact, a few years back, we spent quite a bit of time trying to address all these issues with project planning for large number of development teams. In the video below, you can see our work on continuous planning which was presented at the ICSE 2020 workshop on Rapid Continuous Software Engineering (RCoSE):

What do you mean by software project planning?

But I am getting ahead of myself. Before we can understand the challenges with software project planning, we need to define it. As per Wikipedia, the purpose of project planning is to identify the scope of the project, estimate the work involved, and create a project schedule.

Thus, scheduling and reporting progress are two essential activities in project planning. However, as anyone who has worked in the software industry for some time knows, no matter how good your plan is, uncertainty and ambiguity are always present in the process. The uncertainty about resources and ambiguity around requirements makes it harder to schedule development tasks. It doesn't mean that plans are ineffective, but it does question their utility as a predictor of cost and time it would take to complete the project.

There is a famous quote related to planning that is often attributed to US President Eisenhower:

In preparing for battle I have always found that plans are useless, but planning is indispensable. - Dwight D. Eisenhower

He was of course speaking from his experience as the commander of the allied forces during the second world war, but it does ring true for building software. While search for this quote, I realised there are some doubts on if he really said this or it was Churchill who said it first. So, I managed to dig up the actual audio clip from the 1957 speech where he shared the anecdote about planning, so that you can hear it directly from Eisenhower himself:

What is software planning process?

Now if we look at the history of how the field of software planning has developed over the last 70 years, right after the end of the second world war, we will notice that initially there was a lot of focus on planning as a predictive activity. While, more recently, in the past decade or two we have seen planning processes evolve to take a more adaptive role in software development. Several such frameworks like SAFe , LeSS , XP etc. claim to help enterprises scale their software development processes.

The average size of what constitutes a complex software has also grown exponentially from 10s of thousands of lines of code to 100s of millions of lines of code. There is a clear difference between programming in the large v/s programming the small . While we seem to have gotten a lot better at abstracting and composing programs together, despite all the fancy agile frameworks we still struggle to complete complex large IT projects. In fact, a McKinsey study of 5,400 IT projects found that on an average, over 2/3 of software projects overrun their budget and 1/3 of them overrun their schedule.

The planning fallacy

One of the biggest mystery around project planning is that people consistently underestimate the risks that impact project delivery. So, even if they are aware that most projects are over budget and delayed, if you ask someone while starting a new project they always tend to underestimate the scope and time required to complete it. This is true even if they have personally worked on a similar project in the past that was delayed. In a paper on the subject, author Jeffrey K. Pinto identifies it as optimism bias. Optimism bias makes people see any new project plan with rose-colored glasses and overrate their ability and skills.

Another cognitive bias that impacts planning is anchoring . Initial estimates about a project are generally not accurate. Any subsequent adjustments made to the schedule are made with respect to the original estimate as anchor. This prevents the plan from evolving at a later stage. Even if the anchor is too low or too high, modifications are incremental and always linked to the first estimate. Understanding the psychology behind why individuals on development teams make such recurring errors can help us to account for them, or avoid them altogether.

SAFe, LeSS, XP, DaD: much ado about nothing

In a classical article on project planning, author Steve McConnell described the nine deadly sins of project planning. The article is a great read even today and busts several myths about project planning. One of them is the indiscriminate application of frameworks like SAFe, LeSS, XP etc. without understanding the context and needs of the development teams. In fact, there is complete lack of such frameworks at major tech companies like Microsoft, Google and Facebook. This was recently noted by Gergely Orosz in an article on his blog:

Most successful big tech companies seem to operate on a very simple - plan, build, ship and repeat based iterative process for product development. Another thing to note is that each team is empowered to decide and choose the overall process as per the needs of the developers and engineers on the team. It mirrors my own experience of working at Microsoft back in the day, in fact Steven Sinofsky (former President of Windows Division) has written about this in an article on "Getting (the Right) Stuff Done" .

He describes his golden rule of planning is to never ask for something from someone that does not directly help them to get their own work done. This shows clear understanding of the fact that different teams have their own way of working and developers respond to incentives. Forcing a methodology on a development team from the top is not how great products are built. It requires mission driven teams that work closely together because they have a clear understanding of the goal and are empowered to chart the course towards it.

Root cause of project delays

Now everyone has their own opinion on why projects get delayed. But when I looked at some of the academic research in this area, I found very few empirical studies on the subject. In one such paper , authors Dov Dvir and Thomas Lechler looked at a sample of 448 projects to study the interaction between planning variables and project success. They found that all successful projects, no matter how innovative they are, have a considerably lower level of goal changes, than failed projects.

Grand planning cannot substitute for simplicity of design.

Minimising goal changes helps to keep tasks simple and easy, which in turn leads to on-time delivery. One of the misconceptions many people have is that a better plan or a more experienced team can lead to project success. Unfortunately, there is very little data and almost no academic studies to support this. In fact in an empirical study of various factors and their impact on project success, authors found evidence to the contrary. Human factors like experience of PM, experience of the team members and the effort spent on planning do not impact project performance.

Taken together, these two observations seem to suggest a strange dichotomy with project planning. On one hand, for new product development or innovative projects it is hard to identify the scope. While, on the other, the key characteristics of successful projects are the lack of goal changes and allocation of all resources. How does one reconcile their project plan with reality of product development? In a recent paper on the subject, authors James Derbyshire and Emanuele Giovannetti offer a solution by combining the usual forecasting approach with scenario planning.

Scenario planning vs forecasting

Traditionally most project planning activities are linear in nature and are aimed at reducing uncertainty in the process. Planning a future product based on the present information and data is essentially an act of forecasting. This approach fails to take into account the wider socio-economic and technology trends. Also, for a new and innovative product, there are many things that we may never know. Or, as Donald Rumsfeld would say the unknown unknowns. These unknowns may eventually be responsible for the ultimate success or failure of the project.

There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know. - Donald Rumsfeld

Scenario planning embraces the inherent uncertainty about the world and starts by analysing the different forces that may impact a project. These forces depend on the type of business one is in, but can typically be grouped into social, technical, economic, environmental, and political trends which are known as STEEP. Once we have identified the trends impacting the project, we can group them according to their impact and uncertainty. This leads to the following matrix of possibilities:

The high uncertainty and high impact factors are the ones that make it hard to predict and plan for the future (like Rumsfeld's unknown unknowns). For each of the factors with critical uncertainties we need to plan for both positive and negative outcomes. Each such outcome constitutes a particular scenario worth investigating for the project plan. Even though scenario planning sounds simple on the surface, you can imagine why it would be hard to implement. When was the last time you have saw a project plan that contained anything other than the successful outcome at the end? If we have to deal with the uncertainty that comes with any large scale product development, we need to be willing to prepare for multiple outcomes in our plan:

Portfolio management with scenario planning

What would a multiple product portfolio look like if we consider scenario planning as part of the process? Going back to the beginning, in a framework like SAFe, we use PI planning to find the right balance between multiple teams, considering elements such as, risk vs reward, maintenance vs growth, and short-term vs long-term projects. This tension between different competing priorities pulls the business into different areas over time. The resulting emergent product portfolio looks something like below.

On the other hand, scenario planning can help structure the different outcomes based on identified trends and assumptions. The will help envision several possible futures and then we can work backwards to identify the projects to focus on that will lead to a successful outcome no matter whichever scenario materializes. With scenario-aware project planning, an existing portfolio can be evolved systematically as shown below.

Final thoughts

The discipline of project planning has a rich history and has come a long way over the last few decades (beginning with the end of second world war). Planning is one of the very first tasks while getting started with new product development and yet most projects are over-budget and delayed. It doesn't matter how innovative the project is or how experienced the team, when it comes to project planning, deep rooted human behaviours like optimism bias and anchoring have a huge impact on the success of the project. Existing methodologies and frameworks (like SAFe) are geared to avoid uncertainty and drive clarity in the planning process. By embracing the uncertainty that is inherent in any future scenario we can derive flexible plans that account for various project outcomes.

Breaking the Build is an attempt to understand the human side of software development. Each issue draws upon decades of empirical research and insights from academia, enterprises, startups and open-source communities; to unravel hidden incentives, bust myths and challenge long held beliefs about building software.??

Please subscribe to join and follow along in this journey!

More resources

• If you are curious about how you can automate continuous planning in SAFe, do try out the Sapling tool or check the source code for details. You can also refer to the accompanying paper [pdf ] by Darius Foo , Jonah Victor Dakis Dela Cruz , Subashree Sekar and Asankhaya Sharma .
• The Pragmatic Engineer by Gergely Orosz .
• Hardcore Software by Steven Sinofsky .
• Plans are nothing, changing plans is everything: the impact of changes on project success [pdf ] by Dov Dvir and Thomas G. Lechler .
• Nine Deadly Sins of Project Planning by Steve McConnell .
• Lies, damned lies, and project plans: Recurring human errors that can ruin the project planning process [pdf ] by Jeff Pinto .
• Key project planning processes affecting project success [pdf ] by Ermias Tesfaye , tekalign lemma , Dr.-Ir. Eshetie Berhan Atanaw (PhD) and Birhanu Beshah .
• Understanding the failure to understand New Product Development failures: Mitigating the uncertainty associated with innovating new products by combining scenario planning and forecasting by James Derbyshire and Emanuele Giovannetti .