We've already established what makes a good information management (IM) business case from a high level, i.e., addressing meaningful business value rather than “save everyone time searching for documents.” But the devil’s in the details, so I want to dig down a bit more to give you all more specific guidance on building an effective IM business case.
Bottoms Up, Top Down
One way to build an IM business case is bottoms up, i.e., start from IM capabilities and work your way up to where they intersect with business value: applying social collaboration capabilities, for example, to the work customer service reps do to handle issues and resolve problems. This can be effective, but often leads to an IM-centric view of ROI that shows poorly against more business-centric initiatives. It’s also difficult to bring focus to your business case, because while the set of IT capabilities make sense grouped together, the business benefits tend to be a dog’s breakfast from around the organization.
For both of these reasons, I’ve found a top down approach to be more effective, i.e., start from a business need and work your way down to what IM capabilities will meet it: for example, determining the challenges customer service reps face handling issues and resolving problems and then tying them to the social collaboration capabilities that will address them (and only those capabilities).
A Rose by Any Other Name
The difference between the two approaches isn’t just semantics -- the reason why the top down approach works better is because the bottoms up approach too easily leads to the hammer looking for a nail syndrome. That is, I’ve got this great set of technology capabilities and, darn it, I’m going to get the most value out of them and use them to the fullest … which is great if you’re interested in measuring how well you utilize technology capabilities.
But in the world of funding enterprise initiatives, you succeed or fail based on how well you can impact the business positively. And to do that, you need to start from the business need and work your way to the technology capabilities required by that need.
Let’s look at some specific examples to illustrate the top down versus bottoms up approach.
Bottoms Up in Action
Let’s say you work for a large manufacturer, and you want to deliver improved document management (DM) to your plants. A bottoms up approach would start from a list of DM capabilities something like the following:
- Version control
- Check in/check out
- Audit trail
- Link sharing
- Faceted search
Then, you would work to apply these to as many important business processes at your plants as possible, and your list would look something like this: