UDC 004.4
No Cure No Pay: How to Contract for Software
Services
Tom Gilb
Independent Consultant
Tom@Gilb.com
Abstract. Contractual motivation is needed to avoid costly project
failures and improve the delivery of stakeholder value. Only if the
supplier management is made to feel the pain of project failure will it
strive to avoid it. The current culture of rewarding failure, by paying for
systems development work regardless of the product delivered, must be
altered. Such contractual motivation must be supported by quantitative
requirements and evolutionary delivery. Quantitative requirements allow
project progress and success to be measured enabling monitoring and
testing for contractual compliance. Evolutionary delivery (that is,
delivering early high value in small increments and using feedback from
deliverables to determine future increments) allows early reporting of the
ability of systems development to deliver and so enables any required
corrective actions. Note: This paper specifically addresses the software
problem, but the ideas most likely apply to the wider systems
engineering problem to some interesting degree as well.
1. Introduction
At least 10% of all software projects are ‘failures’ (cancelled before
completion) and another 50% are ‘challenged’ (completed and operational,
but over-budget, over the time estimate and with fewer features and functions
than initially specified) according to widely quoted surveys in the UK and USA
(See [1] quoting a March 2003 press release on the Chaos Report from the
Standish Group, and an Oxford University – Computer Weekly study of
project management by Chris Sauer and Christine Cuthbertson). Several
large UK government projects have reported spectacular failure at great
expense to taxpayers [1,2]. What is the problem? Most discussions have
centered on improving the software engineering process itself: better
estimation, better requirements, better reuse and better testing. No doubt all
these can be improved. However, I suggest the motivation to improve them
needs to be put in place first. Think about it. Most project failures have been
fully paid for! We not only pay well for failure, but the bigger the failure (in
terms of project size and project duration), the more people get paid!
My suggestion is simple. Pay only when defined results are provably
delivered. This requires several things:
Tom Gilb
ComSIS Vol. 4, No. 1, June 2007
30
Contracts that release payment only for meaningful results
The ability to define those results quantitatively, particularly the
requirements currently defined as qualitative, and particularly the
organizational benefits
The ability to deliver the results incrementally, thus proving capability at
early and then on-going stages.
2. Defining the ‘cure’
We write contracts, and we write requirements for projects, but these are
often useless because we define the wrong things: that is ‘valueless’ things!
Such as the following:
• Qualitative critical benefits: that is, words such as ‘higher productivity’
(we do not define quality measurably)
• Functions and use cases (not the improvements needed to them and
the resulting benefits)
• Designs, architectures, technologies (not the results required of them)
• Hours of effort required (not value delivered).
This means we fail to understand the ‘value’ a project is to deliver. We
need to define:
• The different stakeholder groups (‘stakeholders’) involved
• The results that the different stakeholders value
• The quality levels, numerically and measurably
• The stakeholder value that the new or improved system will enable to
be achieved
• An evolutionary series of early, short and frequent delivery stages with
high-value delivered at earliest opportunities.
Of course much of this is management work (not software engineering),
and management consistently fails to manage properly. They make
consistently bad assumptions that the software or IT system will deliver
benefits. But they do not control the delivery of those benefits. Why is
management so bad at this? It must be because they have not received
training (at any level of management training) on how to control IT project
delivery. This is the fault of senior management. It is senior management who
should take action to ensure that money is not wasted on failed IT projects by
ensuring appropriate management training and reinforcing this training with a
‘Pay for Results’ policy for IT projects.
Senior management is also responsible for forcing decisions to be made on
too large a scale and too early. We define too-large pieces of work: we define
work delivery packages in terms of years. We should define them instead in
terms of quarters, months and weeks. We would then see early if any planned
value can be delivered to stakeholders, and if not, we would have chance to
correct the situation or remove the incompetent supplier.
No Cure No Pay: How to Contract for Software Services
ComSIS Vol. 4, No. 1, June 2007
31
We also choose contractors too early, based on the wrong criteria. We
choose based on size and ‘reputation’ (note, not the reputation for delivering
successfully!). We should instead choose suppliers based on proven ability in
the past, and on our project to deliver. One way of improving contractor
selection would be to allow three competing contractors to start work in
parallel on complimentary aspects of a system, and move work towards the
contractors that prove their ability to deliver value. Move work away from
those that do not deliver value as promised. If all three perform well, that is
fine, keep them going!
So what other actions should senior management take to correct all these
problems (not defining results, too-large increments and selecting contractors
based on the wrong criteria)? We shall outline some suggestions in the
following sections.
3. Motivating to contract for results
Senior management must first motivate the cultural change to contracting for
results. Here are some ideas outlining the required high-level policy:
• It is our professional/ethical/legal duty towards shareholders/
customers/taxpayers to make absolutely sure we do not waste money
on projects that do not deliver expected results
• The supplier/contractor has the technical/managerial/economic/
experiential competence to control the results/cost ratio for us. That is
why we are contracting with them. If they cannot contract for results,
we should not do business with them
• It is our professional obligation to always clearly, measurably and
testably define what we expect to get for our money, in advance.
Anything less is incompetence and unprofessional. If we cannot do
that, we should not have the job of commissioning any use of
organizational resources
• We do not intend to ever be a party to failure. If our contracting
process fails to deliver, it is our fault, not the supplier’s fault. Any
failure will be structurally (step size one week, for example) kept to a
minimum, and failure will result in reconsidering the supplier’s
continued participation
• We need to prioritize high value results early one, and lock them in.
We cannot get involved in primarily, and initially, building
superstructures that fail
• Maybe we, the customer, should make this even clearer by bonus or
rewards for employees and teams that manage value deliveries
successfully.
Senior management is going to have to ensure that staff have adequate
guidance and training by supplying the following:
Tom Gilb
ComSIS Vol. 4, No. 1, June 2007
32
• A clear policy (see above)
• Training in quantification of values delivered
• Training in measurement and testing of value delivered
• Training in requirements specification
• Useful templates for specifying requirements and designs [3]
• Access to experts in-house or externally.
• The request for proposal (RFP)
The request for proposal must be along the following lines:
“We invite you to tender for a contract to <build software/deliver an IT
system>. The contract will be based on a ‘value payment’ system. This
means that we will define what we expect in terms of measurable and testable
values from the system. We will pay only when that value is satisfactorily and
provably delivered. We will not pay for effort put in, and we will not pay for
sub-specification results. If you are focused on delivering us the results we
agree on, then you can earn money independently of the costs to you.
Efficient suppliers can earn more than usual. Inefficient suppliers would not.
We hope you will get rich by helping us to get what we expect for our money.”
4. Specifying the contract
A No Cure No Pay contract must be put in place. Such a contract must
suggest the use of evolutionary project management (which we shall discuss
later in this paper). The essential ideas in such a ‘No Cure, No Pay’ Contract
are as follows:
• Payment is totally dependent on proven delivery of the defined value
• Estimates for delivering the value will be made by the supplier in
advance
• We will accept some level of cost overrun compared to the estimates,
when actual costs exceed the estimate (for example, 100%). Above that,
the supplier pays any excess costs
• We will allow invoicing to be triggered based on a simple test of delivery
• Actual payment of the invoice is dependent on a trial period with
continued success (for example, 30 days).
A sample contract is shown in Figure 1.
No Cure No Pay: How to Contract for Software Services
ComSIS Vol. 4, No. 1, June 2007
33
A Sample ‘No Cure No Pay’ Contract for Evolutionary Project
Management
Intent. The intent of the evolutionary project management method is that
the customer shall gain several benefits: earlier delivery of prioritized system
components, limited risk, ability to improve specification after gaining
experience, incremental learning of use of the new system, better visibility of
project progress, and many other benefits. This method is the best-known
way to control software projects [4].
Precedence. This contract has precedence over any conflicting
paragraphs in previous contracts. (This sample contract is designed to work
within the scope of a present contract with minimum modification. You can
choose to declare this contract has priority over conflicting statements in the
initial contract – the alternative is to ‘clean up’ any conflicting statements.)
Steps of a phase. For the defined phase, the customer may optionally
undertake to specify, accept and pay for evolutionary usable increments of
delivery of any size. These are hereafter called ‘steps’.
Step size. Step size can vary as needed and desired by the customer, but
is assumed to usually be of one-week duration.
Specification improvement. All specification of requirements and design
for a phase will be considered a framework for planning, not a frozen
definition. The customer shall be free to improve upon such specification in
any way that suits their interests, at any time. This includes any extension,
change or retraction of framework specification, which the customer needs.
Payment for acceptable results. Estimates given in proposals are based
on initial requirements, and are for budgeting and planning purposes. Actual
payment will be based on successful acceptable delivery to the customer in
evolutionary step deliveries, fully under customer control. The customer is not
obliged to pay for results, which do not conform to the customer-agreed step
requirements specification.
Payment mechanism. Invoicing will be on the basis of evolutionary steps
triggered by end of step (same day) signed preliminary acceptance that the
step is apparently as defined in step requirements specification. If customer
experience during the 30-day payment due period demonstrates that there is
a breach of the specified step requirements, and this is not satisfactorily
resolved by the supplier, then a ‘stop payment’ signal for that step can be sent
and will be respected until the problem is resolved to meet specified step
requirements specification.
Invoicing basis. The documented time and materials will be the basis for
invoicing a step. An estimate of the step costs will be made by the supplier in
advance and form a part of the step plan, approved by the customer.
Deviation. Deviation plus or minus of up to 100% from step cost and time
estimates will normally be acceptable (because they are small in absolute
terms), as long as the step requirements are met. (The assumption is that the
customer prioritizes quality above cost). Larger deviations must be approved
by the customer in writing before proceeding with the step or its invoicing.
![Table 2. This is a conceptual example [3]. Three goals (performance targets) and two resource targets are having the real impacts on them tracked, as steps are delivered. The same IE table is also being used to specify the impact estimates for the future planned steps. So at each step, the project can learn from the reality of the step’s deviation from its estimates. Plans and estimates can then be adjusted and improved from an early stage of the project.](/figures/table-2-this-is-a-conceptual-example-3-three-goals-3qx8pdaz.webp)
![Table 1. A real example of weekly control of quantified quality results from Future Information Management Research (FIRM) [5]. In the 9th week, 95% of the planned improvement is delivered ( 2x planned result) using a design idea called ‘Recoding’. Similar results were achieved every week in the first 24 weeks of using this method of project control](/figures/table-1-a-real-example-of-weekly-control-of-quantified-25pkklp0.webp)
