Why Are We Doing This Project, Anyway?

by Bill Bliss on March 13, 2011

in Aligning All Investments

The overview of Roadmap Integrity Process shows a bubble chart of software projects with cost/effort on the horizontal axis, and estimated uncertainty/risk on the vertical axis. The size of each bubble is the estimated business impact of each project: the bigger the bubble, the more impact the project is estimated to have:

In Estimating Business Impact…Simply, I define what the various bubble sizes mean.  But first, we need to answer the question: business impact against what, exactly?

During the Roadmap Integrity Process, every project is mapped to one business objective, so one of the first steps is to define the set of product-related business goals/objectives. Many companies or business units formulate business goals for every fiscal year and/or quarter. If you have those, that’s where to start.  Not every one will be immediately relevant to your software investments, however. For example, consider the business goal of “Open a European region sales office.” If there’s nothing your technology teams have to do differently to achieve this goal, then there’s no reason to include it on the list.

There will almost certainly be things that your teams work on, or want to work on, that don’t map cleanly to one of the goals/objectives on what’s left. Since every project must be mapped to a business goal, we have one of two choices: we either modify the business goals before starting the project, or we eliminate the project from the list. There are no exceptions.

At first glance, this may sound somewhat pedantic. But it’s one of the core concepts behind the process: it’s what makes the process transparent and objective. It’s based on a simple premise: either there’s a valid business reason for doing a project, or there isn’t. It’s not too much to ask to understand, and agree on, that valid business reason before investing any resources.

Furthermore, it’s a great way to make explicit those usually-implicit business goals that you rarely see on any CEO’s list of business objectives, such as:

  1. Speed, stability, cost efficiency, and quality
  2. Delivers superior customer value
  3. Maintain leadership in <some product or market>

A lot of engineering-centric projects fall into the first category—and few CEO’s will say they don’t want those things. Projects designed to win business away from competitors often are in the second or third. Projects which, if you don’t do, may mean you fail to get new customers or lose existing customers, often are in the third. It will vary by company, of course, but a little discipline means that everyone knows why they are working on a project, and it’s not just because “someone” wanted it.

It’s also one of the things that can keep you from falling into The Un-Innovation Trap—by making a specific business goal for long-term investments, or something open-ended like “innovation and market leadership,” it is very obvious when there is too much or too little investment towards “innovation.”

It’s really all about balance. In fact, the approach is modeled on asset allocation from the investing world, where you keep a mix of investments with different expected returns and risk. For example, in a recent client engagement, about 10% of the total number projects were in category 1 above; about 15% were in what I would classify as “innovation.”

The takeaway? By ensuring that every software project is mapped to a specific business objective, you can have complete transparency on the “why” behind every project. You’ll also know how much you are investing in “innovation.”

Tweet this: @bill_bliss New post: Why Are We Doing This Project, Anyway? http://wp.me/p1pkik-4Y #prodmgmt #innovation

Leave a Comment

Previous post:

Next post: