Proof of Concepts

Is a realization of a certain method or idea to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential of being used. 

A proof of concept is usually small and may or may not be complete.

Benefits:

• Technical Validation
• Improved Practices
• Demonstrate the capabilities to deploy
• Assesses whether the solution should be deployed
• Helps determine whether the software is appropriate

History

One of the early definitions of the term "proof of concept" was by Bruce Carsten in the context of a "proof of concept prototype" in the column "Carsten's Corner“:

Proof-of-Concept Prototype is a term that (I believe) I coined in 1984. It was used to designate a circuit constructed along lines similar to an engineering prototype, but one in which the intent was only to demonstrate the feasibility of a new circuit and/or a fabrication technique, and was not intended to be an early version of a production design.

Use

• When prototyping, testing and validation to prove a particular IT solution.
• Software developers tend to do POCs instinctively when they experiment with technology.
• Entrepreneurs and start-ups demonstrate that a company or product is financially viable

Why

• A PoC generally should be done early in the development cycle or to sell a software concept. It is used to validate technical feasibility, helps identify potential stumbling blocks, identifies what a platform can or can’t provide, helps determine the scope and level of customization necessary to complete the project.
• The PoC can also help identify performance issues.  Generally, today, we assemble many of our applications / solutions in a “composite” fashion.  We’re re-using services, functions, etc. from other applications.  This re-use requires integration points.  It’s these integration points in our overall “context” that we’re vetting with the prototype effort.  While also validating assumptions regarding what the platform or framework can or can’t provide.
• The outcome is a technical feasibility confidence factor along with factors that impact overall scope and estimate of effort.
• This process reduces risk and helps build buy-in across the organization. This approach can be crucial to receiving a green light.
• It is the final validation of all of the research and decision making that the carrier has done to date and sets the stage for success.

How

1. Understand the Goals.
2. Limit the Scope.
3. Develop a Standard Routine.
4. Identify Unique Customer Challenges.
5. Properly Set Expectations.
6. Understand the Customers Environment.
7. Prototype and test.
8. Prepare for your Onsite Visit.
9. The Preparatory Phone Call.
10. Run through a checklist.
11. Spend Quality Time with the Customer.
12.  Follow up Call.
13. Define Next Steps.

Effective

• Identify mutual objectives and BANT (Budget, Authority, Need and Timeline) criteria upfront before you even start talking about the POC.
• Understand why the prospect or customer wants to enter into the POC – what are the business outcomes that they want to achieve throughout the POC.
• Eliminate or sideline the competition by highlighting your strengths and their weaknesses during the POC process
• Connect to your prospect's culture - understand the people and their personalities, their processes, how they measure success, and how they treat their vendors.
• Evaluate if the prospect is a serial technology shopper who puts vendors through multiple proof of concepts without ever making a decision, or their decision making process takes multiple years.
• Always, document the test plan including business objectives, technical requirements, individuals involved, key milestones, and conditions for a decision; and obtain sign off on a formal document from the economic buyer before starting the POC to avoid scope creep.

A graphic example:

<iframe allowfullscreen="" frameborder="0" height="270" src="//www.youtube.com/embed/TCDmZQjyyBQ" width="480"></iframe>