The Fifth Variable

On FourVariables, RonJeffries writes: Resources, Scope, Quality, Time. Those are the dimensions of your project. Memorize those words and work from them every time you report status, and every time you think about what to do, or not to do.

I think there is an important dimension missing - Risk. Just as time is money (a dollar a year from now is worth less than a dollar today), risk is money (a risky dollar is worth less than a safe dollar).

For a long time, I couldn't understand why some companies employ processes which seem less efficient than possible. Today, I think that may be because these processes are a) relatively predictable (risk) and b) work well with less than top-notch developers (available resources).

I believe in the ultimate success of XP not because it's efficient (which it probably is) but because of its treatment of risk: predictability, spreading the knowledge among all developers, testing, short feed-back loops, ... IMHO, this should be a major selling point for you XP guys!

Instead of drawing HyperPentahedrons to represent these five variables, maybe it's better to just have management rank their importance. -- FalkBruegmann

As far as I understand the whole matter, risk might not be a variable on its own. Just consider this example:

You're starting some programming today morning and believe it will be finished tomorrow evening (time), you know what you will have finished (scope) and how good it will do its job (quality), you will do it alone or with a colleague (resource or cost). This sort of belief you might call planning :-).

Then there is some probability that: it will take longer (you may as well be finished earlier but only after you adhere to all ExtremeProgramming principles ;-)), it's not just what it should be (there may be even more than you planned but another feature is lacking), it's performance is bad (just an example for bad quality) and you had to call a friend because there was a problem you could not fix yourself.

This probability that one or more of these four variables go beyond their projected value, that's risk. And it is one of the core concepts of ExtremeProgramming to reduce this risk.

-- HelmutMerz

For risk to be a variable you would have to be able to trade it off against something else. What would be a strategy for increasing risk and simultaneously (for example) reducing time?

How about buying in a complicated package that claimed to do half of what you need to build? If it works, you're well ahead of the game, but you don't know if it will really deliver.

Good example. Posed- The correct strategy is to reduce all uncontrollable risks as far as possible. Please support or refute.

That reminds me of AnalyzingXpWithOptionsPricing. -- HelmutMerz

Risk is a variable, but it is not a Project variable in the sense of How long do you have to go as of today, How much is done as of today, How well does it work as of today, How many people do you have as of today. All of these can be graphed on an objective chart of people, stories done, functional tests at 100, and projected done date, all graphed vs date.

There is no sensible answer to How much risk is there today, in the same way that there is to the Time, Scope, Resources, Quality items.

Instead, risk is assessed element by element:

"We're sure we can implement the regular calls and transfers, but the cross-billing we're not sure about."

"What are you going do to?"

"We have three ideas that might work. We're going to spike them starting next week and by the time we meet again we'll know whether to do it, and how."

"OK, what about the three-party calling?" ...

Seems to me that risk is more of an attribute or aspect of each of these variables rather than a separate variable in its own right. Risk means nothing unless it is associated with something. Risk of what? What is at risk? Probably one or more of time, cost, quality, functionality, schedule, staffing, or resources/materials. Or maybe risk is a function of these other elements.

Risk-based decision-making via risk management/mitigation is supposed to be a way of analyzing, computing and evaluating risk along each of these dimensions so one can make intelligent decisions about how to tradeoff or compromise among them. That still doesn't sound like a variable to me. More like a "weight" assigned to each element of these other variables that allows us to compute weighted "paths" and alternatives on a more equal/normalized footing.

TechnicalRisk and KnowledgeGap contain information about evaluating risk. SpikeSolution is a technique for reducing risk.

Right. Now would you say those support the notion of risk as a variable apart from cost, function, time, resources, etc? Or would you say it supports the notion of risk assessment as an element of determining each of those other variables? (Or something else? None of the above perhaps. ;-)

I don't know if it helps in this context, just a try: RiskIsProbabilityTimesImpact

I suppose you could say that risk can always be traded with other variables. But then again, each of the FourVariables can be traded for the others. For example, if the requirement is to write a program that cracks 1024-bit RSA keys within 1 second, you could:

build a giant mega-super-computer (resources);
compromise the requirement - allow for longer time or less bits (scope);
use a probabilistic algorithm that does not always work (quality);
try to build a quantum computer that could do this job but will probably not be available in the next 20 years (time);
hire a bright cryptographer that will work on braking RSA (risk).

Another example is choosing whether to rely on functions that will be available on the next release of the OS you use (which is supposed to be available before your own application is released) or to write these functions yourself.

So yes, risk is an additional variable. It is not independent, tough. None of the other FourVariables are.

-- YonatSharon

Yonat nearly has me convinced. However, two last dying gasps:

WorstThingsFirst

An XP project moves high-risk items to the front and reduces risk through experimentation. Doesn't risk therefore become of less and less impact as a variable, as time goes on? Therefore it doesn't need to be reported as a separate topic? (But if you're actually reordering the project stories based on risk, doesn't it need to be reported ...)

Risk is a Component

When discussing Resources, discuss resource risks, such as TruckNumber. When discussing Time, discuss risk in terms of possible impact on end date. When discussing Scope, discuss desired features that may not be implemented. When discussing Quality, discuss risks in that realm, such as performance.

So, tell me. If I properly report the FourVariables, will I by necessity cover risk? I think so. I think I've talked myself back into it. How about y'all?

How do you rate the following: Our key vendor just phoned to say they don't think they can get the core technical component to us on time. We can (a) bet our company that they will anyway (risk), (b) delay our schedule to accommodate their tardiness (time), (c) offer them lots of bonus money so they can do whatever they need to get it to us on time (cost), (d) start a parallel design to replace that component (resources), (e) drop that function from our package (scope). Seems like risk gets its own place.

The "dying gasps" are about:

the fact that risk changes as the project progresses;
the fact that the risk variable is not independent from the other FourVariables.

Both these facts as true, but they are also true for the other variables. Each variable changes as the project progresses, and all these variables are interdependent.

-- YonatSharon

A couple of points to consider:

When you're done with your project, you can look back and say it took a certain amount of time and resources, you developed with a certain quality, and your product does a certain set of things (scope). But speaking of the risk no longer has meaning.
A post above cites "we can bet our company that they will anyway" as an example of manipulating risk, but that example is fundamentally different from the others mentioned: it's the only one that will not at all affect the outcome.

In short, the canonical four variables are things you can measure independently of where you are in the project, while risk is not; it is tied to the outlook of the four canonical variables at a given point in the process.

-- RussAtkind

Allow me to introduce a different kind of risk.

I work on projects that require regulatory approval. Sometimes we know what all the regulatory requirements are. Sometimes the regulatory climate changes abruptly as a consequence of politics (no, really) or other factors not under our control and not available at design time. Another example is the customer is acquired and the new owner changes the deal.

The consequences from this kind of thing range from simple add-a-feature/remove-a-feature to rework-the-concept and can be as extreme as project-now-irrelevant.

This isn't the sort of risk that derives from insufficient resources, lack of time, poor quality, or problems with scope. This is more external. This is piano-falls-from-crane-on-your-car-enroute-to-work kind of risk.

Now, the risk itself is not unknown. We know there are regulators. We know there's a political climate. We know that our clients are publicly traded companies.

The point is that, even knowing of the existence of external risk, it is often just not possible to quantify it.

You could generalize the concept and call it "random external influence" (random = we can't compute or predict it), but "risk" pretty much encapsulates the idea.

So, given that this kind of risk is not really a knob on the project dial, is it valid to offer it as a variable?

-- GarryHamilton

See: TheSixthVariable