If you ask users, they might well tell you that in their experience of KM and IT implementations, the old saying sadly holds true: “There’s many a slip twixt the cup and the lip.” That saying captures what often happens when law firm knowledge management and IT personnel start building systems to “meet user requirements.” Lots of well-intentioned folks spend far too much time worrying a problem to death and yet, in the process, sometimes lose sight of what the end-user actually needs or wants. The best cure for this malady is to stick as closely as possible to the user during each of the requirements gathering, design and implementation phases. And, as you’re doing this, make sure that your work product reflects at each stage the users’ growing understanding of the tool and your growing understanding of the users. Otherwise, you’ll end up with a system that faithfully follows the initial requirements document while missing the mark on what the users ultimately realize they needed all along.
For those of you who read this blog post by e-mail or via an RSS reader, please do take a look at the image above. I promise it will be worth your while.
[Photo credit: Dullhunk]
Above and Beyond KM 
That is a great image. It sums things up very, very well. Forwarded on to our PM folks.
Thanks, Sean. I'd love to know what your PM folks thought of it!- Mary
In the mid-90s I had a presentation “Requirements Don't Work” that began to circle in on some of the same topics I'm spewing today. The relevant evidences have just increased in detail.So far the best placeholder is to leverage Design Thinking fundamentals. While there are a variety of ways to consider the approaches, this article details the fundamentals most relevant to IT http://twurl.nl/5t3dlcMy own summary of relevance:Immersive Research — establish the relevant contextCollaborative Discovery — even with paper artifacts a process of 'winnowing' possibilities allows for 'failing faster' (This? No, This? This and This?)Collaborative Development — Moving into construction with same methods as last phaseContinuous Adaptation — via feedback loops (business conditions constantly change — there is no Done)
Paula -You definitely were ahead of the rest of us in the 1990s. Given the inherent shortcomings of requirements, why do IT departments around the world still cling to them? Inertia? Willful blindness? – Mary
In the mid-90s I had a presentation “Requirements Don't Work” that began to circle in on some of the same topics I'm spewing today. The relevant evidences have just increased in detail.So far the best placeholder is to leverage Design Thinking fundamentals. While there are a variety of ways to consider the approaches, this article details the fundamentals most relevant to IT http://twurl.nl/5t3dlcMy own summary of relevance:Immersive Research — establish the relevant contextCollaborative Discovery — even with paper artifacts a process of 'winnowing' possibilities allows for 'failing faster' (This? No, This? This and This?)Collaborative Development — Moving into construction with same methods as last phaseContinuous Adaptation — via feedback loops (business conditions constantly change — there is no Done)
Thanks, Sean. I'd love to know what your PM folks thought of it!- Mary
Paula -You definitely were ahead of the rest of us in the 1990s. Given the inherent shortcomings of requirements, why do IT departments around the world still cling to them? Inertia? Willful blindness? – Mary