Pitfall: Not identifying and managing risks

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

Categories: managerial

What are the risks in modern software development? Look at the pitfalls listed in this book to start. Kind of makes you want to take up gardening, doesn’t it? On the other hand, being able to identify those risks and then manage them puts you way ahead in the development game and can make you extremely valuable as a technical manager.

Why do we sometimes fail to see and handle risks? There are various reasons. We don’t want to confront others and ask hard questions. We don’t want to expose our own ignorance. We keep hoping things will correct themselves. We don’t want to disappoint or upset those above us. We don’t want to have to fire anyone. We don’t want to appear not to trust others. We face resistance, forceful or subtle, as we try to point out these risks and deal with them.

Risk management is essential in modern software engineering. It’s essential for all the reasons it would be in any software development project. But it’s particularly essential if you are adopting a new technology or methodology (the “TOM”), because:

• the number of IT engineers that you have who are both skilled and experienced in the TOM is likely to be small;
• non-IT personnel, particularly upper management, are likely to have high expectations and mistaken perceptions regarding the TOM.

In short, adoption of a new TOM is likely to increase the risks of the project.

Symptoms

Closed door, closed eyes, closed mind. Constant trickle (or stream) of bad news from developers. Spending more time putting out fires and explaining problems to upper management than actively managing and completing tasks.

Consequences

Slipped schedules, missed milestones, project failures, lost jobs.

Detection

Ask everyone involved with the project what risks they think the project currently faces, with “risks” meaning anything that could cause the project to ship behind schedule, over budget, lacking specified features, in a form not acceptable to customers. If anything comes up you haven’t considered and which you aren’t handling, then you know you’ve fallen into this particular pit.

Extraction

Make an exhaustive list detailing all the previously unidentified and unhandled risks that you gleaned from the questioning in Detection. Distribute the list through the development group and then ask for any additions or corrections (a risk identified by one person may be handled by another). Come up with an assessment of each risk: how probable it is, how it could affect the project, and how it can be managed. Pass this list to upper management. Reset and reschedule the project, if necessary.

Prevention

Risk identification and management should be part of project planning and scheduling from the beginning. The more actively you work as a team to anticipate and handle risks, the fewer problems you’ll encounter. Be aware that this takes political courage, though; those above you don’t always want to hear what the risks are or why the project may not be completed in the time frame demanded.

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.