Put Proof of Concepts in the Fast Lane
Three steps to executing proof of concepts faster and better.
You’ve seen a need. You know the solution. You’ve pitched the idea to management. And you’ve heard those wonderful words “ok, let’s do a proof of concept”. Now all you have to is put together your pilot, demonstrate that it’ll work and gracefully accept the kudos.
In an ideal world, you will execute a solid proof of concept in a reasonable amount of time and get a clear-cut result – green light, red light or green light with some tweaking. That’s a great outcome for you and your organisation.
In the real world, your proof of concept takes far too long and sucks up far too much of your attention. Worse again, your intended users either don’t get it or don’t want to use it and you don’t get a definitive result. Or worst of all, that proof of concept sits at the bottom of your to do list, never getting enough attention because you’ve got more urgent priorities.
So how do you mitigate against the risks and ensure that your proof of concept will be one of the success stories in your organisation?
Step 1: Be Realistic About Resources
One of the top reasons for project failure is lack of resource planning. Unfortunately, proof of concept projects are especially vulnerable to resource problems as they will always lose out to core business activities in the battle for time and attention.
In order to maximise your odds of success, take a cold look at resourcing. Say you are a manager or a planner in the supply chain department. Will you have the time to give this project the attention it requires? Do you or someone in your team already have the skills to efficiently design and build a minimum viable product?
Consider that you may only be able to give this 5% of your time or that you or someone on your team may to need to learn new skills. If that pushes the project completion date into the distance, it will reduce the value of the project. It also increases the risk of external events disrupting the project – key people may move to a new role; corporate goals may change.
If this concept is valuable to the business, it needs sponsorship and resources. And if you don’t have the resources or the right skills to keep momentum, consider outsourcing some or all of the work to a specialist company.
Step 2: Invest in Requirements Gathering
The second reason for project failure is unclear goals. Proof of concept projects are often guilty of skipping or rushing this step and that’s understandable; the whole point of the proof-of-concept exercise is to help us figure out requirements, right? Unfortunately, that approach launches the proof of concept on a trajectory without enough discussion. From that point all further decisions are based on that initial trajectory. And like the old story of the guy asked for directions…. “Well, I wouldn’t start from here”.
Don’t miss this opportunity to identify all stakeholders and elicit all their requirements and all their critical success factors. A concise one or two page document is all you need. At Dataworks, we find it useful to include the reason for the project, the hypothesis for the proof of concept, a description of the current process, a description of the proposed process, critical success factors as well as the functional requirements. We also find the following techniques are useful:
- Interviews, questionnaires or surveys
- Analysis of existing reports and emails.
- Use cases and scenarios
- Using “Active Listening” to pull out the hard to articulate or “too obvious to mention” requirements.
Tip! Don’t get waylaid into designing a solution at this stage. This stage is about “what” people need. It not about “how” to deliver it.
When you have an agreed set of requirements, break it down further into “must haves” and “nice to haves”. You now have a strong starting point. You’ve set a course but you’ve set it intentionally and with buy-in from all stake holders. The proof of concept can now test and refine these requirements.
Step 3: Design A Solution
With a clear set of “must have” requirements, you’re ready to start thinking about the “how”. Your aim is to build a minimum viable project to test out your concept. There are many paths to that end goal. We’ll look at two different approaches.
- Approach 1: Proof of Concept
- Approach 2: Prototype and Skeleton Solution
What’s the difference? Let’s take the example of a production department in a Med Tech organisation that needs to improve management of maintenance costs. They believe the fix is to get the hours logged by the maintenance engineers on each shift and use it to determine what are the drivers of maintenance time e.g. product type, batch size, shift time. Timesheet data is not currently available as a feed and there’s a worry that it may not be possible to access it.
A Proof of Concept is typically a “throw away” solution intended to explore requirements. For example, the production department decide to manually type all the information into an Excel spreadsheet weekly for analysis with the intention to migrate to a report in the final solution that directly accesses and analyses all the information.
A Prototype and Skeleton Solution moves to a skeleton version of a working model sooner. For example, it may be a very basic Power BI desktop report that automatically accesses timesheet data for maintenance and presents it without analysis on a daily basis.
On the plus side, the traditional proof of concept approach seems to have the advantage of a quick “boot up”. On the negative side, it misses an opportunity to tackle an important unknown – can the timesheet data be accessed automatically? It also incurs a lot of extra effort for the team which increases the hidden cost of this proof of concept and increases risk of stalling.
Let’s drill into the advantages and limitations of the traditional proof of concept versus a skeleton solution further:
|Traditional Proof of Concept Advantages Uses available resources and skills e.g. Excel skills. Limitations May present a solution that may not be achievable within budget in a production version May not provide sufficient flexibility to explore all functionality. As a result, users may focus on specific aspects of functionality that can be delivered using that functionality. Effort is put into a solution that will be ditched at a later stage.||Skeleton Solution Advantages Opportunity to test out if the basic solution will be suitable in terms of delivering required functionality. Make it easier to envisage the effort and complications that might be involved in building a production system. Opportunity to identify and tackle the hardest problems e.g. issue of data access in this case. Limitations May require professional resources Less opportunity to interact at early stage|
Take some time to explore possible solutions both internally and with solutions providers like Dataworks. There may be non-custom solutions and technologies that you haven’t considered which would suit your proof of concept. For example, with the new low code/no code platforms like Power Platform it’s now feasible to create a skeleton solution that can be extended later or can be developed further in-house.
In A Nutshell
The capability to successfully execute a proof of concept will pay dividends to you, your team and your organisation. It’s vital to create strong momentum and a successful outcome by adequately resourcing and planning it. The Managed Services group in Dataworks can provide consultancy and resources in requirements analysis, project management, technology landscape review, solution architecture and implementation.