The international community
for web and intranet professionals

Vendors vs. system integrators – whom to trust?

April 20th, 2009 by Janus Boye | , , , | 4 Comments

Share

TrustAs a customer it can be complex and expensive to work with both a software vendor and a system integrator. While neither might be downright lying to you, you need to understand the motives behind their recommendations; in particular given the important conflict of interest between two parties who both want as big a share of your budget as possible.

A recent critical blog on portals by Jon Marks, Head of Development at digital agency LBi, reminded me that customers need to watch out. The blog described a case where Marks ponders on whether two Vignette portal products were really necessary for a given customer. In the comments Marks provides a good example of the dilemma that system integrators are facing and the conflict between vendors and system integrators. I respect Marks’ work and recommend customers to follow his blog to get a very open and honest insight into the agency perspective.

Usually any software vendor will try to get you to buy more software, while a system integrator will typically recommend more consulting hours. I’ve seen many cases of the combination of vendor and system integrator gone wrong. The end result has been one of a disappointed customer and a vendor and system integrator pointing fingers at each other. To move forward, sometimes the vendor looses and gets replaced, while in other cases, the system integrator is replaced. Either exercise is an expensive one that in itself creates little value, at least from the customer perspective.

To avoid this mess, you may be inclined to consider working directly with the vendor and their professional services arm. Some vendors will encourage this, e.g. FatWire and Vignette, while others, e.g. Microsoft and Sitecore, will require you to work with a system integrator. In some cases it can be very effective to work directly with the vendor, in particular if you have key account status and a good working relationship with them. In other cases the vendor might know their product well, but not have enough experience with customer requirements and implementations. Finally, I’ve seen quite a few cases, where the vendor did not know their own product very well.

As always, the best way to minimize your risk is to build on your own skill set and exchange experiences with other customers. You may not be in a position to decide whether sufficient skills can be added to your web team, but you can always reach out and talk to other customers.

How do you find the right balance and figure out whom to trust?

Author

Janus Boye

Janus is based in Aarhus, Denmark. As founder and managing director at J. Boye, he has grown the business from an office at home in 2003 to a global operation today

  1. apoorv April 20th, 2009 9:33

    Good post Janus as always. I would like to bring in another angle. In most of our large implementations, content management is only a part of the implementation and so that means there are often multiple vendors involved (CMS, Portal, CRM, ERP, hardware, storage, and mush more). A single vendor’s professional service will never be able to handle this and this is where a good and transparent SI adds value. This could be by way of bridging the gap between multiple vendors, vendors and client, integration, requirement analysis that encompasses multiple technologies and so on.
    So if it’s a single product implementation, there is probably an “OR” but in a large implementation, i’d say there is an “AND”.

    well maybe i’ll write a larger post about the SI view point :)

  2. Philippe Parker @proops April 20th, 2009 9:33

    Completely agree with apoorv.

    In my experience most vendors are unable to deliver a full lifecycle project by themselves, particularly for web. Similarly, very few staff within a system integrator have the technical experience to manage a robust implementation to the vendor’s best practice. So the question is less “which of the two” than it is “what should be the balance”?

    In fact, within full-service agencies there’s often the same dynamic, as I’m sure McBoof will testify, where the experience and creative designers want to push an implementation in one direction, but the technical team are resistant due to technological limitations.

    I think the message to clients should be get people who understand your requirements and can explain the benefits of their proposed approach, whether they’re from the vendor or not.

  3. Jon Marks April 20th, 2009 9:33

    So much to say, so little time. Again, I agree with Apoorv completely. Most big projects do have multiple technologies involved, complicated by the fact they often overlap. For example, every vendor wants their product to also be the “lead” delivery agent – that is, they own the templates and aggregate information from the others. This fight even happens between products from the same vendor. For example (and there are many), it’s always fun having a meeting with someone from IBM Portal and someone else from IBM Commerce Server to decide which of those two should be boss.

    And I also agree with Philipe a.k.a. @proops. We agencies do need the vendor. Even for a product we know backwards, we still need insights into the development roadmap, the “classified” bug lists and the engineers hidden away in a basement somewhere. It’s dangerous to go it alone.

    The discussion about internal dynamics between the different departments in a Full Service Agency is something I’ll post about another time. But it is massive issue. I’m going to jump to the conclusion of my not-yet-written article and propose that a Fixed Price, Fixed Scope Full Service Engagement Makes No Sense Whatsoever. But more on that later.

  4. J. Boye » Blog Archive » SITATM: When system integrators take all the money April 24th, 2009 9:33

    [...] carefully strike the right balance between your vendors and system integrators. Ideally you should trust your system integrator, but that is not always a financially sound [...]

Leave a Comment

Read our commentary policy.