A commonly quoted adage in technology consulting is that “the last 20% of the work takes 80% of the time”. A report that will be used by a wide audience will often be designed by one or two key individuals that represent the wider business. However, due to this responsibility there is often the impression that the report must be fully completed with all functionality before it can be unleashed to the wider business. This can result in it taking a much longer time than expected to deliver new reports. However, by delivering the ‘must have’ information quickly and enhancing the report over time there can be significant benefits realised.
Faster Time to Value
By analysing the entire scope of the requirements given by the key business users it is possible to determine the core functionality which represents the Minimum Viable Product (MVP). If you are able to develop the core 80% of the functionality required within the initial 20% of the overall time that it takes for the full scope to be delivered, then there is a huge amount of benefit that the business users are able to get by starting to use this core functionality. This ensures that users are able to start getting value from the reporting product much quicker than if they have to wait for the full scope to be delivered, with the “nice to have” requirements often representing a significant proportion of the total development time.
Increased User Adoption
Another common challenge in analytics projects is user adoption. Too frequently there is a lot of time creating a bunch of reports which nobody actually uses. Users can often be frustrated with the amount of time that it takes to deliver reports, and the danger is that if this takes too long they will find alternative solutions to their reporting problems. However, using an agile approach can massively help with increasing the levels of user adoption by delivering the core reporting functionality to the users as early as possible. Additionally, the MVP will be simpler than the final report, meaning that it is easier for users to start understanding how to use the report. This also means they will be more likely to use the more complex functionality that might be delivered in a later iteration.
Better Quality
Lastly, and most importantly, the overall quality of the final reporting deliverable is likely to be much higher using an agile and iterative approach. The fact that business representatives often give the initial requirements can also mean that some key requirements from the wider business community are not captured. It can also be difficult for users to visualise and understand the reporting requirement without actually getting their hands on the data and starting to interact with it. However, by socialising the MVP version of the report you are able to receive much more feedback at an early stage of the development from a much wider user base. It can also be a lot easier to adapt to change and reduce the amount of rework that is needed. For example, if you’re baking a cake it’s a lot easier to adapt the ingredients when you’re mixing the cake than it is if you’ve added all of the ingredients and put the cake into the oven. This is very much the case when developing a report as often the functionality will build upon everything that has already been built, meaning it’s harder to change at the very end.
Using an agile approach to building reports can often lead to a solution that both meets the needs of the business users better and delivers value quicker. Viva la evolution!
