How to create a Proof of concept your clients will love?


We often come across a term called Proof of Concept in the Software Industry. Most of us have either been a part of such projects or have managed such projects. But let’s look at the following questions:

What exactly is a Proof of Concept?

How do we manage such a project?

To find answers, let’s break down the “Proof of Concept” clause first and then pick up each item.
Proof: evidence or argument establishing a fact or the truth of a statement.
Concept: an abstract idea

1. What exactly is a Proof of Concept?

In the Software Industry, PoC is a demonstration with the aim of verifying that the idea has practical potential. It can be proof of one technology talking to another or an aim to determine the solution to some technical problem or to demonstrate that a given configuration can achieve a certain output.
Blindly doing something because a potential client has asked us to do might put us in a tight spot during the actual project execution if the idea itself does not resonate with any practical purpose towards a solution.

2. How do we manage such a project?

A PoC should clearly define what needs to be achieved and to what level. For example, it may not be sufficient that communication happens between system A to system B if the complete solution calls for the use case to run in certain conditions along with non-functional requirements. For PoC as well, Testing is required under certain conditions. They are certainly more than simple “ Hello World” program.

There are 4 aspects to consider while planning and executing any project like this:

1. Effort and duration of the PoC.
2. Project scope
3. Choosing the resources
4. Finalizing Acceptance Criteria

Effort & Duration: Typically a PoC should not take more than 2 weeks to be executed as then it becomes something more than a proof of concept.
We should also have 2 people working on POC so that 2 brains can work on thoughtful evaluation without any personal biases towards a certain technology or a solution.

Project Scope: It is important to make sure that you are defining the scope that’s actually well-suited to the concept, otherwise it is a recipe for getting skewed results. Restrict the scope to find a resolution of a specific problem rather than trying to get everything done.

Choosing the resources: Care should be taken to ensure that the people taking part in the PoC represent the right mix of skills in order to make the project as successful as possible. While having a person to work on completely new technology is okay but there has to be someone who can mentor and guide the POC. In the absence of which, it becomes a Research without having any tangible endpoint.

Finalizing Acceptance Criteria:

  • -Ask questions to the client.
  • -Do your best to lay out these questions at the outset of your evaluation, based on some defined goals for the project.
  • -It is important that once PoC development effort has completed you re-focus on the high-level goals in a practical manner.
  • -Non-functional considerations will generally be ignored unless specifically requested.

The following items should be kept out of scope and stated explicitly unless asked for:

  • -Re-usable code
  • -Scalability
  • -Usability
  • -Backup of data or code
  • -Security
  • -Compatibility
  • -Multi-browser or multi-OS support
  • -Reliability
  • -Documentation
  • -Concurrency

Google Certified Agency

about the author