Your BI Project Shouldn’t Be a Lag Activity

There's a school of thought which advocates that Business Intelligence work should lag behind the other pieces of a larger project and that one should never attempt to undertake business intelligence (BI) activities in parallel with the other "core" activities of the project. The line goes something like this: you can't undertake a major project, say the implementation of a new ERP system, and design and implement BI over that system at the same time; the BI components have to happen 6 months or so later, they can't be designed and built as part of the main project because they are dependent on the main project items being in place first. Those espousing this popular line would have us believe that one can't build BI until the system is up and running, there's a good volume of data available and the business users have worked out what reports they really want and need. Anyway, there's no rush - reports and other BI items are only an output after all!

I disagree. Business intelligence items are as much an input as an output. Yes, they draw upon data in the system, but, compliance reports aside, the information they present should be used as part of a decision making process which then causes some course of action to be taken in a larger process. If this isn't the case then I'd argue that the report in question adds no value. It may just as well not be there!

Look at the idea of doing the BI components at a lag behind the main project through another lens. What this is really saying is one of a few things: 

• We don't need the information we'd get from the reports to base decisions upon;

•  We’re happy coming up with and using a range of time consuming workarounds;

• We’ve got a good gut feel for the business. We can get by making guesses for a while; or

•  We can get by not doing some of the things that we used to do before we put this new system in place. This could be anything from something as simple as not providing team managers with trend reports of absenteeism through to things with much more potential for a financial sting in the tail such as not re-forecasting project budgets after the initial baseline as been set.

Also take some time to think about the resultant behaviors that may arise from not having reporting and analytic capability available early in the life of your new system. People in your business need to make choices and they need information to do so. If they can’t get it from BI, from the right channels, then they’ll find and develop a myriad of workarounds in attempts to continue to do their jobs. Wait too long to bring BI to the party and chances are a good number of those workarounds will persist in various pockets throughout your business. 

So I’d suggest a pause for reflection before rushing to adopt the common [BI] scheduling wisdom. Put it in the above terms, mull over it, have the leaders in your business consider it too and then see if there’s still the same appetite to defer that BI work for six months. Yes, bringing the BI work in to the main project isn’t easy, challenges abound, at times it feels like you’re building on shifting sands but the pain of not doing it may be much worse.