Pitfall: Thinking a new technology or methodology comes for free.

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

CATEGORIES: organizational, conceptual

Suppose you were managing a boxer and wanted him to compete in professional karate tournaments. Suppose you gave him some books on karate to study, showed him a film or two, maybe let him attend a three- or four-day karate training session, and then signed him up for a professional karate competition. The chances are that he’d lose, and badly, no matter how good a boxer he was or how earnestly he studied those books.

It sounds silly, doesn’t it? Guess what: this scenario has been played out many times in IT departments and organizations across the nation and the world, but with regards to the newest technology (object-oriented development, web services, XML, etc.) and methodologies (RUP, Agile, etc.).

IT managers and software engineers with no experience — and sometimes with little software engineering training — are given a few books on the new technology or methodology (”the TOM”) in question, are shown some sample programs or design deliverables, and may even be sent to a three- or four-day seminar about the TOM. They are then assigned to a critical development project that is supposed to be completed in record time, have no bugs, and cost less than existing approaches. The results are usually about the same as those for the underprepared boxer in the karate tournament — if not worse.

Symptoms

Reluctance on the part of upper or technical management to devote resources to converting to the new TOM. A key phrase is, “But I thought that [the TOM] was supposed to save money and time, not cost more!” Also — even more dangerously — managers and developers who feel that they have no need of additional training.

Consequences

Projects that fail to show the expected benefits of the new TOM.

Detection

Ask yourself, “If our managers and developers were going to compete against an expert group of TOM managers and developers, how would I have to prepare them?” Your answers should be very illuminating.

Extraction

First, raise everyone’s awareness of the need to better prepare everyone for the new TOM. Second, recognize that you’re in the middle of a project and there are probably significant deadline pressures, so how much you’ll be able to do may be limited. Third, point out that it may well take longer to complete the project without additional investment in the TOM than it will with that investment.

Prevention

As soon as your company, division, or group decides to adopt the TOM, ask yourself the question given above in Detection. Approach it literally from that angle. As you do, you’ll find that there are five key resources that you must invest in:

• People. Recruit developers and managers (from inside or outside the company) with significant experience in the TOM. Budgetary and political constraints may limit what you can do. Also, identify those within your group who are most likely to adapt well to the new TOM.
• Time. It will take time to create project leaders, managers, architects and developers conversant in the new TOM. Some will learn faster than others, but (to extend the analogy) even the best boxer will have to study and train over an extended period of time to compete well in karate tournaments.
• Education. First and foremost, create a cult of learning. Make it clear to developers and technical managers that those who learn the most and apply it will be rewarded. Then start to build the resources. Acquire a large selection of books on the TOM and require the appropriate people to set aside time to study them. Subscribe to the relevant journals and magazines. Send people to seminars, trade shows, and other training. Encourage in-house discussions and debriefings on pertinent issues and topics.
• Tools. Buy the right tools for the job. These include software tools specific to the TOM as well as non-specific tools that support them. Attempts to save money here are almost always misguided and counterproductive; make sure that the tools are worthwhile, but if they are, buy them and train the managers and/or developers on them.
• Practice. You wouldn’t pit your boxer-turned-karate-competitor against the world karate champion in his first match. Likewise, if you can, have the development group start with small projects with low risk and short time frames. After a few of these, the managers and developers will be better prepared to tackle larger, more significant and difficult projects.

This may be a hard sell, but it will pay off in the long run in two ways. First, you will have an outstanding, professional development group skilled in the TOM. Second, you will attract and keep the best people, because the best people thrive in an environment such as this one.

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.