Can somebody please tell me what's wrong with this picture? One Sunday afternoon (yes, I was thinking about this stuff at the weekend) I found myself going off on my own, off-piste. Trying to explain to myself, and thereafter, possibly explain to others why software projects have the kind of life cycle and experience that they do. I've read Freedom from Command and Control by John Seddon and really like his distinction between "Value Demand" and "Failure Demand."
This is my gloss on Seddon, and it's a while since I read him. Roughly speaking:
Value Demand: Things that you want an organisation to do for you e.g. Change a tyre on your car
Failure Demand: Things that go wrong in the process of trying to deliver the value demand, that in themselves need fixing. e.g. Breaking the hub cap while changing the tyre, which then requires a separate extra task, and extra cost of a new hub cap.
However, for an IT project, I don't think this is enough of a distinction. Seddon seems to be writing mainly about service organisations, where what's required to respond to a particular service call is
understood. I would say that in software development, things can a little more complicated. In software development
at each stage of the process, extra value demand can be discovered. I don't know what anybody else has called it, but I'm calling it
discovered demand. Some examples of discovered demand? OK, here goes:
Discovered Technical Demand: A tweak to a web page design (Value Demand) results in a huge number of extra sales of widgets. This brings down the sales database and makes the entire site unresponsive. An entire new database architecture is required to deal with this. This is what my old boss
Mik Lamming used to call "a success disaster."
Discovered Value Demand: Now it's got really easy to buy widgets on your site. It seems obvious that at the joyful moment when you buy your widget you should also be able to comment on your widget purchase on all social networking sites.
Discovered Value Demand: Now the process of buying widgets has been streamlined, it's obvious that some information that's asked for across several different pages would be better off being asked all at once.
Some examples of failure demand?
Failure Demand: The ways the CSS is set up means that most of the importand credit card fields can't be seen on a standard 800x600 laptop screen.
Failure Demand: It at any point you press the "back button" you get a 500 error.
Once you start to think about this, you start to realise that for digital project management, this might be one of the answers for the "ultimate question" of Taiichi Ohno: "What is it?".
What Digitial Project Management is about is delivering value. A lot of value is discovered in the progress of a digital project. So, for most projects:
Managing Digital Projects is about Managing Delivering Discovered Value
OK, back to my diagram. The point that I'm trying to make with it is that at every stage of development value is discovered and failure demand rears its ugly head and needs to be attended to. This might explain why the average error on the estimate of effort and/or time taken to deliver digital projects is 150%.
Posted via email from Agile Lab Blog
