Software Project Managers: Know Your Business Case

Software project management is typically a second or third career for people with a history of getting things done on software projects as analysts, engineers, programmers, or testers. Armed with real-world experience building products, they find themselves promoted out of a hands-on role and thrust into a position of leadership, planning, and coordination of the people and organizations building products—often with little formal training for the role. Taking a project management class or reading a book can convey the basics of the discipline—processes for defining, planning, and executing projects—but the subtleties take longer to learn and master. The same can be said of learning Java: You can take a class or read a book, but this is only starts your journey to proficiency with the language and only begins to prepare you to learn advanced topics of programming, design, and software architecture.

When I ask project managers about the business cases for their projects, common reactions include eye rolls, groans, or a short pause followed by pretending that I didn't say anything.

"Business case" sounds too much like MBA jargon for most software people. One trait commonly shared by software professions is disdain for business majors. What were those business guys learning in business school that applies in the real world anyway—how to dress for success while creating credit default swaps to crash the world economy?

You don't need an MBA to manage a project, but it turns out that your project's business case is your friend. It can help support better business decisions and navigate the dangerous waters of organizational governance and politics. Contrary to what you might think, creation and use of a basic business case is not beyond your pay grade, and it serves you and your project.

What Is a Business Case?
Strip away detailed financial analysis, complex templates, and business school jargon, and a business case is a pretty basic thing: a description of why we believe a project is a good idea for the sponsoring organization. This often takes the form of:

• We assume the project is worth $X.
• We assume the project will cost $Y.
• $X > $Y; therefore, this project is a good thing.

This looks simple—almost insulting. The idea of a business case is simple and easy to understand, but the business case itself can be complex and, as a consequence, often hasn’t been thought through. 

Assumptions About Value
Before a project launched, someone in the nosebleed section of the org chart said something like:

We really need the product/service that project Alpha would provide. I bet it would be worth at least $X in terms of:

• Actual revenue
• Cost reduction
• Customer satisfaction
• Market position
• Improving our capacity to do similar projects
• Public relations value
• Contribution to some larger strategic objective

The process in some organizations is pretty informal, but we have to hope that someone, somewhere, is thinking about these things before we get too invested in the project. What should give you pause are the questions: Who made those assumptions about value? What were they based upon? What was the ultimate first guess about project value—in the form of a number or range? 

Why do you care? The organizational will to complete a project derives from organizational leaders who choose to sponsor it. As long as the project is a priority for them and they remain in power, it is a priority for the organization. Information key to managing your project includes insights into who the project’s sponsors are and what their assumptions were. This is important because the assumptions that may have been reasonable when the project began