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?