Contract models and contract flexibility

Fixed-price, Time-and-Materials, Progressive and Target Cost contracts

In order to meet the requirements that arise out of the different levels of specificity, recurrence and uncertainty of the transaction several contract models are used today. Each of these models has a different solution of specifying flexibility of the three main pillars of an IT contract: price, time and scope. These pillars form the tripod of each project, if one of the pods is wobbly, the tripod in will stand solid. However, cut one totally short, and it’ll definitely fall over. A solid contract will define the amount of flexibility on all three access and the way the flexibility is achieved.

The more flexibility is defined in the contract the more the risk of the project is transferred from the provider to the outsourcer. A project which has a fixed price, a solid deadline and fixed functionality places most, if not all, of the risk at the providers side. A project with a flexible deadline, based on hourly wages and without a descent understanding of the functionality under development places all risk at the outsourcer. The main challenge of contract flexibility is to find a model in which all parties share a part of the risks in such a way that opportunism is minimal and the amount of flexibility is aligned with the uncertainty in the development process.

The types of contract discussed here are: Fixed-price, Time-and-Materials, Progressive and Target Cost. Each of these models tries to solve a different kind of problem. Not one of of them fits every situation.

Fixed Price

As the name implies, a fixed price contract fixates the price, as well as the functionality. In general all three pillars: time, functionality and price are set. This allocates most if not all of the risk at the suppliers side. Fixed price contracts fit products or services that are relatively small and of which the requirements specification is complete and easy to comprehend. Fixed price contracts are suitable for market like transactions as specified by the governance model presented earlier in this chapter. The more the outsourcing objective needs hierarchical structures the less suitable a fixed price contract is.

Time-and-Materials

In a time and materials contract the amount of time spend on the product as well as the resource allocation of the supplier is fixed. The agreement in short states: “The provider will provide the customer with x developers spending y hours a week for a period of z months.” As the price can logically be derived from x,y and z it is most probably fixed. Although a time-and-materials contract might seem odd at first sight, it actually makes sense in the light of staff augmentation and offshore development centers. The customer basically buys resources and will determine how to use these resources by itself. A time-and-materials contract is useful in more hierarchical outsourcing situations where uncertainty and specificity are high.

Progressive

In a progressive contract situation you start of with a framework contract or master service agreement (MSA). The MSA covers all non-project specific contractual and governance issues and standard procedures. Along with the standard procedures on problem escalation and the definition of the formal communications the MSA might also include hourly wages and profit margins.

When there’s no MSA present the overhead costs of creating multiple contracts for small project pieces is generally too high. However, with the MSA in place the project(s) under development can be split into smaller chunks each with a separate contract. In general, chunks developed at the beginning of the project will have fixed price sub-projects and the parts of the product developed later might be build under for example a target-cost contract.

The main advantage of the progressive method is that once you have the MSA in place, the MSA speeds up the agreements on future projects, while keeping flexibility. The main disadvantage is that the customer is at risk if the supplier starts with a project but doesn’t agree to continue with forthcoming projects.

Target Cost

Link to the original article by Horrowitz

A target-cost (TC) contract is suitable for projects which contain a descent amount of uncertainty, a need for flexibility as well as a tight budget. In a TC contract an initial target of functionality is set. Based on exploratory meetings a target is set for the amount of resources and time needed to implement the initial specifications. Based on the target functionality an initial cost price is set, increased by a contingency buffer and a profit margin.

The initial scope of the project, the requirements, can be set based on user stories, story cards or any other system used for requirements specifications. The initial scope setting does not have to be extensive since the contract allows additions and changes, however, those requirement that are specified should be complete in order to avoid difficult discussions later on in the project. When the customer increases the scope during the project or when new requirements pop-up during the development phase the additions can be grouped into three groups (Horowitz 2005): fixes, clarifications and enhancements.

Fixes are changes to the requirements set in the initial scope of the project or extra requirements needed to actually implement functionality which was defined in the initial scope. Take for example an initial requirement for a website which states that the visitors of the website should receive “personalized e-mails” containing their name. However, in the initial design the designer failed to notice that in order to implement the feature the subscription form on the website should contain not only an e-mail address, but also a first, middle and last name field. During development the developer will notice the need for the extra name fields and a “fix” is added to the requirement list. Normally fixes are added as additional hours to the original requirement: sending personalized e-mails. Fixes are normally billed at cost without a revenue margin. This to some extent feels like a “punishment” of the outsourcing provider since it will not make any profit on the fix, but at least the provider gets paid for its actual costs.

Clarifications are requirements that couldn’t have been foreseen at the time of the initial scoping but definitely need to be implemented in order to have a correctly working product. Most of the clarifications come forth out of the advanced understanding of the project of both the outsourcer and the supplier. As with fixes clarifications are billed onto the requirement originally specified, often with a certain profit margin.

Enhancements are additions which are out of scope and can actually be implemented as a separate user story. The non-existents of the enhancement effectively does not diminish the correct working of the product under development. Enhancements are seen as a clear increase in scope and therefore are billed as extra functionalities.

When the scope of the project changes it depends on the kind of change what to do with the budget. With fixes and clarifications the amount of time needed to implement the change is added to the requirement out of which the clarification or fix originated. In case the addition of fixes and clarifications results in an overshoot of the initially planned hours of work the extra hours are billed at cost. You might want to decide to treat fixes as a 0% profit addition, only billing the actual costs, and clarifications as a 50% profit case. By defining different revenue models for different kind of requirement changes a revenue and penalty system is created in which:

• A fix is paid for at cost price, not increasing the profit of the supplier. The supplier should’ve foreseen the requirement in the initial process.
• A clarification is paid for at cost price + 50% of the agreed profit margin. Both the supplier and the outsourcer were not able to specify or think of the requirement.
• An enhancement is paid for at cost price + 100% of the profit margin. The outsourcer thought of something new and extended the scope beyond the original functionalities.

TC contracts allow for a descent amount of flexibility in the specifications, price and provide enough information to set an initial deadline and to extend the deadline once scope increases. Both parties share part of the risk of the uncertainty in the product and the possibility of controlling the scope and therefore the price of the project. The provider is eager to make a solid estimation at the start of the project since an understated prediction will not increase the providers profit. The initial estimation therefore provides the outsourcer with a good idea of the costs of the project. The TC method provides a decent amount of certainty to both parties concerning resources, scope and time. Table 1 depicts a TC contract budget and final financial overview, clarifying the fixes, clarification and enhancements made during the project.