The Effective CIO

Get It In Writing April 13, 2009

When I worked in R&D, we shared our building with another group whose job was to improve engineering productivity.  They took their job quite seriously and had a mandate to investigate any aspect of the engineering groups that appeared to be in need of improved productivity.  They weren’t engineers, but they did claim to understand process and project management, and they often used a new acronym, TQM, as a sign that they were on the cutting edge of this kind of stuff.

As you can imagine, the engineers were not overly enamored of this group.  Fortunately, the productivity team must have decided that our R&D group was beyond help, productivity-wise, since my group was rarely the target of their attention.  On the whole, our groups got along pretty well and often shared information.

At some point, a few folks from the productivity group got involved in a fairly elaborate project, working with another division in my company.  They were very excited about this project, which involved some fancy new computer system to collect and analyze a lot of data.  The more this woman talked, the more excited she got about the project, and the more doubtful I became of her chances of success.

After a bit, I asked her about system performance.  The data volume was large and the analysis was complex.  Even with the best current technology, a functional solution would be a challenge to build. Would the system be able to perform well?  Would the users be happy with response time?

She didn’t miss a beat.  “Of course, it will perform well!  We wrote that into the requirements!”

And off she went.  With the stroke of a pen, she had solved any and all performance issues this new system might have.  As you might imagine, the project never finished, for a variety of reasons.

It is easy to listen to this story and laugh at the naivete of non-IT people.  How could anyone design such a complicated system and them make it perform well with a simple written requirement?

The deeper lesson (you knew there would be a deeper lesson, right?) is that someone failed to educate this person as to the real complexity of her project.  Non-IT people cannot understand what we do.  Unfortunately, when we do it well, we make it look very easy.  When it looks easy, people assume that it is easy and base their world on that assumption.  This results in projects that fail to meet user expectations.

Users do not want to know the details of our technology.  But they need to know when things are really hard or really expensive.  If they probe, you can explain why. We owe them enough information, matched to their curiosity, so that they can appropriately plan and manage their world.  If we fail to do that, we have failed them, no matter how well our technology works.