This blog is part of a series. You can find the first one here.
When you are working in a (BI) team and you have stakeholders that expect you to produce an analysis, it is important to communicate well with them also on the way of working of the team. As a matter of fact, you also need things from your stakeholder. Not only requirements! From my experience, it is a good idea to work in an iterative way, so that you make sure that the “final” product actually is useful. So scheduling touch points and planning meetings in advance with your stakeholders, explaining what you need from them is important.
What does working iteratively means to me?
It means that you prioritise the work and the requirements, it means being more productive and efficient. You start with developing a Minimum Viable Product so that the users and the stakeholders have something to use in their daily work. Then in the meantime they can also test it (explain how!), and then the additional requirements can be added and integrated step by step (agree with the stakeholders!). Again in an iterative way. And of course, all this you would discuss with your stakeholders. Don’t forget to work hand-in-hand with them, so make sure they know what to expect too.
What should you do and ask of your stakeholders?
Your stakeholder is working with you, so they need to give some of their time to meet with you, listen to your questions and answer them, ask you questions, taking the time to look at your work and give you feedback, testing your work, etc.
This very often is not clear, because there is no communication happening on what working on an iterative way means or what is expected from them too. So make it clear! Explain everything!
How do you get started?
Start with a sketch that reflects the MVP (Minimum Viable Product): pen and paper can work, a blackboard, but also a power point slide or whatever digital tool you might prefer. Drawing a sketch makes it real, tangible and many people like to see things visually, it helps them to get a clearer understanding. Discuss the sketch with your team, with your stakeholders and then start to build a prototype in your BI tool.
Demo time!
Once you have the prototype, it is time to demo it to your stakeholder! Highlight the functionalities is ok, but it is much better to find a story – impersonate someone using the dashboard and show the user experience through this imagination character (of course it needs to be plausible). It is not only about functionalities but it is mostly about storytelling. What are you getting out of your analysis?
Moreover, something to think about is going a step further and maybe add some additions that can add value and you spotted or thought about while prototyping.
Seek for Feedback!
After your demo, seek for feedback. Be proactive too, maybe highlighting some things you see room for improvements, ask again questions to your stakeholders, go deeper.
Once you are happy with the first round of feedback, go back to development and implement the feedback you received. Again also here, be proactive! If you think of some additional things, propose them!
And then what?
Then it is a matter of continuing to meet and work iteratively, until the feedback, additional requirements, testing, etc. are all incorporated into the “final” analysis. And don’t forget to help your stakeholders with testing, guide them and monitor how they are doing that.
Conclusion
Of course, not all analyses are the same – some might be simplers, others more complicated, others might require a very big team and have lots of dependancies. But in the end – in all cases it can be helpful to incorporate an iterative way of working. Breaking down something in smaller chunks and build upon can save a lot of time and can also save from misunderstandings, that can affect the success of the project down the line. So it is a benefit for everyone!
Please, continue to follow this blog series if you are interested to drill down more.
Reach out if you want to learn more on how we can help your organization.