Agile, Project Management, Requirements

When is a plan good enough? Provisional Project Planning

As I’ve taken the journey along the Agile path I’ve come to learn two things I am certain about:

1) A detailed Work Breakdown Structure is one of the largest wastes and mistakes that can exist in a project

2) That not creating a temporal plan at some level can also lead to rework and failing late

On the surface, these comments may seem to be contradictory. I seem to be supporting neither traditional or Agile. And I would agree that it can appear in this way. But like most good solutions, the optimal solution is a compromise between extremes.

In my blog about whether Flow can be used on projects, I emphasize the need to plan. (if you are interested, you can find the blog here) I then continue the planning discussion in my Agile Chicken Little blog. (which can also be found here)

My intent of both posts was to communicate my thoughts on the fact that some level of planning is crucial. But when do you know when the plan is good enough? When is it excessive?

Too Much

I must admit I was someone who used to create detailed work breakdown structures. I even used to assign multiple people to one deliverable and have multiple items in progress. Looking back now I see that this was excessive planning for little value. The detailed project plan was also not an accurate depiction of how the actual project would execute.

But even when I started working on more Agile projects, I still sought out a moderate detail plan to try to comfort myself. I thought that we needed a full prioritized backlog of items. I held frustrating meetings with clients asking them if item 101 was more or less important that item 102. (If you were in one of these sessions with me, I apologize and owe you a beer)

Too Little

But as I stated in my prior posts, the creation of a temporal plan is critical to allow the team to think through the project process, dependencies, and possible conflicts. To start to do the project using just Flow may not allow you to fail fast. You may discover a dependency or conflict late in the process. It is possible that an initial plan would have highlighted this issue.

But creating a project plan at the start can create assumptions and issues all on its own. So what to do?

Just right – Provisional Project Plan

It the game of golf, there is a wonderful concept of a provisional ball. In the case where you have already launched a ball into the woods, you hit a provisional in case you cannot find the ball. It is seen as a time-saver to keep the game moving.

I use this analogy when I create my high-level project plans.

My provisional project plans are:

  • Only one way out of many to execute the project – it is not the one correct way
  • It is high level to get me to when I can look for more detail to refine the plan. (i.e. finding my first ball)
  • It sets the expectations with the clients that the plan will change, but that we have at least thought through one way that the project could be delivered.

We then use flow to prioritize the next group of stories in the project. Once they are prioritized we use flow to execute.

Summary

In my experience, these Provisional Project Plans provide the right level of planning. They allow the team to think through the execution of the project without committing to ‘the’ plan. It also then provides the ability to execute in a flow-based structure within the Provisional Project Plan.

Special thanks to Luke Hohmann who illustrated the waste of creating a full prioritized backlog through the use of Innovation Games. By prioritizing and executing in groups of 10-20 items, we are able to efficiently work in a flow mode. (And update our Provisional Project Plan as we execute)

About Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

Discussion

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: