For quite some time, I have been wanting to write a piece titled “Contractual Contretemps” which would be of help to Project/Delivery Managers. It has a nice ring to it, I think. There were other close contenders for the title – like “Procurement Posers” and “Contractual Conundrums” but to me it was clear who the winner was! By the way, “contretemps” is French in origin meaning a dispute or disagreement. It is also a term used in fencing, my friend tells me.
When my colleagues in PM Power got wind of my intentions, many tried their level best to dissuade me. One of them said, he was reminded of his childhood days when his grandma used to give him castor oil to clear the GI tract! Articles on contracts may remind our readers of some such traumatic experience, he said. Not wanting to cause a big purge in our readership, I decided to alleviate the situation a bit. I would write not lengthy sermons but short anecdotes – a spoonful of the good oil at a time, as it were (however, note that this piece is ominously titled “Part 1”!).
By way of a preamble, the anecdotes are based largely on my own experiences in software services and those of my colleagues in PM Power (God Bless them for re-visiting those painful moments!!).
Secondly, the stories are from a service provider perspective, our experiences being such.
Thirdly, I have no legal background whatsoever but share what I have learnt over the years – working with some real smart lawyers & die-hard procurement managers.
Lastly, these anecdotes would be most useful for those Project Managers and Delivery Managers who are beginning to contribute significantly to contract discussions – may be in their first large, multi-year engagement. Hence, grizzled veterans may stop at this point and move on to other (illegal or fencing) contretemps!!
We will start with a few pointers on the so-called “Master Services Agreement” or MSA. The MSA is sometimes misunderstood causing major or minor contretemps in the customer engagement.
Many large IT services contracts are sort of multi-part. There is usually the MSA and then there are individual “project” or “work package” agreements. The rationale for such a split is that
· Certain contractual terms are common, regardless of the type of project or work package – such as charge-out rates for manpower based on skill/role (developer, senior developer and project manager), clauses for termination, intellectual property, liability and so on
· Not all project and work packages can be identified up front at engagement start and specified by the customer. Hence, as and when these pieces are identified and initiated for the service provider to work on, terms and conditions specific to that piece of work are agreed upon – such as acceptance criteria for a new piece of development, service levels for a new type of support such as monitoring the customer’s production environment etc.
The place and importance of the MSA seem obvious. However, at times, technical managers do not quite comprehend it fully, I feel.
A former colleague while discussing project terms & conditions with the customer (where an MSA already existed) famously said “wherever there is an overlap, the project agreement prevails over the MSA”. His logic was that the “specific” (project agreement) overruled the “generic” (MSA). When this statement was made, there was a sudden hush in the meeting room!
Customer’s legal folks do not take kindly to such brash statements from techie managers. After everyone had heard the pin drop, the customer’s counsel said in a very quiet (menacing?) tone “John, the project agreement is to be read with the MSA”. We all got the message and readily agreed…Obvious? Just a nicety? I think not!
The above incident may have arisen from a tendency on the part of Project/Delivery Managers to treat the MSA as a sort of “umbrella” or “skeleton” agreement not worth bothering about much after the initial sign-off – especially, in long-running engagements.
Here is another anecdote told to me by a colleague about the danger of doing so. A project was being executed under the MSA with a defined project scope, acceptance etc as a separate project agreement. The solution being delivered was all based on a proprietary platform & proprietary components which had to work with some of the existing tools that the customer was using.
In testing, it was discovered that the solution interface to the customer’s tools was not working correctly. The cause was found to be a proprietary component from the provider. Upon doing some more technical research, the provider’s project team figured out that the interface worked perfectly if their proprietary component was replaced by an open source one.
Everyone was happy till the project manager ran this solution by his legal counsel. The legal counsel showed him the MSA where there was clause indemnifying the customer for any loss/damage up to $500 million due to law suits arising from use of the solution! The delivery folks had forgotten that such a clause existed – may be they were not even aware!
In the light of this clause and the proposed use of the open source component, the customer asked for an increase in the limit for indemnification from $500 million to $1 billion! The provider management felt this was unacceptable even though the customer was one of their largest.
Fortunately, legal folks from the provider side were able to propose certain additional precautions with supporting documentation which satisfied the customer without having to raise the indemnification limit.
The exact nature of the “precautions” mentioned above is contextual but the take-away for Project Managers/Delivery Managers is to never ignore checking out the MSA when signing up new project agreements under it or assessing a significant project change – you may discover some issues/inconsistencies which may bite you at the wrong end at the wrong time…Obvious? In hindsight?!
Wait, wait, don’t run away. There is more contretemps coming….
