Why Are We Doing This Project, Anyway?

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:

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:

Speed, stability, cost efficiency, and quality

Delivers superior customer value

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.”

About Roadmap Integrity

Roadmap Integrity is a consulting company founded by Bill Bliss with one simple goal: to help senior managers make their companies more effective at creating great software that delivers maximum business impact. It's based on what Bill's learned after almost 25 years of software projects at Microsoft, Expedia, and several smaller companies and startups.