Project Management

Planning: When Have We Done Enough?

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

About this Blog

RSS

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


In the previous blog we examined what the value of planning is, so that we can then determine how much planning we need to do.  The answer to this question was “it depends,” and the implication was that we need to do just enough planning for the situation that we face and no more.  In this blog we go deeper to explore what this depends on in practice.

We learned in the previous blog that our planning efforts should be sufficient, what we referred to as just barely good enough (JBGE) in Agile Modeling, for the situation that we face.  The following figure depicts the contextual factors that we should consider, with the factors motivating us to do more planning on the left-hand side under the red arrow and the factors enabling us to do less planning on the right-hand side under the green arrow.  These factors are mostly qualitative in nature, implying that it requires a judgement call on the part of the people involved with the planning effort to determine whether they’ve planned sufficiently. Let’s explore each of these factors in more detail.

Figure. The factors to determine whether you’ve planned sufficiently.

There are four factors that motivate us to increase the amount of planning we do:

  1. Risk. The greater the risk that we face the more we will want to think before we act.  For example, transporting perishable medical supplies from Toronto to Timbuktu requires more logistical planning than transporting a box of Choose Your WoW! books from Toronto to Philadelphia.
  2. Domain complexity.  The more complex the problem that we’re trying to solve, the more we want to invest in exploring the domain and then thinking through how we will address the complexity.  For example, building a bridge across a river is more complex than building a dog house, so we will invest more time thinking through the building of the bridge.
  3. Solution complexity. The greater the complexity of the solution that we are building, or configuring in some cases, the more thinking we will need to do.  For example, installing an ERP system into an existing organization to replace dozens of legacy systems requires more planning than installing a new app on your phone.
  4. Desire for “predictability.” This can be a common cultural challenge within organizations, in particular the desire to be told up front how much a project will cost or how long a project will take.  These are fairly reasonable requests when the endeavor is something our team has experience in doing, such as a house builder being asked to build a new house. They are unreasonable requests when the team is being tasked with doing something that is ill-defined or whose scope will change throughout the endeavor, the situation typically faced by software development teams.  Far too many times I’ve seen teams run aground due to an unrealistic request for predictability – the teams will overly invest in up-front modeling and planning, will then make promises regarding cost and schedule that either they’re unable to keep or can only keep by cutting scope or quality of the delivered solution.

There are six factors that enable us to reduce the amount of planning that we need to do:

  1. Skill.  The greater the skill of the people doing the work, the less planning will be required for that work. 
  2. Experience.  The greater the experience of the people doing the work, the less planning will be required for that work.
  3. Ease of change. The easier it is to change the work products being produced, including the solution itself, the less planning is required.  For example, we are developing a website it is relatively easy to update and then redeploy web pages if we discover that they need to evolve.  So we can get away with minimal planning.  Conversely, if we are building a bridge spanning a river it is relatively difficult and expensive to rebuild a supporting pillar in the middle of the river if we discover that it was placed in the wrong spot. In this case we face greater deployment risk so we need to invest in greater planning to increase the chance of getting things right.
  4. Access to stakeholders.  The easier it is to access stakeholders, in particular decision makers who can provide direction and feedback to us, in general the less initial planning we need to do.  Being able to work closely with stakeholders enables us to think through the details when it’s most appropriate during a project, not just up front.
  5. Communication and collaboration. The greater the communication and collaboration within a team, perhaps because we’re co-located in a single room or because we are using sophisticated communication software, the less planning is required due to the increased opportunities for streamlined coordination. 
  6. Uncertainty. The more likely that something will change the less planning you should do because when it does change your planning efforts around it will have been for naught. 

To summarize, the answer to “when have we planned sufficiently?” is “it depends.”  In this blog we explored several factors that motivate you to increase the amount of planning we need to do and several factors that enable us to reduce the amount of planning.  In effect we went beyond the typical consultant answer of “it depends” to the more robust answer of “it depends on this.”  

In the next blog in this 3-part series we explore how to be efficient in our planning efforts. I suspect the answer it won’t be what you’re expecting.

Posted on: November 04, 2019 09:42 AM | Permalink

Comments (12)

Please login or join to subscribe to this item
Another driving factor for the amount of planning is the amount of control that you want to have in the project.

More specifically, it's in the granularity. If monitoring the performance on a weekly basis, you'll need more granularity of planning than you would for a monthly statusing of performance

Good reminders, Scott!

The level of uncertainty - i.e. how foggy is the road ahead also affects how much we plan. The foggier the conditions, the shorter the horizon for planning and the greater the optionality we should allow for...

@Greg, I disagree. My experience is that you can disconnect the two concepts of planning and monitoring. I've found that managers who track against a detailed plan tend to motivate a lot of additional stress for team members which reduces their productivity and motivates them to lie about what they're actually doing. I've lost track of the number of times where I've seen people who are asked to report what they did that week, often for a combination of progress tracking and time tracking, to go to the plan and basically report that they pretty much did what was assigned to them, NOT what they actually did. The end result was that false status was reported up the food chain, often for the goal to get management off their backs. And they rarely get caught doing so.

If there's a need to monitor closely, you're better off to take a rolling wave approach to planning and do detailed planning on a just in time (JIT) basis regularly throughout the endeavour. In effect you're monitoring as a side benefit of the JIT planning because the planning effort starts from where you currently are at the time.

Also, on the monitoring side of things, I'd try wherever I can to ensure that any data coming out of the tool usage by the team is being processed and reporting accordingly on the team's digital dashboard. This is very common in the IT space. Outside of IT not so much (yet).

@Kiron, very good point. I was having a similar conversation yesterday at the PMO Symposium with someone. They were struggling with detailed planning in an environment where rapid change was occurring, causing extreme fogginess as you'd say. My advice was exactly what you said, plan in detail in the short term and do your best to steer towards a vague long-term objective. I will update the diagram and blog accordingly later this week (I hope).

hey Scott...good discussion; nice simple diagram. I think many of the experienced and effective PMs on this forum apply this approach and thinking whether they know it or not.

And....(just for fun) be careful...you could end up back in the waterfall...:)

Al, good point. Sometimes waterfall approaches make sense. Right-fit your approach to the situation that you face.

Dear Scott
Interesting reflection on the topic
Thanks for sharing

We agree on the 4 factors that motivate us to increase the amount of planning and the 5 factors that enable us to reduce the amount of planning.

It is easy to place them on both scales when analyzed at the individual level.

It will be harder to do when it comes to an organization

I am curious and expectant about "we explore how to be efficient in our planning efforts"

I totally agree with your comment, Scott, regarding separating planning from monitoring.

More frequent monitoring [maybe with high visibility of work in progress, probably through card walls and burn down charts] allows for more frequent course correction - more agility. In fact, it's really continuous monitoring as team members responsible for performing the work move their own cards on a card wall, hopefully causing automatic updating if burn down charts.

@Scott - I am so intrigued by your comment "I've found that managers who track against a detailed plan tend to motivate a lot of additional stress for team members which reduces their productivity and motivates them to lie about what they're actually doing. I've lost track of the number of times where I've seen people who are asked to report what they did that week, often for a combination of progress tracking and time tracking, to go to the plan and basically report that they pretty much did what was assigned to them, NOT what they actually did."

Are you saying people may not be as much on track for a task as they reported just to get the PM off their back? Or that they did more than what is on the plan, but don't want to elaborate?

Interesting!

Eileen, good question. I should definitely elaborate.

What I'm saying is that the person is doing whatever they believe they need to do to get their job done. Then when asked to report what they did that week they find it easier to claim that they did what was on the plan for them, not what they actually did. They do this because it's unlikely the PM will catch them and it's easier to just tell the PM what they want to hear so as to get the status reporting out of the way.

I've seen situations where:
- the plan said to do X and someone did Y instead
- X hours were allocated, a task actually took Y hours
- X was supposed to do the work but Y did it instead
- Someone was suppose to work on project X but worked on Y instead

Yet in all of these cases, and more, X was reported rather than Y with the PM being none the wiser.

Good one to learn, Thanks for sharing!

Please Login/Register to leave a comment.

ADVERTISEMENTS

"A child of five would understand this. Send someone to fetch a child of five."

- Groucho Marx

ADVERTISEMENT

Sponsors