Checklist: Preparing for the Master Service Agreement
I have stated in an earlier article, Checklist Before Outsourcing Your IT, the high value I place on the use of a checklist before drafting an agreement. It is also obvious that a tool such as a checklist can provide invaluable assistance to the IT Project Manager when preparing for the implementation of a newly purchased software suite. In my research I have found a very interesting article in Wisconsin Technology Network News, WTN News, by Richard Marcus entitled Six things to consider before a major software implementation. Marcus presents a very useful list in his March 2006 article. Admittedly this article is over 2 years old and in this fast-paced high-tech environment the concept of what is “new” and what is “old” takes on different meanings from our traditional understanding of the terms. However, I believe his advice stands the test of time regarding this subject matter.
Marcus begins his article by cautioning the buyer on the critical nature of the purchase and that concentrating solely on the pricing could be a perilous mistake. He then provides his six points that the purchaser should take into account before forging ahead with the implementation. A brief synopsis of these six crucial points is as follows:
- The Software Vendor and the Customer are partners in this undertaking. Both parties must bring their knowledge and skills together in a committed relationship. Success depends on having sufficient resources. The Vendor should already have their team ready and the customer should have a comparable team prepared to spend the estimated time needed for the project. See also the February 15, 2008 post to this Blog, The IT Worker Shortage: Practical Considerations for Tech Buyers.
- Communication is key. Insist that the Vendor set the correct expectations. Talking is not the only art form in this communication process. Listening is essential. Ask questions and let those answers lead you to more questions. Strive to learn not only what the software can do, but also what it cannot do. In the past, I was a consultant for a large software vendor. As a newbie on one of my first implementations, I learned the catchphrase consultants were often overheard to say to the customer when discussing the software’s capabilities, “The salesman said it could do what?” Make sure your requirements are well known and can be met.
- Pricing. Marcus’ admonition above is still valid. Price is not the only factor, but it is still a factor nonetheless. Negotiate a payment schedule that is tied to clearly defined and identifiable milestones that are realistic. Holdbacks dependent on successful acceptance test results should be discussed and inserted into the contract. Too much money upfront surrenders too much influence to the vendor. I was interested to read that Marcus warns the reader not to be swayed by the software vendor’s pleas and worries about revenue recognition. In my career I have discussed this many times, but only in a software license agreement negotiation. A Master Service Agreement is usually a time and materials agreement and hence revenue can only be recognized as it is earned. A Fixed Fee arrangement is a totally different case and will be a topic for a separate post to this Blog.
- A separate Master Service Agreement should be drafted. Marcus points out that it is common for the license agreement itself to contain sections pertaining to services such as ongoing support and maintenance. However, these services are not directly related to the implementation. I have come across license agreements that purport to contain the implementation services section within the license. This should be avoided. His article deals with a major implementation and so most major software developers and vendors already have their contract model set up to have a separate license agreement and a separate Master Service Agreement. This is the preferred approach. An implementation section contained within a license agreement may not address all the salient points of an implementation and also may not be clear and unambiguous on other necessary elements.
- The Master Service Agreement should contain Service Levels. This is a very important item and one that should not be overlooked. A service level agreement (“SLA”) can take the form of a separate schedule attached to the license agreement. Alternatively and depending on the complexity of the requirements of the customer, a separate SLA may be more appropriate. In the SLA the customer should make certain that all of its requirements that were fleshed out during its communications with the software vendor (see point 2 above) are memorialized for future reference.
- Know the use limitations in the license and plan accordingly. Many software licenses are User based pricing. Many vendors are willing to provide some form of price protection for future purchases of users. The Customer should verify that no further implementation work will be needed if more Users are added. However, if the Customer is faced with product based pricing and is not purchasing the entire software suite of products, then further implementation work will be needed if more products are added. This possibility should be fully explored and the consequences understood in the event of future growth.
Marcus concludes his article by stressing that the Customer must do their due diligence on the front-end. With proper planning the Customer can avoid mission-creep and other costly mistakes. Once a major implementation is set in motion it becomes cost prohibitive to put a complete stop to it or redirect your efforts towards another project.
