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 understand the underlying problem so we can deliver what the stakeholders need, not just what they think they need. If you’ve ever read through a request for data and asked yourself ‘What problem are we 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 there are any existing reports or dashboards that need to be aligned. If there is business logic or an expected range of results 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 someone else is working on producing something similar. Understanding their roles and responsibilities 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, and 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 talk through the options. 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 so you can 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. 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 what you believe the requirements are, the timeframes you are working with, and the next steps for your stakeholders.
This pattern doesn’t work for every situation so 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 think about what they need from their data will make for smoother projects both now and in the future.
Top comments (2)
Such a great post. To me sounds like a mini-guide of what you need to think of before agreeing to show something at the end won't solve a thing.
I love it. It's like list of feature that must considered while making a dashboard.