Representative End User Clients
Representative Automation Clients
Representative Software Clients
In my post last week, I outlined the two top strategies that aspiring high-performing analytics teams should adopt:
Fortunately, these are complementary strategies - you can work on both at the same time. I'll deal with formalizing the approach to projects in this post, and we'll get to self-service next week.
When it comes to formalizing the approach, there are two main steps to bear in mind:
Many software development projects now use an agile methodology in place of the very traditional waterfall approach. BI and analytics projects should definitely avoid the classic waterfall approach - it just isn't well suited to business intelligence projects. The waterfall approach is dependent on locking down the requirements early and then pretty much sticking with them. Flexibility is not something waterfall is renowned for...That doesn't marry well with BI and analytics because:
So an interative, incremental approach that embraces software prototyping works much better. For example, show the users a prototype of what they will see and work with (e.g. a dashboard) as early as possible. Iterate that prototype until you have something that reflects the users needs. With the right tool and a few hours, sitting side-by-side, a BI developer and a user should be able to complete this. It's very much a visual and decision-centric approach. Waterfall often seems to be data-centric. A better approach is to show the user how they will interact with the solution to make decisions as early as possible, and worry about where the data comes from after that.
Time to solution is improved too by incremental delivery. Instead of a big bang approach, use bite-sized chunks to implement the solution.
Some BI teams still seem to waste time creating the same reports, over and over. Analytics really shouldn't be a cottage industry in the 21st century. Using spreadsheets, for example, to hand-craft a report every week is just a failure to understand economics. High performance teams automate routine work so that they have more time to dedicate to the more challenging and more strategic aspects of their role. So, try this:
Remember the aim of the game: Get the right information, to the right people, at the right time…at the lowest possible cost. Formalizing your approach can help to achieve both of those goals.
- A formalized approach
- Enabling self-service
Fortunately, these are complementary strategies - you can work on both at the same time. I'll deal with formalizing the approach to projects in this post, and we'll get to self-service next week.
When it comes to formalizing the approach, there are two main steps to bear in mind:
Use an iterative, incremental approach
Many software development projects now use an agile methodology in place of the very traditional waterfall approach. BI and analytics projects should definitely avoid the classic waterfall approach - it just isn't well suited to business intelligence projects. The waterfall approach is dependent on locking down the requirements early and then pretty much sticking with them. Flexibility is not something waterfall is renowned for...That doesn't marry well with BI and analytics because:
- Analytics is often very visual - in my experience, users often know what they want when they see it. But, it's hard for them to describe it well up front. The ad hoc, interactive, "make-it-up-as-you-go-along" nature of modern analytics doesn't help either.
- Information needs change too fast in today's business. As noted, the waterfall approach locks down requirements early and then just grinds on steadily to completion. If that takes too long - a year or two - then chances are the business has already moved on and the project is no longer relevant. Either the management decisions that need to be made have changed, or managers have found a workaround to get the information they need.
So an interative, incremental approach that embraces software prototyping works much better. For example, show the users a prototype of what they will see and work with (e.g. a dashboard) as early as possible. Iterate that prototype until you have something that reflects the users needs. With the right tool and a few hours, sitting side-by-side, a BI developer and a user should be able to complete this. It's very much a visual and decision-centric approach. Waterfall often seems to be data-centric. A better approach is to show the user how they will interact with the solution to make decisions as early as possible, and worry about where the data comes from after that.
Time to solution is improved too by incremental delivery. Instead of a big bang approach, use bite-sized chunks to implement the solution.
Automate routine work
Some BI teams still seem to waste time creating the same reports, over and over. Analytics really shouldn't be a cottage industry in the 21st century. Using spreadsheets, for example, to hand-craft a report every week is just a failure to understand economics. High performance teams automate routine work so that they have more time to dedicate to the more challenging and more strategic aspects of their role. So, try this:
- Standardize reports. As far as possible, cover basic information requirements with a set of standard reports and charts.
- Automate everything you can - the generation of those standard reports, the data integration required, the weekly data refresh required - and so on.
- Save your precious IT skills for strategic stuff that really matters. That would include analytics strategy, technology and product evaluation, and working on enhanced analytics. Perhaps most importantly for many organizations, it also means having time to expand the user population and bring analytics to new groups of users.
Remember the aim of the game: Get the right information, to the right people, at the right time…at the lowest possible cost. Formalizing your approach can help to achieve both of those goals.