06.16.03

By Paul Glen

Have you ever tried to drive around Boston? It’s nearly impossible to navigate the narrow, winding streets that meet at odd angles, curve back around, and join in traffic circles that you find almost nowhere else in the country. Why would any city knowingly design its streets in a fashion nearly impossible to navigate? Well, there’s an old story, perhaps apocryphal, that the streets follow the old cow paths from the days when the Boston Commons was a cow pasture hundreds of years ago.

If you’re tempted to laugh at Boston, take a step back and first look in the mirror and ask yourself if you’ve designed anything like that. Too often, technology projects do exactly the same thing. They build systems that strain to look like something else. One of the first PC based word processors, MultiMate, was specifically designed to look like an even older Wang word processor, as if that were something worth emulating.

These types of designs typically result from several different sources:


IT Resources

Backward compatible technology. One of the most common sources is trying to make something new that retains its ability to support previous standards. You’ve got to balance the need to retain backward compatibility with the complexity of designing, developing, and supporting something that may no longer be in general use.

Minimizing User Education. Another common reason for building new systems that look like old ones is to minimize user education. I suppose that the reason that MultiMate was so popular during the early days of PCs, was not that it was particularly functional, but that typists who had already learned the Wang interface wouldn’t have to relearn a new one to switch to the less expensive PC environment.

Taking Requirements vs. Building Consensus About What Should Be Done. But perhaps the most common source is that too many IT Professionals try to “gather requirements” at the beginning of projects. They make it sound like user requirements grow in strawberry patches and just need to be harvested in order to learn what users need. Unfortunately, users rarely know exactly what they need. More often, there are many different ideas floating around about what’s needed. But I’ve never seen anyone actually just go out, ask a few questions and successfully deliver a system. You’ve got to see the early phases of projects as a process of building consensus within the user and client community about the goals and needs for a new system.

Sometimes it’s necessary to build a system with vestiges of previous ones, but it’s much too easy to just assume that you’ve got to do it. It’s too simple to assume that business operations and users will always do things the way that they do now. Before you build them into new systems, make a conscious decision that it’s worth it. Are you building something that will truly serve the needs of your clients and users or are you laying out the street map of the next Boston?


About the Author:
Paul Glen is the author of "Leading Geeks: How to Manage and Lead People Who Deliver Technology" (Jossey Bass Pfeiffer, 2002) and Principal of C2 Consulting. C2 Consulting helps clients build effective technology organizations. Paul Glen regularly speaks for corporations and national associations across North America. For more information go to http://www.c2-consulting.com. He can be reached at info@c2-consulting.com.


-- ITManagementNews is an iEntry, Inc. publication --
2003 iEntry, Inc. All Rights Reserved Privacy Policy Legal