I recommend beginning a project with a risk assessment to identify potential problems. But such assessments are plagued with potential problems themselves. One is that expertise can act as a lens to magnify only a small part of the project. Fortunately, there are ways to work around these lenses.

Before a project starts, we assess the risks. The essence of this exercise is answering one question: "What could possibly go wrong?"

Several years ago, I was to have a management role in a US $100 million project that was about to begin. My colleague Kevin was to have a technical advisory role.

My answer to "what could possibly go wrong?" was concise and obvious (to me). This large project had been preceded by a set of small projects ($1 million each). On the small projects, teams of six people had worked for six months to develop digital signal processing (DSP) algorithms and implement them on prototype systems. The large project would have a hundred people working five years to build families of deployable systems. The biggest potential problems would be increasing the staff from six to 100 people and learning to work in a culture of verification and validation.

Kevin's answer was also concise but didn't make any sense to me. His biggest concern was they wouldn't be able to develop the necessary DSP algorithms. If, however, they could develop the algorithms, implementing them would be an easy exercise: just gather the programmers, give them their assignments, and there you have it.

I was shocked. "There you have it?" Didn't Kevin realize how difficult it was to coordinate the efforts of several teams of a dozen people each? He didn't even consider the change in culture from prototypes to deployable systems. Most puzzling of all was his biggest potential problem: developing the algorithms. I thought that would be fine. The best DSP algorithm people were on the project. They would succeed -- no problem.

Fast-forward three years into the project, and Kevin and I were both correct. The large project had two major problems. We struggled to staff up from six to 100, and the DSP experts failed on a couple of the algorithms. The large project did not go as planned, but we were able to develop enough algorithms and build enough systems to be a success.

A retrospective considered the vastly different risk assessments. I was a project management consultant; Kevin was a DSP consultant. We had each named risks in our own areas of expertise while excluding everything else. Our expertise had acted as lenses that magnified the parts of the project that we knew best.

That didn't make any sense. If anything, we should have been confident about our areas and found faults in other areas. After all, it is easy to find fault with someone else -- much easier than seeing your own faults. Regardless of the theories, here we were with the facts in front of us. That is one of the problems with recording everything for later review.

Lessons for the future:

   1. Realize that we each have lenses that magnify some aspects of a project. In this example, the lenses magnified our areas of expertise. In other projects the lenses may magnify other things.

   2. Examine yourself and your lenses. Understand what you are magnifying as you assess risk. Checklists of potential risk help to avoid focusing on only a few things, but we had such checklists on this project. We read through the lists and considered each item, but our lenses let us see only one or two things.

   3. Switch lenses and assess again. There are several ways to do this. One is to hire someone else with a different area of expertise. Let that person use his or her lenses. Another is to reassess from a different perspective. I ask myself, "If I were a fill-in-the-blank expert, what would my lens magnify as a risk?" 

Assessing risk is a form of predicting the future -- something we rarely do well, but in this case, both Kevin and I succeeded. Our problem was that our lenses let us see only half of the risk each. Why we didn't put one and one together is another story for another time.

d.phillips@computer.org

Back to Dwayne's home page.