PROJECT MANAGEMENT: AGILE PROJECT MANAGEMENT
What is an agile contract? Do we use agile contracts in Agile projects management?
stand what an agile contract is. Many of the project contracts would involve the customer engaging the supplier to deliver a specific solution in a number of ways and may be quite elaborate. Accompanied with this there may be several drop dead deadlines and associated price or penalties to it. When looking to structure a contract in a way that is more conducive to working with agile, it is most important to understand the level of trust and collaboration between the customer and the supplier. Trust is a difficult area to cover in a contract, as many elements of a contract concern the problems that may occur. Therefore a contract needs to support collaborative ways of working (e.g. by containing incentives and levels of commitment).
A customer and supplier may have worked together for several years and the trust and collaboration between them may be very high. Alternatively, if a supplier is new to a customer, levels of trust and collaboration might be unknown and difficult to assess. The reason this is so important is because it will determine the amount of risk that is shared between the customer and the supplier. The risk relates to the uncertainties of the project. A popular phrase used extensively in project management is a reference to 'known unknowns' and 'unknown unknowns' and these exist on any project. When these unknowns appear during a project, who 'pays' for the change: the supplier because they should have anticipated it, or the customer because they should have specified it?
Alternatively, should the 'cost' of the change be shared because both parties know that there is uncertainty and 'unknowns'? The more trust and collaboration that exist between a customer and supplier, the less likely it will happen that:
• the supplier will add a contingency amount to the price of the contract in relation to the amount of risk involved • the customer will go into too much detail when initiating a project in the understanding that they are removing uncertainties from the project.
Structuring a contract that is suitable when working with agile does not necessarily involve creating a completely new type of contract. Existing contract frameworks currently being used by organizations may still be suitable to a large extent (e.g. as a master agreement). However, change will be needed at the lower levels in order to work in a more agile way (e.g. in a statement of work (or SOW), which may apply to a period of
time, such as a sprint or a release). When using agile, structuring a contract according to the following guidelines is likely to be more beneficial to both customer and supplier than using a traditional style of contract:
• If possible, make the focus of what is being delivered 'outcome-based' in preference to 'output-based'. An output focus is basically about a product or solution that either is, or is not, as specified. An outcome focus relates to the benefits and value that a project enables or delivers. This allows the customer and supplier to work together to create an output (or product) that can be changed and adjusted throughout the course of the project, in order to deliver something more valuable and if the opportunity arises.
• Define the level of customer involvement needed during the project.
• Create several time-based deliveries as part of the main agreement.
• Allow for the project to be stopped at any time by the project board. This allows the customer to stop a project if feedback from early deliveries indicates that the project as a whole is no longer viable.
• Supplier incentives can be linked to the amount delivered. If the supplier delivers everything that was intended during a particular timeframe, then they receive 100 per cent (or even 100 per cent+) of the payment agreed.
Final thoughts, the guidelines for structuring an agile contract for use in an agile project are as follows: We need to focus on project outcomes or throughput in preference to project outputs; Define the amount of customer involvement required in order to collaborate with the supplier in the best way; Buy amounts of time relating to time boxes with deliverables; Allow for a premature end to the project should the project all of sudden become unviable; Relate supplier incentives to the amount of values delivered.
This article was written by Dr Laban Mwansa, MSP®, PMP®, PRINCE2® Practitioner, Agile®,
Laban is a consultant and trainer in project management and specifically trainer/coach in PMP®, PRINCE2® Practitioner, and PRINCE2 Agile® in Zambia, South Africa and Europe for many years. He was in the executive committee of ICTAZ as technical chair. He is also the managing partner of Betaways Innovation Systems and can be reached at: Laban. Mwansa@ betaways- innovations. com, +260975280392 or WhatsApp +27817029669. He is also a professional project management member of PMSA and PMI-USA.