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 firstname.lastname@example.org.