When we work with IT teams, one area that we emphasize is the importance of understanding the business value of what we’re working on, whether that is at the feature, product, or portfolio level. We typically do this using a collection of models that we use to focus on business objectives: Business Objective Models, Objective Chains, and Key Performance Indicators. All of these help us to make important decisions about where to focus our work, and they help us to prioritize the delivery of features within a project. At some level, we use these as well during portfolio management, as we try to determine whether projects should be funded or not.
This is where it gets tricky.
Most IT organizations aren’t arbitrarily scalable. You can’t magically summon developers and BA’s with domain and technology experience. This drives most IT organizations to do annual planning based around best guesses for what capacity needs might be for the year. There’s nothing inherently wrong with this, and it’s hard to run an enterprise IT shop without significant annual budgetary planning. However, when our demand for IT resources exceeds capacity (which happens on a regular basis), we need to be careful about how we choose what projects to fund.
Mapping business objectives to business outcomes, and carefully looking at the Objective Chains for the features that we’re building helps us to define the value of a project to the business. Unfortunately, the “value” can be more complicated than a simple ROI calculation.
When we train business analysts and product owners on “business value”, we generally fall back on one of two ways that software generates value: it increases revenue, or it reduces costs. Once we understand the business value of a software project, we can begin to prioritize projects that bring the greatest value.
Or can we?
If I know that a project will cost me roughly $3M to implement, and have an cost savings of $6M over 2 years, is that sufficient for me to make a decision about whether to proceed? What if it’s compared to a project that will cost the same, but instead of a cost savings will generate comparable revenue over the same period? Are the projects equal in value?
In addition to the simple ROI calculations that we make, it’s important that we understand how our portfolio is supporting overall corporate strategies. If you look at the strategies that typically emerge for C-level planning sessions, you’ll see various items relating to customer retention, customer acquisition, revenue growth, process automation, and compliance. These goals typically fall to different C-level executives, who have very different objectives for the year.
This potentially suggests a different approach to value: rather than mapping to the ultimate value statements (makes money, saves money), should we in fact be mapping projects to the corporate strategic goals? That put executives in a better position to reach agreement between themselves, rather than using IT as a battleground for resources. As we focus more on how projects impact strategic goals, we’re actually able to heat map the way that IT supports strategic goals, which better positions CIO’s to talk about the direct contribution of IT to the strategic goals that are specific to the organization, rather than the direct value of the project.
