This article considers the traditional waterfall approach to an IT project vs an agile methodology and contract.
Traditional IT contracts use a waterfall methodology, which requires a detailed statement of the scope. In practice, the statement of scope used is often insufficient. In the context of a procurement process, there are many factors working against a statement of scope being sufficient, including:
- Customer does not know the technology which shall be used;
- Customer does not utilise sufficient resources;
- Vendors do not do much due diligence on the scope; and
- Negotiations are too adversarial to be conducive to resolving the scope.
In other words, the certainty provided by having a detailed statement of scope may be illusory. IT contract with a waterfall methodology have often failed due to the statement of scope being lacking or defective.
Agile development methodologies
Agile software development methodologies have been around for some time and are widely used by IT project teams. There are a number of different varieties but they all come down to a collaborative process for the design, build and testing of software iteration by iteration.
Recently, the use of agile software development methodology has increased but the traditional waterfall contract documentation is still being used. This is a mismatch, which results in the customer having limited ability to get things back on track when the outcomes delivered are not aligned to their expectations.
Align contract and methodology
Much better outcomes are likely where the contract is aligned with the methodology used. As such, contracts specifically drafted to ensure that the customer retains rights whilst participating in the collaborative process are better suited to the agile methodology. These contracts are known as an agile contract. The key feature of an agile contract is scope governance through a collaborative process involving regular meetings to review the design, build and testing of each iteration.
It is also advisable to build in safeguards against any breakdowns in scope governance, such as:
- periodic right to terminate by the Customer;
- loss sharing on any failed iterations; and
- right of direction on design by the Customer.
IT projects have three key parameters; scope, time and price. If the collaborative process deals with scope then there are various options for dealing with price, ranging from time and materials to fixed price, with a number of additional features available, such as, capping and adjustment. The most natural fit for an Agile Contract is time and materials. In the public sector, traditionally to meet budgetary requirements having fixed time and fixed price for the project was required. An agile contract can accommodate fixed price but a price approach with more flexibility may have advantages for the smooth conduct of the project.
As a way of promoting the success of your next IT project, we recommend aligning your project methodology with your contract design. It is a worthwhile investment to amend your old IT contracts to accommodate an agile contract methodology.