Starting a new contract isn’t always simple. When a contract starts, both parties are willing to accept risk to a certain level. Every contract usually addresses 3 variables:
- Cost of delivery of the scope
- Time or speed of delivery
- Scope of work: what is the client going to get
There are two types of contracts:
- Fixed contracts: where at least 2 out of the 3 variables are fixed. Usually cost and scope, though sometimes timeline is locked in as well.
- Agile contracts: where maximum 2 variables are fixed, and likely only 1 (cost).
At Slash, the majority of our contracts are agile. In this article, we consider why various challenges and conflicts arise in a contract and how different approaches can be helpful.
Challenges of Fixed Contracts
Fixed contracts are suitable for standard projects that do not have a high level of complexity or where all the technical specifications are very well understood (with a margin of error of less than 5%). They can also be beneficial in terms of cost control and risk minimization.
However, common challenges with fixed contracts are:
- Handling uncertainty beyond the original specifications
- Scope creep and change requests
- Tracking and accounting for project status
- If billing is fixed, incentives to shortcut effort
- If timeline is fixed, incentives to shortcut effort
Benefits of Agile Contracts
As there are challenges in most contracts, the significance of agile contracts becomes noticeable. CEO of Slash Andries De Vos notes that both parties in a contract are partners that optimize for business outcomes by establishing deep collaboration and trust.
Common benefits of agile contracts are:
Flexibility
In an agile contract, the client can choose which project components should be fixed: scope, time, or cost. If the client wants scope to be fixed, then time and budget will be adjusted, potentially enabling a client to finish ahead of time or budget. Alternatively, keeping the cost fixed can be more convenient for the client if they do not want the project budget to go beyond a certain amount and then scope becomes a variable.
Encouraging collaboration
Agile methodology is focused on collaboration and result-oriented work. With an agile contract, the parties will need to discuss work progress and interim results frequently. This builds trust and rapport, and most importantly, it enables the client to be involved at all stages of the project and share comments and suggestions early on.
Optimizing workflow
Agile methodology and therefore, agile contracts break the project into several steps, which allows the parties to have a clear and comprehensive outline of what needs to be done. Additionally, the parties can evaluate the work at each sprint, not waiting for the final release.
Now, let’s look at the challenges of agile contracts:
Less Suitable for Simple Projects
Since agile requires significant process overhead for a team to manage (e.g additional meetings/ceremonies etc), it may be less suitable for standard, simple projects. If the scope and cost of the project are well understood, the project may not require the flexibility of the agile approach and contracting.
Requires Trust
As the methodology focuses so heavily on collaboration, it requires that parties invest in building trust and collaborate in that spirit, which might be challenging if the client is unfamiliar with the agile methodology or adopts a traditional client-vendor procurement model.
Different Approaches for Agile Contracts
There are two widely adopted approaches to agile contracts.
Approach 1: fix scope, time/cost flexible
The scope remains fixed, and time and cost become flexible. In this approach, there can be further estimations of time and cost through continuous and regular backlog grooming. Detailed scope may evolve, but the broad-stroke scope is agreed upon and any material changes to the scope can be accommodated through a “switch and replace” approach.
This is a common approach when the project owner has a clear understanding of the product outcomes they want to achieve but the detailed scope and technical complexities to deliver the project are not fully fleshed out.
Approach 2: cost (and sometimes time) fixed and scope flexible
In this approach we optimize for a fixed team capacity that can deliver a relatively predictable workload over a period of time.
The specifications of that workload may not be fully defined yet or in some cases may be totally unknown and emergent based on user feedback, or new strategic initiatives.
This approach is common when developing the products which have a dynamic roadmap: live products with continuous user feedback, early stage startups trying to hustle to find product-market-fit, or strategic projects with regular re-prioritization of features.
What contracting method is right for you: the Cynefin Framework
The Cynefin framework is a decision-making model that helps leaders adjust to different and unexpected situations. An important element of it is drawing examples and conclusions from the leaders’ own experience and organization, its history. The framework is designed to assist with quick assessment of the situation and correct choice of action. It is useful in product development and organizational strategy. The basis of the framework is categorization of situations into five domains, which are defined by cause-and-effect relationships, depending on how clear or complicated the situation is.
At Slash, we usually work on complex custom systems. This type of work is more suitable for Agile development, and the Cynefin framework articulates well why complex emergent projects may require agile. Apart from allowing more flexibility, it also helps when unexpected changes and issues arise. We find the Agile methodology particularly useful for the type of projects that we do, and in our experience, agile contracts do contribute to improving outcomes of the project.
Tag Cloud
Agile - Agile Delivery - AI - amazonecommerce - Animal Framework - Attracting talent - Autonomous weapons - B2B - blockchain - businessbuilding - Business building - Clean code - Client consulting - cloud platform - Code Refactoring - coding - Company building - Computer Vision - Corporate startup - cryptocurrencies - de-risking business building - Deepfakes - Deep Learning - DeepMind - derisking business building - Design Research - Developer Path - DevOps - Digital Ownership - Digital Product Strategy - ecommerce - entrepreneurs - Figma - founder equality - founder equity - front end developer - Fullstack Engineer - Growth strategy - Hook model - Incubator - innovation - Iterative and Incremental Development - legacy system - Manual Testing - Metaverse - methodology - Mobile Engineer - Natural Language Processing - NFT - NLP - online recruitment - playbooks - Podcast - Product Design - Product Development - Product Development Strategy - Product strategy - product versions - project management - Prototyping early-stage ideas - Quantum Computing - Recruitments - Remote Work - Research - research problem - Robotics - Sales machine - scalable software - Scrum - Self-Driving Cars - Serial entrepreneurs - Slash - software - software design - Software Development - Software Development Company - Software Engineering - Spotify Model - Staff Augmentation - teamwork - Tech Talks - tech teams - tech vendor - testing playbook - The Phoenix Project - Unit testing - user interview - user retention design - VB Map podcast - Venture Building - Venture building strategies - Venture Capital - venturecapital - virtual retreat - Web3