This Is How You Should Manage Your Software and System Vendors

, , , ,

Tuomas KestiHaving a third party vendor or software system provider is often a good choice for small and midsize companies to implement certain system or a part of it. Companies of this size often lack the special skills or time to run projects solely by themselves, perhaps of internal nature.

However, selecting vendors and managing vendor relationships can be quite challenging. The big vendors might rely on their name and offer resources that don’t always reflect the expected level. On the other hand, the resources of smaller vendors could be highly skilled but also in high demand, and in the end they will not have enough time to allocate to your project.

Recently I visited a company that uses a customized Microsoft Dynamics CRM system. The customizations are mostly done by a third party, i.e. their CRM supplier. Certain functionalities of this CRM system had started to work slower and slower. This affected their CRM usage so severely that certain daily tasks were impossible to complete. When the end-users do not use the system and they don’t enter any data to the CRM, naturally the system becomes useless and meaningless for the management and for the organization as a whole.

As in many performance issues in CRM, the first place to start looking for the cause of the issue is the database. In this case, database indexing was not implemented after certain customizations were deployed. The client company had specifically asked their CRM supplier to check the “basic stuff”, including the indexing. Of course the answer was that such a basic thing had been checked. However, running certain checks against the database revealed the issue immediately.

No vendor does this on purpose but so often the lack of time means that certain things are not done at all or are done in a great hurry. The vendor is of course responsible for this kind of negligence. But how should the client manage vendors to avoid these issues?

  • When the vendor has been selected and it is time to negotiate the contract, good management and judgment is needed. Do not trust the promises given in sales meetings: make sure that what you expect from the vendor, is clearly documented in the contract.
  • Be sure that the vendor’s team assigned to the project includes professionals from different areas.
  • The team on the client’s side, who works with the vendor, should include people with technical as well as business backgrounds.
  • Preferably a few of the client team members should have some experience of the system. This puts some extra pressure on the vendor, as they now know that their suggestions are not taken for granted without validation.
  • It is also extremely important to manage the invoices and contracts you receive from the vendor. If this comes to your mind later, as an afterthought, you have probably paid extra already.

What are some of the warning signs a client should be aware of when selecting or managing the vendor?

  • If the vendor’s solution is not documented, it’s your first wake-up call. Documentation is always left undone if the solution is implemented in a hurry.
  • If the client’s staff can’t maintain the solution themselves, something is probably not right or the KISS (Keep It Simple, Stupid!) principle has not been followed in implementation.
  • If you are running a huge, global enterprise system, it is probably not a good idea to deploy a customization from a vendor, who doesn’t have experience of a system of that scale.
  • When a generic implementation is deployed to a system that has other customizations affecting each other, it should not be taken for granted that the implementation performs well in all scenarios. In some cases, even a small change in data structure could have unexpected effects. So make sure that the vendor has deployed the implementation to similar systems before trying it on yours.

If something goes wrong in spite of all, it is a good advice to consult a third party. Just to have one fresh pair of eyes to check the situation.

The writer is Cloudriven’s Chief Deployment Officer, CRM Architect and an ironman, who is practically invincible in any sport you can imagine.