How can reports be useful over time without needing constant maintenance? A Ryan Holiday book got me thinking about this. That book is “Perennial Seller“. It is about creative work. About creating work that lasts. A perennial report might sound good. But it lacks something. It’s not enough to last for a long time. It has to be useful in that time also. If not, user adoption will decline with time. Like some plants keep their green color year after year, reports need to last and remain useful as years go by. Reports need to be evergreen. To make them, requirements are the first place to pay attention.
Gather requirements from many sources
Like the qualification process in sales, there can be a similar approach for reports. A qualification process for reporting needs. The whole scope of this qualification process is to solve well-thought-out problems. Not to solve surface-level problems. By the end of the process, it will be clear if the need is valid. Then comes the step of finding patterns.
I try to look for patterns in report requirements. If I find patterns, I try to combine more needs to create a better report. This doesn’t mean to include as much stuff as I can in a report. This would be a counterproductive solution in the end. Instead, I would see if I can use one KPI in more than one scenario, or use some key information for my 2-3 report requirements. Instead of 10 reports, I could create 2-3 more versatile reports that will meet 80-90% of the needs. On top of that, I will use only 20-30% of the initial effort necessary for those 10 reports. My focus is to be efficient. To achieve this I need to remind myself to not rush.
Don’t rush into creating reports
Different elements enter the making of such reports. Mistakes are easy to make, especially if rushing the process. Those mistakes won’t show up immediately. They will become apparent months down the line. When mistakes do show up, the effort necessary to fix the reports will be significant. Most of these problems are fixable at the requirements step.
I’ve worked on reports with a starting set of requirements. Set changed by stakeholders over and over. In the end, I had a completely different report than what I started with. This is why I come back to the same conclusion. Everyone involved needs to spend more time thinking upfront. This will increase the chances for the effort in creating and maintaining the report to be efficient. The first thing to analyze is the business’s tech stack.
Ignoring the current tech stack
Rushing and ignoring the current tech stack saves time in the short term. But it creates many risks. One is the risk of ending up with many different software tools. Tools that pile up monthly license fees. To make things worse, these solutions might not work together. To solve this new problem, investment in more software tools is necessary to make them work together. Before investing in new tools, the current stack needs a new evaluation.
When analyzing the current tech stack, one of three things happens. The first one is that new ways of using the same software become apparent. The second thing that comes is the need to use a new tool to complement an existing software tool. For a complex analysis, Machine Learning can complement the report tool to achieve a better report in the end. The last thing that can come up, is the need for new tools (either reporting tools, or tools users use to create the data used in the report). When doing this analysis, it’s easy to do too much.
Don’t ask for too much from a report
Be careful, as a stakeholder to ask for too much stuff in the same report. It can seem that more information in a dashboard might be better. Doing this comes at a cost. It will be difficult to work with. In this case, users will avoid the report. All the effort invested to create this report will be worthless. This is not what good reporting looks like.
Good reporting is to strip all the unnecessary data to its cleanest form. The result has to ease the report consumption. By doing this, the adoption rate will increase. Being easy to use doesn’t mean giving users less information than they need. Reports need to help users do their jobs better. Sometimes, to do those jobs, users need more information.
When I end up with a lot of requirements, the simplest solution is to spread them in many dashboards. I strive to have one major problem solved by each dashboard. I want to include as few extra KPIs as possible that give the full picture of the requirement. But then the issue of needing more details shows up. I wouldn’t include that information on the same dashboard. I would use the visualization tool’s linking feature to a new dashboard. This way the user can go from that KPI to a new page where he can look up more details. To determine what goes where a long-term approach helps.
Many reasons for thinking long-term. One of them is the volume of data. The amount of data that increases over time. This can hurt the “communication” speed between the source and the reporting tool. It will hurt the report’s performance. It can get to a point where the report won’t be useful anymore. This leads to the realization that not all reports can be evergreen. The main reason has nothing to do with the reporting tool. Nor has anything to do with the underlying data. The main reason has everything to do with the business itself.
Depending on how the business changes, reports can be evergreen or not. This becomes the first thing to look for. Does the business or part of it have reached a point of maturity? Not overall but regarding the reporting need in question. This will validate an evergreen report before development starts. A better approach is well put by Jeff Bezos in Ryan’s book “Focus on Things that Don’t Change”. Those things might not be obvious at first, but through iterations, we can get there.
Is iteration optional or required for evergreen reports?
After concluding that the part of a business that needs a report is stable, the actual work begins. Work that transforms requirements into reports. The only way to do this is through iteration. Especially if we are creating an evergreen report. Otherwise, the quality of reports won’t be what it needs to persist over time. To do this, different people are involved in different stages,
This approach can look something like this. After stakeholders think enough about the initial need, the development team takes over. They create a beta version of the report and show it to a small group of people who can test it. Based on their feedback, the report might need adjustments. Only after this cycle is over, the report can move to the last step. Rolling it out to the whole organization. For this, a report has to work on many levels.
Evergreen reports need to work on many levels
Every report needs to work on the next 4 levels to become evergreen. If one is missing, the report will need extra maintenance or changes over time. Those levels are:
- Business – the business or department of a business needs to be stable. This will determine if reporting will need constant maintenance or not.
- Data – the company needs to have the relevant data gathered in one single performant place. It can be straight from other tools a business uses or from a data warehouse with centralized and clean data.
- Stakeholders – people who need this report need to clarify what they need. Not only that but also communicate it in a clear way to the development. And keep doing so throughout the project development phase.
- BI Developer – besides technical skills, he needs communication skills. He needs to not take requirements at face value. He needs to communicate with stakeholders throughout the report’s development. To help them clarify and figure out what the report needs to do. Since I’m a BI developer, I will describe next what is my approach in this scenario.
What’s my approach to creating evergreen reports?
This is my approach to creating evergreen reports:
- Gather requirements – Talk with stakeholders to understand the reports I need to create. My approach is to start with big-picture questions and from there dive into more detail.
- Duplicated requirements – See if some requirements are already fulfilled in older reports to not create the same thing twice. Sometimes users are not aware of existing reports that can solve their needs.
- Needs consolidation – Group report requirements in two categories:
- Common Requirements – Requirements showing up in more than one report. For example gross revenue for the current year. This KPI is useful for more than one person or department.
- Unique Requirements – Needs appearing only once in multiple report requirements. For example the result of a current marketing campaign. I will include this example in this category if this is a one-time campaign.
- Make a rough draft of the common requirements – this will be the basis for my core report/s.
- Talk with stakeholders again to figure out what KPIs are useful all year round.
- Based on feedback, go back and adjust the reports until meeting stakeholders’ requirements. This will be the core report that will persist in the future.
- The last step for core reports is access. Give access to stakeholders. They can test and provide feedback I can implement further. If the report doesn’t need adjustments, then is ready for the rest of the organization.
- I can move to unique requirements next. Repeat steps 3-6 until I have a version ready for the whole organization.
- In the end, create a new page on the evergreen report (visualization tools may have this feature available in the online version). This page would have “useful links” to the report from the second category. In this way, I can solve three issues:
- I give people access to everything from the same place.
- When the time comes to delete, change, or create new reports from the second category, it will be simple and efficient. I can update the links on that page only.
- If I don’t separate the needs into two categories, I would have to change the underlying data model to accommodate new needs in the future. This is a more time-consuming change which can lead to unnecessary complications.
BI reports can solve different needs. The most important ones are those created once and persist with time. Those reports are evergreen. Reports that once finished need zero or low maintenance over time. They will form the report foundation of any business.