The document discusses the transition from time-based to outcome-based contracting in application development and maintenance, emphasizing how this shift can enhance supplier relationships and deliver greater business value. It critiques traditional contracts that prioritize time management over outcomes and argues for the benefits of focusing on the delivery of functionality and value, rather than hours worked. Outcome-based contracts allow for flexibility in development methodologies and improve efficiency and cost-effectiveness by linking payment to delivered results rather than time spent.

2. OUTCOME-BASED CONTRACTING RELATIONSHIPS
European Headquarters: 3, rue Marcel Allégot 92190 Meudon France | North American Headquarters: 321 West 44th St., Suite 501 New York, NY 10036
How shifting focus from time-based to outcome-
based contracts improves supplier relationships
and drives value.
One of the major challenges between a client and application
development and maintenance supplier is that their relationship is
defined by the production and management of time. Most ADM
contracts can be reduced to a simple equation: Price = Rate(s) x
Hours.
Suppliers remove Cost of Labor from rate to find profit, however;
both parties manage time as the key variable. While these contracts
are governed by project plans and deliverables, the client and
supplier’s primary goal is to manage the consumption of time, not
the production of business value.
57% of CIOs favor
Outcome-Based
Contracts
1 in 2 contracts in
discussion have
Outcome-Based
components.

3. OUTCOME-BASED CONTRACTING RELATIONSHIPS
European Headquarters: 3, rue Marcel Allégot 92190 Meudon France | North American Headquarters: 321 West 44th St., Suite 501 New York, NY 10036
Traditional contracts are abound with very specific language around
Full Time Equivalents (FTE), time collection and reporting, the number
of skilled resources, and the dates by which certain activities must be
competed. While this approach brought discipline to the industry, the
maturity of software development in the 1980s did not allow for
measurement and quantification of output. Time management moved
from being one of the key measures, to the only measure, obscuring
the real purpose of software development.
The premise of outcome-based contracting is that hours (and indeed
rate) are inputs to the process (not outputs), and the measurement of
programming results is now both possible and achievable. Outcome-
based contract structures bring the original intent of software to the
forefront—the production of business value.
DEFICIENCIES OF THE
CURRENT PROJECT MODEL
The focus of most traditional projects is the project plan, which
details the consumption of time against specific tasks. The science of
creating a project plan is well defined but has not materially
improved the successful delivery of projects. While it is easy to focus
on adherence to the plan, the problem is that execution of the plan
itself was not the goal. Even as IT projects adopt Agile methods that
focuses on the code production, the contracts themselves remain
focused on hours.
1

4. OUTCOME-BASED CONTRACTING RELATIONSHIPS
European Headquarters: 3, rue Marcel Allégot 92190 Meudon France | North American Headquarters: 321 West 44th St., Suite 501 New York, NY 10036
Current project planning assumes that the goal is to manage time,
not value. Once a project plan is developed, the focus becomes
making sure that the time allocated equal the hours consumed, and
milestones tend to be large “events,” such as “future state design” or
“environment ready.” These milestones are often vague at the
beginning and funnel gradually down to the “go live.”
Time-based focus creates a false sense of accomplishment.
What is absent from the current project management model is a
focus on the real goal: to produce software in order to support a
business process, and provide business benefit. There is an implicit
recognition that while the first few phases will execute as designed,
at some point, there will be a recognition that the project will go
over the time budget. When that occurs, there are two reactions:

5. OUTCOME-BASED CONTRACTING RELATIONSHIPS
European Headquarters: 3, rue Marcel Allégot 92190 Meudon France | North American Headquarters: 321 West 44th St., Suite 501 New York, NY 10036
Reduce the scope, pushing the unachieved scope into future releases
or extend the timeline. Of the two options, pushing into future
releases is by far the most expensive option, with research by CISQ
indicating that functionality or quality deferred into operations can
cost up to 50 times more than the cost of including it in the original
development.
AGILE projects use this cycle but as a rule, still pay suppliers for how
much time the supplier spends, not the end product.
Another unfortunate side effect is the reduction in QA and Testing
which is often reduced well below effectiveness. As the deadline
looms, project leadership is caught between possibly defective code
and an absolute date. By pushing user test into the end of a cycle,
the test process is “trimmed” into near ineffectiveness, blamed for the
delay, or eliminated. The organizational pressure to “finish” the
project causes a shift in focus from “all defects are bad” to “only the
defects that cause immediate, obvious problems are bad.” It is true
that in many cases the business value of a defective code released
immediately outweighs the cost and political capital of a delayed
release, but both should be possible—not one or the other.
Delaying deployment and cursory testing drive activity into the more
expensive operational phase. When looking at the support budgets, it
is apparent that bug fixes, code defects, and gaps account of most of
the activities. IT support budgets grow and that erodes the business
justification.

6. OUTCOME-BASED CONTRACTING RELATIONSHIPS
European Headquarters: 3, rue Marcel Allégot 92190 Meudon France | North American Headquarters: 321 West 44th St., Suite 501 New York, NY 10036
This challenge is not new and a review of literature uncovers a basic
truth: a focus on project management by itself will not solve the
problem.
DEFINING OUTCOME-BASED
RELATIONSHIP IN ADM
In an outcome-based contract, the focus moves to results delivered
(e.g. story points, function points or value points) by focusing on the
functionality to be delivered and when, instead of time. In this
arrangement, a project that is 80% complete has 80% of the business
requirements delivered, not 80% of the budgeted hours consumed.
Outcome-based contracts invest heavily in detailing the functionality
to be delivered, and the price for each packet of functionality. This
concept may remind many of AGILE, where the focus is on working
software, not documentation. This is a valid comparison. The
principles underneath AGILE extend naturally into the business model
2

7. OUTCOME-BASED CONTRACTING RELATIONSHIPS
European Headquarters: 3, rue Marcel Allégot 92190 Meudon France | North American Headquarters: 321 West 44th St., Suite 501 New York, NY 10036
with the same improvement in delivery. However, OBC focuses on
allowing the supplier to use the right methodology, not just one.
Recent research shows that organizations that use both AGILE and
waterfall perform better than single methodology groups. But, the
principle of smaller, self-contained, and promotable packets applies
well to OBCs. The packets typically follow AGILE or modified
waterfall methodologies with a focus on regularly delivered functional
packages. Each packet should deliver complete functionality in a
state ready to be released. A stand-alone package of deliverable
value allows business value to be released early.

8. OUTCOME-BASED CONTRACTING RELATIONSHIPS
European Headquarters: 3, rue Marcel Allégot 92190 Meudon France | North American Headquarters: 321 West 44th St., Suite 501 New York, NY 10036
By breaking up work into outcome-based packets, functionality can
delivered as the project evolves, changes in design are encouraged as
the project evolves, and testing can be fully embraced at each
release, rather than added on the end. In an outcome-based
relationship, functionality is not deferred to the more expensive
production phase. It can be managed in the relatively low cost
development phase. The support cost (and associates business
benefit) improves as the quality and defect issues are resolved well
before production.
In short, the notion that not all business processes yield equal value
can be factored into the process and high value processes can be
delivered first. This notion is also at the core of DevOps, which
focuses on the tools and techniques for faster promotion to
production. Switching the focus from consumption of time to
production of value changes the way software is developed.
Equally valuable is the feedback loop on functionality. By seeing
results sooner, the next phases are planned effectively. By using
smaller delivery cycles, project planning can focus on real issues and
not be lulled into a false sense of security around delivery. The
notion of 80% complete is applied to value delivered not time
consumed.
The industry recognizes that the average developer can produce
between 12-15 function points per month or approximately 11 hours
per function point. This assumes that reasonable quality standards
are achieved. Depending on a company’s blended cost, a projected

9. OUTCOME-BASED CONTRACTING RELATIONSHIPS
European Headquarters: 3, rue Marcel Allégot 92190 Meudon France | North American Headquarters: 321 West 44th St., Suite 501 New York, NY 10036
cost per function point can be derived. Some basic math yields an
expected cost for that release.
For a particular release X.Y:
ReleaseFP x Hours per FP x BlendedHourlyRate = Expected Cost
Where Release FP = Function Points Produced, Modified, or
Deleted from Application in Release
Example:
200 Release FP x 11 hours per FP x $85 per hr = $187,000 total
release cost
While not a guarantee, it provides a very reasonable estimate that
can be used to cross check the supplier’s cost. The supplier should be
able to deliver this within ±10% of this number (More than 10% is
inefficient while less is due to reuse or to more effective code
processes). In any event, as we are paying for outcomes, this variance
is within tolerance.
It is also possible to collect the actual hours, divide by the function
points to create a feedback loop to the verification process itself.
Adjusting the hours per function point creates a more accurate
estimate.

10. OUTCOME-BASED CONTRACTING RELATIONSHIPS
European Headquarters: 3, rue Marcel Allégot 92190 Meudon France | North American Headquarters: 321 West 44th St., Suite 501 New York, NY 10036
CONCLUSION
Not exploring outcome-based contracts and relationships can result
in a loss of efficiency within the application development and
maintenance process. Language independent, standards-based,
transparent, and highly predictable, OBCs can bring support and
development costs down while delivering the functionality your
business needs. This activity has a few basic rules for success
a) Focus on the functionality, not the hours
b) Use the estimating process to improve predictability
c) Specification are critical, design for smaller efforts
d) Quality is not an option
e) Package based on risk and value
f) Learn and repeat
IT has long looked for a results-based approach to application
development. Outcome-based pricing models provide an opportunity
to move beyond a straight hours based contract, into a structure that
will prevent business failure and the devaluation of IT.
8

11. OUTCOME-BASED CONTRACTING RELATIONSHIPS
European Headquarters: 3, rue Marcel Allégot 92190 Meudon France | North American Headquarters: 321 West 44th St., Suite 501 New York, NY 10036
References
1
Consortium for IT Software Quality, “Template terms for using automated
function points in software ADM contracts”
2
Consortium for IT Software Quality, “Using Software Measurement in SLAs”
3
Consortium for IT Software Quality, “60% software projects fail (one of 2)”
About CAST
CAST is a pioneer and world leader in Software Analysis and Measurement, with unique
technology resulting from more than $120 million in R&D investment. CAST
provides IT and business executives with precise analytics and automated software
measurement to transform application development into a management discipline.
More than 650 companies across all industry sectors and geographies rely on CAST
to prevent business disruption while reducing hard IT costs. CAST is an integral part
of software delivery and maintenance at the world’s leading IT service providers such
as IBM and Capgemini.
Founded in 1990, CAST is listed in NYSE-Euronext (Euronext: CAS) and services IT
intensive enterprises worldwide with a network of offices in North America, Europe,
and India.