Recently I was looking back over some work that I did on Agile methodologies whilst working for IBM.
One of the key tenets of all Agile delivery is to deliver early and deliver often. Whatever you think about using Agile to deliver IT projects in complex organisations it is worth understanding one of the key rationales for this mantra.
Imagine this common scenario in a project steering committee. A stakeholder has submitted a change request for the project. The project team have rapidly turned around an impact assessment which indicates that it will mean delaying the go-live by 2 months to allow for the new functionality to be developed and tested.
How should the committee decide what to do? A common response to this will be to look at the additional delivery costs that this two month delay will be incur. If funding can be found to cover this then the change request is approved.
However what this has ignored is the cost of delaying any realisation of benefits by an additional two months. A sign of a healthy project with a robust benefits case is that less focus is placed on the cost of delivering the project and more emphasis is placed on when the solution will be delivered.
The graph below shows why this focus on timescales is important to the organisation as a whole. It shows two different ways of delivering the same project with the same benefits case. Approach A goes live earlier than approach B but costs significantly more to deliver. However, you can see that it still breaks even earlier than approach B because it started realising benefits earlier.
Agile delivery takes this concept to the next level by “timeboxing” releases of a project. This means that the project team commit to go-live on a particular date. In return other stakeholders commit to the principle that, if necessary, scope will be pushed from that release into subsequent releases in order to hit this date . Doing this ensures that the organisation can start realising some benefit from its investment as soon as possible.
Even if you aren’t working on an Agile project, the next time you’re next asked to look at a change to a project’s timescales have a think about what the impact of delaying the benefits realisation might be.
 There is a limit to how far the timeboxing principle can be taken due to something I tend to refer to as the minimum viable release. This reflects the fact that there is an irreducible minimum set of functionality beyond which any further reduction in functionality will result in a solution that does not provide any worthwhile benefit. This irreducible minimum functionality defines the minimum viable release but you often find it is much smaller than you might initially imagine.