This blog post introduces guidelines that are useful for a successful Proof of Concept (PoC). These guidelines are meant for a PoC project. Guidelines can be used when implementing PoC as part of the ongoing development. 

A PoC project is a short term effort, whose purpose is to find evidence of feasibility - proof of concept. Decision making is easier when there are proofs that a concept suits for the purpose it was planned for. Also, lack of proof means that the concept does not suit for its intended purpose.  Guidelines which are introduced here have successfully been used in Brightly to deliver successful PoC results.

What is a Proof of Concept?

Proof of Concept (PoC) – a phrase that gets thrown around a lot, but ask ten people what it means, and you'll likely get ten different answers. The only thing everyone agrees upon is that a PoC should show if an idea (concept) has potential and can work in practice.

For example, Oxford Languages (via Google Dictionary) defines proof of concept as “evidence, typically deriving from an experiment or pilot project, which demonstrates that a design concept, business proposal, etc. is feasible.” Merriam-Webster Dictionary’s definition is more vague: “Something that demonstrates the feasibility of a concept (such as a product idea or a business plan).” The latter citation is used also in the Wikipedia article of Proof of Concept. 

In essence, a Proof of Concept (PoC) is the evidence of feasibility obtained via a short term effort or project. The proof has two parts, evidence and feasibility, which need explaining. 

The evidence is found through experimentation. An experiment can be a demonstration or an example application created specifically to provide evidence. Evidence can also result from actual product development, for example from a pilot project. How the evidence is gathered, whether through experimentation or other means, depends on the goals of the PoC project. 

Feasibility can be tested to find evidence from different perspectives. While technical feasibility is in focus of a technology PoC, there may be other things to be considered. Feasibility can mean, for example, that there is a market for the concept, or that the organisation has the needed resources and know-how to implement the concept. In many ways, feasibility means that the concept itself is desirable among the potential users, customers and employees. Not every aspect of feasibility is needed to be explored for a PoC, although the PoC may be used to evaluate feasibility on aspects which were not in focus. 

Proof of Concept (PoC) can be defined as follows:

• To prove a concept, its feasibility can be tested from technology, organisation, desirability, or market point of view.
• Evidence of feasibility, the proof, can be found by experimenting with the concept or by other means such as piloting.
• Providing evidence is a short term effort or project.

1. Define Goals, Schedule and Budget

Finding evidence of feasibility means exploring the unexplored. Setting goals is important, because without a goal the effort invested to prove a concept can become too wide or too vague. Setting a goal is a collaborative effort of the customer and the vendor. The intent of a goal is to define the baseline of the PoC, for example is a technology stack or a service idea feasible. A clear goal, even a high level goal means that the vendor knows what evidence the customer is looking for from a feasibility perspective.

Providing proof of concept is a short term effort, so it is important to set the schedule and the budget. Schedule steers how much effort is invested to find evidence of feasibility. With the realistic schedule, evidence or lack of evidence for the concept can be found. Note that since you are investigating a novel concept, the PoC project is a success even if feasibility can not be proven.

Budget is another way to steer the PoC project to the correct direction. Budget effects schedule, development and test environments, like cloud tenants or hardware. PoC does not need complete development and test environments, unless the target is to prove that the concept is suitable, for example for a certain hardware. Budget can also be used to extend the goals if the initial goal has been achieved. You can, for example, find proofs for alternative solutions or technologies, or investigate new ideas emerging from the original PoC experiment.

2. Involve Customers Throughout the Project

Proof of Concept projects are an investment, which have a cost in time and money. Therefore there is a customer who is willing to invest in Proof of Concept because it is needed for decisions that affect future development.

Customer involvement is needed to keep the focus on the original goal. As you gain a deeper understanding of the concept you should refine your goals for best results. Goals can be changed or even removed, if they are not realistic compared to schedule and budget.

All clarifications and changes to the goals need to be sanctioned by the customer. The only way to achieve this is for the customer to be involved in the implementation of the PoC. By refining goals, PoC implementations can focus on meeting actual needs, rather than adhering rigidly to the initial plan.

Customer involvement can be from anything from daily planning sessions to regular review events like sprint reviews. Indeed, the effectiveness of customer involvement is not determined by the actual time spent, but rather by regular involvement!

3. Deliver What is Expected

The ultimate goal, when delivering a PoC, is to answer the question: "Is this concept feasible?” If this question is left unanswered, then the whole effort has been a waste. The question can be answered only by delivering enough evidence of feasibility. Evidence can be found by experimenting, for example using demonstration applications or test environments.

For example, a customer wants to test if a certain Internet of Things (IoT) architecture can be used with the chosen technology stack. This can be proven by setting up required technologies in the test environments and implementing demonstration applications. Implementation should prove that the chosen technology stacks can be used in the end product. Any deficiencies in the technology stacks should also be found, for example, a cloud backend is unable to receive the amount of data sent by IoT devices for any reason.

With clear evidence, it’s easy to make decisions. The customer should expect a certain quality of the evidence from the PoC deliverables. Expectations should be directed at the evidence and how they were found. The means and effort to find evidence should be realistic - you should rule out what is not expected to be delivered when defining the goals. For example any usability requirements of a demonstration application should be ruled out to avoid inconsistencies in expectations.

Expecting too much from a short term effort must be avoided. It is unrealistic to expect PoC to deliver, for example, a Minimum Viable Product (MVP), or even a software which could be used as a product base. The focus is to find evidence of feasibility with the least reasonable effort. This does not mean that MVP can’t emerge from a PoC, rather that it should not be expected.

Deliverables of the PoC must contain examples and documentation of the experiment. They are needed for the customer to replicate the experiment for further inspection. Replicating experiments  is important for decision making, and they also act as working examples for later use. Documentation should also contain information about conditions and extra work which were not directly proven, for example, when experimenting with integration options.

One of the most important deliverables is the end report, which summarises how the concept was proven and conclusions about the concept’s feasibility. The end report serves as a useful reference when making the decision of adopting the concept. The end report should summarise the PoC, including:

• Goals
• Setup
• Technologies and solutions
• Conditions and extra work
• Conclusion

TL;DR (Summary)

A Proof of Concept is a great way to support your decision making. Proof of Concept can provide insight about the feasibility of the concept from several perspectives: technology, organisation, and desirability.

Setting goals, schedule and budget means that the expectations of the PoC are clear and the effort is reasonably short term. Customer involvement throughout the PoC experiment allows flexibility when the knowledge increases and new ideas emerge. Delivering the PoC results need to be focused on the evidence of feasibility, and a good way to deliver them is the end report and documentation alongside the demonstration software.

A successful Proof of Concept has a simple recipe, which we use at  Brightly to provide our customers what they need:

1. Define goals, schedule and budget, and agree on the deliverables.
2. Involve customers regularly throughout the project.
3. Deliver what is expected, the focus is on the evidence of feasibility.

And for the least, the Proof of Concept is a great way to follow agile software development's fail fast principle: If the evidence of feasibility can’t be found with reasonable effort, the concept does not suit the purpose it was planned for.