Which methodology to use
Technology is changing the manufacturing landscape. From automated cars to logistics to robotics to 3D printing. The use of technology is becoming increasingly prevalent in factories and laboratories.
In order to remain competitive, organisations are becoming keenly aware of the need to keep pace with technological advancements and their integration into their business operations.
Procuring IT is not just about entering into a contract or a licence agreement. IT procurement is about understanding and analysing the risks inherent in the procurement, how your everyday business operations might be impacted. It is also about project management and governance. These fundamental ingredients should underpin any contract for the procurement of business critical IT systems.
Contracting methodologies are two-fold. Waterfall and agile contracting methodologies have been around for a good number of years now.
This article provides an overview of those two contracting methodologies.
Waterfall contracting methodology
This is the traditional contracting methodology. It is used where an organisation knows the functionality it wishes to procure at the outset.
The pricing mechanism tends to be fixed price for licence and support (and hosting where this is also required), perhaps with some time and materials pricing in respect of consultancy services required for installation/implementation. Depending on the nature of the consultancy and the bargaining strengths of the parties, it is not unusual to see fixed price mechanisms in respect of consultancy services.
Agile contracting methodology
This methodology is preferred where an organisation is aware that it needs a technological solution but it does not know what that solution might look like. It may therefore decide to build up the solution on an incremental basis.
This allows flexibility to work up the solution and tailor it to the requirements of the organisation piece by piece.
Distinction between waterfall and agile
Traditional waterfall contracting requires the parties to determine, early on in the procurement lifecycle, the deliverables to be produced. Therefore detailed service descriptions or service solutions need to be written at the outset. Athough the waterfall approach can provide the necessary legal contractual certainty in a well written contract, it fails to recognise that:
- the technologies in today’s world means that services are capable of evolving very quickly
- customers may not have the resource and capability to define what they want at the outset
- suppliers may not have sufficient opportunity to conduct due diligence to determine whether their proposed solutions are fit for purpose
- services and deliverables will change throughout the procurement lifecycle.
Agile contracting methodology gets around some of those practical issues. Agile contracting methodology is based on an iterative process executed via collaborative working arrangements whereby the deliverables are designed and developed on an iteration by iteration basis. Fundamentally, the parties are not contracting for an end to end solution defined at the outset but rather aspects of a solution which evolve and are built upon incrementally to achieve the overall business case and meet the objectives.
Each deliverable or iteration goes through a lifecycle which can be anything up to around four weeks. The lifecycle includes designing, building and testing the deliverable or iteration to produce a tangible product which has some value or benefit to the customer, such as a component of software.
Throughout the deliverable or iteration lifecycle , daily meetings are held in which the parties report on:
- what work has been completed since the last meeting
- what work is being planned to be completed before the next meeting
- any obstacles to completing the work.
A clear distinction between agile and waterfall is agile's emphasis on collaboration. Throughout the deliverable or iteration lifecycle, both parties will work together throughout each stage to achieve the objectives. Agile contracting is therefore much more resource intensive on the part of the customer compared to what customers may be used to in traditional waterfall contracting.
Notwithstanding the collaborative nature of agile contracting methodology, it is driven through the pricing mechanisms which for true agile can only be on a time and materials basis. The more the parties move to fixed scope and fixed price contracting, the more the parties move away from agile contracting methodology. Variations to the time and materials pricing mechanisms can be adopted such as:
- time and materials capped per iteration or deliverable
- time and materials capped per iteration or deliverable with adjustment. (The adjustment would apply where the time and materials charges accrued are less than the agreed cap. The parties may agree that the difference between the cap and the accrued charges are apportioned between the parties)
- target cost pricing. (This is a gain/pain sharing mechanism where the parties agree to allocate an agreed adjustment amount if the actual costs exceed or are less than the agreed target costs;
- fixed price per iteration or deliverable.
Contracting for certainty
The correct balance needs to be struck in the contract against granting the customer appropriate rights and protections whilst not stifling collaboration and innovation. The more constraints and rigidity introduced into the contract, the more the parties move away from agile contracting methodology.
If an organisation has a set budget, wants control over charges, then agile contracting may not be the right way to proceed. However, if there is some flexibility around budget and the overriding objective is to ensure that the solution fits the need, then agile contracting methodology may be a consideration.