scispace - formally typeset

Journal ArticleDOI

6.3.2 No Cure No Pay: How to Contract for Software Services

01 Jul 2006-Vol. 16, Iss: 1, pp 910-925

TL;DR: The motivation to improve the software engineering process itself needs to be put in place first, and the bigger the failure, the more people get paid!

Abstract50% of all software projects are total failures and another 40% are partial failures according to widely quoted surveys in UK, USA and Norway. Large government projects in all 3 countries have been reported with spectacular failure and expense to taxpayers (Royal Academy of Engineering and British Computer Society 2004). 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 those can be improved. However, I suggest the motivation to improve them needs to be put in place first. Think about it. Most of these failures have been fully paid for! We not only pay well for failure, but the bigger the failure, the more people get paid! My suggestion is simple. Pay only when defined results are provably delivered. This requires several things: Contracts that release payment only for meaningful results; The ability to define those results, particularly qualitative ones, and particularly the organizational ones; The ability to deliver those results incrementally, thus proving capability at early stages and continuously. Note: This paper specifically addresses the software problem, but I am sure that the ideas here apply to the wider systems engineering problem to some interesting degree as well.

Summary (3 min read)

1. Introduction

  • Most project failures have been fully paid for!.
  • Pay only when defined results are provably delivered.
  • The ability to deliver the results incrementally, thus proving capability at early and then on-going stages.

2. Defining the ‘cure’

  • The authors write contracts, and they write requirements for projects, but these are often useless because they define the wrong things: that is ‘valueless’ things!.
  • The results that the different stakeholders value .
  • It must be because they have not received training (at any level of management training) on how to control IT project delivery.
  • The authors should instead choose suppliers based on proven ability in the past, and on their project to deliver.
  • Move work away from those that do not deliver value as promised.

3. Motivating to contract for results

  • Senior management must first motivate the cultural change to contracting for results.
  • That is why the authors are contracting with them.
  • If their contracting process fails to deliver, it is their fault, not the supplier’s fault.
  • The request for proposal must be along the following lines:.
  • The authors will pay only when that value is satisfactorily and provably delivered.

4. Specifying the contract

  • Such a contract must suggest the use of evolutionary project management (which the authors 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 .
  • The authors 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 .
  • Actual payment of the invoice is dependent on a trial period with continued success (for example, 30 days).

A Sample ‘No Cure No Pay’ Contract for Evolutionary Project Management

  • 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 contract has precedence over any conflicting paragraphs in previous contracts.
  • All specification of requirements and design for a phase will be considered a framework for planning, not a frozen definition.
  • This includes any extension, change or retraction of framework specification, which the customer needs.
  • 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.

5. Motivating suppliers to contract for results

  • Suppliers can be expected to initially resist such contracts, for all the obvious reasons: .
  • They are not sure what they will be getting into.
  • They like the old idea of getting paid millions, even if the result is useless for the customer.
  • Let them know that the biggest share of the business will go to the best value provider .
  • Having looked at the policy and contractual aspects, let’s now discuss some more technical specifics: how to quantify requirements and a brief description of evolutionary .

6. Quantifying qualitative results

  • The authors all know how to specify results about storage capacity, transaction throughput, and response time.
  • The difficulty for most customers is ComSIS Vol.
  • The authors have also seen that once you find a quantification, there is always a practical way to test the level of that quality in practice.
  • Having identified your key sub-qualities, you then have to specify the quality levels.
  • Average percentage (%) of tasks where defined [Users] need no help from people, manuals, help lines etc. to correctly and immediately carry out defined [Tasks], also known as Scale.

7. Direct and indirect results

  • There is a critical distinction between the performance characteristics of software or an IT system itself (system performance) and the organizational impacts that achieving the system performance characteristics are expected to deliver.
  • A system might be designed to a usability level so good that it takes only 10% of the effort to learn and to use that was needed for the older systems.
  • This system performance characteristic has an organizational value in relation to: How many people it affects (savings population) .
  • Maybe in some cases there is an option to contract for the actual savings through time as the product is used.
  • This could hold for a limited time period (say for 60 days or for a year) as a kind of field trail acceptance test.

8. Decomposing projects into small deliverables

  • One useful way to make sure that value is really delivered is to make it happen early and often.
  • In my opinion, that translates to deliveries occurring next week and every week.
  • Those who cannot – are not useful – and not valuable.
  • Then the technological planners need to be taught the art of decomposing their visions into incremental value deliveries.
  • If you don’t get one, you either need to study decomposition methods more deeply, or listen to those who can find solutions better.

9. Summary

  • One way to avoid software project failure is to refuse to pay for failure.
  • This will motivate software suppliers to make use of already well-known and wellpracticed methods for successful IT and software projects [3, 4].
  • There are two key ideas that too many people do not practice (due to lack of training and/or poor management).
  • The first is the quantification of the value expected by stakeholders of the system, especially the ‘qualitative’ aspects.
  • The second idea is to divide all large projects into an incremental series of smaller projects.

Did you find this useful? Give us your feedback

...read more

Content maybe subject to copyright    Report

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.

Citations
More filters

Journal ArticleDOI
TL;DR: The future work could include defining a role and measurement of trust and knowledge sharing in the software project performance.
Abstract: Trust is the most important issue to create relationship making value in knowledge sharing. Knowledge itself cannot lead to a success, as knowledge sharing or flow of knowledge is of prime importance in an organization. Knowledge sharing depends on trust between trusted and trustee members in specific knowledge context and specific time slot. Trust level between members has a high impact on software project performance. The future work could include defining a role and measurement of trust and knowledge sharing in the software project performance.

2 citations


References
More filters

Journal ArticleDOI
TL;DR: Although many view iterative and incremental development as a modern practice, its application dates as far back as the mid-1950s, with prominent software-engineering thought leaders from each succeeding decade supporting IID practices.
Abstract: Although many view iterative and incremental development as a modern practice, its application dates as far back as the mid-1950s. Prominent software-engineering thought leaders from each succeeding decade supported IID practices, and many large projects used them successfully. These practices may have differed in their details, but all had a common theme-to avoid a single-pass sequential, document-driven, gated-step approach.

1,211 citations



Journal ArticleDOI
01 Jul 2005
Abstract: Evolutionary development (Evo) focuses on early delivery of high value to stakeholders, and on obtaining and utilizing feedback from stakeholders. This paper describes from a project manager's viewpoint, the positive experiences that one organization rapidly achieved on switching from using the Waterfall method to Evo. Major benefit came from paying greater attention to the quality requirements as opposed to the previous practice of concentrating solely on the required functionality.

19 citations


Frequently Asked Questions (1)
Q1. What have the authors contributed in "No cure no pay: how to contract for software services" ?

Only if the supplier management is made to feel the pain of project failure will it strive to avoid it. 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.