I just wanted to dump some ideas out there surrounding one of the trickiest pieces of using agile development methodologies in a consulting / outsourced environment: Agile Contracts. Much of the musings below come from other sources with my own thoughts mixed in, but one source I'd like to specifically call out is the PDC 2008 session I attended given by Mary Poppendieck
and Grigori Melnik
The Problem with Two Party Interactions
So the first thing to look at is why we even need contracts in the first place. The conventional wisdom is as follows:
- Companies inevitably look out for their own interests
- Contracts are needed to limit opportunistic behavior
What Mary points out though is that really at the core the problem is that there potentially exists conflicts of interest which drive the paranoia of opportunistic behavior. In an ideal setting though we:
- Assume other party will act in good faith (so this requires a level of trust)
- Let the relationship limit opportunism (again, requires trust, but also some basis for the relationship)
- Use contracts instead to do these things:
- Align the best interests of each party with the best interests of the joint venture
- Eliminate conflicts of interest
I'll come back around to how this type of relationship and contract are formed up in a moment, but first lets look at how the two types of traditional contracts fall short of meeting the ideals above.
Problems with Fixed Price Contracts
- Supplier is at greatest risk
- Customer has little incentive to accept the work as complete
- Generally does not give the lowest cost
- Competent suppliers will include cost of risk in the bid
- Creates the game of low bid with expensive change orders (which blows a hole in the primary reason CFO's like fixed-bids, which is budget predictability)
- Generally does not give the lowest risk
- Selection favors the most optimistic (desperate) supplier
- Least likely to understand project's complexity
- Most likely to need financial rescue
- Most likely to abandon the contract
- Customers are least likely to get what they really want.
Remember, that the "protection" that a fixed-bid contract seemingly provides (if we don't like it, we don't have to pay for it) is all illusory. This is because the value that the project is projected to provide is greater than the price of the effort otherwise the project would not move forward. If the effort is "not-accepted", then the vendor is out the costs of the resources employed on the project. However, the customer is out both the costs of their resources involved in the project as well as the anticipated return of the project (which we already said is greater than even the PRICE, much less the vendor's actual COST). So who is the biggest loser here? Obviously depending on the relative sizes of the vendor and customer it may still "hurt" the vendor more, but clearly the customer has more at stake, and so I would contend that fixed-bid "protection" is a fabrication.
Problems with Time and Materials Contracts
While there are many useful scenarios where T&M projects make sense (staff augmentation, etc...) in general there are quite a few problems with them in an outsourced project model as well:
- Customer is at greatest risk
- Supplier has little incentive to complete the work
- Therefore we believe we need to control supplier opportunism
- ENTER: Project Control Processes
- Detailed oversight generally provided by the least knowledgeable party
- Supplier must justify every action
- LIKELY LEADS TO:
- Increased costs
- Artifact creation that does not add direct business value
- An assumption that the original plan is the optimal plan (the one created at a time of lowest knowledge/information about the project)
Candidate Solution: Target Cost Contracts
Circling back to our idealistic world now that we know some of the problems with traditional contracts, let's look at a different kind of contract. How can we build a contract that has the following properties?
- Target Cost defined and includes all changes
- Target is the joint responsibility of both parties
- Target cost is clearly communicated to workers
- Negotiations occur if target cost is exceeded (or projected to)
- Neither party should benefit under this scenario (it's a failure scenario)
- Primary goal of contract is to remove conflict of interest.
In order for such a contract to work there are a few assumptions that probably need to pre-exist:
- We have some basis for relationship and trust.
- This means we may have to start off with a small project using a traditional contract.
- We are probably using an agile development methodology that utilizes fixed-time, fixed-budget, and prioritized variable-scope mechanisms (backlogs,etc...)
The structure of this contract includes the following:
- An unbrella or framework contract with the legal stuff in it.
- Establishment of a target cost
- Work themes defined in stages (prioritized)
- Stages should be small to limit risk for both parties and to provide everyone with frequent points to revisit the value-proposition of the relationship
- Scope beyond the current stage remains fluid and negotiable
- Contact should describe the relationship, not the deliverables
- Contract should set up a framework for future agreements
- Contract should clearly define a means for mediation if no agreement can be reached. (this is important!)
So what I've found in my almost 15 years in this industry, is that our best customers always seem to end up in this type of contract model anyway (after perhaps a few projects using a traditional contract). But wouldn't it be better if we could actually LEAD into a relationship with this idea in mind and use it as a means to better define our value-proposition and distinguish ourselves from competitors? (or at the very minimum, get to this model sooner than later so that everyone can be more productive).
Those are my thoughts, please share yours!