Using Professional Services Partners For DAM Implementations
I have recently been involved in a number of DAM implementation projects where third party professional services partners have been used by vendors assessed during the selection stage. These kind of hybrid commercial arrangements present potential risk management issues for DAM users. In this article I want to examine these more closely with a view to gleaning some practical advice for those who may face similar scenarios in DAM initiatives they may be participating in.
First, let’s get some terminology established. A Professional Services Partner (‘partner’) typically refers to an external firm who will take on implementation of a DAM solution. Implementation, in this context means configuring and setting up the DAM. Further services like training, developing metadata schema, data migration and integration with other solutions may also form part of the offer.
Implementation partners can go under a variety of other names, including:
- Value Added Reseller (VAR)
- Channel partner
Why are partners used for DAM implementations?
The use of partners to carry out DAM implementations has increased in recent years. Most DAM vendors now have a lot more clients than they once did as demand for DAM solutions has continued to be robust (despite the increasingly homogenous nature of most DAM platforms).
The fragmentation of the market across hundreds of competing firms means that DAM vendors face issues obtaining the kind of funding that might be open to firms in other less diffuse software sectors where revenues per vendor are far greater. As a result, DAM software companies are often under-capitalised and lightly staffed. Many find that they lack the available personnel to simultaneously deal with client implementations and continue development of their products. Using partners can offer a potential solution to this challenge, providing they can manage the arrangements skilfully and without alienating their end users.
Some vendors use partners exclusively for implementation on the basis that either it is cheaper for clients than getting their own personnel involved in client solutions. The argument frequently advanced is that this represents a form of ‘best of breed’ since the vendor is able to concentrate on what they are good at without diluting their offer. There is some merit to this position, however, an equally plausible commercial motivation is that using channel partners enables vendors to externalise the cost of servicing and managing implementation projects (which they might otherwise have to bear entirely on their own). As I will describe later in the article, this is perhaps the most significant risk for DAM users and I will explain how to spot some warning signs, in-advance so that the appropriate action can be taken.
Types of Vendor Partnerships
When I work with clients on DAM implementation projects, a number find the third party relationships between vendors and partners to be a cause for some concern. Procurement staff, in particular, are not keen on hybrid contractual arrangements because of their perceived higher risk and the complications of managing multiple agreements with different suppliers. In some cases, they have good cause to take issue with the approach, however, it is less the concept of using partners that is at fault and more the way in which the vendor and their partner have chosen to manage the relationship between themselves and the client.
Below I describe three common types of partnerships between vendors and professional services providers then assess the risks of each. They can be summarised as follows:
- The partner is a reseller of the vendor’s solution and owns the implementation project (aka a ‘Value Added Reseller’).
- The vendor and partner collaborate but there are two separate agreements: one in the form of a software licence or software service agreement; the other a professional services delivery agreements with the partner.
- The vendor is the primary contractor and uses a sub-contracted firm to carry out some or all of the implementation activities.
1. Partner as reseller (VAR – Value Added Reseller)
The VAR model is well established in technology markets and the nature of the arrangement is reasonably simple to understand. The client’s principal contractual arrangements are with the reseller who manages the implementation and who supplies the licences to use the software. Some specific risks with this approach are as follows:
- Usually the vendor’s brand will be more widely recognised than the VAR. In this case, while the vendor can appear to be a well-established business with financial stability and lots of customers etc, the VAR maybe much smaller and less stable. A risk factor is what happens if the VAR ceases to trade. Will the vendor step in and assume responsibility for maintenance of the solution?
- If the VAR has too much client work, the delivery model may not offer any advantage over a vendor who does not use partners (or at least assumes contractual responsibility for managing them).
- If the VAR ceases to be a reseller for the vendor, what happens to existing clients who have solutions they implemented using the vendor’s product?
This approach to delivering implementations is effective, but some clients may find it unconventional and perceive it as risky. That can be an unwarranted concern, however, I would advise vendors who use this model to recognise it as possible objection from some prospective clients and have some methods prepared to help mitigate these potential risks, even if they do not necessarily agree that they are valid.
A further issue which often crops up in the DAM market is where the VAR partner will decide to compete with a vendor whose products they formerly re-sold. This usually occurs if the partner also offers some related technology (e.g. Workflow, Web Content Management, Product Information Management etc) and they have needed a DAM for expedient reasons to secure business but subsequently decide they can implement their own product instead to increase their own revenue share. While this scenario is certainly not exclusive to DAM, it is a frequently observed truism that as soon as a group of software developers (or those who employ them) produce a search interface with a grid of image thumbnail results, they can persuade themselves that they have just developed a DAM system which can compete with the best of them.
Ideally there should be a symbiotic relationship between vendor and partner where they are both equally reliant on each other. In theory, this increases the risk for the client because there are two entities and multiple potential issues if either of them fails, however, in practice it makes it more likely that they will seek a mutually beneficial outcome since both depend on each other to survive and prosper.
2. Vendor and Partner Collaborate as a Consortium
This is a split arrangement where the vendor and a partner collaborate to fulfil a client’s needs, i.e. as a joint or consortium bid. The vendor provide the software licence, the partner(s) are responsible for the implementation project. These are the risks for this model:
- At least two separate contracts are required: one for the vendor and another for the partner.
- If there is a disagreement about who is responsible for some aspect of the client’s requirements then there is scope for both parties to point the finger at each other with the result that the client may not know which of the two entities will take ownership of a problem.
- Commercial failure of either the vendor or their partner may result in the client having no one to support the resulting solution. Similarly, if the partner decides to cease support for a given vendor, that could leave them without anyone to resolve implementation-related issues, even though the vendor still trades.
This model is popular with larger technology vendors (especially those catering to the enterprise market) because it limits their own legal responsibility and enables them to externalise potential issues. Whether it is as advantageous for DAM users is more debatable, however.
3. Partner as Vendor’s Sub-Contractor
In this case, the vendor calls in third parties to carry out implementation of the DAM, but as sub-contractors to the vendor. In some cases, the vendor might employ multiple partners to handle different facets of the project, e.g. for specific technical expertise. The main benefit is that the vendor assumes overall responsibility for delivery and can manage the delivery supply chain in behalf of the client.
Having the original developer retain ownership of the implementation project is theoretically lower risk because it is assumed the vendor knows their product better than anyone else and is therefore less likely to propose solutions which will be unfeasible to implement. This is not always the case, however and there are further risks to take into account:
- The vendor may choose partners who fail to deliver the required services that are necessary for the DAM implementation to be successful. Although the vendor has responsibility for finding an alternative, there will still be an impact on the expected delivery timeframe.
- There can be a lack of communication between the client, the vendor and their partner service providers. This might not be obvious until quite late into the delivery process when features do not work as clients expected them to.
- Those vendors that have origins in the creative/marketing industries (e.g. as agencies) can sometimes try to disguise the use of partners to try and make it appear as though they have all the required delivery skills in-house. That can cause clients to lack proper visibility of their DAM implementation supply chain and makes it harder to assess risks, especially those that might be increasing silently without any obvious visible signs.
One important recommendation I would make to prospective DAM users who are evaluating vendors is to determine early in the process exactly what delivery model is being proposed and whether partners are likely to get used or not.
A particular concern is when the vendor decides to switch from offering everything in-house to using a partner half way through an evaluation, especially if it is similar to the second approach described above where they will have no ultimate responsibility for what gets delivered. I tend to have a limited level of trust in those vendors who flip between wanting to deliver a solution themselves using in-house resources if it looks like it will be easy (or profitable) and who subsequently decide to switch the arrangement to using a partner if it looks like it might get more complex (i.e. less profitable).
There are some legitimate reasons why this might become necessary, but often it suggests they have begun to anticipate problems and want to retain the less complex element (the licence) but without actually wanting to get involved in the messier job of delivering a working solution that is fit for purpose.
Of the three models discussed above, my view is the final one (where the vendor assumes a primary contractor role) is probably the most advantageous one in terms of simplicity and understanding who has ultimate responsibility for delivery. With that said, much depends on both the nature of the vendor and the prospective partner. There are a number of highly skilled DAM VARs and implementation partners with decades of experience who do successfully service client requirements via the other two approaches. Discounting these simply because the commercial model is not an ideal one from a procurement perspective is short-sighted and can result in a contractual/procurement risk being exchanged for a delivery-oriented one.
The bottom line is that the model/route to market used by the vendor is important, but as ever with a complex subject like Digital Asset Management, it’s the people at the sharp end of the delivery work who tend to be the most significant determinant of whether a DAM initiative succeeds or fails.Share this Article: