A Proof of Concept is a critical first step leading to conceptual development or implementation of new concepts and capabilities. They can be extremely useful tools to demonstrate if and how vendor solutions may fit client requirements and allow project teams to proceed through vendor selection processes. The methodology outlined below not only helps build the core foundation for any successful POC but helps align the effort into existing client vendor processes making for smoother transitions and implementations.
The definition of Proof of Concept is pretty well understood: utilized in most vendor selection processes, a POC is designed to demonstrate feasibility of a proposed idea or concept to solve a business need. It helps identify potential technical and logistical issues which could interfere with meeting success criteria but also provides an opportunity to gather feedback on the product/service while mitigating risk by providing decision choices early on in a development cycle.
While this TIP focuses on the core framework (activities, deliverables, and considerations) necessary to perform a successful POC, it also encourages readers to place additional thought in Proof of Capability, a lesser used term, but equally important when trying to focus attention on the feasibility of specific capabilities within an approved or already successful concept. Knowing a client’s needs and expectations surrounding a POC will help identify whether a proof of concept or a proof of capability discussion is more relevant and which should be used to gain traction in a vendor selection process. The methodology outlined below has been developed for either POC method.
Step 1: Define
- Organize initiative team, owners, and any key stakeholders
- Collectively define goals, inputs, objectives, scope, and success criteria
- Establish resource commitments and finalize a POC schedule
- Deliverables in the ‘Define’ phase should include: detailed POC Scope and Plan Documentation, Success Criteria, and a POC Schedule
Step 2: Develop
- Create POC-specific use cases for minimal but necessary functionalities within the POC scope (for proof of capability initiatives, align use cases to each capability in scope)
- Work with stakeholders to prioritize functionalities across the use cases
- Deliverables in the ‘Develop’ phase should include: Use Cases, Success Criteria (revised based on preliminary findings throughout this process step)
Step 3: Engineer
- Configure and test the required infrastructure and software, and test to replicate the operational environment
- Define solution steps for use cases and implement the POC solution build
- Deliverables in the ‘Engineer’ phase should include: Solution Design, Implementation Plan, Success Criteria (revised again based on latest findings)
Step 4: Execute
- Create test design for use cases and define positive/negative test scenarios
- Design and execute test scripts while recording results and information on failed or skipped tests or test case steps
- Deliverables in the ‘Execute’ phase should include: Test Cases, Test Scripts, and Test Results
Step 5: Evaluate
- Review and validate the POC results with all stakeholders
- Compare outcomes to success criteria in order to develop findings summary and present a lessons learned
- Gain alignment on a ‘move forward’ decision and develop full execution plan
- Deliverables in the ‘Evaluate’ phase should include: Evaluation Model, Finding Summary (w/ Lessons Learned), and an Execution Plan (if applicable)
The definition/exploration phase of the POC may be the most important step in the process. Ensure consideration of all elements/opportunities in the initial ideation sessions in search for vendor demos. Through the POC process, continue to refine requirements/success criteria and filter elements/opportunities through prioritization to an executed plan with defined internal/external capability roles.
POCs typically fall under vendor selection initiatives and while is important to determine a concise focus on scope, not every conceivable question needs to have an answer within it. Control these temptations by remembering the end objective of a POC is to gain ‘more forward’ decisions to inform an RFP, which will in turn lead to a strong SOW and translate into successful implementation. Vendor selection can be a disjointed and frustrating experience, but following the POC approach highlighted above utilizing the proof of concept vs. proof of capability where applicable and modifying your approach to focus on the end goal of the entire vendor selection process will ultimately empower the enterprise and provide value to every client.