The destruction of the space shuttle Challenger in 1986 was one of those events that seared the nation. After the inquiry into the accident was complete, we learned that a small defective O-ring seal had led to the disaster. Similarly, when the space shuttle Columbia exploded in mid-air in 2003, we learned that a piece of foam insulation had fallen off the spacecraft during the launch and had struck a protective tile on the left wing, thereby damaging the shuttle's thermal protection system. During Columbia's re-entry into earth's atmosphere, the damaged tile allowed hot gases to enter and destroy both the wing and, ultimately, the space shuttle. More recently and a little closer to the ground, Boston learned to its sorrow that using the wrong glue in its Big Dig project could cause several sections of a tunnel's ceiling to fall -- crushing a car and killing its passenger. In New York City, officials are wondering if the local practice of pouring concrete in two days rather than five during the winter months has led to a disproportionate increase in the number of construction site accidents.
In each case, it's a seemingly simple thing that is the point of failure.
What's your point of failure? Do you have critical business processes that can be completely undermined by a single design flaw?
One classic KM system design flaw has to do with gathering content. You may have technology that is a thing of beauty, but if content collection depends on the voluntary participation of your knowledge workers, that's a flaw that could be fatal. They often are (or feel that they are) too busy to contribute. Or, as I discussed in my recent posts on capturing content and hardwiring KM into client engagements, if content gathering is not baked into your client engagement process, but is shunted off to the side as something that is nice to have rather than necessary, your content collection business process will fall apart.
Another classic point of failure in law firm knowledge management is appointing KM "guardians" who have the responsibility of ensuring the purity and currency of the KM collection. What happens when those guardians become bottlenecks? That's another design flaw.
Yet another point of failure lurks in the Outlook folders of every lawyer in your firm. If they don't faithfully send copies of their e-mail correspondence to your central records system, how will your firm have an adequate record of your client engagements?
So how do you prevent these potential O-Ring disasters within your systems? The best approach seems to be extremely pessimistic planning. In the midst of project planning it's so easy to get caught up in the excitement and anticipation. That's when you make the mistake of believing that reality will follow your planning. The better approach is to ask at each critical juncture of the design phase: What if this doesn't work as planned? What if users don't comply? If they do not comply, what are they most likely to do? These questions should help you identify potential points of failure.
After launch, repeatedly tracking user behavior and system results can help identify where reality departed from planning. Sometimes the results are serendipitous. More often, these departures from plan indicate a point of failure that wasn't properly analyzed and addressed in the planning phase. Then, the next question is: Should we fix this? That's when you get into some interesting cost-benefit analysis. However, if the design flaw goes to the heart of a critical business process do you really have a choice? Just ask the folks at NASA.