[Copyright (c) 1995, 2007 by Bruce F. Webster. All rights reserved. Last updated: 06/18/07]
CATEGORIES: political
Imagine the following scene. Your company’s executive staff gathers for a presentation on a new technology/methodology that will revolutionize information productivity. After a presentation citing the ongoing problems of information management, enterprise computing, and competitive response, you are presented with the solution that will boost the company’s bottom line and guarantee its future: structured development!
But wait! you say. Structured development has been around for a long time. Lots of folks use structured development and have mixed results; indeed, most don’t use it well. Lots of companies have gone out of business while relying upon structured development. How is structured development going to guarantee our future?
Good question. And yet, structured development and its associated methodologies are likely more mature, established, and well understood in real-world applications than are any of the later technologies or methodologies (“TOMs”) that you may want to adopt. For that matter, the number of competent, practicing engineers who are expert at structured development is likely greater than the number of competent, practicing engineers who are expert at the particular TOM in question. If a company can’t succeed using structured development, why does it think it can succeed using a given TOM?
You may think that I’m being reactionary or that I don’t understand all the benefits that more modern TOMs have over structured development. If so, you miss the point: It is not technique (using Jacques Ellul’s term) in and of itself that will benefit the company, but rather its intelligent and purposeful application by people who know what they’re doing and why. To think that adoption of a given TOM (or even a collections of TOMs) will suddenly make everything better is irrational to the point of superstition.
Symptoms
Unrealistic expectations on the part of upper management. Marketers overpromising delivery times and feature lists. Technical managers who see the TOM as a silver bullet. Developers neglecting solid software engineering practices, because the TOM “doesn’t require them”.
Consequences
At best, you go through a wrenching reeducation and attitude adjustment. At worst, you lose the bet — and the company.
Detection
Take the company’s current business plan, mission statement, and product plans, and eliminate all references to and consideration of the TOM(s) in question. Do these documents still make sense?
Extraction
Point out, repeatedly, that it doesn’t matter what technology you use if the products aren’t worthwhile and if the company can’t get a return on investment. Enumerate the factors required for success independent of the TOM(s) in question. Look at all that you can do to maximize those factors. Then — and only then — look at how the TOM(s) in question can aid and support those efforts.
Prevention
Bet the company on your people, not on some technology or methodology. Isn’t that what politics is all about?
Contributor/References
Webster, from Pitfalls (1995).
