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.