How to ensure business intelligence doesn’t turn into business disaster

The novelty has worn off business intelligence (BI) as it expanded over the years into many organizations. BI is no longer some skunk works adventure that runs independently of the formal organization with little or no oversight beyond nominal executive-level sponsorship. BI projects are now subject to more traditional governance processes that include formal approval of a credible business case and ongoing oversight by the project management office.

Six reasons BI has become mainstream

Interest in BI has grown, even exploded in some organizations, and matured almost everywhere because:

1. BI has produced irrefutable business value.
2. BI opportunities have grown sharply as more and more organizations have become increasingly digital often through a digital business strategy.
3. BI is now recognized as the key technology for creating business value from big data.
4. The cost to develop BI applications has decreased significantly as:
   • Software development tools have become more powerful, cheaper, and easier to use.
   • Data integration processes have been simplified.
   • The cost of computing resources has decreased.
5. Data is being recognized as a strategic asset with BI revealing that value.
6. Organizations are paying more attention to improving data quality that is a prerequisite to BI success.

Ask these 6 questions before deploying BI

What do loser BI business cases look like and how do we avoid them? How do you avoid becoming:

1. Tangled up by uninformed challenges to the business case?
2. Pushed to accept huge scope that can only lead to failure?
3. Consumed by low value internal hoop-jumping review and approval processes?
4. Obligated to create mushy estimates for unknowable tasks?
5. Frustrated that the business value you want to deliver is being delayed?
6. Challenged to estimate business benefits to more accuracy than is feasible?

I’ve described a series of horrible real-world business case strategies that you must avoid at all costs because your BI project will crash and burn. For each dysfunctional strategy, I’ve described a more successful alternative strategy that can win approval for your BI project and help you move forward in delivering benefits.

Avoid an intense BI business case

Because you really don’t know the project scope and issues you are likely to face at this early stage, avoid an intense BI business case that is many pages long and contains:

1. A detailed BI project plan with a huge number of tasks that also claims to estimate effort and schedule for that plan in even more detail.
2. Detailed BI project costs to a narrow range between upper and lower estimated cost.
3. Tangible benefits estimated in considerable detail.
4. A lengthy list of assumptions.
5. A comprehensive list of risks with mitigations.

Not only does all this planning and BI business case writing consume a lot of effort, but these early numbers will also be wildly different from the eventual project reality. Worse, this detail is not likely to increase your success in achieving funding approval because stakeholders will challenge, or at least pick at, the benefits and the estimates.
Instead, develop a modest project description. By modest, I mean a two-page project description for a BI prototype that consists of:

1. A brief description of an innovative BI application idea.
2. A business case consisting of:
   • A conservative tangible benefit estimate of three to five lines with a lower and higher range.
   • A reasonable, but not large, cost estimate of five to eight lines with a lower and higher range.
3. A reasonable intangible benefit list of two to three lines.
4. A list of BI prototypes and data warehouse enhancements.

For example, department managers keep expressing their frustrations about poorly completed orders that are difficult to fill accurately and are triggering a high return rate. You recognize that multiple improvements are likely required. You want to start by creating a series of BI queries to better understand the scope and magnitude of the problems. You draft a modest business case to pitch to the department managers.
A modest project description is often a successful approach for selling your departmental BI project because:

1. The cost is within a manager’s approval limit.
2. Success will provide valuable insights into describing a larger follow-on project.
3. There are no consequences associated with failure.
4. Failure can often be spun as a useful innovation.

Avoid an implausible BI business case

Avoid the temptation to develop an astounding business case, even if you believe it, because that will be received by stakeholders as an implausible BI business case.
Worse, an implausible BI business case ratchets the organization’s expectations so high that your BI project risks being judged a failure even if you deliver huge business benefits.
Instead, a winning strategy is to develop a project charter that includes a business case. A simple project charter consists of:

1. The description of the business opportunity that you see.
2. An outline of your proposed approach to executing the BI project.
3. A rough project plan.
4. A summary business case.
5. An initial project budget.
6. The project organization including the members of a steering committee.
7. An initial risk list with some proposed mitigation strategies.

For example, a vice president sees an opportunity to dramatically expand the territory in which the company sells and services construction equipment. However, it’s difficult to model what the opportunity might produce in terms of sales and net income. Similarly, it will be challenging to forecast capital investment and operating expenses. You realize that producing a reasonable expansion plan will require significant amounts of external data that your company has never gathered and integrated before. You draft a project charter to describe to the vice president what will be required to model the expansion idea in more detail.
Socializing a project charter is often a successful strategy for achieving a consensus on the direction to take when you’re proposing a larger BI application that spans the data sources of multiple departments. In this situation, a stakeholder consensus is often a prerequisite to funding approval.

Avoid a hefty enterprise-wide BI business case

In all cases, avoid a strategy that calls for a BI mega-project and lays out a hefty supporting enterprise-wide BI business case. BI is better implemented or enhanced through a series of modest, focused projects that successively deliver additional tangible business benefits.
For example, a senior executive sees a major opportunity to dramatically expand the use of BI across the continent to:

1. Improve many aspects of business performance.
2. Make performance measures easily accessible to most employees.
3. Encourage a significant increase in the adoption of BI technology for informal self-serve applications.
4. Upgrade data quality and integration significantly to support performance measures and data accessibility.

The contemplated BI project is expected to address a wide range of BI topics including:

1. A better understanding of sales patterns.
2. Sources of quality lapses.
3. Trends in customer service engagement.
4. Causes of product returns.
5. Analysis of product defect and scrap rates.
6. Financial performance variances.
7. Competitor market share and performance comparisons.

Such a major enterprise-wide BI project faces enormous people change management hurdles, major data integration challenges and too many inter-departmental non-co-operation issues to achieve success.
Even if an executive is prepared to fund and sponsor a major enterprise-wide BI roll out, this ambitious moon-shot project is more likely to turn into a quagmire that you don’t want to be associated with. Channel this executive enthusiasm into a more modest BI project focused on the most promising part of the enterprise-wide aspirations that apply to a single department that’s also led by a supportive executive.

Instead, with executive backing, you can develop one of the winning BI business cases that I’ll discuss in the next blog.

What strategies would you pursue to avoid a horrible, unsuccessful business case for a BI project that a stakeholder is trying to impose on you? Let us know in the comments below.