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 2

Part 2 describes 99% of the software industry in Australia


In "The Case against Risk Management" I particularly enjoyed these little snippets...

"Some organisations are so desperate to believe they are in complete control that if they realise the aren't they settle for the illusion of control. The most common symptom of this is ridiculous precision (a very narrow window of uncertainty) attached to estimates that subsequently turn out to be very inaccurate."

Working in Agile Land we face up to the inaccuracy of our estimations everyday. We avoid trying to make precise estimates as we know this is just an illusion. So we use story points or ideal days or gummi bears or dog sizes. We assume an estimate is well an estimate, and for most people in software this is a strange idea, a confronting idea, even a stupid idea.

The whole section on Risk management in isolation is significant - ok lots the book is significant, maybe not the Library of Congress bits, and the advertising. If you start down this road to finding risks and acknowledging uncertainty but you are working in a land of happiness where uncertainty is not acknowledged you are sunk. "The worst organisations penalise unappealing forecasts, but not unappealing results". A friend working for a rather large telco told me the story of the three program managers, the first two were fired as they said the plan was impossible, the third kept their job because they agreed to the plan. Number three gave Churchillian motivational speech to his team "The schedule is impossible but we are going to stick with it anyway".


The Indy Car analogy is excellent.

"When you challenge your subordinates to pull out the stops and bring the project home on time (even though the schedule is ludicrous ... they will take every chance ignoring every imaginable downside, in order to preserve - at least for the longest time possible - any thin, little chance of winning."

I remember discussing one of the side effects of this behaviour 12 months ago with the director media company. He was (and is) a very savvy guy in all things online, but not really in software development. We talked about how in online news it's great to have stories that have long tails ie people keep coming to read the articles after the initial burst of interest. In software development there is a long tail too, but it's not a nice one. If we have a flurry of activity trying to complete some work to a foolishly short schedule we cut corners - either intentionally or unintentionally - the long term effect is when you come back to that code it takes longer to change, the changes are riskier, and the long tail is what looks to be a small cost but it's one that adds up every time you hit that bit of code. Add to this fun that 40-60% of code is developed after release you have created for yourself a serious problem.

How can we avoid this kind of stupidity? <agile rant goes here>

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.