1 May 2003

by Michael Mah, Senior Consultant, Cutter Consortium

A marvelous book just crossed my desk, Waltzing with Bears, Managing Risk on Software Projects by Cutter Fellows Tom DeMarco and Tim Lister. The back of the book reads: “Greater risk brings greater reward, especially in software development. A company that runs away from risk will soon find itself lagging behind its more adventurous competition. By ignoring the threat of negative outcomes — in the name of positive thinking or a can-do attitude — software managers drive their organizations into the ground.”

Hallelujah! Finally, someone is saying what many of us know to be true, whether on a conscious or subconscious level. Other axioms and pearls of wisdom along this theme come to my mind. For me, these include: “That which I feared has come upon me,” and “What you resist, persists.” The message being, that by trying to avoid the subject of risk we, in fact, court disaster. Much like the captain of the Titanic, who, under pressure to cross the North Atlantic faster, wound up tragically crashing the ill-fated vessel into an iceberg.

DeMarco and Lister tell us that running away from risk is a no-win proposition, and that the answer is, as Chapter 1 says, to run toward risk. The premise here is: if a project has no risks, don’t do it. I’d agree wholeheartedly, as a voice in my head says: “The only way out of a problem is through it.” To that end, the authors exhort us to embrace risk and risk management, to face the realities of project uncertainties, to open our eyes to potential pitfalls, and not ignore the presence of those pesky icebergs. The idea is to deal with risk explicitly — up-front — to increase the odds of success.

The rest of the book unpacks the subject piece by piece, illustrating the use of probability profiles, risk diagrams, and project risk simulations. This is wonderful stuff to help managers address these issues at critical planning stages. DeMarco and Lister encourage us to examine a spectrum of possible outcomes and to map potential impacts from causal factors like staff or requirements churn, scope growth, and higher-than-expected complexity. Stakeholders need to be ready in case the unexpected happens, so if “plan A” gets hammered, people are prepared with a “plan B.” Everyone needs a plan B.

My experience is that, 99% of the time, plan A vanishes about 42 milliseconds after a project is started, and most organizations soon thereafter discover themselves unprepared as the fire drills begin. A manager I met with recently exclaimed that planning was fine, but in his experience, once a project starts, the major challenge was dealing with the inevitable changes that occur. What was thought to be small turns out to be large. What was simple, is now complex. People with domain knowledge are unexpectedly lost to another project (in crisis, usually) or, in some cases to another company or city. The unexpected, in fact, is guaranteed to occur. Since software and IT projects are really “knowledge work,” they behave like R&D projects. There are all sorts of unknowns to be discovered in the process of solving a problem.

Here’s where I see the need for what I call “project radar.” Much like an air traffic control screen, project radar tracks the trajectory of a project that is in “mid-flight.” And while I agree with DeMarco and Lister that “risk management is project management for adults,” I believe there’s a serious flaw in how most folks today apply project management to the world of software, resulting in a lack of project radar. Many projects are flying blind.

There’s a reason for this. Most project management schemes monitor time, such as elapsed days or weeks for activities in a pert diagram along with project milestones. They also track effort spent in person-hours or person-days, based on the number of people on a project. That’s fine, but it’s not enough. These two metrics of time and effort only tell us what’s been spent and how much time has passed since the project started. But that doesn’t tell us much. It’s like flying a plane with the only instruments you are monitoring being your watch and how much fuel you’ve used. It tells you nothing about your altitude, speed, or heading.

For project management to be truly effective, you must monitor progress metrics on the product: how much has been built to date, and how good it is at this point of time. This is about tracking the creation of the product in both size and quality. It’s no surprise that these two items round out what is known as “the four core metrics — time, effort, size, and defects.”

When you combine the tracking of all four measures, better radar indicators are possible, providing more information and awareness of project risk than if you track only two. As a project marches along with all the resulting impacts from inherent risks, the inevitable consequences begin to make themselves known and are reflected in these metrics every step of the way. They also do not behave in straight lines; for example, if you’re building 100 C++ objects on a 10-month project, you need to have completed unit testing and integration of about 90% of them by the seventh month in order to make the deadline. Why? Because most of what happens in the final three months is debugging and integration/regression testing. If you’re still writing new code up to the last minute, you ain’t gonna make it.

Understanding these patterns gives managers more accurate “early warnings” to practice real risk management and mitigation at key checkpoints of the project. Tracking size and defects is crucial in this arena, because after all, you can run through the entire budget over a period of time and build nothing. You have to monitor what you’ve built every step of the way, and how reliable it is to have a true indication of where the project is on the radar screen. This enables the savvy project manager to identify impacts early, before a project reaches a point of no return. As DeMarco and Lister point out, selective myopia is a project condition where people only see small problems. Large problems may loom ahead, but they go completely unseen by victims of selective myopia. “Oh, you mean that oncoming train….”

— Michael Mah, Senior Consultant, Cutter Consortium

© 2003 Cutter Consortium. All rights reserved.