Skip to content

September 4, 2011


Is Your BI Project in Trouble?

by Ravi Kalakota

Enterprise Business Intelligence (BI) project failure can happen for a variety of reasons.  Sometimes it’s due to frequent scope changes with a fixed schedule constraint, unexpected and unplanned-for “must-have” requirements changes, loss of key team members onshore or offshore,  chronic effort under-estimation, lack of proper work breakdown structure, lack of QA, and so on.

Regardless of the causes, BI, Analytics, performance management failed projects waste billions of dollars (and hours) each year.

Over the years, I have seen a lot of well-intentioned custom development, commercial, off-the-shelf package customization – SAP, Oracle, Peoplesoft ERP, CRM, SCM – and other enterprise data-warehouse projects get into trouble for a variety of reasons.  Troubled projects usually need triage, recovery, and turn-around skills to straighten things out quickly.

I am afraid that BI and Corporate Performance Management is reaching a phase in its hype cycle where we are beginning to see growing demand for troubled project recovery. It doesn’t take genius to realize that BI/Analytics project demand is growing as it is one of few remaining IT initiatives that can make companies more competitive. However, demand doesn’t imply project success.

This blog posting examines the complex, high-stress period of assessment and recovery of troubled BI projects and offers some steps for their successful recovery.  The steps are from the perspective of a turnaround specialist working on behalf of leadership to rein in a project, but they are applicable to BI project managers practicing “self diagnosis and recovery” as well.

Problem/Situation Summary

Every major corporation is investing in  BI projects these days to get an edge.  BI projects are key to enabling clients to turn oceans of data into predictive models and actionable decisions. The list of BI vendors is growing.  For a BI vendor landscape click here.  For investments in BI by vendor, click here.

While the vendor hype about BI, analytics, and big data is overwhelming, it’s necessary to realize that executing these projects requires careful planning, superb project execution and a little bit of luck for success.

Based on our interviews and discussions, it’s becoming clear that BI, analytics, data warehousing, and data integration project failure is rising.  Some of this is attributed to the growing complexity of the projects. Some of this simply poor project management and execution.

According to Gartner, 70 to 80 percent of BI projects fail or not meet expectations.

Project recovery and turnaround is a significant issue in the IT Industry for two reasons: (1) IT projects have a long history of failure to deliver what was originally committed; (2) Projects come in way over budget and over schedule in cases where they do finish.

In a tight economic environment, project recovery and turnaround is becoming a bigger priority.  Usually the warning signs can spotted early but they reach crisis mode often late in a project schedule (usually close to Go-Live).  I have seen projects literally go from “everything on track” GREEN to “crisis” RED status after a client review. That’s unusual. Project don’t go from “on track” to “failed” overnight.  They first become troubled and then seriously troubled.

The “troubled” period, however distressing, is a galvanizing moment—often the last opportunity—to turn things around and make the project a success.  But, how do you assess a troubled project? When do you put a recovery approach into action? How do you truly rein in a project on the brink of failure?

Characteristics of a Troubled BI and Analytics Project

Enterprise BI projects (usually in $5-20+M range like SAP BusinessObjects) have an enormous scope and cover multiple divisions, platforms, vendors and technologies.

BI and data projects are becoming incredibly complicated. A typical BI project consists of implementing:

  • Front-end BI applications that are used to provide querying, reporting and analytic functions to the organization’s knowledge workers.
  • Back-end source applications that feed the data warehouse that stores historical and current business data, as well as an OLAP server that provides analytic services.
  • A data integration platform for extracting, transforming and loading data (ETL) from disparate source systems, spreadmarts and unstructured sources into the BI target data warehouse.
  • New processes for data cleansing, audits and integration with other applications (ERP, CRM, SFA, SCM, legacy apps, etc)

Typically, these BI elements are implemented in phased manner and by different project teams (onshore and offshore). Each team (usually built around a vendor platform or a functionality set) implements the ability that meets most of its functional requirements. More tools and handoffs create greater complexity and increased interoperability issues, and need more advanced project leadership and coordination.

Enterprise projects get into trouble more often than not.  A “troubled” BI project means that the project’s triple constraints — time, cost and scope — have exceeded acceptable levels.  Usually without immediate intervention, the project in this state will continue on a critical path to failure.

The warning signs of a toxic project include:

  • Poor project definition and management of: Scope, Schedule, Cost; and Quality “baselines”
  • The customer has lost confidence that the project team will ever deliver the promised outcome
  • The team is defensive about its progress
  • Management has lost its  ability to control progress or even to find out the project’s status with any accuracy
  • No one has a firm idea of when the project will be finished and most people have given up trying to guess
  • Unrealistic resource allocations: (1) either too few resources allocated; or (2) Too many resources where PMs chaotic “throw more resources at the problem” while hoping for the miracle.
  • The selected product is evolving and version picked is laden with defects
  • Team members are working excessive hours 70-90 hours per week for several months but only reporting 40-50 hrs.
  • Relations between project team members and between client and project leadership are strained
  • Poor vendor (subcontractor) performance
  • The morale of project team has hit rock bottom — offshore and onshore team members start quitting
  • The project is on the verge of cancellation and client is threatening legal action

The dynamics of fixed price, fixed schedule and Time and Material (T&M) projects all tend to be different. So understanding the symptoms before a root cause diagnosis is critical to recovery.

Enterprise BI Project Recovery

When an Enterprise BI project reaches a troubled state, you do not have the luxury of taking your time to do the requisite stakeholder meetings, conduct bottoms up assessment and do a lot of planning.   Sponsors, clients, customers and other stakeholders will demand immediate results, findings and corrective actions.

They want changes quickly or demand that the project get shutdown.  There will be increased management attention and scrutiny on all activities from this crisis detection point forward.  So you have to act precisely and decisively by putting a recovery plan into motion.

Every project recovery broadly speaking has six key phases:

  • Recovery Intervention
  • Recovery Assessment
  • Recovery Recommendation
  • Recovery Planning
  • Recovery Execution
  • Recovery Closure (transition to normal execution)

Let’s look at two of these in more detail: A Recovery Assessment; and a Recovery Execution phase.

Doing a Rapid Assessment

The focus of the assessment phase is on determining the vital signs or real status of the project and the changes that need to be made in people, technology development, the specifications, and project management processes to improve performance.

Most firms try to use a “throw more resources at the late project.” This rarely works. Fred Brooks in his classic book “The Mythical Man-Month: Essays on Software Engineering”  illustrated convincingly that adding manpower to a late software project makes it later.  Brooks wrote about  the fallacy of adding workers to speed the work by a counterexample: If one woman can produce a baby in nine months, then nine women should be able to produce a baby in one month. The reason why this doesn’t work:  gestation is a sequential process, whose stages cannot run in parallel.

Enterprise projects (like SAP BusinessObjects or Oracle OBIEE) are complex so let the vital signs data tell the story. Building a recovery fact-base requires in-depth understanding the real status of the project (people, process, technology, tools, decisions).  The fact-base is the foundation of corrective action.  The unbiased assessment and recovery team must evaluate what has been done and what has not been done to build a recovery plan. The areas that must be evaluated to gain insights into the root causes behind slippage include:

  • Contracts, milestones, change orders
  • Project charters and Work Breakdown Structures (WBS)
  • Problems, Risks, Defects
  • Issue logs
  • Resources and hours spent
  • Schedule
  • Governance and control processes

Assessment sounds easy but is tricky to do for multi-faceted, multi-workstream projects. In a troubled project environment, tensions tend to run high, people are on the defensive, key members have been re-assigned or left the project, customers are angry and remaining team morale is often low.

Implementing Rapid Recovery

Recovery is defined as saving a project from loss (getting if off crisis-mode) and restoring it to normalcy.  Recovering a troubled project typically involves some key decisions affecting scope, schedule, resources and quality. These typically include:

  • Reduce the project’s scope, which speeds time to completion
  • Increase productivity by adding more specialist resources
  • Remove bottlenecks by focusing on short-term improvements
  • Slip the schedule to satisfy the scope objectives

In reality, it will be a combination of the above. The main goals in every project recovery plan are:

  • Producing an achievable schedule
  • Re-establishing customer and management confidence
  • Re-baselining the project plan
  • Sorting project problems
  • Rebuilding the original project team
  • Cadence – accurate and timely communications

After the recovery plan is generated, it’s time to move to pragmatic action. Unfortunately, it takes a much greater level of project management rigor and process quality to get a project out of trouble than was applied when the project got into trouble.

To maintain the focus in recovery execution, you must begin with the end in mind. The “end state” is a reconstituted project that is no longer in crisis mode. It’s on solid footing with an achievable plan, client participation and support, milestones being met, a well-defined project control and management system, and a team that believes and is motivated for the sprint.


Troubled IT projects are everywhere. According to the widely cited Standish Group’s 2003 CHAOS Report, an analysis of 13,522 IT projects shows that 15% “failed” and another 51% were considered “challenged.” While the overall failure rate is down significantly from a 1994 level of 31%, 82% of projects now experience significant schedule slippage and only 52% of required features and functions currently make it into the released product. 

Recovery of troubled BI projects is simply the next wave. A realistic and pragmatic way to approach project recovery is going to be increasingly required for project teams who are executed BI, Analytics and Big-data projects.

A great many BI projects “go off the rails” because they attempt to follow a traditional IT development lifecycle (analysis, design, build, test, deploy, and adjust). The project attempts to deliver everything sequentially, struggles with the enormity of the situation and is eventually reduced back to a series of quick wins (“footstone” based delivery instead of “milestone” ) providing diminishing value to the client.

As a result, two laws of project recovery tend to hold true; (1) The effort required to correct a project that is off course increases geometrically with time; (2) If project content is allowed to change freely, the rate of change will exceed the rate of progress.

In summary, project recovery is serious business and one that requires senior management attention. It’s often a thankless job where the team brought in to fix the project has to deal with lots of negative issues. Typically, management will go outside and get a specialist.

Additional Notes and Links

  1.  Alvarez and Marsal (A&M) has a dedicated “IT Troubled Project Recovery” group.  Over the past two decades, the team has parachuted into numerous troubled ERP, CRM and other IT projects and helped management and private equity firms turn things around.
  2. A big reason why projects run into trouble is the disconnect between procurement, business and technology.  In large fixed price contracts, Sourcing/Procurement leadership wants to mitigate risk and setup contracts with lots of recourse if the project fails.  However, at the outset, the right level of detail is not available as the business don’t really know what they want. Also technology, data and integration constraints discovered when the project starts often impact the direction of the project.
  3. Conflicting motivations often make the project recovery process difficult.  Client wants to know: When are you going to deliver our (already late) project; Project Finance wants to know: How much is it going to cost us to get out of this (mess). In fixed price and fixed schedule projects the disconnect becomes acute.
  4. See: Why Most Business Intelligence Projects Fail (
  5. For interesting project failure metrics See: A 50% Data Warehouse Failure Rate is Nothing New (
  6. For an interesting perspective see: Friends Don’t Let Friends Overpay for BI (
  7. Project recovery techniques have to be tailored to the maturity of the firm and the organizational scope (departmental, line of business, centralized shared services, corporate). A BI Shared Services, Competency Center or CoE structure is proven to reduce the risk of complex projects…see;
  8. If you need more details of what goes into a troubled project assessment and recovery contact me ( ). This blog posting is not the place for all the requisite detail involved a complex project recovery process.
3 Comments Post a comment
  1. Sep 7 2011

    Hi Ravi,

    I have published some more generic articles on the topic, including this one on identifying troubled projects. Your article though is specific about BI projects, and thus I think your topic is unique (I have never seen it discussed before).

    I’m sure that some PM Hut readers will be interested in your topic, and that’s why I would like to republish your article on PM Hut. Please either email me or contact me through the “Contact Us” form on the PM Hut website if you agree with the republishing.


  2. Richard Parsons
    Nov 8 2011

    It’s an excellent article Ravi – worthy truths and hallmarks.

    I appreciate the focus is a subset of BI: the ‘Enterprise BI project’ – “Enterprise BI projects (usually in $5-20+M range like SAP BusinessObjects) have an enormous scope and cover multiple divisions, platforms, vendors and technologies.”

    I suggest that the size of the project is a key risk factor for failure. BI is not something that must be delivered big bang style. Fewer and fewer tech-enabled change projects are. In my own experience, the grand enterprise project approach is almost always a terrible idea. That A&M has a dedicated rescue team for this sort of thing is telling.

    Full disclosure – I work in a business that almost always takes a different approach to BI for Clients (and for ourselves).

    Aim small, miss small.

    A smaller scale, specific-business-problem-solving approach (with doors wide open to scalability), unlocks benefits in weeks, not quarters or years (per project), improves focus and commitment, reduces risk, increases credibility, better matches investment and return, and develops (positive) standing demand around very deliverable and meaningful expectations. A set of these sorts of projects, each conditional on success of the last, approaches and delivers the target outcomes of the ‘Enterprise BI project’ in an entirely more manageable way.

    And it’s fun (mostly), in that way that grand enterprise projects are not.




  3. Nov 30 2012

    Great Article! While it is true that BI systems are useful, and very much needed for large organizations to stay competitive, the reality is that all these systems are backwards looking.
    You are constantly looking at the costs you’ve already incurred, and problems that already impacted your business.

    This is why Predictive Analytics is such a vital tool to have on top of your ERP or BI systems.
    Check out – they provide today’s leading predictive analytics systems that really take a comprehensive look at your business and help you make better decisions as you move forwards. Super sophisticated mathematics, with an intuitive, and easy to use user-interface.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments

%d bloggers like this: