Shocking KM News! Users Reject Lessons Learned Database!

I know that this will no doubt come as a shock to some, and I urge you to not read this alone — you will need close support to get you through the moment. But I’m saddened to report that according to an audit conducted by the Australian Department of Defence….(here it comes, prepare yourself!) the Department of Defence lessons learned database was “abandoned” by users who found it too difficult to use.

Yes, shocking. Probably the very ever first time that this has happened. Right? (end-sarcasm)

Apparently THE lesson learned about lessons learned systems is that if you fail to involve the users in the requirements process…you will likely (often, usually, frequently, etc. etc.) end up with a system that simply does not meet the need of the users. Duh.

Typical scenario: User sitting in front of the lessons learned repository is about to learn a new lesson — that the system features are either so complex so as to make it too difficult to use (like when in a hurry trying to identify a lesson learned that might be applicable to the specific operation that the user is about to embark upon!) AND/OR the search appliance or capability is inadequate to the task (thus ensuring that the user is MORE LIKELY to BECOME the next lesson learned in the repository before being able to find what they’re looking for in hopes of avoiding the same problem!).

Frankly, none of this is truly “news” is it? We’ve been talking about the very same thing for years. I’ve been suggesting that in many ways, and in many cases, the era of the “lessons learned” repository may be behind us. For these very reasons.

So what would it take to fix it?

Well, there is the obvious issue of the search problems but I’d like to go much more basic than that by suggesting that if you address user requirements right up front, you might even avoid some of those search problems. However, that would appear to be r-a-d-i-c-a-l thinking — involving end users in requirements discussions and all that. Simply gets in the way of good old vendor back slapping and high fiving celebrating yet another successful sale of a technology in want of a problem.

Looking at this particular case here’s what we know – the lessons learned system was too difficult to use.

I won’t cull out all of the findings from the 124 PAGE AUDIT REPORT (!) but the gist of it is that the Australian Defence lessons learned system — called the “ADF Activity Analysis Data System (ADFAADS)” (seriously?) was put together in 1999…using a Lotus Notes platform. With little to no input from potential users.

And in the end, users found features of the system simply too difficult to use. Add in a mix of what was described as complex (convoluted) business rules and some outright wacky search rules and users turned against it. In fact, what the users then did SHOULD perhaps be seen as the most significant lesson learned from this whole disaster — the users simply abandoned the system in favor of setting up their own system to replace ADFAADS.

Yes, the users got together and discussed their needs. Discussed the inadequacies of the current system. And then, being the renegades that they are — they set up their own system. Which actually worked. Using a Wiki. Which the audit report pointed out was a “well-thought out approach to providing wide access to a user-friendly source of learning.” However, as a result of the audit, other than the limited perspective offered by a “working group” there doesn’t appear to be much effort involved in “learning this lesson” in the way of broadly involving users in requirements discussions for the replacement of the current lessons learned system. And there was no discussion of the lack of a KM strategy.

Yupper, that pretty much says it all.

Well, not quite — the audit report makes no mention at all of their having been a KM strategy in place to begin with, and no mention of how lessons learned fit into the big picture. Sounds more like an attempt to “lessons capture” rather than lessons “learned.”