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:
- Engineering projects
- Maintenance work orders
- Set ups
- Standard operating procedures
- Employee onboarding
- Vendor management
- Supply chain
On the face of it, it seems like a great list — who wouldn’t want to positively impact all these key areas? But when you look at it from the perspective of an executive, their first thoughts will be, how can a document management system possibly improve all of these things? And won’t the change management required be massive? How will we keep the lights on while introducing such significant change to operations? What are the risks involved in tackling such a broad sweep of change?
Honestly, there really aren’t any good answers to these objections — at least not any that are going to get this executive to take out a check book … which is one of the key weaknesses of the bottoms up approach.
Top Down in Action
Let’s take a look at a top down IM business case for this same manufacturing example.
To start with, instead of looking at DM capabilities, you would look at the key challenges facing manufacturing operations, which might look like the following:
- Product quality — Latin America
- Aging workforce
- Tech transfer — make anywhere, sell anywhere
- Divesting product line X
- Recent acquisition of competitor Y
The first thing to notice is that this list moves at a higher level than the bottoms up list, i.e., in order to impact product quality or effectively divest a product line, how you do the things in that previous list are critical.
The second thing to notice is that choosing one of the things off this list to address with IM will drive what things off the previous list you will also impact, e.g., using IM to help with divestment will look very different from using it to improve tech transfer.
- SharePoint is Already Legacy
- Are You Too Old to Work in Tech? IT's Midlife Crisis
- Web Content is Obsolete
- Will Salesforce's New Analytics Cloud Make Waves? #DF14
- Salesforce Shares Its Marketing Vision #DF14
- Why Collaboration Solutions Fail [Infographic]
- Microsoft Gives Office 365 More Social Love