This post may court the Business Week curse, but I’m highlighting this story on BI and the recession (here) as the jumping off point for a couple of observations. Rob T.’s comment in the piece (sorry, but I can’t link directly) notes that:
Unlike ERP, BI can be implemented step-wise, first in targeted, strategic areas, and then using a broad brush once it’s value has been proven. A wise strategy for this economy is to start small, pick a problem or area where a quick win is possible and attack it with a 60-90 day effort.
I mentioned this opportunity for short, focused projects in my WSJ interview. These short cycle times and the nature of BI work pose problems for traditional ERP change control and deliverables definition.
For example. what exactly is “done” on a BI project? The traditional ERP definition of deliverables — focused on processes that deliver tangible, measureable outcomes (e.g., Order to Cash, Purchase to Pay, Hire to Retire) — doesn’t work well for BI. Typically, reporting projects focused on # of reports, explicitly defined. Also, in analytics projects those reports or queries often spark more ideas for how data can be cross-tabbed, projected, etc. Do you always want to be presenting a change orders for new reports?
What has worked for you when defining deliverables and change control for BI initiatives? Now if you’ve read this blog for a while, then you can guess that I’m in tune attacking these issues with a capabilities-focused approach to deliverables. This approach points one in the right direction when defining what done looks like. However, many PMs find it hard to grok the requirements and required capabilities of analytics-savvy stakeholders and consultants.