Getting a Project to the Finish Line – Six Drivers of Success You Can’t Overlook – Part V – Solution Fit

Part 5 of 6Leadership/Sponsorship

In the last installment of this series so far, I shared some thoughts a
round the importance of Target Employee Engagement. We’ve also covered the importance of Sponsorship, Organizational Relevance, and Communication to a project’s success. In 2015, NEOS did an informal, online survey where we asked experienced practitioners to rank order six reasons a project fails to deliver its anticipated business value. We’ve covered the “big 4” in these first few blogs…  and there’s a reason I started with sponsorship!

We’re updating this survey for 2016-2017 and would love your insights. If you’re of a mind to share, please click here to share your opinion! It will take a whopping 5 minutes of your time…

Moving on now to talk about Technology (or Solution) Fit. You’ll see that just 9% of our respondents cited the appropriateness of the chosen solution as the #1 or #2 reason a project fails to deliver on business value. This statistic surprised me when I saw it, because in my travels as a consultant, I have encountered many clients who aren’t using their purchased technology to its fullest potential. As I thought longer and harder about that, I realized that the reason for the under-use of expensive systems ends up being inadequate sponsorship and employee engagement, not the system itself. In fact, most companies have a robust procurement and system selection process that more or less ensures a decent vendor choice.

What constitutes a decent vendor choice, and what should you have in your procurement/system selection process? Here are my top three answers to those questions, and I invite you to share yours in the comments.

1. When you start on the search for a new system, start by identifying your “knock out” criteria or questions. Is there a back-end data store with which the new technology must integrate? What functionality absolutely has to be part of the solution? Are there any aspects of a solution that would immediately disqualify it (e.g., financial viability of the vendor)? Issue an RFI to a wide range of potential providers and get them to respond to these knock out questions. Only when you’ve narrowed your vendor list to a manageable few should you issue the detailed RFP. This saves you wading through detailed responses from vendors who should never have gotten past the starting line. It also eliminates distractions.

2. Prioritize cross-functional criteria for your RFP, and ask vendors to respond to specific open-ended questions in their submissions. We’ve got a whole whitepaper that covers the art of writing an effective RFP, and one of the main recommendations is around question writing. Include representatives from all functional areas, and give equal weight to their voices. It’s all too easy to make an emotional decision (yes, it is) because someone falls in love with one of the solutions but, on paper, it fails to meet the highest priority criteria.

3. Choose a vendor whose people and tools mesh well with your company’s people and culture. (The best selection committees make this one of the knock out criteria way back in the RFI stage.) I’ve seen small to medium sized companies choose a behemoth core system or workflow vendor and end up being too small to register on the KPI dashboard of the behemoth, or they falter under the weight of the solution and never install it. A well-vetted smaller provider that is financially sound and has proven installations may be a better fit for you than the industry-dominating Magic Quadrant leader.

It goes without saying that the business case for the solution spend must hold up regardless of vendor personality and RFP responses. Avoid over-buying/building (or, less commonly, under-buying/building) by having a firm grasp of your prioritized requirements and keeping the right voices at the table. There’s no perfect fit when it comes to solution choices, but you can greatly increase your odds by following a few best practices.

The next blog will (sadly) be the last in this series. We’ll talk about the wonderful world of Program Mechanics, which is where most people start when they want to know why their programs are yellow or red instead of green.