How to Conduct Proof of Concept

A Proof of Concept (PoC) is the procedure by which a Team/organization tries to evaluate the tool’s fitment/usability by analyzing it on various parameters. Proof of concept is very critical in identifying new tools for organization, and so it is very important to conduct informal POC with a well-defined process, lacking a full proof process may lead to unproductive tool selection hence take POC lightly may result in financial/resource and effort loss. Let’s try to understand the process of conducting good proof of concept for any tool.

Step 1: Define clear objectives

Its very important to define clear goals before we start a proof of concept, its recommended to create an proof of concept plan document covering below mentioned areas:

  • POC Goal and Scope
  • List of benefits considered after successful POC
  • Tech resources required to conduct POC
  • Entry/Exit/Success Criteria
  • Define clear Schedule for POC or Timebox the estimations (Recently organization implementing Scaled Agile (SAFe) are using Enablers, Spikes or Hackdays to conduct the POCs inside the Agile Delivery schedule)

Step 2: Perform deep Analysis before proof of concept

Requirements analysis is critical to the success or failure of a proof of concept. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
Below are some important consideration for analysis:

  • Identify use cases for proof of concept
  • Minimum viable functionalities within the POC scope (for proof of capability initiatives, align use cases to each capability in scope)
  • Get consensus 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)
  • Solution Design, Implementation Plan, Success Criteria (revised again based on latest findings) )

Step 3: Setup Environment and Create Data

A testing environment is a setup of software and hardware for the testing teams to execute test cases, Test Environment consists of elements that support test execution with software, hardware and network configured. Test environment configuration must mimic the production environment in order to uncover any environment/configuration related issues. Environment is one of most critical factors to get success with POC/test automation:

  • Environment should be replicate the operational/production environment
  • Test environment should consist of production like test data
  • Ensure all integration points to the test environment are functional

Step 4: Start hands-on with ta ool

After requirement analysis and environment setup, it’s time to start evaluating tool by creating some real time scenarios using it. Below are points to be kept in mind while performing hands on the tool:

  • Start test case creation for Business critical scenarios
  • Note down the challenges and issue while creating tests
  • Share the Test Cases, Test Scripts, and Test Results with team fore deep analysis
  • Check if the tool is easy to learn and adopt by involving non-technical team member in POC
  • Gather best practices for test creation and maintenance and check if the tool supports
    • Reusability
    • Scalability
    • Usability
    • Security
    • Compatibility
    • Backup of data or code
    • Multi-browser or multi-OS support
    • Concurrency/parallelism
    • Reliability
    • Reporting and analysis

Step 5: Evaluate the test results

After hands-on is completion one should evaluate the outcome of proof of concept with the team and compare the tool for organizational fitment (fi for the purpose), if tool fits then prepare for its adoption else search for better tool meeting your requirements.

  • Review and validate the POC results with relevant stakeholders
  • Compare outcomes to success criteria with the defined goal and publish the results
  • Provide a POC summary report consist of a comparative study of the tool and associated costing

If the tool passes the complete criteria, then define a path for tool adoption and transition plan consisting of:

  • Training: Training needs for the tool
  • Roll-out: Roll-out plan to the teams adopting the tool
  • Best Practices: Defining best practice and sharing it among the team
  • Evaluate: Monitoring the use of the tool and the benefits transitioned in the SDLC
  • COE setup : Implement a continuous feedback and improvement mechanism

Leave a Reply

Your email address will not be published. Required fields are marked *