A Proof of Concept (PoC) is a high-value component of software development projects.

It’s a time-bound, fixed-scope exercise that tests the feasibility of a technical concept using measurable goals and success metrics. PoCs act both as a way for organisations to discover and learn about new technologies, and a way for organisations to manage the risks associated with exploring new technologies. However, as with any project, PoCs entail inherent limitations and pitfalls that can create cost, time and resource implications. Here’s my top 3.

1. Lack of business readiness.

One of the main pitfalls with a PoC is the inability of the broader business to adapt to the new capability it demonstrates. In practical terms, this can mean that a level of business transformation is often required beyond the original scope of a PoC, to adopt to a new technical system or process. It may be as simple as individual employees changing their workflows, or as complex as reconfiguring multiple business units. This can lead to a sort of ‘false positive’ from a successful PoC: the concept may be technically feasible, but broader adoption may present obstacles.

It’s vital to consider business process change when implementing a PoC into production, and is a crucial consideration in how an MVP (Minimal Viable Product) should be scoped.

2. Defining the wrong success metrics.

Technology is just a tool. Selecting the right tool for the right job is dependent upon having identified the right job to begin with.

Creating a PoC to answer a broad technical question - rather than applying technology to identify a specific business question - is a common pitfall. Consider the statement:

“Let’s see if we can use Machine Learning in Azure to help our business”

This is a difficult thing for a PoC to prove as it has no clear outcome, and it pre-supposes that Machine Learning is the right tool to solve this undefined need. Instead, we could add clarity to our goal by reframing:

“Let’s see if we can use Azure Data Services to help reduce time spent producing financial reports.”

This is a good starting point, and we can quickly refine the key technologies that need to be proved and simple ways of measuring the factors that define success. Good problem statements for PoCs are as specific as possible, often dealing with the viability of very low-level technical challenges such as integrations or data migrations with very narrow success criteria.

3. Building a PoC for production.

It is common wisdom that a PoC should not be put into production. Although this is almost completely true, it is an often-misunderstood statement. A PoC is immediately compromised if it is built to be productionised. This is because the additional considerations and work entailed in creating a production-grade solution adds significant overhead without knowing if the solution is even feasible, often increasing costs and risk against an uncertain outcome. However, if a PoC is deemed a success, that does not mean all the work undertaken needs to be thrown away by default. It means it can be objectively evaluated, and any viable component parts can be reused and carried forward into a follow-on project to build a production-ready MVP.

Moving to a production-grade solution means a much greater focus on code quality, reusability, security, testing and NFRs (non-functional requirements) among other things. Whilst all imperative in production systems, these will often add little value to the goals of a PoC. However, it is always wise during development to adhere to best practices to maximise the potential for possible expansion and refactoring, preventing the solution from becoming entirely disposable.

A good PoC will be rooted in a business value-based outcome and undertaken to prove that the proposed capability through a new application of technology or data is not only realistic, but the proposed approach is also feasible.