How to Ruin an IT Project

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]

Share

7 thoughts on “How to Ruin an IT Project

  • June 30, 2009 at 10:15 am
    Permalink

    That is a great image. It sums things up very, very well. Forwarded on to our PM folks.

  • June 30, 2009 at 9:21 pm
    Permalink

    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/5t3dlc

    My own summary of relevance:
    Immersive Research — establish the relevant context
    Collaborative 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 phase
    Continuous Adaptation — via feedback loops (business conditions constantly change — there is no Done)

  • June 30, 2009 at 11:31 pm
    Permalink

    Thanks, Sean. I'd love to know what your PM folks thought of it!

    – Mary

  • June 30, 2009 at 11:35 pm
    Permalink

    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

  • July 1, 2009 at 1:21 am
    Permalink

    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/5t3dlc

    My own summary of relevance:
    Immersive Research — establish the relevant context
    Collaborative 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 phase
    Continuous Adaptation — via feedback loops (business conditions constantly change — there is no Done)

  • July 1, 2009 at 3:31 am
    Permalink

    Thanks, Sean. I'd love to know what your PM folks thought of it!

    – Mary

  • July 1, 2009 at 3:35 am
    Permalink

    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

Comments are closed.