When I here terms from the agile community like Who says failure is not an option? I have to wince a bit. The notion of failure as a starting point for managing project, ignores the core principle of Risk Management.
This is sometimes common in the agile development world, along with the missing concept of schedule and cost margin, and the critically important technical performance margin.
If you don't recognize them the two people standing next to me (on the left) are Gene Kranz and Jim Lovell. They spoke at our Denver PMI Symposium a few years ago. Kranz never actually used that term. It was created for the movie and the title of Kranz's book.And while they use that term, Lovell has a nice transition. Kranz describes the processes of Apollo 13 and Lovell chimes in Gene - Failure was not an option for you. Success was our only option.
Now we need a context for this notion of Failure
When it is suggested that failure IS is an option, in what context can this true?
- Are you spending someone elses money?
- Do these people approve of you failing?
- What is their tolerance for failure?
- How much are they willing to risk in the face of potential failure?
- How much money will it cost to fail and what is the value you will obtain from the failure?
These questions are actually couched in a large context of Risk Management? And since Agile is supposed to be all about risk management, let's look at how risk management actually works.
First the seminal quote...
Risk Management is how Adults Manage Projects - Tim Lister IBM Fellow
So what is risk and how do we manage it like Adult?
First the notion that you can't manage risk is nonsense. I've heard this before. You can and we do all the time. But we must acknowledge that all risk can no be eliminated. There will always be a residual risk.
There are several pieces to the risk management process:
- What are the risks?
- What is the probability that the risk will occur?
- What is the impact to the project when that risk occurs?
- What is the probability that the impact will have it's full effect?
- What will it cost to buy down or retire the risk to an estimated probability of occurrence?
- What is the residual risk after that risk buy down process and what is the residual impact?
So here's how ADULTS can apply Agile in the Presence of Risk
- What are the risks in the project? - Don't know these and you're spending someone elses money, your career as a PM is going to be short lived.
- Do you have a plan on how to handle these risks? - No? Then you're driving in the dark.
- If you have a plan to handle the risks - either through mitigation when the risk occurs (a general bad idea) or through a risk retirement plan, how much will that cost in both dollars and time? Don't know, then go find out.
Put all this information in your Risk Management Plan - from stickies on the board to a real plan. Don't have a Risk Management Plan, then you're not a PM, you're just an observer of the events unfolding in front of you.
So at the end of the day, if your customer is expecting you to stay on budget - you do have a budget right?, and somehow show up at or near the expected time with some form is useful software, Failure needs to be handled.Failure can'r be your strategy for success. Those are just platitude words. If it's your own money no one cares. But if your spending stranger's money you'd better care.
You can pay for risk retirement work. You can buy down risk by trying something and finding out it doesn't work. Try something else and find out that doesn't work.But you need some estimate of how much all this is going to cost. Otherwise you're just running open ended on budget. I know of any real commercial enterprise that allows that to happen.
But in the end you need a plan for this if you're spending other peoples money. They're going to expect that, it's their money.
Side Bar
There is a good book abut how to manage in the presence of risk and setbacks. Little Bets: How Breakthrough Ideas Emerge from Small Discoveries. These small discoveries must be risk reducing discoveries in the software development business. We're not on the business side (and common mistake in the agile world of connecting business emergent processes - like Walt failing with software emergent requirements failure).
