Building partnerships: choosing a vendor that's right for you

Now that you’ve built a case for change, generated momentum and established your requirements, it’s time to put the company’s money where your mouth is. Read on to discover how to choose the best vendor for your content process transformation project.

Choosing the right vendor for your needs is not only about identifying the provider with the most fit-for-purpose software solution; it’s also about finding a good cultural and strategic match. This is not a mere transaction. You’ll need to work together closely towards a common goal so being able to form a good relationship is critical.

With that in mind, our six-step approach to vendor selection is as follows:

1. Prepare your own high-level solution design.
2. Create a longlist, then turn it into a shortlist.
3. Request proposals and assess.
4. Execute a vendor selection process.
5. Establish the rules of engagement.
6. Build and test a proof of concept.

1. Prepare your own high-level solution design

We know what you might be thinking: isn’t designing the solution the vendor’s job? Well yes it is, although usually with help from both you and the third-party integrator you’ve selected.

But in order to select the right vendor you need to give them as much information about your own systems environment as possible. That way you’ll both be able to determine how or even if their technology fits into your overall tech stack. For example, there’s no point talking to a vendor with a great cloud-based solution if you need to integrate a critical business application that can only be accessed inside the company’s network.

The solution design should include all existing legacy systems within the content environment with particular emphasis on the integration points and an indication of any plans to replace or otherwise modify systems within that environment.

Here’s what we would recommend:

1. Engage a business analyst. Have them review and validate the existing requirements and process flows.
2. Rank the functionality required and link them to outcomes. Use the benefits table you compiled in part one of this series to link each requirement to a desired outcome or benefit.
3. Hire a solution architect. They'll ensure the design meets all the requirements and that integrations are clearly identified. A far more detailed solution design will be done once you’ve selected your vendor.
4. Consider engaging a third-party consultancy. You have a business to run; IT consultancies can provide the high-level architecture and assist with vendor selection.
   
   

2. Create a longlist, then turn it into a shortlist

Even though we warned you against choosing solutions during the initial phases of the project, you wouldn’t be human if you didn’t already have your eye on a few products.

That’s fine. Simply write those vendors on a list – and then forget about them.

As tempting as it is to go with your heart, you’re not choosing which colour to paint the kids’ bedroom. To do this process right you should first cast your net wide. That means doing a full market review. In short: get Googling, read reports by technology analysts like Gartner and Forrester, and reach out to your contacts at other firms. Make that list nice and long.

Again, a technology consultancy can help you here, but bear in mind that such firms sometimes have supplier deals with vendors, so they may not be as independent as you’d like.

Once you have your longlist of possibles, you’re going to need to turn it into a shortlist of probables. The easiest way to do this is to draw up a checklist. Apart from the obvious things – product suitability, licence model, costs – you should also consider the vendor’s existing client base, its size and experience, how it’s funded and what its own long-term vision is.

Remember: your aim here is to cull the longlist, so a phone call or two with each should be enough to weed out the pretenders from the potential vendors.

 3. Request proposals and assess

The next step is to issue a “request for proposal” or RFP to all shortlisted vendors. The RFP should include the following:

1. A company overview. Who you are, what you do, what you hope to become.
2. A brief project overview. Why you’re doing it, what you hope to achieve, how it aligns to your company’s broader strategy.
3. Scope of work and deliverables. An explanation of what services are required and the desired outcomes. This should include your high-level solution design.
4. Technical requirements. Do you have any technological or infrastructure limitations? Does the company-wide tech strategy require use of certain platforms, coding languages or storage?
5. Ongoing support requirements. Will you require ongoing support?
6. Project timeline. Intended start date and finish dates and proposed phases.
7. Budget. If a “hard and fast” budget number has already been determined, share it. In the absence of such a number, you should at least provide a range, allowing vendors to quickly bow out if they know they can’t deliver for that price.
8. Criteria for selection. A list of the yardsticks by which potential vendors will be measured.
9. Proposal timeline. RFP response due date and review and decision timelines.

To assess RFP submissions we recommend using a combination of “yes/no” benchmarks plus some kind of weighted scoring system applied against the responses that require a more subjective assessment. ITtoolkit.com has some more useful detail about how to assess submissions.

4. Execute a vendor selection process

Invite the three highest-scoring vendors to present a live demo of their software solution. (And it must be live; do not accept anything out of a can.) A demo will give you a better idea of the suitability of the software and the opportunity to dig a little deeper into the technology.

The meetings will also give you the chance to get to know the vendors better and interrogate them – politely, of course – on some of their RFP responses. Do they really understand your vision? Do you feel like your companies can form a working synergy? Is the presentation professional and in line with their RFP?

If the presentations are not successful or raise concerns you ought to consider inviting the lower-ranked vendors to demo. If they are also unable to provide satisfactory presentations then you’ll need to revisit your longlist again.

5. Establish the rules of engagement

Now that you’ve selected your vendor, you should formalise the guidelines governing division of labour and how the relationship is to be managed:

1. Who’s doing what. This ought to have been made clear during the RFP process, but formalising it is essential. Who’s handling project management? What about training, change management and deployment resources? Who’s going to produce user guides and manuals?
2. Negotiate all costs up front. If payment is milestone-based, what are those milestones and what does success look like?
3. Chain of command and escalation procedures. Who are the project leads, both business and technical? Who are the primary decision-makers? Does the project require after-hours escalation protocols?
4. Contacts and comms. Publish team members’ contact details centrally and agree on communication platforms (email, Slack, WhatsApp) and update frequency.
5. Document management. Who is responsible for document management and where and how will they be stored?
   
   

6. Build and test a proof of concept

Before leaping from blueprint to live technology environment, there needs to be an in-between stage – a kind of proving ground where you’re able to verify the vendor’s ability to deliver. That’s what a proof of concept (POC) is for. A POC is a prototype that the vendor builds to prove that the proposed solution will work. It should test not only the technology but also the capability and approach of the vendor and validate the working arrangement.

Here are some tips for ensuring an effective POC phase:

1. Allocate enough time and resources. Don’t do this on the cheap. Be prepared to devote substantial time and consider backfilling roles.
2. Make sure the POC uses real content. No point trying to validate with dummy data; use live data duplicated into a test environment.
3. Forget about aesthetics. Doesn’t matter if it’s ugly, it’s just gotta work.
4. Aim for a fully integrated testing environment. If that’s not possible, test it in principle and document fully.
5. Form a testing group and provide training. Include SMEs and people you have identified as likely to be positive and objective contributors to the change process.
6. Build proper test cases with outcomes. Ensure the steps are clearly identified and that you know what success looks like.
7. Follow the intended content workflow. Look for inefficiencies – waiting times, double-handling, motion waste – throughout the process.
8. Run surveys of every session. Capture the good and the bad; have a team meeting post-POC to review the feedback.

If the POC does not deliver on the vendor’s promise or shows that the working relationship is such that successful project delivery would be unlikely, then you should be prepared to stop the project, reevaluate and find a new vendor.

Conclusion

It’s not entirely correct to say that your ability to work with the vendor is more important than the product itself – but it’s a photo finish. Building a strong and productive working partnership – a sustainable collaboration based on a shared vision and mutual obligation – is critical to the success of your content process transformation project.

To ensure you set yourself up for vendor-selection success you should first ensure that you’ve gathered your requirements and created your own high-level solution design. From there, having done a full market analysis and created a longlist, whittle it down to a shortlist and issue each potential vendor with a detailed RFP.

Then, using assessment criteria and a scoring system, rank the proposals and invite the top three candidates to present a live demonstration. Once you’ve chosen your vendor, immediately set the ground rules and begin working on a proof of concept.

And then the hard work really begins.

 Read our final installment of this series here: On target: how to ensure successful project deployment

Read More about our Complete guide to running a Content Technology and process transformation project.