This content originally appeared on DEV Community and was authored by Helen Anderson
As analysts, we’re often asked to quickly produce dashboards or metrics that aim to solve a specific problem. This is more challenging than it sounds as data isn’t always available, in the right format, and sometimes a dashboard isn’t the right way to present insights we do find.
Scoping sessions help us to understand the underlying problem so we can deliver what the stakeholder needs, and not just what they think they need. If you’ve ever read through a request for data and asked yourself ‘what problem are we actually solving?’, or ‘how are they going to use this data?’ it’s time to run a scoping session.
Why?
Help me understand the problem this data will solve?
Open up the conversation by trying to understand why the dashboard or data has been requested. The answer will help give context to the request and how it will help make a decision, optimise a feature, or inform. This context is great for getting to grips with the data request and also appreciating the greater vision our stakeholder has.
What?
What is the definition of done?
The answer to this question helps determine what will solve the problem. The effort involved in producing a one-off number, a chart for a slide deck, a csv file they edit themselves, or a dashboard that refreshes each month varies. Teasing out what the stakeholder thinks they need during a face-to-face conversation isn’t about ‘solutionising’ but finding out what the stakeholder’s expectations are.
What data do you have access to already?
Any insights already gained make a great starting point. This doesn’t have to be data or research, any links to relevant documentation, websites, and meeting recordings can be useful while understanding the scope of the request.
It’s also worth finding out if the stakeholder has any existing reports or dashboards that need to be aligned to. If there is business logic here or an expected range results need to be in getting access to this early is useful.
Who?
Is there anyone else working on this?
Just like finding out if there are existing numbers to align to, it’s important to find out if there is someone else working on producing something similar. Understanding their roles and responsibilities as well as your own means the project can get off on the right foot.
Who will need access to the insights or report?
This is important to finalise who needs to see the results, but also who doesn’t. If the final report is commercially sensitive it’s worth getting this information in advance. Security groups may need to be created and the stakeholder can be reminded of their responsibilities for keeping the data secure.
How?
How can we get access to the data we need?
This is relevant when you need access to new data or application-level data that isn’t available in the data warehouse. If you need to engage the help of DBAs or data engineers from other teams you should get this arranged early. No analysis work can begin if you have no data to work with.
How would you prefer results be delivered?
Talk through options for a final report at a very high level. This doesn’t mean you need to go into the details but broadly talk through the options to be considered. Discuss the trade-offs between all the possible options and if there are any uncertainties and data gaps you can foresee.
It’s important to note you shouldn’t come up with a solution based on similar reports done in the past. The key to scoping the requirements is to understand the problem and create a solution, not replicate what’s been done for another project.
When?
Are there any hard deadlines to meet?
This is relevant if you are required to pull numbers for a press release or a board report with a deadline. Knowing this will help you focus on creating a timely solution that maybe isn’t perfectly polished.
Discuss your confidence in the data only if you have worked with it before and are confident it hasn’t changed. If you haven’t seen the data don’t promise a delivery date. You need to take the time to think through the requirements and see what you are dealing with.
What’s next?
The scoping session process isn’t over at the end of your meeting. Show that you have understood the problem by writing up what you believe the requirements are, the timeframes you are working with, and the next steps for your stakeholder.
This pattern doesn’t work for every situation so you will need to adapt your questions for each project. The point here is to build relationships and offer help to stakeholders so they gain trust in us and our process. Encouraging our stakeholders to really think about what they need from their data will make for smoother projects both now and in the future.
Read more
Shaping your team culture
Helen Anderson ・ Sep 9 '20 ・ 3 min read
This post originally appeared on helenanderson.co.nz
This content originally appeared on DEV Community and was authored by Helen Anderson
Helen Anderson | Sciencx (2021-05-06T10:56:00+00:00) Do you really need a dashboard?. Retrieved from https://www.scien.cx/2021/05/06/do-you-really-need-a-dashboard/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.