Pitfall: Adopting a new technology or methodology for the wrong reason

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

CATEGORIES: organizational, conceptual, political

Management is always looking for the proverbial silver bullet, despite Fred Brooks’ warning to the contrary. Good reasons may exist to adopt a particular technology — such as object-oriented development — and/or a particular methodology — such as RUP, Agile, or CMM. However, there are many more misunderstood, misguided or just downright bad reasons for adopting the new technology or management (”the TOM”), particularly for projects already in progress. These include (but are not limited to) the following:

• You (or your boss or your developers) read an article about it.
• You want to cut back on the development staff (not necessarily a bad idea in and of itself, but not a good reason for adoption of the TOM).
• You think it will eliminate or at least significantly reduce the need for testing.
• You have to complete a project by a certain date.
• You want to complete a project ahead of the currently scheduled date.
• You believe you can complete software projects much faster using this TOM.
• You believe the TOM will eliminate all your software engineering problems.
• You believe the TOM will reduce project risk.
• You believe the TOM is necessary in order to implement certain functionality and/or user interface design.
• Someone wants to sell you a product (e.g., development tools) or service (e.g., training or consulting) focused on this TOM.

…and so on. Note that many of the goals above are desirable and may well be aided or even achieved via the TOM in question. The pitfall, however, is that the initial adoption of a TOM almost always has a negative impact on current projects and efforts. It is, if you will, a corollary of Brooks’ Law (”Adding manpower to a late project makes it later.”)

Symptoms

Other organizational pitfalls (to be added later) are a good initial set of symptoms.

Consequences

Possible project slip. Failure to achieve expected benefits, resulting in disappointment for yourself and (worse yet) for your superiors. Projects become unacceptably late or even fail. Heads roll, including possibly your own.

Detection

Ask all people involved in the decision to use the new TOM to write down their reasons (in detail) for doing so, along with all the corresponding risks they see. If the answers to the first question match the list above, you’re likely in trouble. If no significant risks are listed, you’re in even more trouble, because it means that people may not be thinking carefully about the impact.

Extraction

Gather all the key managers and decision makers. Discuss the findings gathered under Detection. Explain (carefully) the problems that underlie any faulty reasons. Establish what should be the proper reasons for adopting this new TOM and what the likely benefits of doing so will be (as well as the timetable of achieving those benefits). Reset expectations to the best of your ability.

Prevention

Pretty much the same process as Detection and Extraction, but it before you start the process of actually implementing the TOM. Emphasis very heavily that most benefits of a given TOM are long term and require significant up-front investment in training, tools, analysis, design and personnel.

Contributor/References

Webster, adapted 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.