Some highlights from Waltzing with Bears Part 4

We now know all about what, why and how for risk management so it's time to get down and dirty with How Much.

It's about value. This is great, I work for a bunch of people who start to go a little weird if they haven't said "Value" at least three times a day, and there's a good reason for this, apart from them being odd.

You make something, anything, for some value. You put effort in to get something out. The value of a software project needs to be clearly stated, and someone/some people need to be accountable for the delivery of this value. The other side is easy, there is always accountability for cost, schedule, scope, but what about the purpose of the work, who is accountable for that.

When benefit cannot be stated more precisely than "We gotta have it" then the cost specification should be "It's going to be expensive."

Explicitly stated value allows you to prioritise the work, essential if you are to deliver incrementally. Best of all it allows you to stop the work. When the value is lower than the cost to develop, don't do it. So easy, well so easy to write, is very hard to do. People don't like to spend the time to do this kind of work, it's hard and can be confronting. It's out of the ordinary "my business case said we'd get 300 new customers a month, that's value" but "which bit of this project will give you that? Surely some elements do more than others?"

2 points Tom and Tim make on why this is either not going to happen or be very hard
1 - it opens the door for an additional level of accountability
2 - there's no obvious pay back

I would say that one payback is that you can stop the development when what you spend is more than you will get back and if you don't explicitly state value how do you know what risks you can take?

Some highlights from Waltzing with Bears Part 1

A rip snorting book full of horror stories and help to avoid them. Title of chapter 2 says it all:

RISK MANAGEMENT IS PROJECT MANAGEMENT FOR ADULTS

Other highlights...

Prologue
Ok so I get a project that is going to fail and I have to believe in the schedule, despite the impossibility. When it fails we all go "oh dear, what a shame, but we tried". Using Clifford's argument about the ethics of belief is interesting, you need to have some evidence for your belief. Of course people will believe the crazy schedule anyway, as Cialdini points out in his book on Influence, once you make a public commitment to something you create reasons for that commitment, so this is part of being human. Wow this was going to be highlights and I am babbling.

back to the other chapters

If a project has no risks don't do it

Obviously the authors are nuts. But wait it's Tom DeMarco, he seemed sane before. "Risks and benefits always go hand in hand", phew, that seems more sane. So if I don't take a risk I don't gain anything. The risk elevator is nice analogy, a business that is standing still - ie not taking risks - goes backwards.

"Taking explicit note of bad things that can happen (risks) and planning for them accordingly is a mark of maturity." Where as technical proficiency is not a sign of maturity.

Denver International Airport disaster sounds like a great application of the 5 who's. Ask who five times and you can find the best person to blame.

The case for risk management is well put. The first one sounds wonderfully exciting "Risk management makes aggressive risk-taking possible", gosh. I hope I can remember this and the others next time I need to be "negative" on a project.