Software Development Contracts for Increased Agility
- Tudor Precup
- January 13, 2023
Fixed and Evolutionary Software Development Contracts
Software development contracts can be fixed and progressive or evolutionary. The latter is the best option for complex software development projects, while the former is suitable for smaller projects that are well-defined and do not allow scope creep. Fixed contracts provide comfort to both clients and lawyers because they aim to protect them from potential risks. However, they often do not take into account the possibility of the project not reaching its goal. Clients who think they can predict the whole project beforehand are mistaken; the software development process is intricate and can have unexpected turns at each step. Therefore, contracts should promote collaboration, flexibility, and openness between all parties involved.
Risks with Fixed Contracts
Fixed contracts go hand-in-hand with fixed-price, fixed-scope software projects and present significant risks. For example, such agreements cannot always account for a user group that may have gone unnoticed during the development process. If this occurs, the client may need to undertake a product redesign to incorporate the new group’s needs. Catching the error late in the process puts considerable pressure on costs. In short, the project team might have to redo part of the already implemented functionality to integrate the new ones successfully. With a progressive contract, the client can avoid such setbacks. As lawyers usually focus strictly on handling a loss of trust and collaboration between parties, they can miss the primary role of the contract, which is to support the project’s goal.
Bridging the Gap Between Legal Professionals and Project Teams
When framing contracts, legal professionals must plan for the worst-case scenario. In short, this means a break of trust and collaboration. In most cases, there is little trust between the contracting parties when they draft their first contract. Consequently, negotiations often resemble a war. To switch from the battle mood to collaboration and transparency, each party must learn about, understand, and address the valid concerns of the other. Thus, lawyers with little or no experience in agile development should get accustomed to the methodologies for progressive delivery. On the other hand, the IT provider must listen carefully to the client’s concerns and find ways to alleviate them. Including legal professionals in cross-functional teams before the start of the project can help draft contracts that serve the project’s real purpose.
Supporting Agile Development with Contracts
A typical contract for sequential development makes the supplier responsible for any failure in the process. Thus, the customer can treat any deviation from the pre-established process as a breach of contract and seek remedies. Conversely, Agile proponents consider this approach unreasonable, unfair, and unproductive for both parties. The main argument for this statement is the unpredictable nature of software development and the certainty of some degree of failure. Contracts should permit oversights and provide the legal means to correct them efficiently and cost-effectively. Therefore, Agile contracts must emphasize real-time visibility and control of the project over legal remedies for failed projects. Why focus on failure when we can create the premises for collaboration, transparency, and shared responsibility? Adapting existing templates and contracting approaches to support the Agile model is not for the faint-hearted. We will present next several solutions that can lead to agile contracts.
Say No to Software Development Contracts Without a Project Vision and Clear Business Goals
There are cases when none of the contract drafters has been working on the project. In such cases the documents can miss the project’s vision, scope, and business goal. We advise you to avoid negotiating such contracts since they signal a silo mentality. Failing to involve the development team and product owner in contract drafting leads to rigid clauses focused on risk management instead of on producing working software. In short, tell the client’s professionals who drafted the contract you expect a clear project vision and scope and a well-articulated business objective. Furthermore, make it clear you want the software development contract to start with an executive summary that includes the engagement and payment models. If the legal professionals need clarification on your requests, suggest they attend a workshop on project visioning and one on the Agile SCRUM methodology.
Minimizing Waste with Agile Software Development Contracts
In any software development project, there is always some degree of waste. This can be caused by overproducing features, underutilizing people, and losing valuable know-how. Furthermore, waste results from missed deadlines, unclear or delayed instructions, task switching, and unrealistic expectations. Coding errors, learning new technologies, and half-finished work can also lead to losses. Fortunately, there are ways to reduce the impact of these losses with an agile contract. These include defining an effective communication process, clear roles, and responsibilities, and not requiring an initial product backlog. Additionally, letting the project grow gradually and testing the deliverables at the end of each iteration can reduce the error rate. However, some losses, such as knowledge loss when people leave the team and time loss from task switching, are unavoidable.
Limiting the Impact of Non-Legal Contracts
In software development projects, agreements that are not legally binding contracts can have a negative impact. To limit their consequences, it is best to use agreements that prioritize collaboration, development, and knowledge. Having too much focus on non-legal contracts during a project’s execution can impede the successful completion of the product. Additionally, such contracts can cause lengthy and difficult discussions. To avoid this situation, the parties in a purely agile project should avoid predefined lists of deliverables and backlogs. Instead, they should add features to the product in a process of ongoing learning, discovery, and improvement.
Avoiding Lists of Deliverables and Excessive Planning in Software Development Contracts
A new partnership in software outsourcing usually starts with low levels of trust and transparency. Consequently, the parties ease their concerns by including pre-defined lists of deliverables and various plans in software development contracts. Unfortunately, this approach takes precious time and produces no value. Why bother with a pre-defined list of deliverables the client cannot know upfront? Rather than guessing what would make a good product, the parties should embark on a voyage of discovery and learning. In this trip, they will shape the deliverables with the constant involvement of their users. An early focus on deliverables will produce waste activities. The same goes for quality plans. How can one define them when the client only knows how the product will look at the last development iterations? The parties in an agile development project should focus on cooperating to create useful software.
Addressing Lawyers' Concerns With Agile Contracts
The contracting parties spend significant time drafting and negotiating liabilities, indemnification, penalties, warranties, and termination. All in the name of risk management. Of course, all these areas deserve attention. The question is how much. Signing a contract that makes no party happy is undesirable. Instead of battling each other, the contracting parties should reflect on how vital those provisions are for the project’s success. Unsurprisingly, negotiating software development contracts is labor intensive. As many legal professionals lack understanding of the development work, they focus solely on their perspective, causing tensions in negotiations. The good news is that the frequent incremental delivery of completed product parts makes negotiating critical contractual terms less stressful. Furthermore, the parties define the requirements iteratively in agile projects, avoiding waste with useless requirements.
Avoiding Penalties and Incentives in Software Development Contracts
Penalties and incentives are common in software development contracts. After all, why shouldn’t they be? It seems logical to expect a payoff from both positive and negative reinforcement. However, there is ample evidence against the belief that performance- and deadline-based incentives are beneficial. Instead of helping reach the project’s goals, they reduce quality and transparency. To get the incentives, providers sugarcoat their results. Conversely, to avoid penalties, they sacrifice code quality. All these unwanted side effects can stretch the budget and even derail projects. Furthermore, drafting, writing, and negotiating the provisions for penalties and incentives take plenty of time for salespeople, procurement specialists, and legal professionals. So, what are the alternatives? First, simplify the contracts by avoiding performance-based penalties and incentives. Next, make it easy for the customer to terminate the project at the end of an iteration if they are very dissatisfied. Last, consider shared pain/gain models.
Other Best Practices with Software Development Contracts
To let change occur naturally, avoid a rigid change management process. Furthermore, base the entire acceptance process on the definition of done agreed upon by the customer and supplier at each iteration and involve product users at every step. As for liabilities, keep them low with the incremental acceptance of functionalities. Furthermore, mitigate termination with the delivery of working software in each iteration. Finally, leave room for early termination based on completing all the project requirements. Obviously, a supplier with dozens of people allocated to the client for several years is in trouble if the client terminates the contract much sooner than agreed. For such cases, agree on a penalty for the client that is proportional with the number of people terminated and the timing of the termination.
Pricing Models in Software Development Contracts
Software development contracts range from fixed-price, fixed-scope, and fixed-duration (FPFSFD) to time and materials. When trust between the parties is low, clients wish to mitigate the risks with FPFSFD contracts. Furthermore, they want to know the total project cost for budgeting. Suppliers also like FPFSFD since it lets them secure the total order value. Besides, FPFSFD allows salespeople to get a full commission at contract signing and managers to save time on the project. As mentioned before, suppliers have enough aces up their sleeves, so risk mitigation by the clients is unlikely. The opposite of an FPFSFD contract is the fully progressive, time and materials one, which shifts the risk to the client. Signing such contracts is possible only when the trust between parties is very high. We will touch on several types of contracts and strategies used to transition from FPFSFD to progressive contracts.
Main Types of Agile Contracts
While the traditional FPFSFD contracting approach still has adepts, most providers refuse it upfront to avoid costly contract disputes and the high risks it entails. Instead, they favor one of the following three types of agile contracts:
- Incremental delivery,
- Target cost,
- Time and materials.
Incremental delivery contracts break up a project into smaller pieces, each checked at a review point and paid after the review. The parties can check the project’s progress, make changes, and continue or end the agreement. In a target cost contract, the price agreed-upon covers the supplier’s costs and overhead, plus an allowance for the supplier’s risk.
Target-Cost Software Development Contracts
Target-cost software development contracts use a formula to adjust the price paid by the client. The formula compares the actual cost with the target cost and adjusts the price, so that both parties benefit from any cost savings and share any cost overruns. Thus, when the actual costs exceed the target, the parties share the burden, and they both gain when the costs are lower. This approach encourages waste reduction, as the supplier wishes to increase the project’s profitability and the customer to save money. The parties can adjust the formula during the project to reflect increased transparency and improved collaboration. Their success in this endeavor depends on open-book accounting and framing the adjustment guidelines early in the process. Furthermore, the provider should run automated tests for acceptance and avoid requesting adjustments frequently.
Variations of Progressive Software Development Contracts
Clients may prefer capped versions of progressive agreements to limit costs. This approach helps promote efficiency and avoid unexpected expenses. While the capped version can reduce the flexibility and agility of the time and materials contract, it is still less restrictive than a fixed price, scope, or duration agreement. Examples of contract variations crafted by agile outsourcers include:
- fixed-price, variable-scope,
- capped-price, variable-scope,
- capped-price, partially fixed scope,
- capped time & materials per iteration, release, or project,
- fixed price per iteration,
- fixed price per story point or function point and
- hybrid shared pain/gain models.
With the latter, the client’s payment depends on the actual effort. If the time the provider spends on the project deviates from the estimation, the corresponding payment varies less. For example, if the supplier’s effort is 15% less than estimated, the customer pays 5% less, while for a 15% higher effort, the customer pays 5% more.
Multi-phase Software Development Contracts
The multi-phase pricing model suits long-term projects that the parties can break into shorter contracts. At the start of the collaboration, trust is at its lowest. Consequently, using a fixed price contract eases the tension and helps predict the costs. As the relationship progresses and the parties establish effective communication channels and processes, they begin to trust each other. When this happens, switching to a less restrictive contract that encourages collaboration comes naturally. Besides low trust and cost predictability, regulatory constraints and the initial lack of vision can justify a multi-phase pricing model. Here is a typical example of such a model:
- Fixed price, fixed scope per project,
- Fixed price, variable scope per project,
- Fixed price per unit of work,
- Capped time and materials per iteration.
Conclusions
For many clients and legal professionals, the goal of software development contracts is to mitigate the fears and risks of the contracting parties. Yet strong clauses that provide security can slow the project’s progress. Legal professionals should prioritize project goals and incorporate principles like collaboration, transparency, and trust in contracts to support agile projects. Thus, the focus of a software development contract should be on ensuring the client gets good working software with minimal effort. The article presents different ways to achieve this goal. It starts by covering different types of contracts used in software development and ways to minimize losses. Furthermore, it touches on invoice, penalty, and deliverable list avoidance topics, common pricing models, and multi-phase contracts.