A proof of concept (PoC) assesses the viability of a software product for solving a business need. That’s a fancy way of saying it tests to see whether an idea will work.
The concept part of the PoC consists of the basic framework for the software solution. It’s not fully fleshed out or completed yet; it’s just the bare bones needed to decide whether you can move forward or whether changes need to be made.
The proof part of the PoC rests on specific success criteria and positive results. You have to know what you’re trying to accomplish, and you have to know when you have achieved it.
It’s always best to start with realistic expectations for both for your team and the developer before diving into a PoC. So let’s take a look at the steps you need to follow so you can create a successful PoC that gives you the intel you need to make a wise decision.
Before You Begin Innovating: Build or Buy?
The benefit of established off-the-shelf software is that the developer has likely been through several iterations and has had the chance to prove that the product creates value. You can also compare several similar products and choose a best-in-class solution.
But there are drawbacks too. The solution may be too rigid for your needs, it may not be compatible with your other technology, or it may not have all of the functionality you’re looking for. In other words, while it creates value, it may not create the right kind of value for your business.
So when should you go the custom software route instead?
* When your unique process provides a competitive edge that can’t be replicated by off-the-shelf software solutions
* When you need both broad and deep functionality
* When your industry requires specialized software capabilities (compliance with regulations is often the reason)
* When you need the option to modify software over time
* When you need a software solution that can communicate effectively with your current technology stack
If you’ve done a thorough needs analysis and it makes sense to build instead of buy, you’ll work with your developer to create a proof of concept. Of course, great ideas don’t always flow through to become great products. That’s what the proof of concept is for—to evaluate the viability of the software idea.
But even ideas with excellent potential can fail if they don’t have the right support system in place. In the hustle to create a viable concept, don’t forget these foundational steps.
Step One: Define Success
The PoC is not a finished product, so don’t expect it to look like one. Instead, decide what specific components or assumption you want to test and define them explicitly at the outset. Ask these questions to determine your acceptance criteria:
* What specific business process are we testing?
* What is our current process/methodology?
* What works/doesn’t work with our current solution?
* What problems does the software need to solve?
* What happens if we don’t develop a new software solution?
* What value do we want to realize?
* What metrics will we use to measure performance?
* Who will use and support the software if it is implemented?
* Is this the kind of solution users are looking for?
Every stakeholder should have a list of criteria to measure success of the PoC. Know what you’re looking for at the outset, and don’t fall prey to Shiny Object Syndrome.
Step Two: Align Expectations
The PoC needs champions who will keep the process moving and make sure everyone understands the goals and success criteria. This team may include the company decision maker(s), the IT manager, the development lead, and other influential stakeholders. These people will work together to make sure everyone has the same expectations and that the right information is readily available.
Aligning your expectations gets everyone on the same page in these three areas:
Communication is probably mentioned in every single article you’ve ever read about project management, product development, or agile methodology. That’s because it’s important! Communication is the key to successfully creating a proof of concept that does its job.
Collaboration among team members goes hand in hand with communication. Inaccurate information or lack of preparation from any party can risk the success of the PoC. Close collaboration helps team members keep the focus on the must-haves while also learning more about the potential capabilities of the software.
Set a start date and an end date for the PoC. This process should not linger indefinitely. The goal is not to explore every detail of the software or configure it precisely to your specifications. It is to test an idea to see whether it can be developed into a final product that benefits your organization.
Make sure every stakeholder knows what you’re trying to accomplish, what you want the technology to do, and how you will know if you have been successful.
Step Three: Plan Your Process
Limit the scope to resolving a specific problem or answering a specific question. For example, will an IoT infrastructure solve your equipment maintenance problem? Will this AI solution improve your recruitment process? Will this ERP improve task completion efficiency?
The proof of concept should demonstrate viability for every aspect of the project:
Will the data be secure and easily managed? Will the storage and reporting functions meet your needs?
Does the software solve the problem you need it to solve?
If UI/UX is part of your project scope, include this in the PoC. Is the user experience satisfactory? Can users navigate the software intuitively? Does it mesh with your processes?
The PoC should include clearly defined tasks that you want to test. It helps to write these out in brief statements so that your team can check them off as they are accomplished.
Step Four: Test and Report
The proof of concept is not a demo; it is more like a test drive. As such, you need an environment similar to the one you expect to have at full implementation. This doesn’t mean it needs to be a full-scale environment, but it should function in the same way. For example, you can test in a single department or among a group of customers limited by geography.
Here are a few more things that can help ensure a successful PoC:
Dedicate a representative from the developer
This person should help you work through any challenges and stay on track during the testing process.
Keep your success criteria front and center
You’ve gone through the exercise of defining your success criteria, so don’t make the mistake of marginalizing those criteria because something else crops up during testing. Keep your eyes on the prize. You need this innovation project to hit specific targets.
Keep detailed records so that you can identify glitches and replicate the PoC environment when you’re ready for the full implementation.
Be ready for glitches. If everything went right the first time, we wouldn’t need a proof of concept! The goal is to evaluate whether you are on the right track or whether you need to readjust your design.
Because communication is so important to a successful PoC, I’ll reiterate: be sure to keep the lines of communication open between your team and the developer. If possible, have someone from the development team on site during the PoC process to address any problems or challenges that come up. If that’s not possible, at least have someone on standby to be reached by phone.
If your PoC was a success, congratulations! But you’re not done yet. Don’t rush too quickly from PoC to development. The pilot stage is where you get to put meat on the bones you tested during the PoC. In other words, it’s time to flesh it out and get it ready for some serious user testing. And that’s when things really get exciting.
Looking to bring your ideas to life?
We are committed to guiding you towards the best solution for your business.Schedule a Call With Us