The requirements gathering in any IT project is essential. In Business Intelligence it ensures that both parties agree on what story the dashboard will tell. Having a standardised process within your BI team is vital as it not only protects the stakeholder but also protects the BI developers further down in the development life-cycle process.
Consider the scenario that you have a new stakeholder that you have never worked with before. What are the steps that you have to take early in the process to ensure that the client's requirements are successfully captured and the project is delivered ensuring all requirements are met?
My process includes a series of Requirements gathering meetings (could be one or more). The agenda for the meeting will include:
Introduction
Introduce yourself and get to know the stakeholder a bit more.
Get to know his involvement in the project and what his responsibilities are.
Also, inform him of any other projects that you might be working on simultaneously which might affect the deadlines in future.
Become aware of his workload as well.
Who are the main stakeholders apart from him that are involved in the project?
2. Define ways of working and checkpoints
Doing this early in the requirements phase process ensures that both parties agree on the communication style and also how often you will report on the project progress.
Some suggestions - set up a slack/Microsoft teams channel, have a checkpoint meeting (e.g. every Tuesday at 11 AM) to report on progress and do live demos, and send a weekly update to all parties interested in your project to inform them of progress and blockers
3. Proceed into requirements gathering using a templated Dashboard Planning Document
The questions you might consider asking in your Dashboard Planning Document are:
What is the Dashboard objective? - Describe a concrete goal for the dashboard. Use plain English to explain what is the dashboard about and what story is it trying to tell.
What are the Team Processes that you should be aware of? - Describe the team processes that need to be taken into consideration. How are they using the metrics? How does the team operate and how will they use the information?
Record the main KPIs and Metrics (into a table)
Metric | Definition | Formula | Notes |
| | | |
| | | |
| | | |
Who is your target audience? - Identifying the target audience early in the process will help you understand whether you need to restrict the dashboard to only specific users or apply any Row Level Security if needed.
Call to Action! - What decisions and short-term actions can the end-users take based on this dashboard?
Include Wireframes! - Include designs of the charts including filters as part of your design phase. A picture paints a thousand words!
What is the Data Update Frequency? - How often does the client need the dashboard updated? - (Hourly?/Daily?/Weekly?)
Define Deadlines (subject to change) - It's always good to define deadlines early in the process but make sure to communicate with the client that those are subject to change as there might be unknown blockers that you are not yet aware of. Also, take your colleagues' Annual Leave into consideration.
Always require a signature! - Requiring a signature is an essential part of the requirements gathering process. It not only protects you as a Developer but also protects the stakeholder. It ensures that the project will be delivered to the agreed requirements.
Having a clear process for gathering requirements and getting to know your new stakeholders will help you massively in successfully completing any new BI project. I have shared with you my personal approach to tackling the requirements gathering phase of a project. Please feel free to share or add any ideas that might improve my current process.
_edited_edited.jpg)
Comentarios