Coincidentally, the topic of Agile Funding models came up at work recently, which got me thinking again about my last post. Specifically, how best to match a set of requirements to a delivery and funding model. Whilst Agile delivery is the current 'Silver Bullet' for delivery, it is not always suited to a particular business need.
The table below provides a brief summary of the best known delivery approaches;
| Approach | Summary | Application |
| Waterfall | This is the traditional model in which each phase of the approach follows on sequentially from the previous one, and is completed in full on the first pass; Requirements -> Design -> Development -> Testing -> Deployment.
| This approach is best suited to projects where there is a need for very detailed upfront analysis of the complete solution; this may be due to the complexity and interdependency of the solution or it may be through a need to be confident of the suppliers understanding of the complete solution.
|
| RAD | Rapid Application Development sits half way between Waterfall and Agile. In this approach Requirements are defined up front, but the Design, Development and Testing are completed iteratively with the final solution being deployed once completed.
| This approach is best suited to projects where there is a need for a degree of flexibility in the scope of the delivery and where there is a need to test the delivery of discreet functionality as the solution is built up. This approach has proved useful for projects that run over a long period of time as a mitigation against scope creep. This approach is well suited to business critical solutions that carry a high degree of risk.
|
| Agile | This approach is an advancement of RAD and JAD where short time boxes are used to deliver which encompass requirements -> deployment aimed at delivering fully functional deliverables.
| This approach is best suited to projects where there is a need for very rapid time to market. The approach works well where there is a low degree of risk regarding the delivered functionality; making it possible to release functionality early to users as Beta releases, slowly building up the capabilities of the solution.
|
As discussed in the previous article, one of the challenges facing CFO's is the matching of requirements with funding models. This is generally determined by the choice of delivery model.
In the case of Waterfall delivery Fixed Price is often the preferred option of the CFO. Suppliers bid based on the project definition and provide a quote based on their understanding of scope. A contract is then drafted around that understanding and subsequently Change Requests are negotiated between the two parties to arrive at a final working solution. The need for CR's is often a result of changes in requirements between the time the project was scoped and the time the development phase is under way; this can be quiet a considerable elapsed time period on large and complex projects.
For Rapid Application Development Projects, where more is known about the potential scope of the project and there is more control over the delivery, due to the iterative nature of the approach, a Time and Materials funding model is often adopted. The approach allows for better control of scope and risk and therefore T&M is often seen as being less risky than it is for Waterfall and T&M funding gives the necesary flexibility to handle changing requirements as the iterations progress.
For Agile a more radical funding model is recommended, as discussed in the previous article (Commercial Models for Agile Delivery).
