Design Thinking in The Vendor Selection Process

Many years ago, working at HP, I quickly learned to schedule my vacations according to the marketplace. Common practice was, when customers (well, prospects) went on their vacation, they first dumped some work on my colleagues and myself, sending us 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’d be expected to process/answer many detailed questions and submit a response when they came back from vacation. Most RFPs were issued, especially here in Germany, during the summer and just before Christmas. 

I got the impression that creating these RFP documents, and then processing the vendor replies, was the main event for many buyers. It wasn’t necessarily about picking the right solution. The later stages (presentation, demo, negotiation, sales) seemed to happen very quickly afterwards.

Further work experience also taught me that the famous adage that “70% 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. There were often: 

• 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 needs 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 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