PoC: What, why, and how?
Get the best practices on how to perform a proof of concept process for your organisation.
Whether you are helping your organisation choose a vendor or a solution in the realm of digital, a proof of concept may be an invaluable tool. Let us discover why it can benefit you, your team, your stakeholders, and ultimately your customers.
What is a proof of concept?
A “proof of concept,” or PoC, is a demonstration of the practical feasibility of an idea or theory. A PoC is usually small and limited in scope and timeframe (from two days to two weeks), as it is not meant to be a complete, finished product.
When do you need a PoC?
Initiating the process of PoC is most relevant when your organisation is considering buying or subscribing to a new solution—e.g. CMS, CRM, ERP, marketing automation, cloud, infrastructure, security. This, in turn, may be a part of a larger procurement process in your organisation, where PoCs are organised with the top two candidates of a given solution.
A demo can be a useful introduction, but how does the given solution harmonise with your specific needs and framework? A demo can work flawlessly, but is designed specifically in a controlled environment for a presentation that is supposed to impress you. The solution has not been battle-tested for real-world deployment, as CMSWire says.
A PoC, on the other hand, lets you dig deep and get a real sense of the implementation, what resources are really required, what you can actually build and do with the solution, and how the solution works for your team in a realistic setup.
Essential steps of a PoC
The first thing to remember when conducting a PoC is that it does not have to be an overwhelming piece of work. You decide how comprehensive it needs to be—and whom to involve. You can e.g. perform a PoC by yourself and not involve the vendor.
When that is said, here are the essential steps of a PoC you always should remember:
1. Define the use case
A proof of concept is a process designed to present a feasible solution to a specific problem. What are you trying to solve with the new solution you are considering? What are you trying to do? There are marked differences between e.g. testing out eCommerce integration, building a customer journey, assessing security, and trying out a new resource management system.
You should therefore explicate in advance what features and possible caveats your team should scrutinise during a PoC.
2. What should be clarified beforehand?
As with any digital project, you should prepare as thoroughly as required before conducting a PoC. In this step you need to clarify several important aspects:
- The nature of the collaboration with the vendor
- Assessing your organisation’s experience with the solution
- Estimate the amount of work that can be done in the limited timeframe
- The expected user experience and availability of functionality
- Determining what technology is needed and what you already possess
- The possibility of integrations
- What skills are available from both internal and external sources
- What kind and amount of reporting is expected
3. How to organise the project
As mentioned, a PoC does not have to be comprehensive—it can last from two days to two weeks, depending on your requirements and goals.
There are many ways to organise digital projects, but for longer PoCs a sprint may be the best M.O. A sprint allows your developers, designers, editors, quality testers, and other team members to conceptualise, build, test, and iterate in a fairly Agile manner.
Establishing project ownership is another essential preparatory step in regard to PoCs. An owner can direct the general direction of the project and inspire teammates to perform their best. Thus, decide who gets to be the product owner and the project owner—sometimes these two may be the same person.
As for valuable inputs and resources, make sure you involve users and developers from the get-go. Your team can help a project owner think more clearly by providing critical input and suggestions to his or her proposed plans.
Sometimes it may be necessary to teach your team the fundamentals of a given solution before embarking upon a PoC, in order to get the most out of the building and testing phase. Allowing your team to be involved with the PoC makes sure you get real, hands-on experience and valuable feedback by the actual users of the solution.
6. The actual PoC
The actual proof of concept process can be relatively short or long, depending on your needs. Running it may consist of sprints, where a team of internal and/or external resources build and test a feasible solution for evaluation purposes.
The process may be intense, but leaves you with invaluable information and the vendor with useful experience as well.
In the evaluation, you should assess what you did accomplish and whether any predefined goals or KPIs were fulfilled, and finally how the solution compares to a potential competitor.
A PoC may seem like a daunting task. However, if it is planned and executed correctly, it can be relatively resource-forgiving, but still provide very useful insights into a solution your organisation is considering.