What Could Possibly Go Wrong?

[article]
Summary:
A software project is a complex thing. It involves many players, many tasks, and lots of things that could go wrong (and often do). If not for dogged optimism, some projects might not be tackled at all. But optimism doesn't mean turning a blind eye to potential pitfalls. In this column, Esther Derby applies a lesson about asking, "What if..."

What could possibly go wrong in your software project? Thinking about what could go wrong identifies potential problems and gives you information to build a more error-resistant plan.

A while back, I decided to wallpaper a small room in my cabin. Even though I had done a lot of home projects, I'd never wallpapered before. But my mother-in-law Shirley is a wallpaper queen. She can do three rooms in a day. After talking with Shirley, I made a list of materials and tools I'd need and calculated the number of rolls of wallpaper required to cover the room. I estimated that if Shirley could do three rooms in a day, as a beginner, I'd better allow a whole day to do one room.

On Saturday morning, I stopped at the home remodeling store and bought everything I needed and headed up the road to the cabin. I was set. I knew the approach, I had a plan and all the materials. I was confident I could finish the job in a day. What could possibly go wrong?

By Sunday afternoon, I had a rather long list of things that could go wrong:

  • Not all the rolls of wallpaper were from the same print lot. The color and texture of half the rolls were noticeably different from the other half.
  • The water trough for wetting the paste (free with five or more rolls of wallpaper) developed a crack and leaked pasty water all over the kitchen floor.
  • Even though I switched paper lots in a corner, if I looked closely, I could see that the colors didn't match.
  • I didn't have quite the right tool to smooth air bubbles out from under the paper, and in spite of all my efforts, some stubborn air bubbles remained.
  • Too much fussing with the air bubbles squished out the pre-applied paste, and the paper came unstuck from the wall.

The list was actually longer. Did I mention that my cabin is two and half hours down a two-lane road from the nearest home remodeling store?

When we design solutions and plan software projects, we tend to plan for things to go right. It's a human tendency to be optimistic and concentrate on how to get things done rather than dwell on what could go wrong. And I believe our software culture encourages this tendency—how many times have you heard someone say, "Failure is not an option," "Don't be negative," or "Don't tell me about problems, tell me about solutions"?

We go through stages of understanding the problem—we gather requirements, develop analysis models, and then design software solutions. We develop plans to build and deploy the solution. We come up with a well-ordered set of actions that will lead us logically and inevitably to the goal.

And then we skip an important step. We don't sit down and think about what could go wrong. We learn about weakness in our plan and design approach as we go. Discovering oversights by running into walls costs money, causes delays, and can compromise quality.

I (now) use a rule of thumb when I approach a new project or design problem: I try to think of ten things that could go wrong before I start. If I can't think of ten things that could go wrong, I haven't thought enough.

First, I look for "lack of" areas where the team doesn't have experience, knowledge, or information. Then I look for areas where we're dependent on someone else to provide something—areas where the project team doesn't have control of a needed component. I look for areas where not all the key players are in agreement. And I look for areas where there's not enough time to finish a component—or finish with desired quality. These questions help me identify natural areas of risk. I pull out a list of common software project risks to jog my thinking.

About the author

Esther Derby's picture Esther Derby

A regular StickyMinds.com and Better Software magazine contributor, Esther Derby is one of the rare breed of consultants who blends the technical issues and managerial issues with the people-side issues. She is well known for helping teams grow to new levels of productivity. Project retrospectives and project assessments are two of Esther's key practices that serve as effective tools to start a team's transformation. Recognized as one of the world's leaders in retrospective facilitation, she often receives requests asking her to work with struggling teams. Esther is one of the founders of the AYE Conference. She co-author of Agile Retrospectives: Making Good Teams Great. She has presented at STAREAST, STARWEST and the Better Software Conference & EXPO. You can read more of Esther's musings on the wonderful world of software at www.estherderby.com and on her weblog at www.estherderby.com/weblog/blogger.html. Her email is derby@estherderby.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Apr 29
Apr 29
May 04
Jun 01