Contracts in Agile

Experience sharing by Amit Srivastava and Srinath Chandrasekharan

HCL Technologies

Fixed Price Contracts in Agile

These are called so because they ‘fix’ the scope and price of

a project.

Some of the advantages of using FP contracts are (from a

client perspective)

• Client risk is reduced as scope and cost is defined.

• Both parties to the contract are in better control as the way

forward is described.

• Vendor has a strong incentive to control costs.

• Companies have experience with this type of contract.

While it is strongly advised that Agile projects should follow a T

& M pricing model, the ground reality is that some of the

clients prefer to go with the ‘Fixed Price Contracts’ as they

would like to know upfront what it that they will be spending on

the project.

Types of Fixed Price Contracts

in Agile Target-scope model

Budget for the project is fixed, i.e. fix the Price only and

not the scope.

Scope is negotiable based on commonly agreed rules.

Effort is tracked per feature during implementation

Exchange Requests:

The contract is signed like a normal Fixed Price Contract

but provision for Exchange Request is made.

Execution happens in the Agile way.

Whenever change is needed to the original scope, the

change request is estimated for effort (and thus cost).

After approval from customer, the team decides to

remove one or more features or same effort from the

product backlog. This is in agreement with the Product

Owner and the Agile team

Types of Fixed Price Contracts

in Agile Sprint Contracts:

In this type of contract, the client agrees for an overall contract /

price based on initial understanding of the scope.

This is further broken down into milestone based payments. For

example, the contract maybe for $50000, but there can be a clause

which says that payment will be made only if 90% of the user

stories at the end of every sprint meet the acceptance criteria. This

will force the service provider & client to lay down the acceptance

criteria unambiguously.

Mixed Contract:

In this type of contract, the Requirement gathering/elaboration

phase is run in T&M mode with the duration being Time boxed to

say 2 months.

At the end of this phase, the team comes out with a well

understood requirements document and the effort (thus cost) as a

Fixed Price.

When to use a contract type –

A guideline

Contract Type When to Use

Target-scope model Client has a fixed budget which is not negotiable. HCL has worked with the client earlier and hence trust factor is high. Some previously used and understood estimation mode is available.

Target-cost model Client is new to HCL. Clear definition of fixes, clarifications, and enhancements is available.

Exchange Requests Budget is fixed. Estimation model is clear and understood clearly by both sides.

Sprint Contracts Initial understanding of the scope is high. Team is confident of delivering an agreed percentage (which it commits to) at the end of sprint. Estimation model is clear and understood clearly by both sides

Mixed Contract Requirements are not clearly understood and hence estimation cannot be done; hence have a requirement stabilizing phase in T & M mode. Client can commit time during the requirements hardening phase. Estimation model is clear and understood clearly by both sides.

Case Studies

A) New customer migration from legacy platform to .NET due to performance and

maintenance issues

Data Migration

fixed bid quote

requirements can change during project course

Legacy system so hardly any documentation

B) Existing customer with new project Government sector

Usually only documents given as input

No customer interaction

No RFP as such

Customer specified to follow AGILE

Case Study 1 (New Customer)

• Approach

• Created business flow

• Validated approach with customer

• Engaged customer in RFP process

• FP estimation with assumptions

• Retrofitted the sprint plan based on when the delivery to be done Staffing mode

• User story broken down

• Result

• Fixed bid quote with option to revisit estimates at specific time intervals

• Transparency in estimates and issues

• Win-win situation

Case Study 2 (Existing

Customer)

Approach • Understand an already executed (Agile) project and

calculate FP’s retrospectively. • Get effort for this. • Compare difference in productivity and use that for

giving quotes

Challenges • Requirements may change during the execution. • Typically govt clients depend more on documents as

compared to discussions ( opposite of Agile manifesto)

Questions ?

Questions ?

Thank You

Thanks Amitk.Srivastava@hcl.com

C.Srinath@hcl.com