Shifting to Software-Defined
Showing results for 
Search instead for 
Did you mean: 

Anatomy of a successful Proof of Concept


In the current IT subscription economy, the ability to easily acquire, install, and use new solutions has created some complex situations.  Organizations can spend their time churning with multiple Proofs-of-Concept (POC’s), endless trials and deployments that never quite hit the mark. These failed attempts tend to show the symptoms of an initial POC that had undefined objectives, unclear use-cases, and lack-luster alignment of business-needs to POC approach or implementation alignment.

The anatomy of a successful POC is business-success oriented, and includes a clear plan and a structured testing process. A successful POC is tied to well-documented use cases that directly correspond to business-success-metrics. The requirements for a successful POC don’t change depending on the type of POC:  Private Cloud, Hybrid, or a Network Function Virtualization (NFV). These efforts should never be just an extended solution demo.

In HP’s New Style of IT, POC’s do more than just show-off Software functions. They aim to validate customer real-world use-cases and help customers align business-success-metrics to staged technology implementations. This alignment of business goals, revenue metrics or strategic drivers to best-of-breed implementation practices is the key to achieving pre-production-like POC’s.

In my experience, the anatomy of successful POCs has always included definitions within four general categories:

  • POC Focus or Charter
  • POC Plan
  • Execution
  • Conclusion

The overlay of business-success metrics, with weighted early-success and incremental-success through use-case iteration and integration, ensures POC return on investment and alignment to time-to-market targets for business leaders.  The amount of detail or granularity within these categories depends on the approximation of real-world criteria, the length of the POC, and the integrated-complexity of the POC.

The POC construct can have a sliding scale of business requirements, can iterate (on/off premise or hybrid) and the length can vary from a few weeks to a couple of months. The length of a POC is directly proportional to the number of use-cases, “real-world” business characteristics or near pre-production validation of the enterprise solution. A DevOps-like approach for POC’s can be structured with first-milestone success building and must-have business-outcomes that are validated in use cases through Agile-like POC sprints. Each POC sprint delivers pre-production functionality and articulates outcomes tied to business metrics.

Short POC’s, example a one-week or two-week POC, tends to be an off-premise simulation for a pre-configured set of use-cases with pre-defined conditions and configurations to showcase solution alignment to enterprise needs. The general intent is truly a quick “proof – of – concept” before further business investment is made toward New Style of IT solutions. This type of POC aims at validating IT-services to a subset of business metrics. These short POCs are a good fit to determine quick functional criteria and enable a contrast between current-state and potential future-state(s).

In contrast a customized POC, usually runs longer than three weeks, can have on-premise or hybrid structure, include configurable use-cases, as well as perform real-world emulation and validation of IT-services aligned with business-outcomes. This configurable scale of pre-production activities allows organizations to easily iterate and integrate from POC to production environments in a DevOps approach. The depth or granularity within the four categories (POC Focus or Charter, POC Plan, Execution and Conclusion) can also be iterative but a focus on first-milestone success and outcome-articulation must be integrated within each POC-sprint. Decisions to release pre-production POC implementation to light house usage or limited audiences are easier with clear alignment to business drivers and end-customer-success.  

The Four Categories - Anatomy of a successful POC


Charter, Focus and Background

The Focus or Charter for the POC is one of the key areas that defines “success-criteria” for the POC efforts and follow-on iterations. As part of this category, the business case for POC-investment is aligned to the POC. The sponsor details the funding approach, the time and/or scheduling and the dedicated resources to Plan, Execute and Conclude/Report the POC with integrated business-outcome articulation.

Generally speaking when use cases increase in business value, the associated validation planning, testing and resource allocation will increase proportionally. When documenting the Focus and Charter of the POC, it is important to also address the “why”, as it will provide alignment to success-metrics:

  • Reduce risk or manage-risk of true production implementation
  • Reduce cost and effort of true-implementation by validating use-cases and assumptions
  • Align to real world conditions and operational or maintainability challenges
  • Evaluate inter-operability of solution components with existing disciplines or processes
  • Establish baseline for investments in people, processes and technology aligned to future-state
  • Deliver higher quality through tighter tech-alignment and by putting lessons learned early into POC
  • Reduce time to market by showing parallel implementation components or savings


Additionally the Charter category may include a paragraph on the background or relevant information about source and target operational models. This level of granularity is not always required, but it may be helpful in defining the POC governance structure and associated business rules to define required vs. nice-to-have features/functions. The governance model (or at a minimum business rules) for change management by any stake-holder, business customer or steering committee needs to be documented. The key is also to document the POC exit options for specific high-visibility business requirements, with governance oversight and re-entrance options included.


The Charter category should conclude with clear definition of POC-dedicated resources and a solid communication plan. A successful POC also addresses the knowledge transfer plan and gives up-front examples or samples of data or reports that are expected. This “base” of information provides the guidelines for the detail within the POC Plan and Execution Categories—as well as final Report and POC migration towards pre-production. This also helps clear the hype around POC and helps differentiate between required functions with business outcomes and those “would like capabilities” that have an unclear line to business drivers. It is important to actively manage Private Cloud POC scope creep and use this opportunity to also assess internal Resource Capability vs. Discipline or supply-chain gaps.


POC Plan

The POC Plan Category is well-suited for an iterative approach based on POC sprints. Each POC Sprint needs to be formatted with Early Win and clear use-cases, business success criteria and outcome-articulation. The POC sprints can iterate from low-complexity with a sliding-scale to include more use-cases and also into Pre-Production delivered business-capability. The “success-criteria and outcomes” need to be articulated and communicated to POC audience, and as a result the POC Plan granularity may need to include:

  • Communication to POC plan tie for both internal and external, as well as vendor-management
  • Governance plan with steering committee and scope management or new-POC-requirements
  • Business-Consumers and Audience of Cloud/NFV services
  • A clear definition of Stakeholders for POC
  • POC Exit Options or specific high-visibility requirements
  • Identify key-participants for the POC that are involved beginning-to-end: security, networking, storage, project management and analysts at a minimum
  • Establish use cases with “must-have” evaluation criteria weighting security and networking
  • Ensure the definition of Testing Process, Test Plans and Test Cases covers all use cases
  • Vendor or vendor-partner support for Test Process
  • Specify business-drivers and associated costs to deliver consumable service to the target customer—whether internal or external
  • Establish realistic traffic, load, performance and UX usage criteria or requirements
  • Establish decision making processes and stakeholder “voting” of modifications/compromises


POC Plan Category should also include POC-accelerators within POC Sprints (where applicable):

  • Pre-develop Test-Diaries and Checklists for testers and end-customers to capture:
    • Findings and extra criteria
    • Unexpected results
    • Work arounds and specialized conditions
  • Implementation Recommendations and associated pre-deployment checklists
  • Results capture of both RAW and summary information tied to criteria weighting
  • Lessons Learned and documented GAPS, Limitations or pre-requisite configuration options


POC Execution

Execute a comprehensive POC testing and validation based on POC Plan Category methodology with structured and formalized testing process. The aim is to balance hands-on testing experience with the validation of use-cases and performance testing as defined in POC sprints.

POC Execution should focus on early-successes and build proof that the solution works effectively and efficiently at real-world performance levels:

  • Weighted and Prioritized POC sprint execution of use cases and business requirements
  • Manageability, maintainability and operations with ongoing staffing costs
  • Delineate the implementation of specific requirement : security, networking, analytics, storage
  • Review auditing/compliance components for different frameworks: PCI, CSA-CCMs, HIPAA
  • Performance and physical constraints of reference size, power consumption, associated costs
  • Balanced score card that ties together the weighting of use cases and business drivers
  • Standardized validation rules with quantitative tests based on documented pre-conditions, pass/fail criteria and post-test level set
  • Incorporate “ease-of-use” or configurability requirements and match against consumer-expectations and existing tools or interfaces
  • Result tables that have direct plug-ins for test-plans and test-cases (with attached RAW logs) to facilitate in-flight and conclusion reporting
  • Capture complete snapshots including performance metrics (CPU, bandwidth, memory, etc.)
  • Additionally assess the experience of your system administrators, operators and consumers as part of the POC


POC Conclusion and Results Articulation

The POC Conclusion category is one of the key areas within the “The anatomy of a Successful POC”. The planning of the artifacts in this category is directly linked to the POC Charter and is one of the key delivered-values that articulates business-success to the overall POC. The POC Conclusion and Articulation needs to be iterative as well as at the end of the POC section as capabilities are moved into enterprise production environment:

  • Knowledge Transfer within a Devops model
  • Articulate results in terms of business-outcomes and next-steps
  • POC sprint outcomes, POC Final Report and POC Balanced score card
  • Syllabus with domain specific terminology and mapping to internal nomenclature
  • Identify Re-Use and future change-management requirements
  • Identify new-functions or requirements that are found to be important
  • Pre-Production presentation and demo showing key findings, processes, business-outcomes linked to validated use-cases for PRODUCTION, and future options

Additionally, successful POC may include external reports and parallel effort validation linking key use-cases and POC-concepts and POC-outcomes with vertical-insights and competitive-insights. This can enable pre-production POC’s and staged solutions to be integrated with business-success milestones and market conditions and may spawn potential future usage models or future POCs for customer-extensions.

About the Author


June 18 - 20
Las Vegas, NV
HPE Discover 2019 Las Vegas
Learn about all things Discover 2019 in  Las Vegas, Nevada, June 18-20, 2019
Read more
Read for dates
HPE at 2019 Technology Events
Learn about the technology events where Hewlett Packard Enterprise will have a presence in 2019.
Read more
View all