Have You Heard This One Before?

"Sometimes I hear software development project managers say 'We'll tackle that risk later; that'll give us much more time to think about it while we're doing all the easy stuff.' Whenever I hear that, my blood pressure goes through the roof!" exclaimed Roscoe.

"Ah, Roscoe, I know where that wrong thinking comes from," I said. "It's what we tell American students about how to take tests in a time-constrained setting. Over and over again, we admonish them to do the easy stuff first, to 'get money in the bank' and reserve the remaining time at the end to work on the harder stuff. The logic is to get as much credit as you can for what you know, and 'don't leave money on the table' because you run out of time."

Roscoe reflected for a moment. "Well, that might be a legitimate strategy for certain environments. The problem is, software projects are different. You don't get partial credit for an unfinished project the way you get partial credit for an incomplete test. In project settings, you must solve the hard problems. So the situation is not only not analogous; it is diametrically opposite."

I agreed. "So what you're saying, Roscoe, is that the idea that a team will work on the 'hard' or 'high-risk' problems in the background is an exercise in wishful thinking, because:

• While the team is working on 'the easy stuff,' they will not be thinking about the deferred risks. Teams have difficulty focusing on too many things at once, and once they start working on the easy stuff they will forget about the risky stuff they deferred. 'Out of sight, out of mind.'

• Parkinson's Law says that the 'easy stuff' will expand to fill out the schedule. This will squeeze out the harder, more risky stuff. I have seen this happen over and over again. After taking 20 to 30 percent longer than expected on the soft issues, sometimes due to excessive perfectionism, the team finds itself behind schedule. Then it gets hit with the really hard problem. Which, of course, was there all the time; it didn't go away because they ignored it.

• The net result is that the team winds up having less time to work on the hard problem rather than more time.

• And here's the ultimate disaster: Sometimes, to solve the hard problem, you have to throw away the work you did on 'the easy stuff' and do it all over again."

I concluded with, "So once again, the moral of the story is: Prioritize your risks, and attack the biggest ones first. If there is not enough time left over to do 'the easy stuff,' then you were certainly going to fail anyway."

"Now you're striking oil, Sonny," said Roscoe, and added one more cogent observation to supplement mine: "If I were behind schedule, I would feel much more comfortable going to my boss and asking for more time if I could demonstrate that my team was executing on a plan that had already squeezed out most of the risks. On the other hand, if I had to admit that not only were we behind schedule but also that there were still high-risk items on the table, I'd be in a very weak negotiating position. I probably wouldn't get my extension, and the project might be cancelled. And maybe it should be."