Contracts


What is the purpose of contracts? There are two schools of thought on this question:

1.

The purpose of contracts is to protect each party from opportunistic behavior on the part of the other party.

2.

The purpose of contracts is to set up appropriate incentives for companies to work together in a synergistic manner.

Depending on which approach you take, contracts can make lean software development impractical in a contracting environment, or it can set up a framework for all parties to work together to achieve the best results possible.

The T5 Agreement

BAA manages most of the major airports in the United Kingdom, and it was a public entity until the 1987. It started building Terminal 5 at Heathrow airport in 2002 and is scheduled to open the terminal on March 30, 2008. The project is hugeit will cost of 4.2 billion. From the beginning, BAA realized that it simply could not afford the kind of cost overruns and extended deadlines that are so typical of projects of this size. Any significant delay in the project, for any reason, no matter who was at fault, would be a death knell for BAA.

So BAA studied what went wrong on airport projects with large delays and overruns, as well as other public projects that went badly astray. It came to the conclusion that the contracting process was the cause of the problems. In a stroke of management innovation, BAA realized that the essential problem was that contracts try to dispose of risk by selling it to contractors. The contractors charge more for assuming the risk, but in the end, if there are problems, it would be BAA that suffered, not the contractors. So BAA decided to assume and manage the project risk itself, because it could not afford to leave performance up to contracts and the courts.

BAA devised what it calls the T5 Agreementa legally binding document that replaces conventional contracts and changes the rules of the construction game. BAA agrees to assume all riskand in return the contractors agree to work in integrated teams, mitigate risks, and work to achieve the best possible results. The project is broken into about 150 subprojects, each of which has a team of contractors, an agreed target cost, and a pool of risk/incentive money. Contractors are paid for their time and materials. If something has to be redone, there are no arguments, they still get paid. If the subproject exceeds its target cost, the money comes out of the risk/incentive pool for that subproject. At the end of the subproject, the team that worked on it splits two thirds of any money remaining in the risk/incentive pool.

The T5 Agreement addresses both risk and incentives in a completely unorthodox way that BAA is convinced is saving it a significant amount of money while keeping its risks low. The agreement raises the threshold for conflict and lowers the cost of collaboration, putting all of the incentives in place for independent contractors to collaborate with each other. Between BAA supervision, peer pressure, and pride in workmanship, the teams have not only gotten things done on time, but they have caught up on several weeks of slippage due to bad weather. To date the project is "spot on schedule," and there is every expectation that Terminal 5 will be pretty close to ready for its planned opening on March 30, 2008.

The PS 2000 Contract

The PS 2000 contract was developed by Norwegian Computer Society in alliance with the Norwegian University of Science and Technology (NTNU) and leading industry and public organizations in Norway. Developed specifically for use in large public IT projects, the PS 2000 contract came from the observation that it is often difficult to draw up a detailed specification of an IT system during the procurement and tendering process. It is based on the following premises:

  1. Best practices show that a flexible iterative development model is more suited to the uncertainties and risks of many large-scale IT projects.

  2. This requires mechanisms for establishing a common understanding between the contracting party and the customer.

  3. The party developing the system is the most qualified to find the best way to meet the objectives and needs of the customer.[8]

    [8] From http://dataforeningen.no/?module=Articles;action=ArticleFolder.publicOpenFolder;ID=1044, February 2006. See this Web site for more information.

The unique thing about the PS 2000 contract is that it is a contract about how the customer and the contractor will work together, not a specification of what will be delivered. The body of the contract establishes decision-making boards, names mediators in case of disagreement, and specifies the general rights and obligations of each party. The project objectives and target cost are called out in annexes. The contract specifies the method by which the system will be iteratively explored, and as more details are agreed upon, the objectives are replaced by the agreed-upon details in an iterative manner. The target cost annex specifies the method by which both parties will share in any savings or overrun and provides an upper limit and lower limit for the overall cost.

Relational Contracts

Both the T5 Agreement and the PS 2000 contract are relational contracts[9]that is, they describe the relationships of the parties rather than the expected results of the relationship. Relational agreements are focused on aligning the incentives of the parties with the good of the joint venture. The underlying assumption is that people will naturally look out for the interests of their own company, so a relational agreement is specifically constructed to make it clear to people doing the work that the best interests of their individual companies are best served when they focus on the best interests of the joint venture.

[9] The Lean Construction Institute has more on relational contracts at www.leanconstruction.org.

A Joint Venture

Our two companies had very novel, complementary technologies and we figured that by combining them we could come up with a truly innovative product. But separately, the technologies were the basis for a very large portion of the business of each company. There was no way we could risk working together until we signed a joint venture agreement, which protected the intellectual property of each company.

It was challenging to work out the details. My colleague at the other company and I knew exactly how we wanted to work together, but we needed a way to define how joint inventions would be defined, how they would be handled, how the prior intellectual property of each company would be protected, what would happen if either side opted out of the joint venture, and so on. We spent very little time and effort worrying about how the research would proceedwe set up a governing board to oversee thator how the costs would be splitthat would be easy. We spent just a bit more time ironing out the profit-sharing details of the agreement.

The really difficult part was creating an agreement that would allow scientists and engineers from both companies to sit in a room and jointly brainstorm ideas about how their technologies could work together to make a superior product. This was a true challenge because what was at stake was the most precious asset of each company: its intellectual property.

The agreement took a couple of months to work out, and in the end, it was all about how we would work together. With the document signed and tucked out of the way on a shelf, we could finally get on with the business of working together.

Mary Poppendieck


Peter Drucker estimated that collaborative relationships can save a joint venture 25 percent to 30 percent of the cost of doing business.[10] We certainly see this in the case of BAA: Raising the threshold for conflict and lowering the threshold for risk among its many subcontractors significantly reduced both risk and cost for BAA. Throughout this book we have seen that a lean approach to software development can create significant improvements in the quality of the software, the speed of delivery, and the long-term maintainability of the system. We have seen that these benefits come from the synergy of people who combine their skill and experience to create knowledge more effectively together than they can separately.

[10] Peter Drucker, Management Challenges for the 21st Century, Harper Business, 2001, p. 33.

Most software development contracts are predicated on a different set of assumptions. They include a product specification as part of the language of the contract and assume that the specification substantially represents the desired result. If that assumption is in error, most contracts offer ineffective remedies. A relational contract starts with the assumption that the product cannot be effectively specified in the contract, so the language focuses on how the parties will work together to determine what to deliver.

Relational contracts generally designate a target cost and a target schedule. Both parties agree to work together, using the mechanisms in the contract, to deliver the best possible value within the cost and schedule targets. The contract sets up incentives for both parties to work collaboratively for the good of the joint venture and reduces incentives for parties to advance their separate interests.

The use of relational contracts in software development is a new and emerging area. We believe that those who learn how to forge synergistic relationships across company boundaries will see at least the 25 percent to 30 percent cost reduction predicted by Drucker, and quite possibly they will do significantly better.




Implementing Lean Software Development. From Concept to Cash
Implementing Lean Software Development: From Concept to Cash
ISBN: 0321437381
EAN: 2147483647
Year: 2006
Pages: 89

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net