The marketplace for business intelligence and analytics tools becomes more saturated every day. Between standardized reporting, ad hoc self-service visualizations, and predictive analytics, many managers and buyers are so overwhelmed by keeping up with product releases and understanding tool features that they do not have time to consider the pitfalls that can sabotage a successful implementation, regardless of which tool is selected and used. Here are 5 considerations to help you deliver a successful reporting implementation, no matter what technology you are using.
What do your users really need?
You have been tasked to replace a report that was built on a system that will no longer be supported by the company starting next quarter. You have a sample output file and the requirements documentation from the first implementation. Great! Now all you need to do is find the best tool that reproduces that same core functionality at the lowest cost! Hold your horses. Oftentimes, analytics experts are brought in to replace a specific system or after functional requirements have already been gathered. By not including the analytics experts from the very beginning, you risk not diving deep enough to understand the ultimate use case.
Sure, your users say they need a tabular Excel file, but what are they then doing with that file? Perhaps they are manually plugging it into a macro-ridden Excel workbook or Access database to generate a dashboard that you didn’t even know exists; that dashboard could have been created and refreshed by your team for the entire enterprise to use, but you did not identify those requirements! Or, perhaps your end user is data-savvy and wants to be able to slice and dice in her own way. In this case, why build a report at all? Enable ad hoc reporting capabilities and watch your user do the work for you, enabling you to help other less data-savvy users with your time!
Consider employing the ‘5 Whys’. When a user answers your initial “What do you need?” question, follow up with, “Why?” Once you have asked why 5 or so times, you will have a much better idea of the actual needs of that person. For example:
You: What do you need?
User: An Excel export of sales by salesperson, refreshed monthly. Make sure their Employee ID is included.
User: Because I take the data and use vlookup functions to match their actual sales against their targets.
User: So that I can send the numbers to their corresponding regional sales managers.
User: To let them analyze how their salespeople are performing against their personal targets and the regional averages.
User: So they can share those numbers with their salespeople in their monthly performance feedback meetings.
You have uncovered that the Excel export wasn’t really needed at all. You could build a dashboard that is automatically refreshed to include actuals and target data and is designed in a way to facilitate the users’ monthly feedback sessions! Instead of eliminating one step of the process by producing the originally requested Excel export, you can eliminate 4-5 steps by creating a fully automated performance management dashboard.
Look for existing solutions and tools.
Excellent, you have talked to your users and understand what they need from you to be successful. It is time to start building! Wait a minute. Are there any tools within your enterprise currently in use that could be extended for your needs? Just who is going to maintain and enhance this new solution once it is deployed anyway?
When a group builds their solutions in a silo, they risk replicating previous or ongoing efforts and building something that is overly bespoke. I have seen companies with competing reporting solutions that tell different pieces (or different versions) of the same story. Perhaps marketing built a slick dashboard to identify the customers that are most interested in your hot new product. Separately, operations has a report displaying yearly spend by product and customer. But, if these two reports don’t integrate, how can you understand opportunity conversion or identify existing customers whose business you could extend?
Involve IT and affected business stakeholders early and throughout the process. Understand the data elements and functionality that will be implemented and ask if they are already being used anywhere else. If there are planned future enhancements, consider who may be implementing them and plan accordingly.
Your users are not programmers.
You are on your way! With a clear understanding of your users’ goals and the existing technical landscape, you can begin developing in earnest. Don’t jump the gun! Your developers are eager to get started, but you need to make sure that you are building something that doesn’t require your users to have a computer science degree or attend a 2-week boot camp to properly use.
By and large, your end users will not be programmers or understand the ins-and-outs of data modeling. They don’t care that the database field names are DIM_CUSTOMER.CUST_NM and FACT_SALES.QNTY; they want to double-click ‘Customer Name’ and ‘Order Quantity’ and see a list of customers with the total quantity they have ordered. While a certain level of familiarity with the data can be expected of your end users, this should be business and domain knowledge (salespeople represent many accounts) not database knowledge (DIM_SALESPERSON has a 1..1:0..N relationship with DIM_CUSTOMER).
If there is a standard calculation for margin, build it into your solutions so everyone calculates margin the same way. For pre-built reports and dashboards, use the same terms and definitions with which your users are familiar. For ad-hoc reporting, present a model that is organized and requires as little explanation or narration as possible. The less time your users spend feeling frustrated by trying to decode your solution, the more time they spend feeling empowered by using it to answer their critical questions.
Avoid the big reveal.
You are knee-deep in development and everything is going well! Your developers are typing away and you are only a few days away from delivering the final product; your users will be very pleased! I hope this isn’t the first time they will see the solution. What if you spent weeks or months creating a polished, production-ready dashboard, but it is nothing like what your users are envisioning?
While addressing consideration 1 above (what do your users really need?) sets you up to build an impactful solution, your users haven’t seen anything yet. While certain visualizations or user interfaces might have been discussed while gathering requirements, most users will have more feedback once they have something to look at. By waiting until the solution is almost finished, you risk surfacing deep variances between your understanding and your users’ expectations past the point where you have the time or capital to resolve those variances.
Hold frequent review sessions with your users, starting as early as possible. This could be with basic working prototypes, wireframes, or even just hand-drawn mock-ups. By socializing your approach and direction early and often, you will help ensure you are going to meet your users’ expectations before your timeline and budget have run out.
Start managing change on Day 1.
Your solution is built, you can deploy it and inform your users that this life-changing tool is available for their benefit! Well, it may be too little too late.
The number 1 reason why reporting implementations fail is because the solutions aren’t adopted and used. We are often so focused on delivering a working solution that meets the business and technical requirements that we do not consider how we manage and communicate the changes and impact. The enterprise may be rife with home-grown solutions and approaches that conflict with your new solution. You and your team might have built the best set of dashboards and reports under the sun, but if there isn’t a plan to retire or convert old reports and processes, or to communicate the new functionality to your end users, they will never be run or seen.
While you are putting together your project plan for development and implementation, make sure you are also considering change management and training. Consider sending periodic newsletter to impacted users to communicate future changes and enhancements, scheduling standing training classes or office hours to support the new solution, and creating RACI charts to formalize department liaisons and IT contacts, etc., to let users know what to expect and drive excitement for your solution.
The common thread that runs throughout everything discussed is the user. The user’s goals need to be fully understood. The user needs to be included and consulted throughout the implementation process. The user needs to buy into the solution approach and feel empowered by what is delivered. Reporting bridges the gap between the user and the analytics group: your users will be the measure of your success. Involve all pertinent users and deliver a solution that is as user-friendly as possible, and its adoption will reflect your efforts. Once your initial group of users has adopted the solution, they will evangelize it for you and will quickly come asking for more!
West Monroe Partners Advanced Analytics team provides an uncommon blend of deep technologists and business consultants who are business intelligence experts. Our approaches are tailored uniquely to provide sustainable solutions across various industries for our clients.