Fixed price contracts in agile - ALN Delhi NCR Meetup - 2


Published on

Experience sharing by Amit Srivastava and Srinath Chandrasekharan
- HCL Technologies

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Fixed price contracts in agile - ALN Delhi NCR Meetup - 2

  1. 1. Contracts in Agile Experience sharing by Amit Srivastava and Srinath Chandrasekharan HCL Technologies
  2. 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. 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. 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. 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. 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. 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. 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)
  9. 9. Questions ? Questions ?
  10. 10. Thank You Thanks 