How do you develop your content management requirements?

Typically, organisations will identify a business strategy, develop requirements based on that strategy to improve revenue or reduce costs, and then develop a software architecture based on those requirements. But when should the technology drive business change?

The simplest answer is “never”: don’t let the technology tail wag the business dog. But the simplest answer is rarely right. New technologies can lead to competitive advantage as well as stimulate innovation culture, so there should be room for a technology-led approach. You do need to establish some criteria for initiating these kinds of projects, however.

Emergent benefits but a defined problem
You may not know precisely what benefits the new technology will bring — this is particularly true of very new technologies that have little case history of ROI — but that shouldn’t in itself preclude assigning the project a budget. What should prevent you starting the project is not having a problem. This might be an operational issue such as ineffective project communications, or the opportunity to target a new market segment. But the problem needs to be there even if it’s not clear how the new technology will resolve it.

For example, online retailers have long had an issue with customer trust. People don’t buy products just because the website says it’s worth buying. But if you add the facility to comment on or rate a product, this gives some reassurance to the buyer. It improves sales markedly for some items, but risks reducing them for products that receive poor reviews. While it’s not 100% clear what effect customer ratings will have on your revenue stream, they do address the perceived trustworthiness of the product description.

If you want an example where this hasn’t worked, consider Second Life. Eighteen months ago, virtual worlds were the bandwagon to be on. It wasn’t clear what the benefits would be but it was technologically cool. The problem was that there was no problem. Second Life didn’t offer any real communication improvements while tapping a relatively small market that could be reached through other channels anyway. There may well be scope for virtual worlds in future, but they need to address a real business issue before they’ll take off.

Ability to deploy quickly
Since the rate of obsolescence outpaces the rate at which companies change [slideshare], you’d better be quick about your work. If it takes you a year to roll out a new technology, this should be business-driven, not led by a technology which will be old hat by the time it’s deployed. Software as a service gives companies a real advantage to deploy quickly, as do flexible server environments. You should certainly be looking at these kind of tools if yours is an organisation that likes to be at the leading edge.

Acceptable cost
How much money are you willing to risk if the technology doesn’t bring any benefit? This is a difficult assessment to make as you’re less likely to have a watertight figures than if you went down the more traditional business case route. Normally your assessment would be: my problem costs me £X, so if I spend £Y then I’ll get a return within Z months, so £Y can be my project budget. When you’re technology-led, you’re unlikely to know how long it will take to get a return. So you need to treat your budget as a sunk cost that you’re comfortable writing off.

This doesn’t necessarily mean that your budget must be small: the car industry spends a fortune on innovation because the risks of losing competitive advantage are so huge. Of course, you can limit your risk of failure by running a pilot, which will help you to satisfy the need to deploy quickly as well as constrain costs. Your project budget should be based on the scale of the problem you’re trying to solve, rather than on the scale of anticipated benefits.

Exit strategy
If the technology isn’t as successful as you’d hoped, or it’s viable but creates other problems you hadn’t forseen, you need a cost effective way to abandon it. This is particularly relevant for information management projects. If you put business critical information into a new wiki that has poor adoption, you absolutely need a way of getting that information back in a format that can be migrated to another system. Your project needs to include a decommissioning approach.

Ride the wave
Technology should inform your business strategy, but being at the crest of the hype cycle isn’t enough. If you apply these criteria to technology-driven projects however, you should go some way to avoiding the trough of disillusionment, both emotionally and financially.