Vendor Contracts: 14 things to watch out for

One of the tricks to a successful contract and vendor relationship is the actual strength and flexibility of the contract between both parties. Aside from the typical ways we setup contracts and use industry standards, we also need to consider the key areas that we should be watching out for… or better yet… what are the "gotcha’s" that you need to be concerned about?


If I was explaining this to someone in a leadership role, I’d want to make sure the following list was incorporated into our discussion. Narrowing this down to 14 areas was tough, but here goes:

  1. Vendor Capacity – Do you know what the vendor has in place today, what is planned to support future deployments?
  2. Increase in Volume – Can vendor delivery scale to meet increased demand or services? For example, if you do increase the volume of work, have you pre-defined your expectations for pricing and delivery?
  3. Transition – Has the transition been defined with explicit deliverables for pre-transition, transition and post-transition.
  4. Current Staff – What will you do with the staff currently performing services? Will they become part of or integrate with vendor delivery? Who is driving continuity and knowledge transfer?
  5. Contract Changes – How will both parties deal with changes to the contract?
  6. Vendor or Client Default – If something happens, has the model for remediation been defined prior to the contract execution?
  7. 3rd Party Default – Has the model for remediation been defined if a supplier in the chain of delivery defaults or is not able to provide services?
  8. Proprietary or Confidential Content – How will the vendor maintain the confidentiality of content across the delivery model?
  9. Governance – Is there a complete governance framework in place for managing the execution of the contract for all parties - you, the vendor and any 3rd party suppliers?
  10. Contractual Structure – Has the contract been structured with the right tools to sustain and address prospective areas of risk?
  11. Data Privacy and Security – Has the combined team addressed privacy and security requirements in a proactive and continual manner that does not pose risks?
  12. Risk – Have you looked at each operational aspect of the contract and identified what actions would be necessary if the risk becomes a reality?
  13. Communication – Does the contract address both internal and external requirements, with a pre-defined approach for effective communication and change management?
  14. Lack of Investment or Commitment – Do you have the appropriate commitment for all parties to address oversight, contract commitment and the proper access to required tools? For example, what does your contract specify regarding 3rd party software access rights?

The items above are just a handful of key considerations. There are many more items to consider and take into account when delivering a strong and flexible contract between both parties.

Managed Services

Why are we so enamored with the term ‘Managed Services?’ Although the term itself conjures up great visions like

- Once and for all resolving my issues with the IT organization, 

- Moving to a service-based or utility-based model, or

- Letting someone else deal with the headaches of delivery, while I (and my team) can focus on what the business really needs …..

... we should be aware that our daydreaming needs a dose of reality.

Any of these visions are great and would be a wonderful case study for others to envy, but let’s get real. The reality is that very few organizations take the time to really figure out what they need and what the market can deliver before embarking on the journey to deliver managed services. We are fascinated with the term, thinking it will be as simple as turning on/off a light switch. We fail to remember everything that went into making that light switch work to begin with and what makes it continue to work well. Instead of getting caught up in the lore of ‘managed services,' take the time to figure out what you need in order to bring managed services into your environment.  There are some great successes and some equally great failures. Try a couple of these techniques and see what happens:


  • Look at what is happening in your industry with managed services. How many of your peers are using managed services to deliver competitive capability? For example, you may have a hot new internal development project underway with a two-year window for delivery. Check on your competitors; chances are they are delivering it in six months, leveraging a vendor to build and maintain the new capability and even to run the infrastructure. Better to find this out sooner than realize what you are delivering is outdated.
  • Look at what you can get rid off.  Take some time to seriously look at your portfolio of applications with a new set of eyes. Can you ignore the internal architecture team’s position of ‘buy, hold, sell’ regarding your internal technical architecture? Ask yourself, why do I need any of this? Can a vendor take any of this, start running it and then help me move to a new architecture or delivery model? 
  • Consider waiting until the market can deliver a managed service in your specific industry. Chances are, you may have something that the market is only starting to look at and build a capability.  It’s only a matter of time until someone in the market figures out how to lower the total cost of ownership and enhance the technical capability. You could choose to wait it out or you could choose to devote some resources to creating the new capability with a strong partner. The deciding factor may hinge on competitive advantage, as well as the risk that you will assume with the approach.


The techniques and approaches for managed services are currently evolving. There will be more to come as this area evolves. We will continue to be enchanted with the topic of ‘managed services' - hopefully moving away from that first blush of fascination to the reality of the work required for successful market delivery.