Pages

Showing posts with label Business case. Show all posts
Showing posts with label Business case. Show all posts

Tuesday, 25 May 2010

The business case for DSDM (and Agile generally)

Currently I am participating in a very interesting discussion about the business case for DSDM with the LinkedIn site’s DSDM Group, particularly with David Winders.

There seems to be very little hard evidence that DSDM is significantly more efficient than a waterfall approach at doing the work, which would seem to kill the business case stone dead. After all, why incur the costs of migration if the grass really isn’t any greener on the other side?

But as the discussion has evolved, it has become clear that this is to misread what Agile methods like DSDM (or Scrum) are offering. (And perhaps this should have been obvious from the start – I only really noticed this point once the discussion was well under way).

To boil down what is (for the time being) the final argument, there is indeed a narrowly economic argument for DSDM. Unlike a waterfall, DSDM is never going to waste stakeholder time and money by delivering (say) 100 function points that were agreed a year ago, when they were almost certainly based on premature and immature judgements. We probably don’t want exactly those things any more: our thinking has evolved, our goals have evolved, and the business situation has evolved. Instead it (DSDM or any other agile methodology) will deliver 100 function points and for much the same price per FP, but they will all be FPs we know we want.

Add to this DSDM’s far closer control over the delivery process, which makes it far less likely that the whole project will go over budget, schedule but under scope, and the business case for DSDM is clear: even if DSDM projects don’t cost less per FP, they represent better value for money, because they are all FPs you want.

Another interesting point was made by John Isgrove of Collaborative Consulting -

What we found was that DSDM completed the same development in 66% less time. It did not complete in less effort however as with agile projects they tend to be shorter but fatter resource profiles i.e. work for less time but more people involved at the same time across the time period. Overall effort was about the same with with higher proportions than the waterfall project being spent by the analysts and testers.

Friday, 15 August 2008

What business cases are worth

Although a sceptic about many aspects of business, one thing that seems to offer real value is the business case. Being able to show that what comes out will be more than what goes in strikes me as a fairly elementary requirement for testing whether a project or operation is worthwhile, and some of the business case models I have seen are pretty sophisticated.

Pity so few businesses have any idea how to use them. A few may be using concepts like ROI for real planning, but for most this sort of calculation is used strictly after the event. Likewise for project-based organisations. For example, in the IT world a majority of projects now have a business case, but only a minority really use it to manage the project. It ought to be an invaluable means for making all sorts of decisions – prioritisation, triage, change requests, everything really. But in practice it isn’t.

My favourite business case story comes from a decade ago, when I was consulting to a credit card company. One day there landed on my desk the business case for a marketing project that said, among much else, that one of the benefits planned to accrue from the project was that the company would issues 750,000,000 more cards in Europe.

750,000,000 more cards? That was almost two for everyone in the EU! So of course I rang up the analyst who had written this and it turned out that he had meant to write 750,000 – a rather more realistic number. We had a friendly and very amusing conversation about how easy it is to make mistakes of that kind. But when he said he would correct the document and reissue it, I asked him to leave it just as it was and se who else noticed.

So we waited. And waited. The claim was repeated in every important document from that point on wards – the requirements spec, the analysis, the designs, the testing – everywhere. And not a single other individual questioned this preposterous number. Ever.