Agile Contract Types

One of the four values stated in the Agile Manifesto is “Customer Collaboration over Contract Negotiation.”

Contracts are rigid by nature. The Statement of Work (SOW) must be clearly defined, and payment terms and conditions need to be negotiated and agreed upon before signing the contract. Since the terms and conditions stated in contracts are legally enforceable, making changes to them after signing can be challenging to manage.

In projects using a predictive development approach (traditional or waterfall), the scope of work and the requirements to be outsourced are usually clear during the contract-signing process, so the number of changes made to the contract after awarding it is limited.

However, in agile projects, the scope of work is continually redefined based on customer feedback and business needs, and the requirements for developing this scope are progressively elaborated. If you are outsourcing work in agile projects, signing a rigid contract and strictly adhering to its terms and conditions, without allowing flexibility for the ever-changing scope and newly discovered requirements, can make contract management impractical. This often results in not building the product according to the customer’s evolving expectations.

Therefore, in agile project management, we have specialized contract types and contract options that allow us to outsource work to sellers without fully defining the scope of work and requirements at the time of awarding the contract. These contract types also help retain the flexibility needed during contract execution, which is crucial in agile projects.

To understand agile contract types, it's helpful to have a basic understanding of the product backlog, business values, product backlog prioritization techniques, and traditional contract types such as Fixed Price, Cost-Reimbursable, and Time and Materials contracts.

Let's now explore the different types of Agile contracts.

1. Emphasize value delivered

In agile projects, the project scope shall be maintained in the form of the product backlog. Each item we have in the product backlog is called a product backlog item (PBI). Most of these PBIs will be the features and functionalities we will have in the final product. You can treat a product backlog as a big To-Do list with all features and functionality that need to be completed to build the final product. Each of these features is called an increment. An increment is a potentially shippable portion of the final product that can be delivered to the client, and the client can reap some benefits by utilizing the feature delivered.

For example, if you're developing an online banking website, the online banking website is your final product and is made up of many increments, otherwise called features like the money transfer feature, download bank statement, check account balance, pay credit card bills, mobile notification, and so on.

In agile projects, we don't make the client wait for several months to see the whole product; instead, we build the increments, and when they're ready, we review them with the client and ship the completed increments to the client for usage. For example, let's say we are done with the money transfer feature; we won't worry about building the other features for now. Because the money transfer feature is ready, we'll hand over this feature to the client, and the client can utilize this feature and benefit from it. Of course, the client is yet to receive other key features that shall be delivered in the future, but the client is now happy because he got a part of the final product, which will help the client’s customers to do fund transfers without having the need to go to the bank to do it. Now you have delivered value to the client by letting his customers do banking at comfort, and also the client will charge some transaction fees to his customers and generate revenue.

Every feature in the product backlog shall have a business value. Business values could be both tangible and intangible, like profit, ROI, brand value, customer satisfaction, increasing the customer base, social cause, etc.

I hope now you are clear about the business value and how each increment in the product backlog serves the business value.

Now let's learn about the challenge we have in building each increment in agile projects.

If you outsource the work to a seller, we must define the scope of work and how we will compensate the seller for the work to be performed. This is very difficult in agile projects because at the beginning of the project, you won't be able to tell what the increments (features) we will have in the final product are and the requirements needed to build them. In agile projects, we progressively elaborate the requirements, and this method is not compatible with developing the statement of work and agreeing on what basis the payment will be made.

If the seller agrees to do the work based on fixed hourly rates (time and material contract), due to the ever-changing nature of work, we as buyers won't know how much money we will spend in total to finish the work. The seller will keep on charging us for all the work performed on an hourly basis. All the redo and undo we do to the work after reviewing them will be charged by the seller, and so this is very risky for the buyer from project cost management.

On the other hand, if the buyer would like to use a fixed price contract, then a clear statement of work is essential to define the price. However, due to the dynamic nature of the scope, it wouldn't be possible to use a fixed price contract.

So how shall we manage this situation?

We can emphasize value delivery. In this contract type, we don't pay the seller based on the number of effort hours spent to build the increments agreed upon hourly rates. Instead, we pay the seller based on the value of the delivered feature. The seller might have spent more or fewer effort hours but cannot charge the buyer based on that. The value of each feature or increment we have in the product backlog shall be discussed and agreed upon by both the buyer and the seller before signing the contract, and the payments will be made for the completed deliverables (increments) based on the agreed value they are worth.

In the above picture, you can see a product backlog. The feature name column has the feature list. The features are prioritized based on the business value they offer to the customer. In the value weightage column, you can find the agreed weightage of the features in percentage. The buyer and the seller negotiate and agree on these values of each feature before signing the contract.

Let's say the contract is worth $200,000 (Total value of the final product). You can calculate the price tag of each feature based on its respective value percentage, which you can find in the Value column.

The payments are tied to value delivered and are neither tied to the quantity of features completed nor the number of effort hours spent to build them.

By looking at the Pareto chart below, you can understand that a handful of features deliver most of the planned value of the final product. In this case, the first 4 features deliver 70 percent of the total product value.

Do not assume that a high-value feature will always take a lot of effort to build. Not necessarily.

For example, a customer support chatbot feature might require more coding effort than the fund transfer feature, but it’s not as valuable as the fund transfer feature.

There are several advantages to using an Emphasized Value Delivered contract:

1. It allows us to deliver all the high-value features at the beginning of the project. This way, if there are any funding issues toward the end, we only need to compromise on low-value features that still need to be completed.

2. Payment to the seller is processed based on the value delivered, not on the effort hours spent building the feature. This provides significant flexibility in making necessary changes to features without worrying about paying more based on the number of hours spent.

3. It allows the buyer to provide feedback to the seller for each increment built, and payment is only made for delivered value after the buyer accepts the completed increments.

   
   

2.  Money for nothing, Change for free

A method to close a contract early if most of the expected business value of the final product has been delivered.

For example, when 90% of the product value has been delivered, the customer will begin the contract closure process and compensate the seller with a percentage of the remaining budget as agreed (example: 80/20 sharing ratio).

In the above product backlog, by delivering features 1-7, we will accomplish 90% of the expected value of the final product. To achieve the remaining 10% of the product value, we must implement features 8 to 10, which will cost $20,000 ($8,000 + $6,000 + $6,000).

The buyer might consider closing the contract, knowing that 90% of the product value has been achieved and may not be willing to spend $20,000 to realize the remaining 10%. However, the seller may not be fine with this, as they would lose a potential earning of $20,000, so they must be compensated for the early closure of the contract. In contract terms, this compensation is called a cancellation fee.

This compensation amount can be calculated based on the agreed sharing ratio (e.g., 80/20) of the amount saved by the buyer by closing the contract early. In this case, the amount saved is $20,000, so the seller would receive 20% of $20,000, which is $4,000.

This $4,000 is often referred to as "money for nothing."

"Money for nothing" is also known as the early cancellation option. This option provides a win-win situation because the buyer saves $16,000 in potential expenditures, and the seller earns $4,000 for services no longer required.

Change for Free:

Change for free allows the buyer to change the scope of the work stated in the contract by replacing certain features with other features of the same net value at pre-determined time in the Contract life cycle. For example, features 8, 9, and 10, which collectively represent 10% of the product value, could be replaced with two features, each representing 5% of the value. This option provides the buyer with the flexibility needed to accommodate the dynamic scope of the project.

3. Fixed-price increments

Fixed Price Increments is a variant of fixed-price contracts (commonly used in projects following the predictive development approach). We know that for a fixed-price contract, the scope of work must be well-defined. However, this is not viable in agile projects. So, instead of fixing the price for the entire product or software, we set a fixed price for each increment (Features/User Stories) in the product backlog.

In a Fixed Price Increments contract, the features or increments are referred to as micro-deliverables.

The seller can charge the buyer after completing each increment, based on the agreed fixed price for the completed increments.

The buyer may suggest many changes to the increments as they are developed, and the seller may spend more or less time building the increments. However, the seller cannot charge the buyer based on the effort hours spent building the increments. Payment for the completed work will only be based on the agreed fixed price assigned to each increment in the product backlog.

Completion of each increment is confirmed based on the Definition of Done (DoD). Therefore, we must include a proper Definition of Done for each feature in the proposal and consider a contract amendment to allow scope changes during contract execution.

This contract type gives the buyer more control over the money spent.

If the scope of an increment changes during contract execution, the fixed price for that increment will be revised based on the scope change, and the new price will be fixed. This limits the supplier’s financial risk of accommodating extensive scope changes without adjusting the fixed price. Only for increments whose scope is modified will a price amendment be made.

In the table above, you can observe that the prices for increments 3 and 5 were re-estimated due to scope changes, while the fixed prices for the remaining increments remained unchanged.

I understand you may find it a bit challenging to differentiate between Fixed Price Increments and Emphasized Value Delivered contract types. Remember, in Fixed Price Increments, the price for the increments is set based on the effort required to build them based on features complexity and bigness.

However, in Value Delivery contracts, the amount paid to the seller is based on how valuable the feature is to the customer. A small feature can be highly valuable.

4. Multi-tiered structure

A multi-tiered structure is not about how the work will be completed and paid but rather how the contract is structured to offer flexibility for modifications.

Instead of creating a final contract as a single document, the buyer and seller can achieve greater flexibility by describing different aspects in separate documents. This is similar to how in employment, the terms and conditions of employment are separate from the cost-to-company document. The content of the cost-to-company document changes year by year, while the remaining terms and conditions of employment remain relatively constant throughout the tenure.

In a multi-tiered structure, we maintain three different documents: the Master Agreement, Schedule of Services, and Statement of Work. The Master Service Agreement contains contract components that typically do not change, such as warranty terms, dispute resolution clauses, and non-disclosure agreements. In contrast, the Schedule of Services captures contract items subject to change, such as service rates and product descriptions. Lastly, dynamic elements like scope, schedule, and budget are formalized in a lightweight Statement of Work. This way, when we need to modify a particular item in the contract, the entire contract does not need to be altered.

Isolating the more changeable elements of a contract into a single document simplifies modifications and enhances flexibility.

5. Graduated Time and Material Contract

This is a type of time and materials contract. In a time and materials contract, the seller charges the buyer based on agreed hourly rates and the number of hours spent performing the agreed-upon work.

One of the drawbacks of a time and materials contract is that the buyer does not have much control over the seller's performance, as the seller is paid the agreed hourly rates regardless of performance. This issue is addressed using a graduated time and materials contract, where the hourly rates are tied to specific performance metrics.

We link metrics like quality, cost saving and timely delivery of work (using the Definition of Done) to financial rewards and penalties. For example, in the table above, the second column represents the graduated hourly rate. For early completion, we reward the seller by paying a higher hourly rate of $100, whereas for late completion, we penalize the seller by offering a lower hourly rate of $70. For on-time completion, we pay $85.

This approach encourages the seller to perform well while giving the buyer some control over the seller’s performance.

In this case, we used schedule performance as the performance metric. We can set any performance metrics, such as quality and cost savings, based on our project needs.

6. Not-to-exceed time and materials contract

This is also a type of time and materials contract. One of the biggest risks for the buyer with a time and materials contract is that the buyer may not know the total cost to complete the contracted work. Until the work is finished, the seller can charge the buyer on an hourly basis.

In a not-to-exceed time and materials contract, the buyer sets a limit on the overall budget and keeps it fixed. This budget limit acts as a ceiling.

In the example below, the contract budget is set at $40,000.

The seller will perform the assigned work and charge the buyer based on the agreed hourly rates. The buyer can incorporate new ideas and innovations into the project scope (product backlog items) that were not initially planned by replacing the original work (scope).

As the seller charges based on the agreed hourly rates, the fixed budget will gradually be burned down, and once the set budget limit (ceiling) is reached, we will close the contract.

We might end up compromising on some low-value features at the bottom of the product backlog due to limited funds, and this is acceptable in most projects since these low-value items often don’t contribute significantly to business value.

In the example above, we compromised on Features 9 and 10.

The advantage of this contract type is that it mitigates the risk of poor project cost control, as we know the maximum amount we can spend to complete the work.

8. Team augmentation

In this case, we don't really outsource the work to the seller. Instead, we onboard the necessary resources from the seller’s side to work directly on the project, making them part of the actual project team. We refer to these hired resources as either external employees or contract employees.

Just like our internal employees, they will perform the assigned work and provide status updates. The project manager is responsible for their performance, and we compensate them based on the agreed hourly rates.

This is a quick way to jumpstart your project without the need to draft a detailed statement of work. Additionally, using this method allows us to hire experts and employees with skills not available within our organization and release them once the project is over by closing the contract.

© 2024 by EZBRAIN EDUTECH PRIVATE LIMITED. All rights reserved.

Copyright and License to use

This blog is the intellectual property of Ezbrain Edutech Private Limited. Readers can use it for their individual learning needs and share it with others for personal use. It is prohibited for other companies and legal entities who intend to use this blog for training purposes or to benefit themselves, their clients, and customers in any possible way. To republish or reproduce our content, you must obtain our written permission.

Disclaimer

The views, facts, and opinions expressed in this blog are based on the author's professional experience, beliefs, and facts collected from reference materials mentioned under References and citations. We did our best to ensure the content's correctness to make it reliable. Learnings from this blog help the learners, in general; however, we neither guarantee this blog will make the learners clear any project management certification exam nor its correctness. We are not liable for any consequence of applying this blog's learnings and advise readers to do things at their discretion.