A commonly quoted adage in technology consulting is that “thelast 20% of the work takes 80% of the time”. A report that will be used bya wide audience will often be designed by one or two key individuals thatrepresent the wider business. However, due to this responsibility there isoften the impression that the report must be fully completed with allfunctionality before it can be unleashed to the wider business. This can resultin it taking a much longer time than expected to deliver new reports. However,by delivering the ‘must have’ information quickly and enhancing the report overtime there can be significant benefits realised.
Faster Time to Value
By analysing the entire scope of the requirements given bythe key business users it is possible to determine the core functionality whichrepresents the Minimum Viable Product (MVP). If you are able to develop thecore 80% of the functionality required within the initial 20% of the overalltime that it takes for the full scope to be delivered, then there is a hugeamount of benefit that the business users are able to get by starting to usethis core functionality. This ensures that users are able to start getting valuefrom the reporting product much quicker than if they have to wait for the fullscope to be delivered, with the “nice to have” requirements often representinga significant proportion of the total development time.
Increased User Adoption
Another common challenge in analytics projects is useradoption. Too frequently there is a lot of time creating a bunch of reportswhich nobody actually uses. Users can often be frustrated with the amount oftime that it takes to deliver reports, and the danger is that if this takes toolong they will find alternative solutions to their reporting problems. However,using an agile approach can massively help with increasing the levels of useradoption by delivering the core reporting functionality to the users as earlyas possible. Additionally, the MVP will be simpler than the final report,meaning that it is easier for users to start understanding how to use thereport. This also means they will be more likely to use the more complexfunctionality that might be delivered in a later iteration.
Better Quality
Lastly, and most importantly, the overall quality of thefinal reporting deliverable is likely to be much higher using an agile anditerative approach. The fact that business representatives often give theinitial requirements can also mean that some key requirements from the wider businesscommunity are not captured. It can also be difficult for users to visualise andunderstand the reporting requirement without actually getting their hands onthe data and starting to interact with it. However, by socialising the MVPversion of the report you are able to receive much more feedback at an earlystage of the development from a much wider user base. It can also be a loteasier to adapt to change and reduce the amount of rework that is needed. Forexample, if you’re baking a cake it’s a lot easier to adapt the ingredientswhen you’re mixing the cake than it is if you’ve added all of the ingredientsand put the cake into the oven. This is very much the case when developing areport as often the functionality will build upon everything that has alreadybeen built, meaning it’s harder to change at the very end.
Using an agile approach to building reports can often leadto a solution that both meets the needs of the business users better anddelivers value quicker.Viva la evolution!