©IACCM 2009. All rights reserved.

©IACCM 2009. All rights reserved.

So far as I know, the memorandum issued by President Obama on March 16th calling for improved contract management was a first. I am not aware that any other head of state ever highlighted the importance of contract management discipline in the effective and proper application of public sector funds.

Recent incidents demonstrate the urgency of this need. For example, Sherry Gordon reported yet more problems for the UK's National Health Service when she wrote recently on Spend Matters. And the US press has been full of the contention in Virginia, where Northrop Grumman won a major IT outsourcing contract that is now riddled with questions. A further variant arose earlier this month, once again affecting the UK health service, when the press questioned the competence of procurement in its use of reverse auctions to select and deliver outsourced care services – and its failure to oversee the results (see Reverse Auctions).

It can be tempting to blame the suppliers. For example, it is suggested that Northrop Grumman lacked the skills and experience to undertake the outsourced work in Virginia and the media in the UK is pointing at BT as the culprit for missed deadlines and service level failures. But in the end, projects like these depend upon a high degree of collaboration and honesty between the parties. They also require robust governance and rigorous performance management. And that has to be a mutual commitment and capability. Blame is rarely all on one side; and certainly not when, as these incidents suggest, the problems and issues go back over a number of years.

Today's complex, service-based deals demand selection and post-award management procedures that are far more robust than most public sector agencies are equipped to provide. Traditional procurement training is inadequate – and in many cases makes the problem worse. The tendency for public procurement policy to focus on price alone is reinforced by training programs that treat suppliers as untrustworthy and to be held at arm's length (see for example my recent blog on A Simple Way To Undermine Procurement Success). In many cases, delivery personnel have little training in supplier relationship and performance management, there is little or no continuity of staff and fragmented responsibility for outcomes.

President Obama's concern was echoed in a recent report by the UK's National Audit Office, which focused on the challenges in post-award contract management and highlighted deficiencies in current practice. Last year, a Rand Corporation report on EU Public Procurement Policy (based on research by IACCM) was scathing in its observations of contracting policy and practice. The report highlighted the distorting effects of risk-averse terms and conditions, often compounded by the use of external consultants and law firms. Overall, it found that the lack of robust and transparent contracting principles not only sets the seeds for potential failure of many projects, but also leads to higher pricing due to the levels of risk that suppliers must bear.

All the evidence suggests that the need for improved contracting competence is urgent. It is refreshing that President Obama's advisers have understood the need (and IACCM members are invited to respond to that initiative); and there are similar steps afoot in the UK and Australia. However, given the scale of today's public sector expenditure, combined with the need to ensure greater efficiency and (shortly) savings, the pace of change must be faster.

This article is taken from the Commitment Matters blog. IACCM members are invited to send their views on changes needed in public procurement to info@iaccm.com.

• Templates for common business agreements
•  A question and answer wizard that shows clause permutations
• Software that writes clauses and assembles a contract
• Contract assembly tool to create your own personalized Q&A wizard and templates
• Multiple version tracking and red line comparisons
• Free, provided at no charge 

This paper reviews certain contract elements encountered in Information Technology application development contracts. The contract provisions are (1) deliverable milestone billing structure, (2) holdback, (3) warranty, and (4) critical deliverables. 

1.       Payment Milestones

a)       Background:
 
The deliverable milestone billing structure is quite common in contracts that require a contractor to construct something tangible for a Customer. The Building Construction industry has a long history of receiving payments based on percentage of completion or pre-determined construction stages subject to Customer acceptance. Under this type of billing arrangement, the Customer approves periodic payments or “draws” against the total contract price based upon the Supplier’s completion of certain construction phases and satisfactory inspection by an independent government building official. In some construction contracts, the Supplier is not allowed to build profit into these periodic draws with all of the projected profit for the entire project being built into the final draw due. Construction type draws might include the following major phases of a new building construction project: foundation, framing, rough carpentry, rough electrical, rough plumbing and others.
 
In the automotive industry, tooling Suppliers often are paid on a percentage of completion basis with final payment due after the tooling has been proven to meet the production specifications. This is known as Production Part Approval Process” or “PPAP”.   PPAP is a process where the Customer verifies that the engineering design record and specification requirements are properly understood by the Supplier and the resulting tooling and processes meet these requirements in an actual production run at the manufacturing facility of the Customer over a pre-determined period of time (typically 3 – 6 months).
 
In the software application development process, payment milestones might include such things as:
 
Project Schedule
System Design document
Code Build
Test Cases Complete
Unit Testing
Integration Testing
User Acceptance Testing
Deployment
Warranty Acceptance
 
These examples of deliverable milestones are not intended to be all inclusive, but are representative of the major application development project stages that can be quantitatively measured as being complete. 

b)       Customer Perspective:

In an application development project, the Customer’s expectation of the Supplier is to develop a product that meets the Customer specifications within a desired time-frame.   The Customer value is not fully realized until the final work product can be used in production so the Customer motivation is to place the highest value on the final work product.   For longer term engagements, the Customer may be willing to pay for interim deliverables but still desires to place the greatest weight on the finished product.
 
c)       Supplier Perspective:
 
With development projects that could span multiple months, the Supplier desires to obtain payment on a percentage of completion basis. A fair compromise to this is to base the payment on mutually agreed to interim milestone deliverables or phases in the development cycle, such as the ones mentioned earlier. Once the Supplier provides the Customer with the deliverable and it is accepted by the Customer (usually using some pre-determined acceptance criteria or testing results), payment is made to the Supplier. The Supplier should price each interim deliverable in line with the estimated effort required in relation to the total project in order to match price with effort.   In addition, it is advisable that the Supplier negotiate a number of milestone payments throughout the development project life so as to have a steady stream of billable events. 
 
The risk to Supplier is that if any milestone is late or does not meet the acceptance criteria, payment is delayed until the deliverable is completed and accepted.   When a project is running late, the Supplier may also have to invest additional resources to get the project back on track, further worsening the performance to the Supplier’s point-of-sale model.
 
The project schedule should have some pre-determined, time-limited Customer review and feedback period so as to avoid the Supplier milestone payment being held in limbo for an indeterminable period of time.
 
 
2.       Holdback Provisions
 
a)       Background:
 
Holdback is a contract mechanism that allows the Customer to hold back some percentage of the total contract price from the Supplier until a pre-determined period of time or event following delivery of the work product. Holdback in the construction industry and manufacturing industry is not a new concept but it is a relatively new provision in computer application development projects.   There are three main components to holdback provisions.  
 
a.        The time period that the holdback amount is held by the Customer

b.       The amount of the total price that is being held back by the Customer

c.        The criteria used to release the holdback amount

1) Time Period:

Typically the time period is between 30 and 90 days but it could be longer. Some contracts hold back until the warranty period has expired while still others may specify a time period to prove that the work product functions as specified over a pre-determined use period in the Customer production environment.

2) Amount:
 
The second component in the holdback provision is the amount of the holdback. Typically one can expect anywhere from 5 to 25% of the total contract price to be held back.  
 
3) Criteria for Release:
 
The third main component is the Holdback release criteria. This can be from the very simple, like a pre-determined period of time after delivery or it can be based on more stringent exit criteria (warranty, pre-determined production performance over some pre-agreed to period of time).
 
b)       Customer Perspective:
 
The Customer’s motivation to utilize a holdback provision is to retain part of the total price of the project until the Supplier demonstrates that the deliverable has met the requirements over some pre-defined period of time.  This provides an incentive to the Supplier to deliver a quality product.  This approach maintains a Supplier interest beyond just the delivery of the final work product and prevents a Supplier from pulling a dump and run, with full payment in hand.
 
c)       Supplier Perspective:
 
If the holdback period is for some extended period of time and/or is a large percentage of the total price, the Supplier may consider a time value of money cost element when developing the price of the project. Typically, if it is expected that the hold back period will be longer than 30 days or the holdback amount is larger than 15%, one may consider pricing in this lost time value of money. The Supplier should insist on a holdback release criteria that is objective and consistent with the application development requirements.   During times of tight credit or where a Customer is under financial duress, the Supplier may want to cap the holdback amount or eliminate it entirely to reduce cash exposure. Projects that exceed some pre-determined threshold should require the Supplier to obtain internal leadership approval prior to submitting a pricing response to the Customer.
 
 
3.       Warranty
 
a)     Background:
 
Warranty has been a staple in the consumer hard goods industry for years. However it is relatively new in the Application Development space. The warranty concept is relatively the same for both consumer hard goods and Business to Business IT application development. That is, that the product is warranted to run as advertised or according to specifications for some period of time after delivery.
 
b)        Customer Perspective:
 
The Customer’s desire is to seek remediation in the form of corrective actions by the Supplier in the event that significant defects or non-conformities to the requirements exist in the final product. The length of the warranty period should be of a sufficient duration to detect any non-conformities over the normal cyclical use of the applications. Typically this can be done in a 30 day period for applications with monthly cycles and 90 days for those applications that run on quarterly cycles. Even though the Supplier may have run a variety of tests (unit testing, integrated testing, user acceptance testing, load testing, performance testing, etc.) on the application to make sure it performed to the specifications, some things may not get discovered until it runs in the actual production environment.
 
When the application development project (i) is complex, (ii) utilizes leading edge or unproven technologies, (iii) is of a nature that the test cases may not capture the variety of conditions that may exist in the production environment, or (iv) will not have access to an integration testing environment that mirrors the production environment, the application may encounter problems that may not surface until the application is running in the Customer’s actual production environment.   Thus there is a need for the Customer to have some recourse with the Supplier after the application is put into production use.
 
c)   Supplier Perspective:
 
The Customer expects and Supplier strives to develop an application that performs to the Customer specifications. The warranty objective for the Supplier is to limit the warranty period to a reasonable time-frame. Since application development is not a precise science, the defects or non-conformities required to be corrected during the warranty period should be material in nature and related to the actual functional requirements but not minor issues related to look and feel. For example, font size or screen colors should not constitute a warranty item. However, missing a key end user function should be a warranty item.
 
Warranties should be limited to 30 to 90 days after being placed into production use.   If the resulting developed application will not be put into production use until sometime after delivery of the final work product, the Supplier should consider negotiating the removal of the warranty coverage or changing the warranty period to some fixed time-frame following delivery of the work product. The Supplier does not want to be in a position of having to provide support for an undeterminable, unquantifiable warranty time-frame.  That would require the Supplier to maintain some level of expertise to be on hand to respond to the “just-in-case” and undefined warranty situation. 
 
 
4.       Critical Deliverables
 
a) Background:
 
1)       Critical Deliverables are those deliverables that the Customer deems key milestones or activities during the system development lifecycle.   Failure of the Supplier to deliver these on time will cost the Supplier in the form of Critical Deliverable credits to be paid to the Customer. Critical Deliverables are the Customer’s financial motivator to the Supplier to keep the project on track so that the Customer can realize the benefits associated with the enhanced functionality.  
 
2)       At this point, it makes sense to discuss the relationship between Critical Deliverable Credits and liquidated damages as Critical Deliverable Credits are often viewed as liquidated damages.   Liquidated damages (also referred to as liquidated and ascertained damages) are damages whose amount the parties designate during the formation of a contract for the injured party to collect as compensation upon a specific breach (e.g., late performance). In order for a liquidated damages clause to be upheld in a legal ruling, two conditions must be met. First, the amount of the damages identified must roughly approximate the damages likely to fall upon the party seeking the benefit of the term. Second, the damages must be sufficiently uncertain at the time the contract is made that such a clause will likely save both parties the future difficulty of estimating damages.
 
The use of the terms Critical Deliverable Credit is used instead of the term “penalty” because based on legal principles “damages for breach by either party may be liquidated damages in the agreement but only at an amount that is reasonable in light of the anticipated or actual loss caused by the breach. A term fixing unreasonably large liquidated damages is unenforceable on grounds of public policy as a penalty.” Further, “when a sum is stipulated in a contract as a punishment for default, not as the measure of compensation for breach of contract, the stipulation is a penalty and is invalid and non-enforceable.” Critical Deliverable credits are allowable because each party know what is in their own best interest to include or exclude from the contract. Each party knows their own situation and the surrounding circumstances better than any third party (including an arbitrator or a court).
 
Key Definitions:
 
Critical Deliverables mean those deliverables performed on a one-time or periodic basis, for which a Deliverable Credit may be payable.
 
Critical Deliverable Credits means the monetary amount(s) that the Supplier shall pay to the client (or apply against Monthly Charges) in the event of a failure to achieve a Critical Deliverable.
 
Typical Critical Deliverables associated with IT Application Development projects are as follows:
 
Supplier Project Team Fully Staffed and Equipment/Software Available for On-Time Project Start
Detailed Integrated Project Schedule (WBS) Signoff Obtained
Construct Tollgate
Test Tollgate
Deploy Tollgate
Close Tollgate (including warranty period completed)
Requirements Signoff Obtained
Design Signoff Obtained
User Acceptance Test Signoff Obtained

3)       Critical Deliverable TBD Credit amounts in RFPs: If a Customer issues a request for proposal which has Critical Deliverables and the associated credits that indicate a “to-be-determined” (TBD) amount, then the requirements are incomplete. Some Customer do this as a practice, with the belief that Suppliers should not price any additional risk or harden the solution based on the size of the Critical Deliverable credit. This is not only a bad contracting practice, but it also brushes past business realities that risk is not an element that influences solutioning and pricing. Certainly if the Critical Deliverable Credit due the Customer for failing to meet a particular milestone was $100,000 versus $1,000 per week late, the Supplier has to either (i) design a hardened and resilient solution to significantly reduce the chance of failure to meet them and/or (ii) add a price premium to allow for the risk of experiencing a Critical Deliverable failure and then having to pay the Customer the resulting large credit.   The economic risk is 100 times higher with the $100,000 per week Critical Deliverable credit versus the $1,000 per week late credit. In either case, the price to the Customer for the same work effort would be impacted.   Although this example is a bit extreme, it does illustrate the point of how the size of the Critical Deliverable Credit can influence the risk to the Supplier and thus the resulting price to the Customer. 

If the Supplier accepts the “TBD” amount without a qualifying statement, the Customer could later insert some amount much larger than that anticipated by the Supplier, thus increasing the risk profile to the Supplier.   Leaving the “TBD” amount in a Supplier response implies that the amount of the critical deliverable credits has no bearing on the risk profile of the engagement. The Supplier is advised to qualify the response by providing the Customer with those critical deliverable credit amounts that fit the Supplier’s risk tolerance and making the response contingent on Customer acceptance of the proposed Critical Deliverable Credits. The Supplier should develop the solution and price to meet these proposed Critical Deliverables. Other alternatives are (i) the Supplier could request the Customer to provide complete requirements by including the critical deliverable credit amounts prior to the Supplier responding to the RFP or (ii) the Supplier could always opt to no bid the opportunity.

4)       Critical Deliverable due dates: The Customer includes the due dates for the Critical Deliverable (for example, “in accordance with the Baseline Project Schedule” or “XX weeks after some project event”), along with the lateness allowance of that Critical Deliverable (one week late, then a credit is paid). Early service level methodologies, used the Critical Deliverable Credit as a one time payment for missing a Critical Deliverable Due Date. Today, it is not uncommon to find Critical Deliverable schedules designed to have the vendor pay a repeating credit until the Supplier provides, and the Customer accepts, the deliverable.  A Critical Deliverable with a Critical Deliverable Credit based on a per-week-late basis, would require the Supplier to pay the Customer the Critical Deliverable Credit for each week that the Critical Deliverable is late until it is delivered. For example, if the Critical Deliverable is based on a “per week late” Critical Deliverable Credit and the Critical Deliverable is 4 weeks late, then the Supplier will pay the Customer 4 times the Critical Deliverable Credit amount. Critical Deliverables that are late may also cause subsequent dependent Critical Deliverables to be late thus increasing the Supplier’s Critical Deliverable Credit exposure. One can see how the Critical Deliverable Credit can snowball to become quite onerous to the Supplier if the project falls behind schedule early in the project time-line.

5)       Progressive Critical Deliverable credits: A recent new, more onerous twist to the Critical Deliverable is the progressive credit. In this scenario, the Critical Deliverable Credit increases in size as the deliverable continues to fail meeting the Due Date.

 
EXAMPLE:
 

 
 
a)     Customer Perspective:
 
The Customer interest is keeping the project on time. By including Critical Deliverables and the associated critical deliverable credits in the contract for the application development project, the Customer provides a financial motivator to the Supplier to stay on time.
 
Critical Deliverable Credits should be viewed in light of the entire damages picture that is drawn from the performance failure. Taking into consideration the contract’s direct damages cap - the Critical Deliverable Credits should be viewed as an additional remedy over and above the direct damages cap. 
 
b)    Supplier Perspective:
 
The Supplier’s objective is to develop a solution and align its internal incentives with the Customers requirements and emphasis as described in the Critical Deliverable Due Dates in the proposed project schedule and the Critical Deliverable Credits. For interim Critical Deliverables, the Supplier should try to negotiate a waiver of any interim Critical Deliverable Credits if the final Deliverable is delivered on time.  Another risk mitigation action is to negotiate lower Critical Deliverable Credits for these interim deliverables with a larger Critical Deliverable Credit attached to the final work product deliverable.
 
For projects with a milestone billing structure, the Supplier should push for milestone payments for each Critical Deliverable. The rationale is that if the deliverables are critical to the Customer then these deliverables must also provide value in the form of a milestone payment.
 
Removing the subjectivity out of Customer acceptance is another way to mitigate risk.   The Supplier should propose objective acceptance criteria and if the deliverable meets these objective criteria than the Critical Deliverable is met.
 
Conclusion:
 
Information Technology Application Development projects are bound to have one or more of the following types of contract elements:
 
·         deliverable milestone billing structure
·         holdback
·         warranty
·         critical deliverables
 
The key point to remember is that these contract elements all should involve some level of risk assessment to be done by both the Customer and Supplier. All development projects will have some level of inherent risk just by the nature of the work. The contract elements listed above are a way to shift some of the risk from the Customer to the Supplier.  Given that certain information technology consulting groups cite that the failure rate of “large” IT application development projects ranges from 50 to 80%, it is important to understand the impact of the risk re-allocation presented by these contract elements.
 
Taken to an extreme, let’s take the example of a long term, complex, high dollar value project with one milestone payment due at completion of the work product, a high percentage (15% or higher) holdback amount with an extended warranty and holdback period and multiple progressive critical deliverables with excessive critical deliverable credit amounts. In this situation, the Supplier may add additional resources and “over solution” in order to provide additional assurances of timely delivery against unknown risks and may also add a price premium to cover the time value of money and contingencies for critical deliverable credit payments.    This will translate into a higher price to the Customer. An overly high risk profile will cause potential Suppliers to price in the additional risk resulting in an unacceptable price point for the Customer or even worse could influence some capable Suppliers from even bidding on the work.
 
The key is to balance the Customer desire for timely execution to the project schedule with the Supplier’s risk tolerance. By striking a balance to the risk allocation of these contract elements between Customer and Supplier the resulting agreement should increase value to the Customer and provide a tolerable risk profile to the Supplier.           
 
The author is employed as a Contract Consultant in the Legal Affairs office of HP Services, a division of Hewlett Packard (Mike worked for EDS, prior to HP’s acquisition of EDS in August, 2008). Mike has over 15 years of Information Technology contracting experience on both the Buy and Sell side. In addition, Mike has taught graduate level MBA courses as an adjunct faculty member for Davenport University in Warren, Michigan. Thank yous go to Jason Cole and Doug Peters (also an IACCM member) for their editorial comments to prior drafts of this paper.