This article is part of the series on Contractual Contretemps. If you have missed the first one in the series, take a look at “Contractual Contretemps – Part 1” which covered a few tips/anecdotes on Master Services Agreements in the context of software services. We now continue with the series which would be of help to Project / Delivery Managers who are beginning to contribute significantly to contract discussions with customers – may be in their first large, multi-year engagement. Drafting a major contract is a team effort involving the sales team, account management, delivery/technical teams and senior leadership in addition, of course, to the organization’s legal team. Key aspects that the delivery leaders like Project & Delivery Managers need to be actively involved are:
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 will cover the first two in this article.
1. Commitments made by the provider organization
Generations of delivery leaders would vouch for the complexity in managing this aspect. In the case of a commitment related contretemps, as a provider, it may not be possible to take a “hard” stance based on whether a specific commitment is stated in black & white or not in the contract. There are reasons for this:
– In the pre-sale stages, everyone is keen to close the deal and get the contract signed-off. Many people from the provider organization – from sales, pre-sales and delivery – would be interacting with the customer at this stage and may be making verbal commitments which may not get communicated to anyone else, leave alone being documented in the contract; even if commitments are only verbal, provider organizations may have little choice down the line except to honour them when they threaten to sour the relationship with the customer
– In order to keep the contract compact, detailed information is provided in schedules to the contract (such as the Statement of Work) or through references to other documents like product specifications, standards to be followed etc. Information in these documents even in black & white may be open to interpretation by the customer to the detriment of the provider
So, how best to manage commitments given the above?
– Provider-side teams working together from sales, pre-sales and delivery must be enabled through process & tools during commitment making leading up to contract drafting
– The above team must, through a healthy commitment making culture and common understanding of how best to balance sale-ability and executability of the work being bid for
– Senior leadership needs to support the bidding teams in the above by
- providing direction
- helping internal arbitration as needed
- providing additional “breathing space” for delivery folks (through provision of extra resources, setting lower profit margin goals and so on) where needed –such as in cases where saleability has prevailed over everything else
The book “Managing Technical People” by Watts Humphrey provides an excellent chapter on developing the “commitment culture” in an organization. By the way, there is another blog available on the book.
2. Statement of Work (SOW)
In the software services context, the SOW is often an addendum or a schedule to the main contract (although in some other domains, it may be a complete stand-alone agreement in itself). Many of you would be familiar with what the SOW is all about. So, we will not re-hash that. Rather, I would make a few observations from our experience in coaching project managers (PMs).
Sometimes, PMs ask “is the SOW not just the statement of customer’s requirements?” If the customer has provided detailed requirements for, say, a software product, it may be well be. This happens when the SOW covers parts of a development life cycle such as coding and testing only.
However, in general, the customer may provide only a high level set of business requirements. In such cases, the requirements need to be analyzed by the provider and the scope of the product (functions and features at a high level) need to be part of the SOW. Bear in mind that the customer’s requirements are a unilateral statement while the scope in the SOW is mutually agreed to by both the customer and provider.
There are other elements that are needed in the SOW (assuming it to be a schedule in the main contract) which make it not “just the statement of customer’s requirements” – elements such as:
· Project assumptions
· Major milestones and dates
· List of deliverables
· Applicable standards
· Acceptance criteria
In summary, terms & conditions and major commitments surely need to be covered in a contract & accompanying SOW. However, in a software project, many situations would arise which need to be addressed through the change control process in the contract. Changes that arise could range from those having no or only a minor impact on the contract to those which could be showstoppers.
We started with the list of key aspects below. Of these, we have covered the first two in this post. Watch this space for the remaining ones.
1. Commitments made by the provider organization
2. Statement of Work
3. Performance guarantees by the provider
4. Contract breaches & remedies
5. Change control
If you have comments/experiences to share on managing contracts, write to us at info@pm-powerconsulting.com.
