Contracts

In a software context a contract is a written or spoken agreement that is intended to be enforceable by law between a customer and a supplier on how a product or part of the software development process will be delivered.

As mentioned in the Holistic Software Development Manifesto we value customer, business, developer and operations collaboration over contract negotiation. This means that HSD encourages open collaboration between people rather than contract specification. Creating formal agreements between people can inhibit them from working freely together, creating transactional relationships and a loss of focus on Business Value.

However, contracts are oftennecessary, and are normal between organizations wishing to work together. The reasons behind writing a contract to formalize commercial relationships are to protect both parties from liability when something goes wrong and to place costs and schedules on a formal basis. As such, contracts tend to deal in negative language that focuses on potential failures and consequences, detailing limitations. By their nature, contracts are somewhat adversarial and damage an open collaborative relationship between organizations.

As a necessary evil, contracts are often managed by procurement departments, account managers and sales people rather than Business Leaders and Delivery Teams to separate the adversarial negative nature of legal agreement from the people who will actually work together on a day to day basis. Although this separates concerns, sales and procurement people may not have the necessary deep knowledge of software engineering and so will require technical support to develop meaningful contracts.

Small contractors (often called Small or Medium Enterprises, SMEs) generally won’t have dedicated legal or account management staff and so will have to deal with both sides of agreement and delivery themselves – this often leads to a less adversarial relationship as people intending to work together on a regular basis tend not to start their relationships with an argument.

Contract Types

Software Development Contracts are used to agree:

  • An entire product (or product family) delivery between a customer and a development organization (see COTS)
  • Out-sourcing part of the development process (e.g. System Analysis or Testing)
  • Augmenting internal delivery capability by using an out-sourced team
  • Augmenting internal delivery by adding individual contractors
  • Out-sourcing the entire delivery process from Portfolio downwards

Note that the first and last options are very similar with the subtle but critically important point that the end Customer is typically different. In the first option the end Customer is the person requesting a product from an organization. In the last option the person requesting the product, is part of a supplier organization and so the products they receive are for selling on to a Customer organization. This structure confuses who the real end customers are. This distinction can cause many problems as the intermediate organization typically acts as a “customer proxy” to their internal delivery teams leading to conflicts of interest and confusing otherwise simple communication lines. If supplier organizations, often embedded in customer organizations, further out-source or augment their teams with other suppliers then things get even more confusing.

Where work is too big to be done by the home organization, and so supplier partners must be used we recommend partitioning work by Business Value rather than parts of the development process. Commercial placing makes sense if specific parts of required Business Value can be packaged up in relative isolation from other parts of a solution. Even if work can be separated by Business Value, only place with commercial partners based on a valid Build or Buy decision (taking into account position on the Commoditization Scale).

Each of these types of work requires a different contract approach and so people with intimate knowledge of software development, in both breadth and depth must be involved in developing contracts. We have seen many software development contracts which unintentionally incentivize very negative commercial behaviors.

Recommended Usage of Contract Types

Different contract types will be selected based on the needs of the business. In our experience augmenting internal teams with individual contractors (on a Time Hire basis) rather than using a body shopping supplier is preferable however if scale is an issue this may not always be possible. When paying a supplier for people a customer is paying for both the people and the supplier’s overheads rather than just the people. Where entire teams or development organizations are out-sourced the contract models used may change as trust improves (or decreases) between customers and suppliers.

When outsourcing work, risks are not transferred – at best they are shared. The idea of risk transfer via out-sourcing is a myth perpetuated by software development suppliers. As a result, we only recommend out-sourcing low-risk tasks, maintaining internal innovative research and development as well as intellectual property generation. If you must out-source work then out-source the predictable boring work, keep the cutting edge – your next strategic advantage in-house.
Businesses that place their core Business Value in the hands of suppliers are at the mercy of those suppliers.

Contract Content

Contracts set expectations between organizations and so often include details of:

  • Schedule
  • Scope
  • Quality
  • Payment Terms

However, as noted in Risk Driven Lifecycle, at the beginning of a piece of work we typically know very little about it, as knowledge is gained uncertainty decreases. This cone of uncertainty, based on risk, is reduced quickly in iterative/agile processes but is stretched out in waterfall teams.

This uncertainty means that at the beginning of a piece of work, when we know the littlest about it, our estimates of schedules, scope and quality will be at their most inaccurate – typically by a factor of 4. Unfortunately, this is also the time at which contracts are written.

When suppliers are pushed into accepting risky projects they will build in contingency (a form of waste) into their plans, driving estimates and costs up to mitigate their financial risk.

Contracts that ignore the cone of uncertainty, the evidence of past projects, and do not have flexibility to change will be bad for both customers and suppliers.

If work cannot be clearly specified and “confidently estimated” (in terms of the Certainty Scale described in Estimates) then fixing those details contractually is nonsensical. This situation rarely exists, except for highly predictable, almost commoditized work – which is actually ideally suited to out-sourcing. Many organizations we’ve worked with fool themselves into ignoring uncertainty in software contracts using inappropriate production metaphors only to feel the pain later.

Targets and Incentives

Targets reinforce measurement driven behaviors and can often be counter-productive as they reduce a focus on Business Value moving the focus to meeting the target instead.
Setting targets leads to goal-seeking behavior where any behaviors that helps hit the target is considered acceptable. In one of our clients an agile mentoring team was required to run a number of maturity assessments on development teams. This requirement became a target of 1 per month. This target caused two dysfunctional behaviors:
  1. A pressure to get maturity assessments done caused the mentoring team to hassle development teams, damaging their reputation as positive enablers
  2. One month there were no assessments done because the various teams couldn’t fit in an assessment. The mentoring team’s management rounded up this 0 to 2 on their monthly report
We discuss the validity of “maturity assessments” later in this Process Metrics in the Metrics and Reporting View.
Goal seeking involves working backwards from the target to derive actions that will meet the target.  A better approach is to simply tell people what behaviors you’d like them to exhibit.
Incentives have the same effect in terms of goal seeking. They can have a very negative effect on people doing knowledge work (see Motivation) and supplier relationships (see Contracts).
At another client we were asked to examine a contract model that was proposed by a supplier with incentives built into it. The intent of the incentives was to reward the supplier for delivering the scope within initial time estimates. When we compared the various scenarios the supplier proposed through their own models side by side a perverse effect emerged that the supplier would actually earn more money by delivering late, and to a low level quality. Although this wasn’t intended by the supplier, or obvious from the model at face value once exposed the contract model was rightly shut down in favor of a simpler model.
The best incentive for teams is continued motivation, any incentives that are counter to that motivation (in terms of autonomy, mastery and purpose) will be damaging.
We do not recommend the use of targets or incentives.

Contract Models

Assuming a valid build or buy decision has led to a contract being let for software development work there are a number of typical options available. We strongly recommend avoiding contractual incentives. The primary incentive to a supplier is repeat work providing a continued revenue stream – short term profit increases are counter-productive and damage collaborative relationships. Our experience of incentivized contracts is that they inadvertently promote negative behaviors. Short-term contractual incentives do not incentivize supplier delivery teams, but supplier sales teams.

Fixed Price

Fixed Price involves fixing cost, scope and schedule at the beginning of a contract.

Fixed Price can be attractive to business leaders because it offers the illusion of certainty. You know what you’re going to pay – which is true. But unfortunately, you don’t know what you’re going to get, or at what level of quality. Some businesses believe that Fixed Price is easier to manage despite all previous evidence, and so apply a pressure on their organizations to “go Fixed Price”. Often the urge to go fixed price is a response to historical abuse by suppliers of other models – which is a very dysfunctional way to start a new contract.

Long term fixed price is a bad model for pieces of work with any amount of risk. Risks are a source of variability which a fixed price model doesn’t easily cater for. Formal contractual change requests are time-consuming and often expensive leading to dysfunctional behavior amongst customers and suppliers trying to avoid additional cost (such as classifying all defects as change requests). Even a very well understood project that lasts a long time is likely to have enough variability to make a Fixed Price contract damaging to both parties.

When a project goes wrong, a Customer is ultimately left with the problem, risks are never truly transferred, only shared. Contractually liability is normally capped and “reasonable” quality/scope clauses leave enough room for the Supplier to get out of a contract delivering a fair amount of the scope, as originally specified, at a low level of quality. The Customer then has to spend more money fixing the product leading to another contractual phase.

Fixed Price is the least mature model for the majority of software development work.

Firm Price

Firm Price involves setting upper and lower limits for cost, scope and schedule at the beginning of a contract.

Firm Price models are often variable cost models with an upper and lower cap to limit liability for both parties. Although Firm Price models superficially sound like they solve the problem with Fixed Price contracts, in practice partial progress towards Business Value is very hard to quantitatively measure. Attempts to measure based on Story Points or any other abstract measure are deeply flawed and should not be considered as valid contractual models since Story Points are both abstract and relative. During Continuous Investment Review we measure progress as % of budget and % of scope, however we expect both of those to change. Firm Price models put limits on how much change is acceptable. Unfortunately, some suppliers will underestimate risk in order to win work from a customer.

Firm Price models that add flexibility by building in scope/quality change within a certain tolerance on top of a Fixed Price base can work if the length of the project and risk impact are low enough for Fixed Price to be a valid model.

Time and Materials

Time and Materials is effectively a time-hire model where a Customer pays a Supplier a certain rate for each day they work on the project.

This model can work if the Customer and Supplier have high trust, high levels of engagement and collaborate well together. Often Time and Materials can feel like a trap for Business Leaders as they have no upper limit on costs and can feel as though they are paying for nothing as a Supplier can leave the contract having earned money but not delivered anything. T&M can feel like you don’t know how much you’re paying or what you’re going to get.

Time and Materials is well suited to high complexity situations where scope, resources and schedules are highly variable. However, to work Time and Materials must be predicated on a high trust collaborative relationship and works well with known individuals and small companies, but less well with large vendors.

Weighted Fixed Price

Weighted Fixed Price is an evidence-based variation of Fixed Price in competitive markets that weights supplier estimates based their previous performance.

Suppliers who have delivered on or under budget are more likely to be selected for future work than those who go over budget.
If Supplier 1 delivers 10% late on Project A then when we’re looking to place Project B for 500k and we’re looking at each supplier’s estimates, then we’ll add 10% to Supplier 1′s estimate.  That means all other things being equal we’ll choose the other suppliers, not Supplier 1 for the new work. Suppliers who typically come in closest to, or even under, their previous estimates will have a negative weighting. Weighting is transparent to each supplier but not across suppliers.
This provides the following pressures:
  • Suppliers don’t want to underestimate – if the underestimate then they’ll come in over their initial estimates and adversely affect their weighting and therefore their chance for follow on work
  • Suppliers don’t want to overestimate – if they overestimate so that they can manipulate their weighting next time, or build in risk buffers, they won’t get the work because they’ll cost too much
  • Suppliers don’t want to take on complex, high risk work because they can’t predict the effect on their weighting
As mentioned previously, out-sourcing doesn’t transfer business risks to suppliers, because the customer is still the one needing the business benefit and paying for it, especially when things go wrong. The Weighted Fixed Price model is intended to genuinely transfer the complexity risk to suppliers, if they’re willing to take it.
The Weighted Fixed Price model creates a pressure on Suppliers to avoid bidding for work that is too risky or complex. This means that customers using the WFP model may find it difficult to place such work with suppliers which is an early sign that it is too risky to be predictable and probably shouldn’t be out-sourced anyway.

Recommended Approach

As mentioned previously we strongly recommend avoiding incentives as repeat business is the best incentive to a supplier.
There is often a tension between a management desire for Fixed Price contracts (as financial liability is limited) and collaborative development teams and suppliers wishing to use Time and Materials, especially for complex and risky projects. Fixed Price and Time and Materials are often viewed as polar opposites, but they’re not.
There is no need for this tension however as the two common variations of these models used in practice actually make them almost exactly the same thing – a few tweaks and they’re our recommended approach.
To prevent runaway costs with Time and Materials such contracts are normally controlled using a financial cap within a certain time period. There is a possibility of less than the full cost being spent in a time period, however, there is normally a certain amount of pressure to avoid underspend in complex organizations (as it makes financial planning difficult) and so in practice, a Supplier is encouraged to spend the full amount in each time period. This means that the contract is actually a series of time bound Fixed Price contracts – although scope is variable.
When using Fixed Price models complex contracts are normally split into phases, each with a Fixed Price, to protect suppliers from signing up to too much financial liability when the cone of uncertainty is at its widest. This makes a series of time bound Fixed Price contracts, the number of which is usually flexible as risk reduces over time and understanding increases. Scope or quality is re-negotiated at each time period leading to essentially a controlled Time and Materials approach.
There are only two differences between these approaches:
  • The time periods to which they’re normally applied –  Time and Materials capped time periods are often months or quarters. Fixed Price time periods are often 6monthly or above.
  • Scope –  Time and Materials phases are normally loosely scoped; Fixed Price phases are normally tightly scoped.
In fact, these approaches can be completely merged in the Phased Fixed Price model.
Phased Fixed Price
Phased Fixed Price involves fixing costs and schedule on loosely scoped short/medium term goals, re-negotiating at each phase. Phases are normally tied to short term releases, monthly or quarterly as a maximum.
We recommend the use of Phased Fixed Price for any fully outsourced team, or product, where complexity and risk means a simple fixed price model isn’t possible – which is most of them. The length of the phases (time periods) is flexible but we recommend that they align to Releases to ensure that the Customer always has a cohesive product at the end of any contractual period. We recommend this approach for development contracts and COTS Implementation. Releases should be rapid, even continuous, in which case we set the contractual release periods to be monthly, or if an organization isn’t that agile, quarterly.
Future scope, timescales and costs are renegotiated at each Release. In high trust environments, or as trust increases, both customers and suppliers tend towards agreeing to “more of the same” at each phase boundary. This has devolved into controlled Time and Materials. If trust decreases, scope controls can be increased (assuming complexity isn’t too high) evolving back to Phased Fixed Price.
Controlling scope at a contractual level without presupposing details and limiting creativity is difficult, we suggest doing so at a high level. If the contract is strategic then use Strategic Goals, if the contract is more product focused, or system of systems focused, then use Features or Integration Scenarios.
Continuous Investment Review, a governance practice,  can ensure that further spending is justified at each Release.