A proof of concept (POC) is undoubtedly the most effective way to prepare for a Business Intelligence implementation.
If you’re not careful however, the proof of concept itself can also get too large and unnecessarily complex. Here, I share some of my top tips on how to keep the proof of concept for your BI Project from derailing, and to make good gains on this stage of preparation.
As the name suggests a proof of concept is used to test an idea and to generate evidence or proof that the proposed solution will achieve your objectives.
In this case, it is a great way to reduce the risk of your BI project failing. You have opportunity to perform a test-run on the feasibility of a proposed solution for your business, product functionality and to evaluate vendors. After more than 10 years working in this space, I’ve learned some of the critical factors that will influence the success of your business intelligence proof of concept.
The proof of concept must be managed like any other project with dedicated time, people and budget. This is a great point at which you can start to keep your proof of concept manageable: define a scope of time for the project to address your objectives.
Keeping time limiters in mind will help to keep your dataset at a suitable scale and complexity. It’s important to remember we are testing the feasibility of Business intelligence as a way to improve company performance, and software features. You aren’t setting out to tackle the entire enterprise with a BI solution just yet, you want to make sure business intelligence can truly help the company.
From my experience, 10 weeks is adequate for a robust evaluation of your Business Intelligence tools and design.
As for resourcing: I’ve discussed how important it is to gain stakeholder buy-in from across the business in a previous blog. So while you may have a technical team member leading your proof of concept, it is important that you prepare several members across various departments that they will be required to spend time reviewing or contributing to your proof of concept.
The process of purchasing a Business Intelligence or Analytics solution is so much more than buying software. Once you’ve completed the proof of concept, you’ll be working closely with a BI provider through a process of solution design or customisations, implementation and ongoing support.
A Business Intelligence provider will also be involved in the set up your proof of concept. They should assist you in keeping scope manageable. It’s important that you take this opportunity to evaluate their professionalism, talents and ongoing costs.
Probably the most important part of a successful proof of concept is to have clearly defined objectives and scope. Keeping everything focused on a list of desired outcomes will ensure success.
When pulling together your objectives, it’s very important:
The POC must tackle a current business problem or process that is attainable but still complex enough to prove out the BI system and design.
Consider current and future business requirements. Can the application be customised to generate new and ad-hoc reports?
Focus on value, and not the mechanics. You’re making a couple of shortcuts on the scope of the implemented project, but logic of the solution should remain solid.
List out the minimum functional requirements.
Involve non-technical staff and end-users involved in the evaluation, so you can assess user experience and the likelihood of uptake across the business.
Deliver both a pre-canned dashboard and/or reports as well as light weight ad-hoc capabilities for users.
If you’re not using your own data, the proof of concept doesn’t prove a thing. The value of business intelligence is demonstrated by applying it to real business problems with your data.
This will also boost relevance for your stakeholders, improving your chance of getting stakeholder buy-in for your BI Project, and it’ll deliver value and time savings when you’re at the point of formally implementing a BI solution.
By selecting a distinct business query that will offer value to the business or your customers, a proof of concept can also be used as the starting point for further design, saving some time and money on getting your eventual BI project up and running.
For the same reasons it’s important that you use your own data, it’s important to apply your proof of concept to a real business problem.
From my experience, keeping your proof of concept focused on one discreet business problem is the most effective way to contain your scope, complexity and meanwhile, address the question of feasibility and test functionality. It may be a single dashboard and supporting report. You can measure the automation of data, system features and the viability of the solution as implemented for the POC for your business.
Not only can you perform rigorous testing of features, feasibility and your vendors, but you can certainly manage this in our recommended 10 week timeframe, and use the proof of concept in the design of your BI Implementation.
Check out Blueprint Intelligence’s $0 Dashboard Offer: a free proof of concept for 30 days, applied to your business problem with your data.
