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.
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.
Contracts set expectations between organizations and so often include details of:
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
- A pressure to get maturity assessments done caused the mentoring team to hassle development teams, damaging their reputation as positive enablers
- 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
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 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.
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 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 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
- 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.
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.