A common gripe we hear among business intelligence (BI) analysts is they don’t like the briefs they receive from business users. Business users don’t seem to fully understand how BI tools work.
Part of the problem is that BI is such a vast field. End users might understand what business intelligence is in a broader sense, but don’t necessarily know how to get the results they are looking for.
This lack of understanding on the client side ultimately impacts how well the BI team executes on the project. So we’ve developed five tips to help your team avoid the most common pitfalls to a functioning relationship between BI analysts and the business users.
1. You need someone from the business team who understands the technology
BI, at its core, gives understanding of data so businesses can make better decisions. Experienced practitioners are constantly learning new areas and techniques for getting better understanding of data. But end users don’t know this space. They may know what data they have to use, and what needs to be done, but they don’t know the details of how to do it.
On top of this, one of the biggest tools is data, which is typically pulled from third-party databases. Any problems with data quality mean the eventual reports and insights will be incorrect. If there is no one on the client side who can identify missing or incorrect data, the result will be wrong — no matter which tool or platform you use.
At the end of the day, the business user is always going to understand the business requirement better than the BI team. So you need someone from the business team who can understand the technologies that go into BI and help ensure the brief is logical and can be answered using the available tools. They can help develop the plan, then sign off as you go through the process.
2. Go back and forth until you’re clear on the requirements
Even if the client team is certain they’ve given you everything you need, it’s never a good idea to start working without qualifying - and, if necessary, requalifying - the brief with key stakeholders so you don’t have any doubts on what the functional and business requirements are.
Make sure you understand the essential end goal and how the insights you derive will be used across the organization. You need a shared clear picture of what the end users throughout the enterprise want to see. Then articulate and refine the requirements and expectations until everyone is clear.
Doing this will help both sides avoid issues during the project. It helps keep the project on track, helps the BI team focus on which tools they need and the ultimate views they are required to deliver. Also, where appropriate, it helps clarify how training documents are created to help end users better interrogate and understand the reports and data. It also helps to avoid scope creep, where business and end users add or integrate new features that are beyond the initial brief.
3. Be clear on the constraints
Another element you want in that briefing process is a clear set of priorities, budget, and deadlines you want to push for. Once you start a project, there are financial and time constraints. You have to prioritize the essential requirements and items so the business intelligence and data analysts have a clear understanding of what needs to be done. By inserting benchmark or ‘gate’ reviews into the process will help keep things on track, and ensure appropriate buy-in/approvals as the project is managed. This helps the entire process proceed smoothly.
It’s especially important to block enough time for testing. If a bug or fault in visualization isn’t captured during testing and it gets pushed into production, the end users will end up unsatisfied and the developers will have to go back and work on what they thought was already done.
4. Create a holistic briefing document
Once you’re clear on the expectations and constraints, create a holistic document that outlines the entire process from start to finish. In most cases, the business user’s initial brief explains the ‘why’ behind a project. It’s up to the BI team to work on the ‘how’ and outline this in a document. This document should include the functional requirements, business requirements, and realistic deadlines.
Be clear on the delivery process. Unless it’s a small project, you’ll deliver in stages. Outline which features you’ll deliver at each stage, based on the development methodology, so you have those milestones set. Don’t leave any room for disconnects or additional requirements in the future.
5. Develop a proof of concept
A proof of concept (POC) gives an idea of what the final delivery will look like. POCs can be certain snapshots or screenshots of the working tool. Since each BI tool packages results differently, the analysts have to package it in the way the business user wants. That’s what the POC does. If the POC doesn’t match what the business wants, go back to the drawing board to refine it.
Follow these steps. Once you do this, you’ll be ready to go into the actual working, testing, and release process. Developers have to be on their toes all the time to make sure you catch any visualization errors or bugs in the testing process. The key is to continue mediating between the development team and end user, to ensure they get what they were expecting when the project is released into production.
Visit https://bipp.io/request-demo/ to see how bipp makes it easy for both business intelligence analysts and business users to create a solid, shared brief and get to insights faster..
