2. 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.
3. 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
4. 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.
5. 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.
6. 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
7. 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
8. 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)