The KM Business Case: Assessing the situationMarch 12, 2007 at 4:32 pm | Posted in business case, knowledge management | 4 Comments
When talking to clients about business cases for portal, content management, collaboration, or intranets I have found that they jump too quickly into their spreadsheets or lists of benefits. Before jumping into the number crunching, it’s worth taking a step back to look at what is really being asked for. The intention of this list is to help business case authors to be aware of the catches and pitfalls, to know the questions to ask of their peers and financial folks, and to lay out the territory so they can avoid unnecessary work and find the path of least resistance to gaining approval.
Some questions to ask to assess the situation before diving into the business case:
Why me? Did every initiative have to have a business case? Did e-mail?
Business Case vs. Business Plan: Are you producing a business case (presented to a decision maker who will judge whether to proceed with the direction recommended in the plan) or a business plan (done after a business case is accepted and contains all sorts of things the judge probably does not need to know such as the phasing and schedule, staffing plan, and project plan)?
Business case vs. ROI: A business case is not necessarily numerical. Providing a spreadsheet when the boss expected a textual business case can sink your project, or at least waste a lot of time.
ROI, NPV, IRR, payback, TTV: If you’re doing quantitative analysis, do you have a choice of method? Are the time period and discount rate specified? If not, this just becomes an exercise in picking the most favorable parameters you can get away with.
Conceptual vs. Concrete: How fuzzy (“collaboration in the workplace”) or concrete (a specific product) is your initiative? Do you have the option of how to scope it? Business cases can be at many different levels: Technology, program/project, Organizational, and Conceptual
Project vs. infrastructure: A project has a discrete beginning, middle, and end. Infrastructure is ongoing. Quantitative analysis such as ROI was made for discrete projects and is difficult to apply to infrastructure where one does not know exactly all the ways in which the enabling infrastructure will be used. Also, the infrastructure simply makes other assets more efficient (people, systems), rather than directly providing benefit itself, so determining what percentage of improvement is due to the boost provided by the infrastructure is like trying to determine how many milliseconds faster a runner is because of the vitamins she is taking. One common way around this problem is to “projectize” the infrastructure: to take one major and immediate way in which the infrastructure will be used and justify its entire cost based on that project, treating the rest as free icing on the cake (“And we’ll get to use it for other things too …”).
Hard vs. soft: You can think of both costs and benefits as being on a hardness scale like the 1-10 one used in the Mohs Scale of Mineral Hardness. Provable, measurable impact to a company’s profit through increase of revenue or decrease of expenses, accurately attributable to a direct cause, is a diamond (10). And it’s equally rare and valuable. On the other hand, “It will save every salesperson 5 minutes per day” is talc (1). Simple, easy, and soft. Helping to decrease printing expenses by providing information online is maybe Orthoclase Feldspar (6. OK, I looked it up on Wikipedia). No non-investment business could function if it required a rating of 10 on benefits and costs for everything it did. Some faith (faith = (10 – hardness rating) * 10%) is generally involved.
Net benefit vs. status quo: Generally the status quo – the current state cost of doing nothing and proceeding as always without the infrastructure project – is incorrectly assumed to have a cost and benefit of $0. This math ignores the possibility that the status quo itself may have costs and benefits, particularly if the environment is changing in some way.
Prioritization vs. financial testing: The effect of the project on the time and money of the company and attention of your team and those touched by the project (including the end users) needs to be prioritized against other potential projects. On occasion, KM project owners jump through many financial hurdles only to find their project rejected anyways since other projects were deemed more important or worthy of the effort.
Lottery vs. followup: Is the business case treated as a lottery where winning results in a pile of cash showing up at the door? Or does the eye of the finance department continue to watch you after you win approval? You should have to show you actually used the resources allocated for the project in question and got the benefits you promised.