For a business analyst, defining reporting requirements can be a true test of our professionalism. No BA wants to simply take down requests as if stakeholders were ordering a meal. But when it comes to “reports”, it can be difficult to really dig into the underlying need behind any request, and the path of least resistance can be tempting. The end result is often wasted time generating reports that feel useful but don’t actually help anyone – and dumping data out into spreadsheets can inadvertently circumvent data governance controls.
Business analysts aren’t waiters. We’re more like sommeliers if anything.
In this post, I’ll explore how we can establish better reporting requirements – and some of the better alternatives available.
Be clear about what decisions you want to make with information
If you can’t articulate the decisions (and subsequent actions) that will be made using data, the report is probably not going to be useful. It can indicate a floundering attempt to manage things that will feature ad hoc (and often panicked) responses.
I’ve found Lori Silverman’s analysis and discussion on this topic to be hugely inspirational. You can hear her talk to Adrian Reed on how we’re “drowning in data” here.
Business analysts can spend time working with stakeholders to really understand the business rules and logic that would be applied, and what the downstream activity will look like – which may be escalation, or corrective actions. Get this defined.
Once you’re clear on the decisions to be made and the subsequent actions, it should be pretty obvious what information is actually required. Be ruthless, and strip out any information from the report that doesn’t aid the process.
Put preventative controls in place where you need them
Many reports are created to compensate for the absence of preventative controls upstream. Getting a spreadsheet or pdf after the event is (at best) a detective control. Assuming someone spots the issue in the report – which may be a month after the event – they’ll still need to spend time addressing the problem.
As a BA, you can work with your stakeholders to establish effective preventative controls that will stop issues happening in the first place. This might include upstream checks or the inclusion of poke-yokes.
Put alerts in place for when things stray outside tolerance or appetite.
Preventative controls may not always be feasible, but timely alerts can at least help address problems more rapidly. So many reports get generated days or weeks after an issue has occurred. Corrective and compensatory actions will be harder (and possibly more expensive) to undertake.
Instead of a reporting requirement, perhaps a requirement around an alert would be more appropriate. The right person can be informed of an issue immediately, and they can set about addressing things right away. And (as with the previous point) be clear on what you expect people to do when they receive an alert.
Information at the right time
Simply, do you need a report, or is a real-time dashboard better. And what do we mean by “real-time”, anyway?
Dashboard requirements can be really tricky to articulate usefully using words (or user stories!). Wireframes and mock-ups can be a really useful elicitation and communication tool in this area. Tools such as Balsamiq can be great for this, but I find scribbles on a big piece of paper can work just as well!
Be clear about what you need to see
Some reporting requirements are essentially a request for a data dump. Dreadful on a spreadsheet, and even less useful in a dashboard.
I like to talk to stakeholders using an analogy: position vs distance vs speed vs acceleration vs jerk vs jounce (yes, really). It may be more useful to understand movements in data, rather than totals or individual data points. Are you expecting someone to analyse what they’re seeing to generate insights, or can this be automated?
It’s also important to determine the importance of knowing things are “ok”. A weekly report that says “this is fine” is a likely to be a waste of time – but it can be a comfort blanket if nobody has confidence in the alarm system.
In conclusion
When receiving any request for a report, a business analyst’s first response should be to start asking some deep and probing questions. In many instances, a report won’t be the most useful solution for preventing issues or detecting them in a timely manner. BAs have plenty of elicitation techniques to probe further; it’s not a “no”, it’s a “no, but…”!
Reporting requirements don’t always need a report.