Nicholas Carr has a nice summary on his blog post ‘Down the drain‘ describing why large projects so often fail.
His second point is the classic trap that so many knowledge-based projects fall into:
…Always create software to solve the day-to-day problems faced by the actual users, not to meet big abstract organizational challenges. Solve enough little problems, and the big ones take care of themselves. Fail to make users’ lives easier, and they’ll simply bypass the system (and never trust anything you do ever again).
This has been consistently demonstrated over the past 14 years, particularly in relation to content-management systems. Organisations spend vast amounts of time and resource designing the ‘perfect’ intranet with the ‘perfect’ taxonomy, ‘perfect’ search engine, ‘perfect’ workflow processes, ‘perfect’ metadata set, ‘perfect’ rules for adding, modifying, approving, archiving content (and all its glorious metadata)… you get the idea, and the project fails miserably because it is focused on solving a perceived organisational problem (‘we need a knowledge management system’) rather than solving actual user problems (‘I don’t know who to contact for help on…’, ‘I can’t find previous reports on…’). The end result: people avoid using the system because a) it is difficult and time-consuming to use and b) it does not provide them with enough benefits.
In recent years, I’ve seen customer-relationship management (CRM) projects fall into exactly the same trap. The focus seems to be more on generating lots of reports to support business plans than on helping people improve customer relations. Yet it is through improved relationships that business metrics will be achieved, not from viewing charts about the current state of play. (See also: Seven Productivity Tips)
The most successful information-based projects are typically started by the content users themselves, rather than the IT department or management. They grow bottom-up, with minimal investment, and spread organically through popularity – they are useful, they solve a problem. Instead of being concerned with clamping down and stamping out these projects, the IT department should embrace their benefits and help convert the projects from start-ups to fully supported applications. And that does not mean spending the next 3 years designing and implementing the ‘perfect’ replacement…
Update: FT article describing the successful approach adopted by the BBC, via the person who did the adopting
Joining Dots 