Project Management

Planning: How Valuable is it?

From the Disciplined Agile Applied Blog
This blog explores pragmatic agile and lean strategies for enterprise-class contexts.

About this Blog


Recent Posts

#NoFrameworks at Agile Middle East 2020

The Art of Guesstimation: Why Shouldn’t We Estimate?

The Art of Guesstimation: Why Should We Estimate?

The Art of Guesstimation: Estimation on Software Projects

Planning: The Efficiency Zone

Categories: Planning

Winston Churchill once said “Plans are of little importance, but planning is essential.” What Churchill meant was that the value is in thinking something through, in planning it, before you do it. So this leads to some interesting questions: How much planning should we do?  How can we get the most value out of our planning efforts? I wish I could tell you that there is solid research evidence to answer this question but sadly I haven’t been able to find any (if you know of any, I’d love to hear about it). Luckily though, we do have a lot of experience and observational evidence to fall back on.

From an accounting point of view we know that value is calculated as benefit minus cost. The implication is that all we need to do then is calculate the benefits of planning, and the costs of doing so, apply a bit of math and there you go.  How hard could that be? As we know it’s very difficult to calculate the benefits because some are qualitative, requiring a bit of creativity to turn them into a monetary figure. The bigger challenge is that planning is just one activity of many that go into achieving a benefit making it difficult to tease out the planning portion of the benefit earned. Calculating the true costs of planning isn’t much easier when you start to consider the downstream implications of the work required to gather the inputs that go into the planning process.  This is a particular problem in creative domains such as software development, more in this in future blogs.  The implication is that in practice there isn’t an easy way to determine the actual value of planning, which explains the dearth of research evidence around this issue.  

Because there are no hard and fast rules to determine the value of planning, practitioners rely on belief systems to guide their thinking.  Figure 1 overviews two common belief systems, the traditional (sometimes inappropriately called “predictive”) belief system and the agile belief system.  We’ve labelled the latter as undisciplined because we will distinguish this from a Disciplined Agile (DA) strategy later.  The traditional belief system tells us that the more effort that you put into planning the more value that you will gain from doing so.  This belief system tells you to think things through in detail before you do them.  This increases value by avoiding mistakes in the future, thereby reducing costs. At the other extreme the (undisciplined) agile belief system tells us that there is very little value in planning, that you are better advised in focusing on being able to react to feedback.  This enables you to deliver sooner and thereby earn the actual benefits sooner and longer, thereby increasing value.  The obvious downside of course is that mistakes will be made, sometimes serious ones, thereby increasing both costs and risks. 

Figure 1. What our belief systems tell us about the value of planning.

The methodologist in me tells me that extremes are generally a bad thing, that for most situations the answer lies somewhere in between.  The easy answer would be to simply draw a dashed line in between the two curves in Figure 1, or get really fancy and introduce some sort of range between the two lines, but the easy answer is wrong.   What we really need to do is look at what actually happens in practice, something that we did in the Agile Modeling (AM) community in the early 2000s.

In AM we needed to determine the value of modeling so as to provide coherent advice around when to model and to what extent to model. To make a long story short, we observed that the value of modeling followed the law of diminishing returns as you can see in Figure 2.  A little bit of modeling offered a lot of value.  So did a bit more, then a bit more, then a bit more.  But very quickly we reach a point of diminishing returns, the total costs of modeling soon exceeds the total benefits of modeling – once a model is sufficient for the situation that you’re thinking through with it, you reach a point where any more modeling removes overall value.  This point is what we called the just barely good enough (JBGE) point, although others prefer “sufficient” as a term.  So why am I talking about the value of modeling? Because modeling and planning are slightly different flavors of the same thing: Thinking something through before you jumping into doing it.

Figure 2. The value of planning/modeling.


JBGE?  What?

Many people, particularly those who follow a traditional “predictive” lifecycle approach, tend to be taken aback when they’re told the most effective plans are those that are just barely good enough.  The problem is that they often interpret JBGE as insufficient, yet by definition that is clearly not the case.  If your planning efforts haven’t been sufficient then you can still benefit from more planning, or to be accurate you can benefit from good planning at the right time.  But, if your planning efforts have been sufficient, or more than sufficient, then more planning is only going to remove value.  From a lean point of view over-planning is a waste.  

To summarize, the DA belief system is that the value of planning and modeling follows the law of diminishing returns. There is significant anecdotal evidence that bears this out but as I indicated earlier the research evidence is sparse.  I’ve actively prodded researchers along when I could for the past 15 years to get this evidence, but these efforts have always floundered when they discovered that this research is very difficult long-term work.  

In the next blog in this 3-part series we explore how to determine when your planning efforts are sufficient.  Following that we work through how to be efficient at planning.


Posted on: October 24, 2019 11:59 PM | Permalink

Comments (16)

Please login or join to subscribe to this item
This is where that lean principle of deferring decision making till the last responsible moment rings true. Planning as an activity is critical and should be happening throughout an initiative's lifetime but the level of effort put into and the level of detail found within a plan should match the level of certainty at a given point in time.

On highly predictive projects, more detailed plans can add value at an early stage while on larger or more complex projects or any others where an adaptive lifecycle would be appropriate, the JBGE principle would result in lighter ones.

You should have included Mike Tyson's quote about the value of plans, Scott :-)


Actually, I have a good quote coming up in a future blog on this topic but I'll see what I can do to squeeze in Tyson's.

Dear Scott
Interesting your reflection
Thanks for sharing
He knew the thinking about plans and planning methods as belonging to Dwight Eisenhower.

Agile approaches are also planned for 2 to 6 weeks.
Or am I mistaken?

@Luis, it depends. In some forms of agile short-term planning is often done for short time frames as you suggest. In #DisciplinedAgile we suggest that you consider product planning for the long term at a very high level, release planning at for the intermediate term at a bit more detail, and short term planning for the next few weeks at very detailed levels. Basically a rolling-wave approach.

Hi Scott - Just barely good enough... that is the thinking we need in our relentless efforts to reach perfection, which we will, of course, never achieve, and, of course, don't need to!

The two graphs in your article are striking. They provide at a glance the thinking of many who are not Agile indoctrinated, and the thinking of those who are. The concept of diminishing returns as it applies to plans and planning certainly is applicable and crucial.

Do and produce what is necessary for understanding and no more. It is a difficult concept to push in some traditional organizations... but they are coming around, and in no small part due to the approach of "Disciplined" Agile.

Mike, thanks!

I think one of the reasons why traditional organizations struggle with agile is that all they've heard is the fairly naive rhetoric of the undisciplined agile folks. The solutions to the challenges that these organizations face are out there, but they need to get past some of the wishful thinking within the agile community.

I get what you're saying... It's just so rare to see enough planning at all, let alone too much. And if I say something about too much planning, I usually get a lot of support. With trying to convince people to plan *at all* I'm met with skepticism.

Great article Scott...
I wholeheartedly agree with the comments above - especially Kiron Bondale's
I worked almost exclusively in the waterfall model at a Canadian financial institution for over 20 years. I led, participated in and/or witnessed the detailed planning for all project activities. That "perfect" plan took a LOT of time and effort. I don't recall when I was introduced to the concept of rolling wave planning but I liked it and found that the more I used it the better project results were - less re-working of a detailed plan - more effort spent on creating detailed plans as they were needed. Balancing the need for a "perfect" plan with the need for speed and delivering is definitely the way forward...
How do we achieve that? How do we convince others that this is the way to go?

@Trevor, you're right, it can be hard to convince some people to invest in planning. With some people I have to wait until things go awry due to lack of planning, it's only then that they might be willing to listen.

@Anne-Marie, similarly I find that with the true-believers of detailed planning I also need to wait until they're frustrated with the overhead of reworking the plan until they're willing to consider a better way.

Here some people try to juggle between Agile & JBEG and in this process they make things complicated.

We get asked by team members quite often that if the plan will always change, why bother with it, and I often give them a analogy with golfing. Let's say the hole is Par 3, the golfer plans how to get to the hole in 3 shot and tee off, the ball lands somewhere, then the golfer review the situation, and hit the ball again with a revised plan, and that is how planning works. Not planning at all will be a golfer that look at the general direction of the flag, put on a blind folder, spin around a few times, and then tee off, and repeat the process wherever the ball lands, the chances of eventually sinking the ball will be close to zero.

Dear Scott
Thank you for this clarification about planning in Disciplined Agile
I will really have to study this project development approach

This is the best relatively simple explanation/comparison of traditional verse agile I've seen so far. I come from the traditional side based on my project experience and can see the downside of "too much planning" especially the guessing that goes into the long range detailed planning. In addition to lost effort there can be a tendency to "follow the plan" verses effective delivery of the project. The challenge is in determining the JBGE point. "How much is enough?" This depends on the nature of the project - a software project is different than a construction project and different again from a manufacturing process. I really like the idea of finding a middle ground between traditional and Agile. I see both models having benefits and risks but rather than picking one over the other I suggest a risk/benefit analysis to establish the best path for each particular project.
I think about a road trip with my wife - she's traditional needing to plan each washroom and food break for the entire trip prior to starting out. I tend to be a little more Agile, book the overnight stay (due to availability) yet go with the flow in between.

A hybrid approach, Peter. I think you nailed it. Tailoring is a big part of the choice of methods in any project.

And I like the analogy. Go with the flow. hmmm....

My fav quote on planning is “Good fortune is what happens when opportunity meets with planning.” – Thomas Edison.

Thank you Scott for sharing interesting insights.

Please Login/Register to leave a comment.


"You can't build a reputation on what you are going to do."

- Henry Ford