Money For Nothing: Agile Procurement Management

 

Having been involved with large infrastructure projects, both in IT and construction, it is almost always the goal to get vendors to settle on a fixed priced contracts.  The advantage of using this type of contract is the reduced level of work required by the buyer to manage the contract. The buyer will know the price being charged and the incentive lies with the seller to control costs. 

The two things to closely monitor is to ensure the work outlined in the SOW is actually being completed per the contract and the other is control change requests, which are typically negotiated away by the vendor to secure the contract but used to get back the profits lost due to it.  I have personally been involved with projects that had out of control change requests that resulted in projects being way over budget and delayed.  Though I don't have the statistics on hand, I'm certain many of the major project failures were due to the inability to manage changes in fixed price contracts, especially in the government sector.

Agile/Scrum does not have much literature on integrating procurement management with Agile/Scrum since most of these kinds of projects are done with co-located, in-house teams, though I did find this post from Jeff Sutherland that outlines a "money for nothing" approach, which is a hybrid fix price contract that includes time and materials for changes.  Here's a summary:

• Insert Money for Nothing clause in fixed price contract.
  • Only operational if customer follows Scrum rules
  • Mutually agreed estimates for all work items
  • Otherwise contract reverts to time and materials
• Customer determines ROI cutoff where implementation of the next feature costs more than the value of the feature
• Supplier allows termination of contract at any time for 20% of remaining contract value
• Supplier assumes risk of late delivery of mutually agreed deliverables

I've only previewed the presentation by Jeff Sutherland and plan to review it in depth, but some issues that come to mind for me immediately is to ensure the stakeholders understand that this is fixed in price, but not in price and scope and that changes can be added giving them flexibility, but to do so requires the removal of other features.  Another is the involvement of the Product Owner, since he/she is the one who works with the customer to obtain requirements that will add business value for the customer.  That person will have to buy off and fully understand the impacts of this approach to make it successful.

Have any of you out there adopted a similar approach?  I'd be very interested to know!