Testing the Waters with a Proof of Concept – Part One

Part One – What is a Proof of Concept?

Trialing new IT systems as part of a Proof of Concept (POC) is a good way of reducing the risk of overall projects by allowing the customer to:

• Ensure they will be getting the functionality they expect to be delivered
• Experience what its like to work with the system vendor and get a feel for how they respond under pressure, how responsive they are to requests and how well they understand what is required.
• Identify and highlight gaps that can only be uncovered based on working with the system over a period of time.

In recent client engagements, we have been involved in several IT systems implementation Proof of Concept (POC) projects and while these projects have involved many similar activities, they have had different purposes, process roles and outputs.   Most notably, the main difference is the purpose.  Some argue that a POC “must be” a milestone in the implementation plan, others argue that it is a valid step in vendor selection and not part of implementation.  So who is right?

Neither.

As long as the purpose, process and roles are clearly defined, conducting a POC either as a part of vendor selection or as an implementation milestone is equally valid.   What is essential is the agreement of the purpose of the POC between the vendor and the customer as well as the communication of the purpose, process, roles and responsibilities and deliverables to the evaluation team and the business.

 What is similar?

Whether conducting a POC as a part of vendor selection or as an implementation milestone, the POC should:

• Be conducted at the customer’s premises
• Involve end-users as well as members of the evaluation team to ensure that there is business buy in

What is different?

There are two scenarios where a Proof of Concept is appropriate:

1. Scenario 1:  As Part of a Vendor Evaluation Process:  After conducting a cut-down evaluation of system vendors, the customer has narrowed the field to one or two likely candidates and ask them to be involved in a Proof of Concept.
2. Scenario 1:  As an Implementation Milestone:  In this scenario, the customer has already gone through a procurement process and selected the vendor involved in the Proof of Concept.

The two Proof of Concept scenarios need to be structured and managed differently.  There will be different working relationships and underlying assumptions between the customer and vendor depending on which scenario and circumstances are chosen for the Proof of Concept.  It is therefore essential that all stakeholders understand which scenario is being used and agree on a common set of inputs, outputs, and possible consequences from the Proof of Concept.

We’ll talk about how to structure a POC for these two scenarios in our next blog posts.