Defining a Proof-of-Concept

  • Josh Hooks

March 15, 2014

When potential software buyers are evaluating different options and third party solutions, they typically brainstorm and refine a long list of required functionality or performance concerns that must be addressed by the software in question. One of the first tools identified to resolve these questions is the formal proof-of-concept (POC.) Here is some food for thought when planning your next POC.

Before I go too far, let me provide some context. In this case I’m referring to a software deal that depends mostly or completely on the successful completion of the POC, so the stakes are about as high as possible for the vendor. Potential buyers must gain a reasonable amount of certainty that their use cases can be satisfied. A decisive outcome is the critical component to any well-run and executed POC, as there may be subsequent evaluation activities to consider. Without these constraints the POC is just an informal exercise to verify some requirements, and can be handled differently.

What are some of the key elements to a decisive outcome?

  • Decide whether functionality or performance is more important to your situation. Usually both cannot be optimized in a short timeframe with a limited team, so be pragmatic with your choice and run with it.

  • Identify a clear set of achievable and practical goals(if you use an agile approach this will be similar to any normal acceptance criteria). The team will more easily understand their mandate and have a better chance to meet expectations.

  • Explicitly define what will not be done to avoid any confusion. In many cases less important functionality can be deferred to the development phase, with the possibility to use an in-sprint spike as a way to prove it out.

  • Don’t expect to rely upon the POC code as production-quality. Successful POC code may be mined for reuse during the project itself, but only with additional coding and testing iterations.

When POCs don’t work well, too much scope is included initially, and the team tries to boil the ocean of requirements they are given. Uncertain results ensue and ultimately delay the business value of the entire initiative. Don’t let this happen to you!