Planning for Value

“Reduce your plans to writing. The moment you complete this, you will have definitely given concrete form to the intangible desire” – Napoleon Hill

“Plans are of little importance, but planning is essential” – Winston Churchill

“No battle plan survives contact with the enemy” – Colin Powell

One of the most significant contributions of the Agile community has been the realization that creating software is an uncertain business. Unfortunately, this realization has led some of us to the conclusion that the act of creating software cannot be planned. There is a big part of me that can empathize with this point of view. What’s the point of creating a plan if we know the business objectives are going to change, requirements are going to change, and even technologies are going to change? I have worked in many traditional projects where change management was the single biggest part of my job. Why not just get going and see where we end up?

The challenge is that business planning doesn’t work that way. Product owners are asked to create their business cases months in advance of the upcoming fiscal year. Once funding is approved those guys are on the hook for the revenue. This is a big part of our reluctance to let go of the big up front planning processes. As businesses, we want some sort of assurance that we can deliver on our revenue targets. To these companies, funding a project with only the promise we’ll get the most important features first is not very reassuring. We must KNOW that those features are going to deliver the EXPECTED value. Our jobs depend on it.

When the context we operate in is uncertain, we have to plan for that uncertainty. To do this, let’s look at the following three planning alternatives:

Make sure the project will yield an acceptable return with less than 100% of the desired features.

Sure… I want a crystal ball too. Problem is we don’t have one. If we have a firm date, a firm cost, and a fixed set of features; odds are we are going to fail. If time and cost are king, we have to be flexible on features. We need to know up front that we can go to market with less and still produce acceptable value to the company.

Commit to high level features so team has room to negotiate through the life of the project.

In most corporations, there are at least a few other teams that must know ahead of time what you are going to deliver and when. Marketing comes first to mind, so does sales. For those guys to be successful, they need to know what is going to be delivered much earlier than most of us are willing to commit. Committing to high-level features gives us enough specificity to communicate about the product while allowing the team to fine tune the implementation of those features as the product progresses.

Manage the project’s value stream rather than changes to features or tasks.

We know that project requirements are going to change along the way. They should. As we build the product we are going to learn more about what we need and how best to build it. Those changes still need to be managed. The company decided to invest so many dollars to yield a particular return. Do we know how any given change will impact the value of the product? Let’s start looking at how our changes impact the metrics we really care about… value.

Let’s not be afraid to plan in the name of agility. Let’s just be smart about what we are planning and leave ourselves room within the plan to be successful. At the end of the day, it is the value that we deliver to the organization that matters, not how well we followed the plan.