Pitfall: Adopting a technology or methodology without well-defined objectives

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

Categories: managerial

One of the defining moments in American politics during the 2nd half of the 20th century came early in the 1980 presidential campaign. Senator Ted Kennedy, heir apparent to the Kennedy legacy, was challenging his party’s incumbent, Jimmy Carter, for the nomination. Carter was seen as vulnerable to a Republican challenger, so Kennedy was ready to step up to fill the shoes of his two martyred brothers. Whatever his past troubles, he was still considered a shoo-in for the Democratic nomination and a credible response to the Republicans.

Then during an interview for a CBS news profile on Ted Kennedy, journalist Roger Mudd asked Kennedy why he wanted to be president. For only a minute or two — but for what must have seemed like an eternity — Kennedy struggled inarticulately, unable to utter a coherent sentence, much less a compelling, thoughtful response. It seemed that either the question had never occurred to him or he was unwilling to express his true reasons and unable to come up with an acceptable substitute on a moment’s notice. Whatever the case, his support peaked at that moment and slid downward from there. He lost the nomination to Carter, who in turn lost the election to Ronald Reagan.

What’s the point? Just this: If you’re going to adopt a new technology or methodology (the “TOM”), be sure you know exactly why you’re doing it and what you hope to get out of it. It is not uncommon for development groups to decide to adopt a new TOM because it is a Good Thing; yet they fail to establish what exactly they expect to get out of it. “Faster development,” “greater flexibility,” and “code reuse” are nice phrases, but so are “the flag,” “motherhood,” and “apple pie.” Many groups explore a particular TOM because it’s interesting and new. A pilot project may be well defined — for example, the creation of a simple custom application — but often no clear follow-up exists.

Symptoms

Lack of measurable progress; lack of defined deliverables; lack of understanding as to what comes next.

Consequences

Loss of focus and direction; pilot projects seem to drag on forever; real projects are constantly redefined.

Detection

Describe in writing the ideal state of this TOM in your firm in, say, two to five years (depending upon the size of your company and team). If this is hard to do, or if what you write seems vague, then you have a good indication that you’ve fallen into this pitfall.

Once you are satisfied with this statement, then describe in detail — working backward from your long-term goal — each of the steps to get you from where you are now to where you want to be. If you run into gaps or leaps of faith, then you know you’re facing this pitfall.

Extraction

Follow the process in Detection: work backward from your long-term goal in a series of steps, filling in any gaps that you encounter. Be very about identifying and defining the objectives for each step.

Prevention

Follow the process described in Detection and Extraction. You may end up deciding that your long-term goal is unrealistic; if so, adjust it. Remember that conditions will likely change over three to five years, so make sure that you aren’t locked into that single goal. Instead, make sure that at each step or phase, you have a chance to re-evaluate or reset the eventual goal and shift accordingly.

References

Webster, from Pitfalls of Object-Oriented Development (1995).

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.