When it comes to knowledge-based systems (i.e. ones that don’t work too well without people involved), a lot of the value will emerge as the system is used
Malcolm Gladwell has an article in the New Yorker, “Enron, intelligence, and the perils of too much information“, that contains an interesting paragraph (or two):
…National-security expert Gregory Treverton has famously made a distinction between puzzles and mysteries. Osama bin Laden’s whereabouts are a puzzle. We can’t find him because we don’t have enough information. The key to the puzzle will probably come from someone close to bin Laden, and until we can find that source bin Laden will remain at large.
The problem of what would happen in Iraq after the toppling of Saddam Hussein was, by contrast, a mystery. It wasn’t a question that had a simple, factual answer. Mysteries require judgments and the assessment of uncertainty, and the hard part is not that we have too little information but that we have too much.
This contrast could be applied to different I.T. projects.
Organisations I work with sometimes struggle to cope with my explanations that, when it comes to knowledge-based systems (i.e. ones that don’t work too well without people involved), a lot of the value will emerge as the system is used and it is best not to try and perfect the design up front because it will change as the system is adapted by those who use it… in fact, the best design is one that is created specifically to be as adaptable as possible.
This explanation doesn’t always go down too well, particularly with IT folk. They want to eliminate ambiguity from the project and they want precise outcomes. They are trying to solve a puzzle. Transactional systems (i.e. ones that prefer minimal human involvement) behave like puzzles. Knowledge-based systems need to be treated like a mystery.
Since becoming closer again to the inner workings of IT within organisations, I believe the key challenge is how the IT dept is perceived. The traditional approach to IT projects seems to be – 1. business instructs IT dept to deliver new system and provides budget, 2. IT dept runs project to deliver new system, 3. IT dept hands over new system to business. That approach works just fine when you are dealing with a puzzle…
(Hat tip to IFTF’s Future Now blog who called out the New Yorker article and paragraph in their post – Puzzles, mysteries, and thinking about the future)
Joining Dots 