After I graduated from university I joined Esso as a trainee systems programmer and quickly learnt that what was taught in computer science classes was different from what was expected in the business world. There are many aspects to this, but one thing in particular that was impressed upon me was the need to build a business...
case for any nontrivial project. This, as a minimum, should include the estimated costs of the project, what risks are associated with it and the monetary value of the estimated benefits.
In my lessons on how to build a business case, I learnt about internal rate of return (IRR) and net present value (NPV) at a tender age and was taught that a project should always have positive NPV and a rate of return better than the target “hurdle rate” set by the company. (The hurdle rate varies from company to company but is intended to reflect an organisation’s cost of capital plus some margin and is typically in the range of 18% to 25%.)
The idea of this approach is that there are always more ideas for projects than capital and resources to deliver them, so by using such monetary measures you have an objective way to rank and select those projects with the largest potential business return. I rather naively assumed that all companies operated in this way, and that every significant project in industry went through such a process.
The case of the missing business case
Now that my early career years are a distant memory, I am still constantly surprised by the degree to which project justification is by no means standard in large companies. I have spoken to many people leading large projects around master data management, for example, and found that while inevitably the project budget (always in the millions) was signed off by someone, in many cases there was no business case at all. In research that my analyst company The Information Difference carried out in 2010, involving 257 companies worldwide, an amazing 68% of the respondents with live data governance programmes admitted that they did not measure the cost of poor data quality and 42% had implemented their programmes with no business case whatever.
Moreover, the biggest barriers to implementing data governance, in the same survey, were identified as “competing business priorities were more pressing” and “lack of support from other areas of the business.” These things would surely be eased by having a strong business case. At the fundamental level, senior management usually care about things that increase revenue, reduce costs or reduce risk to the company (such as complying with regulations).
If projects are undertaken without quantifying the benefits, it is difficult to engage with senior management unless the project is solely in response to regulatory risk or compliance. Indeed, it is interesting that the recent Solvency II regulations for European insurance companies, which are quite specific about the need for data governance, have sparked off a whole series of projects in the insurance industry. These companies presumably had not felt the need for such projects previously.
I have recently been doing some research into large data management projects in a range of global companies. Even in these large projects, which involved literally hundreds of staff and global implementations costing tens of millions of euros, many simply had no business case at all. No attempt had been made to quantify expected benefits, let alone to actually go back and check after the project launch whether such benefits had actually been delivered. In the Information Difference’s late 2010 data governance benchmarking research (with 134 respondents), we found a statistically significant correlation between those data governance programmes that were claimed to be successful and those for which a business case existed. At the very least, such a business case is going to help explain to people why they should support such a project.
Processes hold the key to business cases
Although many companies struggle with developing business cases for data management projects, in my experience it should not be particularly difficult to build one. Begin with examining your business processes, one by one, such as “sell to customer.” Hopefully, your business processes are documented in some way, and many companies have business process owners assigned. Talk to the appropriate businesspeople responsible for these processes and identify what are the perceived problems and bottlenecks in each process. Some of these will be due in some way to data issues. For example, there may be a high number of queried invoices, or missed deliveries, or customer returns, or disputes with suppliers. Each of these has a cost to fix; for instance, fixing and resending a delivery has a cost that can at least be estimated, and so does the time associated with querying an invoice (as does the effect on company cash flow of payments taking longer than they might).
What impact might a data management project have in each of these cases? If you could reduce the missed shipments by 50%, say, what cost saving would that have? In many cases the effects may be small, but across a large company such things add up. By considering the value associated with each process and assessing the likely cost associated with improved data management, it should be possible to see what level of savings is attainable. If the project to fix these issues is going to cost more than the likely savings, then don’t do the project. But usually the state of data in most companies is so chaotic that it does not take long to come up with some surprisingly high potential savings. To be rigorous, run the business case across a range of scenarios and see whether it still stacks up even under pessimistic assumptions.
Business case as communication tool
If you go to the trouble of building such a rigorous business case, you will have something that is a lot more useful than just ticking a box on a form. You can use the business case to articulate to people why they should engage with the new project and what benefits it will bring to them and the company in general.
In my experience, change management is one of the most difficult issues for any data management project. People inherently dislike changing the way that they do things, especially if it does not have some immediate benefit to them personally, so a well-crafted business case can be used to reduce resistance to new projects, and this may be the greatest benefit of all that a business case can have.
Andy Hayler is co-founder and CEO of The Information Difference and a keynote speaker at conferences on master data management, data governance and data quality. He is also a restaurant critic and author (www.andyhayler.com).