This article is third in the series on Contractual Contretemps. It is a continuation of Part 2. You can look up Part 1 as well on tips/anecdotes on Master Services Agreements. In the earlier Part 2, we introduced the list below of key aspects that technical leaders like Project & Delivery Managers need to be actively involved, viz:
1. Commitments made by the provider organization
2. Statement of Work
3. Performance guarantees by the provider
4. Contract breaches & remedies
5. Change control
We covered the first two in the list above in Part 2. We will cover the remaining three aspects in this article.
3. Performance guarantees by the provider
Since we have already covered “Commitments made by the provider organization” in Part 2, one may rather perversely ask “Are performance guarantees by the provider not commitments?” Of course, they are – but they are dealt with as a separate topic here given their importance and potential for contretemps!!
There is a wide range of possibilities in performance guarantees. Examples in the software services context are:
· “The seller shall ensure that all staff requests from the customer are responded to within 3 (three) business days”
· “The seller shall ensure that 90% of the staff requests in each quarter are fulfilled as per customer requirements within 30 days of receipt of written staff requests from the customer”
Examples in the software product context (bespoke development) are:
· “The software product shall provide a response time of between 3-5 seconds for all mutually agreed list of functions under a specified test environment and transaction volumes”
· “The software shall support transaction throughput of up to 4000 (four thousand) per hour in a mutually-agreed test hardware/software configuration”
The contractual contretemps arising from performance guarantees is, of course, due to the customer wanting to make them as general as possible and the provider wanting to make them as specific & unambiguous as possible (assuming complete avoidance is not an option!).
Resolving disagreements in such cases is often guided by “reasonableness”. Surprisingly, legal folks on both sides are often able to find that common ground acceptable to both – better than the technical managers who have to deliver on the guarantee! There are, of course, technical bounds on what can be achieved and commercial sense of what is practical for the contract value.
A friend told me of an instance of a most draconian performance guarantee he had encountered – “that the application software delivered by the provider shall function without interruption for a period of 60 (sixty) days”. If you feel that it is not so draconian, have another look! The application software may never achieve that goal!!
Draconian or not, oftentimes, stringent performance goals become non-negotiable – say, in financial services, health-care and so on. In such cases, Project/Delivery Managers need to remember that old adage that “performance cannot be added at the end”. Enough time and resources need to go into architecting and designing for performance, adoption of proven development standards, prototyping, applying the right expertise early and of course, planning for an optimizing & specialized testing.
These days, high-volume, high-performance software applications are becoming the norm with so much B2C interactions over the Internet – the world of Social Media-Mobility-Analytics-Cloud (SMAC). Business demands are high and technology is rising up to the challenges of “big data” processing in real time. Contractual aspects also have to keep pace – enabling reasonable flexibility and ease of doing business.
While concluding on performance guarantees, we cannot forget contractual “Disclaimers”. Disclaimers are “customer beware” (caveat emptor, as they say) statements that cover what the product/service is NOT. If you ever read the disclaimer in fine print on the glossy boxes of off-the-shelf software products, you would realize how sweeping they can be!
4. Contract breaches & remedies
We have covered contract commitments and performance guarantees. The related question is what happens if the provider fails to meet those?
Breach of contract could arise from any number of sources in the contract such as:
· The provider may have assured certain aspects under confidentiality. If these were compromised during project execution, it may be considered a serious breach
· There may be repeated delays in deliverables
· Quality of services may be consistently below agreed levels and the provider efforts to improve them inadequate/ineffective
· Customer may be unable to pay for deliverables as agreed
So, what is the role of Project/Delivery Managers to working out situations of potential contract breaches and remedies that the provider can agree to?
Take for example, schedule conformance in a project. In many cases, a great deal of importance is attached to it. Customers may ask for penalty clauses to be incorporated entailing, say, $xyz of payment by the provider to the customer for every day of slippage.
Providers often respond that such clauses should not be one-sided and there should be comparable “reward clause” if goals are over-achieved (such optimism!). Providers also try to agree on an upper limit for such penalties (such as the contract value itself).
Technical managers play a big role in managing risks arising out of such clauses. They are responsible for selecting the right solution approach, optimize concurrency in execution, foster team work for achieving performance goals, gain customer cooperation and so on.
Just as there are a whole host of possibilities of breach, there are varieties of ways in which remedies can be provided. The ultimate remedy is, of course, to terminate the contract with provider reimbursing the fees received till that time. But, abnormal termination of a contract is often not that simple – perhaps the subject of another article down the line.
It is often said that when either the customer or the provider gets to the point of saying “let’s open the contract and see what it says”, it is pretty bad news for all the people involved! Project/Delivery Managers when making commitments and delivering on them must strain every sinew to avoid that situation. That’s the bottomline – even after spending all the time & effort on potential contract breaches and remedies!
5. Change control
I will conclude this article with a few remarks on change control. Projects evolve in terms of what is known and what is unknown in terms of what the customer really needs and the quantum of work required to identify & meet those needs. Inevitably, many things change in the project calling for refinements if not outright ground-up re-planning – especially in software. Therefore, change control clause is kind of a “hygiene” clause in software development contracts. One must have it – it is part of the contractual “dress code”.
Many of the change control clauses in contract would cover the process of managing change, documentation for a change request, reviewers & approvers of change and so on. That much is pretty much obvious – unlikely to cause contretemps at a contract level. However, in practice, change management gets to be complex in execution and the nitty gritties of separating “change” from “defect” and steering one’s way through various stakeholders depending on the magnitude of the change. Contractual help in such circumstances is limited where so much “art” is involved!
If you have comments/experiences to share on managing contracts, write to us at info@pm-powerconsulting.com.
