Home > Managing the Business > Consultancies and Contracts

Consultancies and Contracts

Every MS consultancy with which you do business is going to ask you to sign two contracts related to services.  They go by various names but are usually called  Master Services Agreement and Scope (or Statement) of Work.

The Master Services Agreement defines the on-going business relationship with the consultancy.  Specifically, it will address billing policies, intellectual property ownership, non-disclosure rules, travel policies, payment terms, etc.  In essence, it will usually address everything that normally does NOT change from project to project (or engagement to engagement). 

The Scope (or Statement) of Work (sometimes also called a Service Order) defines the scope of work to be delivered in the current engagement.  If well written, it should clearly define the deliverables (dates and content), the personnel (level and rate) and the list of services being provided by those personnel to reach those deliverables.  In addition, it will provide a time and charge estimate (for time and materials) or the fixed fee terms (amount and milestone schedule).  Where conditions in the MSA are changed, they should also be specifically listed in the SOW.

On the surface, this seems pretty straightforward:  one document tells you the business rules, the other one tells you what we are going to do, when we are going to do it, who is going to do it and how much its going to cost.

And yet, for all its simplicity, it’s in this process that so many expectations are improperly set leading to later problems and relationship challenges.  In no particular order, here’s the three top areas where I often see less than perfect contract clarity:

  1. Travel Expenses:  If a consultant is coming in from a another location (define that as more than about 75-100 miles away), expect to pay the travel expenses UNLESS the contract explicitly says differently.  If the contracts are silent as to travel expenses both parties should insist on language being included that outlines a policy to which you both agree. 

2.  Travel Time:  A consultant that is sitting on a plane is not billing.  So, expect most consultancies to charge you for some degree of travel time.  The most often used methods are 1/2 rate/both ways or full rate/one way.  Another method I’ve seen is flat rate per trip.  Sometimes you can get this waived if a) the overall project is large enough, b) the consultancy is desperate enough (not a good sign, by the way) or c) you commit to a certain minimum number of hours of billed time per trip (usually its 32 minimum).

3.  Data Migration:  Especially for CRM and ERP, who is responsible for pulling the data out of the legacy system and validating it before it’s migrated?  Who has to format the data into an acceptable input format?  If an error occurs on import, who is responsible for fixing it?  When the import is complete, how much validation work is the consultancy and how much is the client supposed to do?  Lastly, specifically what data is being migrated?  It’s not enough to say “Customer Records”.  In AX, a customer record is completely different than that in CRM and I guarantee you a client may think a customer record includes all transactions where the consultancy just thinks of it as the customer name and address data.  The best solution I’ve seen is to include a data mapping diagram as an attachment to the contract that shows the data points as mapped between the old and new system.  Even better, do the data mapping diagram based on the GUI’s of the legacy and new system so its completely clear to the business folks signing the contract.   If this is not possible, the contract language should be clear about the assumptions inherent in the data migration so that both parties can agree if conditions change later.

I’ve also had problems around testing (both unit and system) and training (project team vs end user vs content in both), but by and large, the above has caused far more confusion than anything else.

Next to last, a note to consultants:  read your contracts with an unbiased eye, like you’ve never done an engagement like this before.  Is it clear?  Can it be understood by a laymen?  More importantly (even more important than its legal enforceability), can you manage to it?  If not, assume you will have several negative conversations with your clients along the way.

Lastly, a note to clients: Read the contract, esp. the statement of work.  Everything you discussed in sales meetings for the last 6 months is boiled down into a set of rules in the contract to which the services team will manage the engagement.  If you don’t understand it, and you sign it, you are inevitably going to be disappointed the first time someone says “change order”.   Insist on clarity (in the contract, not verbally or in side agreements) and then manage to the agreement as written, not as promised during a sales cycle.



Categories: Managing the Business Tags:
  1. September 1, 2008 at 7:58 am

    Great Post. I especially loved your idea about documenting the migrations using screenshots of the GUI of both systems! That will be very effective.

  2. Christina Belding
    September 11, 2008 at 11:49 pm

    Outstanding post. I especially like that you clearly point out to ALL to read the contracts- and ask for clarity if something is not understood before it’s signed.

    Too often, contracts are created with verbiage that may be well known to the author (especially as it’s related to modules, functions, acronyms, etc.) however its completely meaningless to those responsible for financial funding or executive approval.

    It goes without saying that some people will never ask about what they don’t understand for fear of being viewed as illiterate in the subject-but I’m glad you ARE saying it.

    It’s also interesting how few ever re-read the contract at the end of the engagement-those that usually do are in a problematic state in the first place. My recommendation is to do a contract review at the end if for no other reason than to prove to yourselves how much you learned through the process.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: