Uncertainty is the secret sauce of the Roadmap Integrity Process. It’s the missing piece of the puzzle in planning software projects and creating a product roadmap, and it’s what makes the process unique.
Over the years, I can’t count the number of times I have been involved with projects that didn’t go as well as planned. There are many reasons, but two of the most common are:
- Failing to deliver expected business results despite careful planning, detailed requirements, and seemingly good execution
- Missed delivery dates (especially painful when people have made external promises and commitments that can’t be kept)
There’s a common saying in the US, “Hindsight is 20/20,” meaning it’s always easier to see things more clearly after the fact. It’s true for software projects too. Looking backwards, you can usually identify what went wrong:
- Things you didn’t know or consider, but if you had, you would have done things differently
- Conversations that didn’t occur, but if they had, you would have done things differently
- Things you did do but shouldn’t have
- Things you didn’t do but should have
What if there was a way to know these things in advance?
Obviously that’s impossible…but you can have the next best thing.
photo © 2007 Anders Sandberg | more info (via: Wylio)First, an analogy. Let’s say you walk into a completely dark building. The lights aren’t working, you don’t have a flashlight, and you have to get from the entrance to another room in the building. How long will it take, and how likely is it that you’ll run into something? Of course, your answer will vary based on your familiarity with that building. You’d give a different answer for your own house or office versus your favorite grocery store versus a building you’ve never been in before. Instinctively, you know in an unfamiliar building, it will take longer and you’re going to bump into more things along the way, whereas in your own house or office you’d probably do it quickly and would rarely, if ever, bump into anything.
But what does that have to do with software projects? Simply put, executing on every project is like walking through a dark building. And just as you can fairly accurately estimate the difficulty of navigating through a dark building if you know it’s familiar or not, there’s a simple question whose answer predicts how long it will take and the likelihood of bumping into things along the way:
How well do we understand how to solve this problem?
There are three possible answers:
- Low – we’ve done things like this before and don’t expect this to be significantly different
- Medium – we’ve done things that are kind of similar, but there are significant differences
- High – there are a large number of unknowns and open issues, including ones we haven’t thought of yet
But there’s a bit more to it, because on a software project you’re not walking through the dark building alone. It’s more like a slow relay race where different people are responsible for different parts of the journey. How does this change things? For one, consider the case where the building is your own house or apartment. It may be familiar to you, but it’s likely to be unfamiliar to everyone else. If it’s your office building, it’s likely to be familiar to everyone. You get the idea.
That’s why project uncertainty is the sum of uncertainty from several perspectives: product management (what does it have to do?), development (how is it going to work?), and any others that have tripped you up in the past and are likely to do so in the future: product support, field sales, marketing, legal—it varies by company.
When I’ve used this technique on teams that I’ve managed, I found the following:
- Assessing uncertainty is fast and easy. After answering this question for 5-10 projects, people quickly get the idea and can usually assess a candidate project’s uncertainty in under a minute, even if the description is only a sentence or two. When it takes longer, usually the project’s scope or description is refined in the process, and team members are on the same page about what the project is or isn’t.
- Projects are innocent until proven guilty. When there’s a type of uncertainty outside of product management or development, usually it’s because there have been some failures in the past. Maybe a feature is easy to design and implement, but requires 100 servers that aren’t in this year’s budget. Maybe a feature requires customer service agents to receive special training or to create special processes. Maybe the field sales force needs special sales materials. It could be anything. The funny thing is, on any given project, the odds of a problem occurring might be low, but when there is one, often it’s a doozy. With this approach, it’s easy to identify projects for which there is such risk, long in advance, without burdening the 90%-plus of other projects for which there is little or no risk.
Last but not least, uncertainty is not static. If you go ahead with a project, over time uncertainty (and therefore risk) decreases as you learn and prepare more. The dark building becomes more familiar to more people on the team over time. The key is that you know what you’re getting into before you enter the building, so you have time to prepare and set expectations appropriately.
The takeaway? By asking a simple question for every project, there is a simple way to assess uncertainty and execution risk for software projects, incorporate it into your roadmap planning process, and to manage risk on an ongoing basis.
Tweet this: @bill_bliss New post: The Secret Sauce: Managing Uncertainty and Execution Risk http://wp.me/p1pkik-2U #prodmgmt