jump to navigation

Get It In Writing April 13, 2009

Posted by Chuck Musciano in Random Musings.
Tags: , , ,
trackback

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.

Advertisements

Comments»

1. John Baker - April 13, 2009

Over the course of my career I have been a big fan of User/Customer and IT/Development interactions over the life of the application. The most recent version of this concept has been in the Agile/Scrum approach to product development. In this approach, every 3-4 weeks some version of the application is shown to the customer and users to obtain feedback. For the application in your story, an early iteration would expose the very slow performance OR the architect would have focused an early iteration on testing the performance envelope. A guiding principle in Agile (http://agilemanifesto.org/) is to prefer “Working Software over comprehensive documentation”.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: