It has been a while since my last post but recent interactions with clients prompted me to pick up my virtual pen again. This time I would like to share my findings on how clients see the business case as a tool to prove the worth of a business initiative grounded in IT development. As a teaser; so you read the rest of the post, let me postulate that furniture assembly is a good analogy.
Over the last few months I have positioned the business case to a multitude of clients in various sectors, e.g. insurance, professional services, energy and telecommunications. Every conversation about: how, when, why, who and what the business case would involve or get done was different. As such, it occurred to me that there are two major aspects everyone engaged in such an effort has to be clear on as no standard view of what a business case is and is not exists and how its findings are best used and published. Google “Business case for Software” and you’ll know what I mean.
So what type of organization engages in such analysis? There are many forces at play when a business case is first being conceived as the “thing to do” to get attention or approval from the top brass. Absent any conclusive evidence I could locate; company size, industry, location, business model, IT savvy/budget or commercial success do not seem to play a major role in why certain organizations undertake a business case or not or how they execute it a certain way. Logic would have it that larger organizations with well-funded IT departments do it regularly and more formalized but you would be surprised. However, in most instances, it is still something some mid-level, departmental manager ends up tackling.
The forces to contend with are many and often hard to detect and size up. However, I think we can all agree that enterprise-level IT initiatives are typically approved via a democratic approach as they are inherently risky and the organizational smart money is on the visionary guys who under-promise, over-deliver and keep their heads down from the heated exchange of egos fueled by their personal tech beliefs (Inmon vs Kimball, etc.)
As a consequence, the average CIO tenure is often little longer than four years and in case you run into a CIO with longer tenure, he has learned and practiced the art of envisioning the tech nirvana, promising the obvious and delivering the possible. In case of Master Data Management, a CIO may actually have the opportunity to see the effects of an investment while not investing his full year three and four in implementation mode only. Thus, business cases are a good way for all parties involved to cover their rears, get a decent feel for the size and importance of an existing business problem they already know of and even some other (un)related ones they have not even considered. Moreover, this is even truer for fairly encapsulated, high-impact projects, like MDM, lasting less than one year but affecting many systems and processes. This factoid may also draw attention from other departments and their leadership so it may be wise to involve them early to be part of the discussion and create a sense of co-ownership and joint pain.
So what does this mean for the lead architect, sr. financial analyst, project management office consultant or head of data warehousing or application development, who get stuck the most often with following through with some sort of financial justification? Well, first you have a choice between paying a multi-national consulting firm $250k+ for doing the work (if budgets permit), doing it yourself (if time and skill permits) or finding a 3rd party to do it for you for free. There is no data on which of the three options occurs most often but if it were your little company, would you not want to go the “free” route? Let’s face it all options come with strings attached, such as buy my product and services or the CFO’s question, “Why is this more important than my team’s current work?” (Business Case for doing a Business Case)
In such case, most major software companies (for sake of disclosure: Informatica via my group as well) offer such services in various states of polish, scope and organizational invasiveness. Informatica chose to go the “light” route to deliver “Return on Data” with a much focused, custom approach with minimal amount of disruption to an organization’s daily business and with as little boiler-plate content as sensible. For completeness sake, we call it a Business Value Assessment (aka BVA).
Now that you know this valuable fact, let me not focus on how we would like to do it in our tech nirvana but explain how clients view using it. Some of the, what I would call BVA sponsors, mentioned earlier, intend to only have IT staff on various levels engaged with us. Here we often hear that the IT realm knows enough about the business problems to gather the data necessary for populating a financial model. Even if such would be the case, without the business leadership (Sales, Marketing, Service, Operations, Finance, Procurement…) involved these days no decent-sized IT project will get funded. Other clients take us immediately to the SVP/EVP levels only to find out that they may not have the necessary detail to do any analysis.
Others treat the business case as an Area 51 exercise before they go public corporate-wide with stunning findings. This will intentionally not involve potential opposition too early but runs the risk of analytical incompleteness. Others are asking us to do the analysis a week before a steering committee decision or ELA negotiations would commence. Here it sounds like an often unnecessary last-minute rubber-stamp on something already agreed upon. On the other hand, some chose to come to us for help so early, they had to re-educate involved people over and over ultimately running the danger of making a non-invasive exercise actually invasive. Maybe the visionary got ahead of himself being unclear about corporate priorities, or his de facto clout in the organization.
While there is no right or wrong way to do this, it certainly helps to follow the “manual” of the company who will do the actual “assembly”. Given their experience with their model it is always advisable not to deviate too much from their “Swedish furniture assembly instructions” but accommodate unexpected discoveries (there is no hole there, screw missing) even if you don’t know fully yet where the various screws go. As one of my colleagues once said, “A business case is as much of an art as a science.” I would love to hear your thoughts on interesting scenarios you have been engaged in and how your firm is typically making financial sense of an IT investment.