Do's and Don't's in IT: Never the Twain Shall Meet?

CIO Insight, in partnership with Baseline Magazine, is featuring a year-end review of nearly 230 case studies done over the past five years to distill out the "Top 10 Lessons for IT Project Success."  Reading that piece in conjunction with "Top 10 Project Pitfalls You Can Avoid" is a fascinating exercise in realizing how the obvious sometimes bears re-stating and—I am quite confident this perspective is entirely unintended by the writers—also gaining insight into why so many IT projects do, indeed, fail spectacularly:  Because many of the top 10 "do" recommendations are perilously similar to many of the top 10 "don't's."

But first, let's rehearse what we really do seem to know about IT projects:

• Technology cannot set the agenda; business processes must.  For example, while Toyota relies heavily on technology at its manufacturing facilities, one senior VP at the Boston Consulting Group who has studied Toyota observes "What strikes me about Toyota is, if you were to ask them if they have a technology strategy, they would probably say no, we have a business strategy."   The result of that insistence on the primacy of the business objective?  Merely that Toyota is the most efficient, highest-quality car manufacturer in the world.  To be sure, there are some valuable cultural overlays to this—including just-in-time supply chain management and, famously, kaizen, or continuous improvement; but my favorite of them all is genchi genbutsu, which literally translates to "Go and see for yourself."  In other words, at Toyota you're not permitted to just hear about a problem and try to act at a distance; workers, team leaders, and executives alike are required to go see the problem directly and work collectively  on a solution.  My recommendation?  Steal this practice.
• Track IT projects across the entire enterprise. Unless you're doing this, you have no hope of ensuring that your IT resources (human and financial) are devoted to the highest-priority, biggest-payoff projects.  Don't let IT descend into the chaotic pit of "emergency response central."
• Get everyone who matters in one room.  Or else the "solution" you design and start to build, at great cost, will irritate, offend, or simply not work for some critical constituency.
• Clean up your data—and keep it that way.  This seemingly obvious statement actually covers an entire landscape of IT project failure modes, including:
  • tolerating aging and incompatible systems which do not communicate with each other and cannot be integrated
  • the dog-chasing-its-tail syndrome of trying to retroactively fix erroneous information after it's been propagated across multiple systems
  • living with systems that routinely disclose bad information outside your firm
  • and recognize that one reason data gets dirty or noisy to begin with is poor design—of the screens, prompts, language, and choices available to users entering or updating data.  A confused user confronting an ambiguous or unclear choice cannot be counted on to read the developer's mind.

Now we get to the fun part:  How much family resemblance is there between the "do's" and the "don't's?"  Turns out, a lot.

#1:  "Get everyone in the same room" (do) but "Projects are impeded because they require approval across multiple divisions" (don't).

#2:  "Biting the bullet and migrating off an older technology can pay off" (do) but "A project's scope is too monolithic and gargantuan" (don't).

#3:  In one of my very favorites,  we have duelling "do's":  "The easiest solution isn't always the best" vs. "Don't use complicated, expensive software when a clipboard and pencil will do."  (I told you —how juicy is that?)

#4:  "Give users what they want" (do) but "Access rights are undocumented" (don't).  How are these at odds?  Simply in the intrinsic way that security and convenience are almost always at odds.

So that was fun, but what can we take away from all this sport?

Lesson One:  There's a reason the IT landscape is littered with the corpses of expensive projects.

And, far more important, Lesson Two:  If you're about to dive into the deep end of the IT pool, don't imagine for a second that you can rely on staff or vendor reassurances, untested assumptions, user omniscience, or management's heedless assent to pave the way.  You are in charge:  Navigate with crystal clear eyes.