Design Thinking About The Vendor Selection Process

by Peter O’Neill, Research Director, Research in Action GmbH.

Way back in my first years working for an IT vendor, I quickly learned to schedule my vacations according to my marketplace. Common practice was, when customers (or those who I wanted as customers) went on their vacation, they first dumped some work on my colleagues and myself.  We’d receive a thick envelope (no Email in those days) containing a “Request for Proposal” or even worse (sounds so uncommitted!) a “Request for Information” — long, detailed documents laying out a series of specifications and functions that they wanted to see in our product. We would be expected to process and answer all questions and reply when they came back from vacation. Most RFPs were issued, especially here in Germany, during the summer months and just before Christmas.

I got the impression that creating these RFP documents, and then processing the vendor replies, was the main focus for many buyers. The later stages (presentation, demo, negotiation, sales) seemed to happen very quickly afterwards.

Of course, further work experience taught me that the famous adage that “70{9388bcb60c6488a42b9434699bbf55e32510a7f2522b97b882e05d0ad226590f} of IT projects fail” is very true and continues to be so. I would suggest that one reason for this is the above process. Many companies assume that the most important component of any process automation project is the vendor selection process (VSP). Once that’s done, it is easy sailing – just install it, configure it, (perhaps) train the users and run the system.

Well, I’ve now assisted many a client through their VSP and sat in on their meetings with potential suppliers to provide my input as “an outsider”. I trust that my assessment of the vendors’ offerings and potential to fit into their planned technical architecture was useful. But still, I’ve often left the meetings with the feeling that the client wasn’t really prepared for the full project.  I would notice that many aspects of the project were not yet thought through:

• No sample business workflows (much of which is outside the software they’ll buy)
• No profile of their potential users (devices, competencies, preferences)
• No sample reports or dashboards designed
• No prioritization in their list of requirements – all was equally important.

Process automation projects fail because of a bad fit between project solution and requirements. And when I say “project” I mean much more than the software product. The solution must cover the complete business scenario to be improved, which is usually only partly through technology – process and organization always need to be tuned as well.

I suggest that it is now time to reconsider the role of the VSP – it should not be “the means to an end” – better to turn it into the kick-off for a process transformation project.

In 2009, the Hasso Plattner Institute of Design at Stanford came up with the concept of “design thinking” which has been adopted by many IT organizations and software vendors as the basis for their development projects. The associated meeting/communications method, SCRUM, has now even been adopted by modern marketing departments. The Stanford School process proposes these steps in a project:

Empathize – Define – Ideate – Prototype – Test.

So here is what I envisage in a modern marketing process automation project:

• Empathize. Collect and describe the requirements based not on technical specifications but by describing real business scenarios – improved workflows that marketers care about. Include persona profiles and the desired “usage tone” (marketing- or IT-centric, advanced or casual user, terminology known or not, device preferred, location of task, reporting requirements, millennials!). A scenario documentation should resemble the briefings given to marketing agencies – not an RFP spreadsheet.
• Define. Based on the make-up of the user-team and other requirements such as integrations and services, you should be able to easily segment the vendors and arrive at a shortlist. Provide the scenario documentation to those vendors and gather their responses as a first selection phase. Allow them to be creative – they may even be able to propose process improvements that you had not yet identified.
• Ideate. Invest time here to engage with three to five vendors to explore how they would help you to automate the scenarios. If you want to restrict this phase, limit how many scenarios each vendor works on – one will probably suffice for you to form an impression of the vendor’s suitability as a business partner.
• Prototype. The people at Stanford would love you to be putting Post-It notes on the wall in this phase, but you should probably expect your vendors to be able to demonstrate how they would support your scenarios with their software. You should now be down to one or perhaps two vendors. As well as checking whether they have realistic expectations, also use this phase to observe how the project members will work together – vendor people with your colleagues but perhaps you are also bringing together colleagues who are strange to each other. Create a conflict situation by changing a scenario and see how all players react.
• Test. After selecting your technology provider, you now move into the project roll-out phase, which is usually focused on just one team, location or business area to generate success and then a more expansive roll-out. Continue to expect the vendor to treat you as a business partner and working to ensure your success.

The test phase should actually never end. Wise project managers will maintain a running, live doc of the business requirements, because they’ll change over time. Display it in a flexible and editable spot to allow you to constantly re-check what you need, and the costs associated with it.  Also, ask yourself periodically what can you cut? Or what hasn’t been used in months? Who is now using the software – is that different than initially assumed?

Something to think about the next time you plan an automation project.

Always keeping you informed!

Peter O’Neill