A NASA Scientist walks into…

A scientist from NASA walks into a local office supply store looking to purchase a 3D printer to print intricate 3D titanium parts vital for the international space station. A friendly clerk says that they don’t have 3D printers at the store, but they do have some ink jet printers that are “representative”.  The clerk demonstrates the inkjet and the scientist loves it. He is convinced that since the ink jet printer works, the 3D titanium printer must work as well. His problem is solved. He purchases four and then goes next door to Taco Bell for lunch.

A Demo and a Prayer

Surprisingly, people do go to Taco Bell for lunch and businesspeople also purchase mission critical business software with little more than a promise from a salesperson and a strategy based on hope.  They hope that the salesperson was telling the (whole) truth and also hope that even though they did not demonstrate the actual software doing what they needed it to do, they did promise it would work after the prospect gave them a purchase order.

It seems unfathomable that we still buy software this way. In talking with a colleague just yesterday I asked him why businesses don’t demand more proof from software vendors that their products will work as claimed.  He was spot on when he said that it is both a supply-side and demand-side problem. “Most software vendors aren’t set up to properly execute a Proof of Concept (POC) and most buyers neither demand them nor are equipped to execute them.”  I could not agree more, but it is a problem we all need to fix.

Billions at Stake

Corporations spend billions on software each year. It powers our tech and service-based economies. Vast corporate buying teams are formed to evaluate products. Stone-faced procurement agents and lawyers scrutinize detailed proposals and thick contracts. Complex spreadsheets are created to analyze the net present values of future cash flows. In the end however, it typically is left to the users to connect the dots and determine the equivalent of the question above; Can this ink jet printer print 3D titanium parts for a space station? Mostly relying on what they observed in an incomprehensible software demonstration. It is what we call “faith-based purchasing” and it happens in thousands of conference rooms every day.

Of course, the corporations are not just betting the cost of the purchase. Software can have profound impacts on vital processes like customer service and operations. If the software doesn’t work properly, the implications can affect customers, employees and other stakeholders, sometimes harshly. The real cost of software that does not work can inflict wounds that take years to heal.

A Better Way

There is a better way. Become a Missourian! Missouri is the Show Me State. It really is that simple. Demand that software vendors show you the software working in your environment with your documents, processes and data in a Proof of Concept project (POC). After having completed many POCs over my career, I have come to believe that a well designed and executed POC is an insurance policy for the software buyer (and for the software vendor too).

For those unfamiliar with POCs, they involve a project to prove the proposed value of software where one or more software vendors proving their software in a limited, but representative, real-world solution. Practical and realistic scenarios are created by buyers for the vendors to clearly show how they can meet the business, technical, process and cost needs of the buyer. The concept is simple, but can be challenging to execute We have some learned some best practices along the way and thought we would share.

How to POC

As corporate buyers look to buy software, the real question should not be “Will this work for us?”, but instead, “How can we provide evidence on the benefits of this solution?”.  At BRYJ, almost all of our new-customer projects start with a POC. It protects both the buyer and the vendor by ensuring that expectations are set correctly and then met, for all involved. Here are some high-level recommendations for your POC:

1. Avoid Free POCs: Free POCs are a challenge for both vendor and customer engagement. My experience is that customers pay little attention because they have little “skin in the game” and vendors look at POCs as money losing affairs that should be dispensed with quickly and with as few vendor resources as possible. The truth about free POCs is that you typically get what you pay for.  You need commitment from everyone involved to get at the truth. Recommendation: Avoid free POCs. Create a paid project with a project plan, milestones, deliverables… and hold the vendor accountable for providing useful data and results.
2. Decide What are you Proving: Most POCs (especially free POCs) are a lot of work with little actual data that proves anything.  POCs should start by establishing what it is you want to prove. It sounds simple, but it is definitely not.  Are you testing technical ability of a product to do X? Or perhaps, you are looking to ensure that Y costs are reduced without a reduction in quality? Perhaps it is about speed or customer experience. Recommendation: Establish clear, written expectations on what you are trying to prove with the POC and gain approval of all involved.
3. Determine How and What to Measure: It is equally critical that you determine how the POC will measure success or failure.  For our POCs we typically focus on technical, process and cost measures, but these will vary based on your goals. Of course, the technical aspects need to be objectively measured. But this can be difficult since most vendors are challenged by POCs. Be specific. For process measures, make sure that your business users can test and measure the implications for process speed and quality, at a minimum. Get your bean-counters in the room for the cost measures.  Make sure that the business case is built from actual data output from the POC. Recommendation: Design measurement into the POC. Be rigorous with your vendor in providing complete and clear data. Evaluate results carefully.
4. Get Help: Proof of Concept projects are not a walk in the park. With this in mind, consider engaging a company like BRYJ that has experience with POCs. At BRYJ, we have a checklist-based approach to POCs. We believe and have seen how a well-designed and executed POC can mean the difference between great success and utter failure.

We are proud of our work to end faith-based purchasing. We believe that customers should demand more from vendors and solutions. Vendors should be held to a high standard that ensures the promised benefits that the buyer needs to justify the purchase. We should all demand more than a demo and a prayer.

Let’s Talk POCs

If you would like to learn more about the BRYJ and our approach to POCs, please reach out to me at mike@bryjinc.com. Thanks for reading. Please consider sharing with your network.

Mike Hurley is co-founder and President of BRYJ, Inc. BRYJ, Inc. is a consulting and systems integration firm on a mission to help organizations with intelligent capture and digital transformation. Our team has been helping companies digitize their processes since 1997. You can follow Mike on Twitter @BryjMike or connect with him on LinkedIn here.