A proof-of-Concept (or POC) is a great low-cost exercise when in need of further assurance in solution selection.
A POC is a limited scope implementation of a proposed solution with the main purpose of verifying the feasibility of selected functional and non-functional aspects.
POCs offer a limited scope implementation project with a limited timeline. It minimizes the risk in solution provider selection by allowing you to assess the solution fit according to your specific challenges, rather than relying on the provider’s sales promises.
In this article, I'll cover why you should choose a POC for spend analytics, 8 common pitfalls, and finally, how to manage a successful POC project.
Why choose a POC for Spend Analytics?
A POC enables the evaluation of the supplier's ways of working and whether they would be a good fit with your teams. You can use a POC to initiate a change management process for the soon-to-be-introduced new solution by involving a diverse set of stakeholders in the solution evaluation.
Additionally, these projects help you in building the business case, as advanced analytics solutions potentially reveal tangible savings opportunities already within the POC scope.
At a minimum, you will gain a better understanding of resource requirements for full solution implementation based on realized work effort in the POC phase. This will help you justify your initial calculations.
Basing your decision solely on the RFP questionnaire template doesn’t seem feasible, but there is a simple workaround.
See why you should be implementing Spend Analysis software -- key benefits & overview.
8 Common pitfalls of POCs
According to CIPS, 90% of procurement technology implementations fail, and POC projects are no different.
While there are undisputable benefits in trying before buying, sourcing teams often fail to achieve the goals they envisioned when entering a POC with a potential procurement solution provider.
While the plug-and-play SaaS software rarely calls for more than a free trial or demo access, other solutions require a well-planned evaluation process – and often a POC project as part of it.
These 8 pitfalls are what you should watch out for:
- Not defining important provider capabilities or sharing, but only consulting a few internal stakeholder groups and sharing no expectations or evaluation criteria with the provider.
- Allow only showcasing a limited scope of activities while excluding challenging tasks that considerably affect the result of subsequent activities.
- Expecting all functionalities to be available and fully configured to your needs – even those you’re only slightly interested in.
- Providing too short of a timeline for execution from data delivery to results presentation while still expecting similar results as from the full project.
- Including an unreasonable amount of data considering the envisioned timeline.
- Involving too many providers in the Proof-of-Concept phase and allocating too little time to support each supplier in solution configuration-related questions.
- Involving too few internal stakeholders with homogeneous backgrounds, and in the worst case, no one with hands-on experience in solving the challenges the solution is envisioned to solve.
- Forgetting to properly evaluate the results of a POC.
The 3 steps to successful POC projects
While there are numerous common mistakes one may make, there are only 3 steps you need to take to get your POC right.
These steps will essentially ensure the POC answers the questions you wanted to be answered while also maintaining the low-cost and short delivery timeline of the project.
1. Define criteria for success
These might be features or services previous solutions (internal or external) have failed to deliver upon or new more advanced functionalities where solution value or provider maturity must be evaluated carefully.
Then, one should source for evaluation criteria from different stakeholder groups (category managers, buyers, procurement analysts, procurement controlling, IT, etc.) and from people preferably with hands-on experience to avoid missing crucial areas to consider in the evaluation process.
This will also initiate a broad change management process across the company instead of limiting it to a narrow sourcing team. Once you’ve ironed the criteria out, remember to share those with your candidates so that they know where to put their efforts.
2. Define the scope and timeline
Align the POC scope with the defined success criteria to ensure all important features and functionalities are demonstrated adequately and the focus is crystal clear to maintain a limited scope and timeline.
The scope can be split into activities, data, and functionalities.
Let’s cover these in more detail as they will have a significant impact on how the project will look (and if you will be able to get evidence for your evaluation).
- Major activities in Spend Analytics include connectivity (extraction and integration of data from multiple sources), cleansing and enrichment (classification, supplier parenting, and connecting internal and external data sets, for example), and analytics. Often, only some of these are included in POC scope.
- In spend extraction and classification more data is good. But more data also means a longer lead time for a project. Providers might focus on different categories to showcase their best performance while coping with a limited timeline which makes their end-results non-comparable in the end. Perhaps you would like to test vendor capability in data cleansing and enriching in only one business area. Working with a limited scope can both shorten the timeline and make providers more comparable while still allowing them to involve all relevant internal stakeholders in the process.
- Advanced best-of-breed Spend Analytics often offer a broad set of analytics functionalities combined with additional modules and features, such as savings tracking or benchmarking, for end-to-end value delivery in strategic procurement. Implementing all such modules and features in a POC might be overkill especially when they require extensive customer-specific configuration work. Like in the data scope, it is a good place to challenge the relevance of non-core functionalities in POC scope.
3. Define your evaluation process
You should set up a predefined and well-documented evaluation process that is fit for purpose. This sounds like a trivial exercise, but it isn’t (at least after having seen dozens of evaluations only or mostly based on a quick presentation).
To begin with, you need to get back to your success criteria which should outline the key themes of the evaluation together with more detailed and refined evaluation points.
In general, you should put emphasis on the team’s first impressions and perceived user experience. These will influence user adoption in the wider user base in full rollout later down the road.
Furthermore, it is also worthwhile to assess non-functional aspects such as if the tool aligns with your organizational strategy, processes, and culture, or if the provider is willing to develop the functionalities and features together with you.
Nevertheless, don’t forget the key challenges you wanted to test in the first place with the POC, e.g. enhance the quality and integrity of data extracted from your ERPs, improve classification accuracy and coverage, or find those automated, truly actionable insights from analytics.
While good UX is vital, a new and shiny solution will take you nowhere from the status quo if it replicates the original issues like low data quality.
It is essential to involve stakeholders from diverse backgrounds as you did for evaluation criteria collection. As a project manager, you should make sure your evaluators will remain engaged in the process and that they will take part in required briefings and presentations.
Weighted average scoring is a powerful tool to ensure the total score will suitably drive decision-making in the end. However, since grades-only evaluation gives a relatively “black and white” picture, they should be accompanied by rich qualitative feedback to also consider the subtle differences in providers’ offerings and ways of working.
With these two forms of feedback combined, you avoid the tick-the-box feature bingo that will lead to failure in vendor selection.
Spot-on assurance for accelerated time-to-value
Following the steps, you should have quick results that support your decision-making, internal sales, and change management.
You should have focused on areas that were important in the first place. You should also have a better understanding of solution providers’ ways of working and whether they would be a good fit for your organization.
In short, you should be able to make a well-informed decision in a timely manner.
Are you looking for a Spend Analytics solution and planning for a Proof-of-Concept process? Let us know and let’s have a chat!
Contact Sales
Banner image by mikar (Unsplash.com)
