It sounds like an oxymoron: reduce risk and increase value. If it sounds too good to be true then it usually is. But in the world of software application development there is a technique that can do both. It goes variously by names such as prototyping, iterative or Agile development. The roots of the technique go back to the earliest days of software development but only recently has it moved towards the mainstream.
The problem with the technique is that it is in many ways counter intuitive and goes against some traditional wisdom. But since IT projects have been failing spectacularly for many years some traditional wisdom needs to be reconsidered and our intuition examined carefully.
The trick to squaring this particular circle involves dramatically reducing the time between the start of a software project and the first delivery of working, usable, software product. Then repeating the approach again and again. This creates a feedback cycle in which projects can be controlled.
This immediately has several effects: firstly projects start to deliver tangible business value sooner and secondly risk is reduced because deliveries are made throughout the development cycle rather than in ‘Big Bang’ at the end.
Another, potentially valuable, effect also occurs. Because development phases now occur in parallel rather than in sequence decisions can be deferred until later in the cycle. Consequently more flexibility is introduced into the project.
Too good to be true?
Although the ideas behind iterative development have been known for many years it is only in the last few years that the techniques and approaches needed to make iterative development to work well have been understood.
Technical techniques like: test driven development, emergent design and refactoring are relatively new to software development. Unfortunately this means that few software developers were taught these skills in college.
But it is not only technology techniques that need to change: project and line management need to change too. Again, because these techniques are new few managers are experienced in using them. Some of these techniques can, at first sight, appear counter intuitive and if applied poorly can actually damage a project.
If all this sounds risky in its own right then you might prefer to stay with the traditional techniques, except that the traditional techniques don’t actually work that well so using them is itself a risk. Fortunately the new techniques have their roots in the Lean systems developed by Toyota and in Organizational Learning – a well-developed Business School subject.
The catch
The good news is that migrating to an iterative approach need not involve replacing your staff, existing IT staff still know your business best. The bad news is that moving to iterative development involves more than simply passing a mandate and instructing people to do it.
To successfully perform iterative application development staff need to change the way they work. The process and practises of successful iterative development are different from those of traditional – or ‘waterfall’ – development.
Example
Imagine a 12 month long application development project. The project is forecast to deliver a business benefit of £2m at a cost of £50,000 per month for the duration of the project. Let us assume a discount rate of 5% per annum (0.42% per month) and negligible inflation.
In a traditional project all benefit is realised at the end of the project, at the end of the final month. At the beginning of the project we can calculate a net present value of £1.32m or return on investment of 20% – using an internal rate of return calculation.
Contrast this with the same project run on iterative lines. The same costs, final benefit and discount rate apply but this time the project delivers value at the end of month third. In each month after the second one-tenth of the final value is delivered. Thus benefits are realised sooner.
This increases NPV slightly, to £1.35m, up £36,000 but has a more dramatic effect on RIO which increases to a staggering 100% because benefits flow so much sooner. This is because the project is cashflow negative for a much shorter time.
Now imagine the project was cancelled in the sixth month. In the traditional scenario the project looses £300,000 without delivering any value. However, in the iterative scenario the £300,000 costs are more than matched by the £500,000 of business value delivered, even here there is an overall NPV of £489,500 and an ROI of 95%.
|
|
Traditional
development
|
||
|
Month
|
Development
costs
|
Value
delivered
|
Net cashflow |
|
1
|
£
50,000
|
£
0
|
-£ 50,000
|
| 2
|
£
50,000
|
£
0
|
-£ 50,000
|
| 3
|
£
50,000
|
£
0
|
-£ 50,000
|
| 4
|
£
50,000
|
£
0
|
-£ 50,000
|
| 5
|
£
50,000
|
£
0
|
-£ 50,000
|
| 6
|
£
50,000
|
£
0
|
-£ 50,000
|
| 7
|
£
50,000
|
£
0
|
-£ 50,000
|
| 8
|
£
50,000
|
£
0
|
-£ 50,000
|
| 9
|
£
50,000
|
£
0
|
-£ 50,000
|
| 10
|
£
50,000
|
£
0
|
-£ 50,000
|
| 11
|
£
50,000
|
£
0
|
-£ 50,000
|
| 12
|
£
50,000
|
£
2,000,000
|
£
1,950,000
|
| Total:
|
£
600,000
|
£
2,000,000
|
£
1,400,000
|
| NPV:
|
£
1,318,595
|
||
| IRR:
|
20%
|
||
|
Iterative
development
|
|||
|
Month
|
Development
costs
|
Value
delivered
|
Net cashflow |
|
1
|
£
50,000
|
£
0
|
-£ 50,000
|
| 2
|
£
50,000
|
£
0
|
-£ 50,000
|
| 3
|
£
50,000
|
£
200,000
|
£
150,000
|
| 4
|
£
50,000
|
£
200,000
|
£
150,000
|
| 5
|
£
50,000
|
£
200,000
|
£
150,000
|
| 6
|
£
50,000
|
£
200,000
|
£
150,000
|
| 7
|
£
50,000
|
£
200,000
|
£
150,000
|
| 8
|
£
50,000
|
£
200,000
|
£
150,000
|
| 9
|
£
50,000
|
£
200,000
|
£
150,000
|
| 10
|
£
50,000
|
£
200,000
|
£
150,000
|
| 11
|
£
50,000
|
£
200,000
|
£
150,000
|
| 12
|
£
50,000
|
£
200,000
|
£
150,000
|
| Total: | £
600,000
|
£
2,000,000
|
£
1,400,000
|
| NPV: | £
1,354,669
|
||
| IRR: | 100%
|
||
| Assuming |
| Annual discount rate:
|
5%
|
|
|
Monthly discount rate:
|
0.42%
|
|
|
Monthly project cost:
|
£ 50,000
|
|
|
Projected final value:
|
£ 2,000,000
|
|