Now we should turn to how to nail down what your sponsor and future dashboard users will use the dashboard for and when they are expecting it to be up and running. No need to dive down into the weeds at this point (see my blogs on Scoping for that), this is just a high level overview of the objectives and timing.
Your business sponsor should be able to give you a fairly concise description of their business problem(s). List these problems with the aim of a limit of three. Then focus on the business goals. Both of these should help you to write the objectives for the dashboard – e.g. my sales consultants need to monitor customer satisfaction feedback (business goal) so that we can improve our customer churn rate (problem: our churn rate is too high).
The next part would be to elicit how this will be done. In other words – what KPIs can help achieve this? If known, these can be identified at this stage. If you haven’t already been given some history of the sponsor’s business problems by now, this is a good time to bring it up.
- Are these KPIs currently monitored in another dashboard?
- Has someone tried to build a dashboard to solve these problems before?
- Why was it not successful?
- Will the new dashboard replace existing reports?
Make a note of these, their owners, data source and where they are stored in your planning worksheet.
Last, but definitely not least, you’ll want to get a general picture of deadlines and timings. The hard deadlines, such as a board meeting or specific event should be found out first, followed by any soft deadlines which could be “sometime in Q3” for example. For both of these types of deadlines, you’ll want to ask: what if the deadline can’t be met without changing the scope? Recording the answer to this sets their expectations and is extremely critical when delays and scope creep start to find their way into the dashboard building and testing phase. As with any project if you can under promise but over deliver, you will be in a much more enviable position!