BI Success Often Looks Like an IT Failure

SOURCE: LogiXML

July 16th, 2012 by Charles Caldwell, Manager, Sales Engineering

Truly successful BI projects will look like IT project failures to many people.  For anyone used to delivering traditional IT systems (desktop productivity, back office and front office automation, data entry systems, etc.), BI has always seemed frustrating.  The model of defining requirements, delivering requirements, and then maintaining the system over a three to five year life span just doesn’t seem to work in BI.  Many BI practitioners, particularly first-time implementers, will report with a large degree of frustration, “Every time we give them what they asked for, they come back with changes in their requirements;  we never seem to get it right, they can’t tell us exactly what they need, and we can’t keep up.”

The industry has long looked at this experience with a sense that it should be different.  Shouldn’t BI projects behave more like other IT projects?  Shouldn’t we be able to “get them right the first time?”  And more recently, we’ve thrown in the towel and gone looking for new methodologies to adapt to what seem to be never ending change in requirements.  BI Competency Center and Agile BI methodologies, though from different backgrounds, both espouse close proximity to the business, iterative approaches to building infrastructure and applications, and trying to more functionally cope with what seems to be the holy grail of “getting BI right.”

So why is BI so poorly behaved compared to a “traditional IT project?”  Why is it that we can “never get it right?”  And why might that actually be a sign of BI success?

Let’s take an Expense Entry System as an example of a traditional IT project.  You need to enable business users to enter expense items with some key information: vendor, expense account, amount (or perhaps at times units and rate such as mileage), and date. You probably need some approval functionality, the ability to add new users, new vendors, new expense accounts, and so on.  And you may need to layer in expense policy rules, alerting, and some workflow.  This could be relatively complex, but the requirements to support the expense reporting process are well known and change very little over time.   You gather the requirements, implement (perhaps in multiple versions), and go into maintenance mode.  (I apologize for oversimplifying.)

Now, let’s take Expense Entry Reporting.  It seems obvious that we’ll need to see reports on expense by account, or by employee, or by manager, or by date.  We probably also need some workflow reporting, such as pending approvals.  But what will happen is that once the business users start working with data and learning more about the business, they will formulate new questions.  What if the mileage rate increases next year?  Is there seasonality in our lodging expenses?  Does any vendor make up 50percent of expenses in a given account?  What were meal expenditures for the Northwest sales team in 1995 and 2005?  Even if you give them the super, self-service BI solution with “all the data,” my experience is these requests don’t stop.  And now, add in all the other IT systems we could use to generate reports.

Here’s the deal:  Most IT systems are about support known processes.  Enter your expense report.  That’s it.  BI systems are about supporting both known processes (did everyone enter their expense report?), as well as unknown (or unforeseen) processes.  Said another way, BI supports learning.  It helps the business learn new things about both internal and external conditions.  And as we learn, two important things happen:  We change what we do and we change the questions we ask.  And guess what, both of these will change the requirements of your BI system.

In the most successful cases, BI projects generate competitive advantages which allow you to change the rules.  And that won’t just make the BI system obsolete.  You’ll be reworking entire parts of your organization, as well as the systems that support them.

Charles Caldwell is a sale engineer manager at LogiXML. Read more posts by Charles here,  here , and here.