Risk Management Plan

Many programs are low risk and don't really warrant a Risk Management Plan. One should even conduct a RiskAssessment in these cases, since otherwise you could be surprised at the degree of risk you have accepted.

Risk comes in three major flavors: TechnicalRisk, ScheduleRisk?, and FinancialRisk?. MauriceZeldman, a management guru, likes to use the phrase in his presentations that "You can have it Good, Cheap, or Fast -- pick two." That is very true and related to the categories of risk.

When you must accept a high degree of risk, analyze the risk and provide a plan to handle the risk. What I do is create a LeadPlan? (usually the high payoff, high risk plan) and a LagPlan? (a less acceptable alternative which nevertheless meets the minimum requirements or is at least tolerable) then you need to create a set of triggers that determines when you activate the Lag Plan in the event that the Lead Plan is going poorly. -- RaySchneider

[Was the switch from "I do" to "you need to . . ." intentional?]

ExtremePlanning makes the risk management plan an implicit part of the overall plan by 1) putting more valuable stories first in the plan, so less value is at risk and 2) after having done 1, putting technically riskier stories earlier in the plan. Still, the best risk management is not to have any, so we try very hard to get rid of technical risk in the exploration phase.

The three variables idea is a cruel hoax. It leads people to ignore scope, the most important project management variable. My customers are far happier managing scope while I explain the impact on the other three, than any project where "your choice of any two" has been in force. -- KentBeck

"cruel hoax" seems to me to be an exaggeration. The idea is fundamentally sound, i.e. you inherently increase the other two when you constrain one. For example if you increase time available you inherently make it more expensive since time costs money. Higher quality design generally takes longer and is more expensive. Some things are inherently time-limited such as publishing deadlines and having a booth at a show. Other things demand a standard of quality that cannot be compromised on - safety of flight is one I remember from my flight testing days. As a generality the three parameter summary it a good one, I think, because it captures a true idea in a catchy phrase. Perhaps the real enemy is simplistic planning that imagines that we as human beings have far more control of what we do than we really do. This leads to RewardTheNonContributors? and PersecuteTheWorkers?. There have been some interesting studies in which the best result was obtained by no explicit planning. I have to believe that those were very small projects. --RaySchneider

[Do you mean studies of cases where the best result was obtained by a deliberate policy of not planning, or cases where the best result was obtained without explicit planning, but where omitting planning wasn't a specific policy laid down in advance?]

I'll stand behind my comments. Saying that there are three variables leaves people manipulating three variables and treating scope as a constant. This leads to a host of project management problems that could be solved easily by actively managing scope. The clever phrase makes the problem worse, because it is so easy to remember and understand. As Will Rogers said, "It ain't what you don't know that gets you, it's what you know that ain't so."

I'm with you on simplistic planning being the problem. However, I think that a simple plan actively managed is the best solution for the scale of projects I see (2-20 person years). I bow to the Lockheeds of the world for being able to put together fighter planes. Most software projects are several orders of magnitude simpler than that. -- KentBeck

Kent Beck and Ray Schneider are dancing around the "SixBlindMenAndElephant?" pattern (not documented). They both seem to be sharing insights from a common set of experiences in project management but they interpret those experiences somewhat differently.

I would submit two things. First, Kent Beck's "Scope" variable is part of RaySchneider's "Good" variable. I say this because "Good" means "Quality". Quality is a measure of how well your deliverable corresponds with the specifications or requirements you were trying to achieve. "Scope" implies the set of base-line requirements. Scope creep means the deliverable is drifting from the established requirements. If the "Scope" aspect of "Good" is a distinction that Kent Beck wants to prioritize in his rule-of-thumb, then I,say, go for it!

Second, "Good, Cheap, and Fast -- pick Two" rule-of-thumb assumes an established, "taken-for-granted" technical or operational paradigm underpins the project context. I'd contend that by changing the paradigm (perhaps by shifting from a structured to an object-oriented perspective) you can actually have all three - Good, Cheap, and Fast!. Cool! -- Dean H. Nelson