5 Common Business Intelligence Project Mistakes #2

5 Common Business Intelligence Project Mistakes #2

Second in a 5-part series

In my first post on 5 Common Business Intelligence Project Mistakes, I discussed the first common mistake of not bringing operations / infrastructure colleagues on-board early in a new BI process. In this post, I’ll talk about the second most common mistake, provide a specific example, and explain how you can avoid making it.

Mistake #2:

 You don’t create a proof-of-concept/pilot/quick win iteration before full implementation.

A BI project is usually a resource-intensive initiative.  I’m surprised how frequently a greenfield project is started in full-throttle mode – establishing milestones and deadlines in the far future and focusing on major elements. Project managers create extremely detailed plans. Management approves them and starts to expect results and hopefully green dots on the status reports. Business analysts continue churning out the requirements. Solution architect and developers start profiling sources and work on data models. The whole mechanism comes into motion.

There is one problem though, and that is estimating. Most likely, a lot of the estimation was really “guesstimation.” Imagine this scenario: the project manager requests estimates from the technical team in the very beginning of the project.  However, the only information they might have at this early point might be the number of source tables, data volume, and approximate number of existing reports (which is still not sufficient indicator of workload). They do their best to estimate; however, that guess is almost always incorrect. From my experience, there are always some situations which render this approach inaccurate.

I’ll provide a specific example. A BI team had to extract some data from Excel files that were used by many analysts in the organization. The initial expectation was that this activity would not take more than a day. As a result, this activity got pushed to the middle of the project’s lifecycle. However, at a closer examination, it became apparent that it was not just a single spreadsheet – it was an Excel monster with almost 50 linked spreadsheets and close to a 100 of complex macros. Adding insult to an injury, there was no documentation (it just worked). We managed to extract most of the data and rules; however, it took much longer than a day. This could have been avoided if we tried to extract some of the data from the spreadsheet in the beginning of the project.

You would not purchase a car without first test-driving it, would you?  Hence you should plan for an initial proof-of-concept roll-out for your BI project. By doing this, you will:

–          Set up BI software and establish your dev/test/prod environments, working out any kinks upfront

–          Improve communication between team members, establishing rapport.

–          Familiarize business users with the development process and the BI tool of your choice

–          Establish early visibility for the project and gain management’s buy-in (everyone likes to share in a success story)

–          Catch small bugs and issues before they grow into monsters

My suggestion is to keep your BI project relatively simple, focusing on a solvable business problem (that could be a part of a bigger picture), and ideally planning for a 12-week release that would enable enough substance to build on.

Stay tuned for Mistake #3 in my next post.


Write a Comment


Contact Us Close