- Deploying solutions (particularly web based solutions) nowadays can cost very little $$$ especially if you’re adopting continuous integration techniques - so any percieved deployment 'overhead' is almost negligible.
- Most applications that our organisation has developed over the years either include functionality that is never or rarely used and (at the same time) do not include functionality that the users would love to have. My estimate is around 20% unwanted features and 40% missing features. Delivering often and early allows you to get feedback from users that can change the direction of the project in time to reduce both of these figures.
- If the project does not return the expected value you can cancel it after the first release rather than waiting to find out that it’s a dud after deploying the complete system.
- Releasing the project in stages allows the roll out of the application and subsequent training to be spread over a longer period and can run in parallel with development. This can actually result in faster delivery overall.
- Bugs are fixed closer to the time when they are created. If each release needs to be bug-free a bug cannot last in the system for longer than a single release. It’s widely accepted that a bug found early is easier to fix.
- Early releases mean we can deliver business value sooner and can start depreciating the costs of the software assets sooner – the bean counters seem to like this.
- Even if the project overall takes longer (but we didn't think it would) the perception from users is that it’s arrived sooner – the users will be using the first release early on, which will increase their sense of ownership, which will feedback to future development work. The perception of most development work is that it’s slow and unresponsive, frequent releases can help change that. In fact users are probably more willing to wait for subsequent releases if they can see progress being made.
- In addition, this particular project would change some business processes, we didn’t want to change these too fast for the business, nor were we sure that the proposed changes would be feasible – the staged release helped us to mitigate these risks.
Thursday, June 28, 2007
I recently had a meeting with a manager trying to get approval for a small/medium sized project. The project team advocated developing and rolling the solution out in three separate phases. This manager’s response was ‘surely this will take longer and cost us more?’ I’m not sure how common this is, but we countered his argument by making the following points: