Part 8 - Building a Business Case: Where we go from Here
In my last post on this subject, I want to talk a little on where we go from here.
The driver behind writing this series has been the fact of being asked for a business case structure again and again and again, but only finding high-level phrases like “align IT with the business”, “improve our service delivery”.
There are some who will state that you don’t need a structured business case – you just need support from the executive suite, and if you don’t have it, there’s no point in moving forward. Effectively, faced with a CIO who’s being challenged to articulate how EA will help, with concrete examples, these people are saying “ah, in that case you’re screwed.” I'm trying to be a bit more helpful.
So to finish, I’m going to muse on how my initial scribblings here might be taken and improved by someone with more brainpower than myself – either in a generic sense, or to tailor them more closely to the concerns of a specific organization.
The basic structure was as follows;
There are three ways that I can see this being improved.
Different categories of benefits and costs.
The five categories listed are somewhat arbitrarily chosen – like any taxonomy. There may be better ones, especially in so far as matching up with the specific concerns of the organization. Looking at the strategic plan for the organization (or the IT department if the corporate level one is not available) may give some insight into what categorization speaks to the executive suite.
Different components of the categories.
As I’ve said before, the biggest benefit of this exercise is in thinking through precisely how EA will help each area. There may well be other components that I’ve not considered.
Different metrics for the categories
For each component of each category, I’ve identified a way or multiple ways to measure the effect on that component. In doing so, I’ve utilized the approach proposed by Hubbard in “how to measure anything” – ask ‘why do I even care? What would I expect to change? How does it even affect me?’ and then from that ask ‘how would I know that the thing I’ve cared about has changed?’ You can apply this to new components of categories, or the existing ones above to obtain metrics that seem more convincing. Hubbard’s book is a good starting point.
In any model, you can change figures around and produce the result that you want if you’re really determined. If that’s the culture in an organization, then that’s a bigger issue than you can address with a business case, and out of the scope of the purpose here.
But in the course of writing this series I’ve become doubly convinced that there is value in the business case exercise whether an organization is dysfunctional or not, whether the board supports EA or not. Independent of trying to prioritize investments, the value is in that it forces you to think about what end results you hope to achieve and what you are going to need to do to accomplish the task. Having this clearly thought out will be invaluable in selling the idea – upwards, to the executives who need to support this effort, and downwards to the architects whose jobs it will change.
If you missed the beginning of Peter Harrad's series on Building a Business Case for an Architecture Model - work your way through from part 1. here