Why high percentage of BI projects end in abandonment or failure

1

Practical Advice from the Experts

Part 1: Why high percentage of BI projects end in abandonment or failure?

Zeyad Sweidan

24 September 2008(Last updated 25/09/08 to include input from attendees)

2

Introduction A questionnaire was sent to ACS members with the

following questions: Q1) What is your definition of failure? Q2) In your opinion what are the 3 most causes of BI project failure? Q3) Lessons learnt from previous projects? Q4) Any particular question you want to ask the experts in relation to

causes of BI project failure?

This presentation is to share the responses and use them as discussion points with the panellists and audience

3

Meet the Panellists

Hanne Breddam: Director, BusinessMinds

Steve Hitchman: Managing Director, Management Information Principles (MIP)

Andrew Cherry: Principal Consultant & CBIP, InductiveDW

4

BI Project Failure

“60% of BI projects end in abandonment or failure” Business Intelligence Roadmap by Moss, Attre

“In 2005 Gartner predicted 50% of data warehouse projects through to 2007 will have limited acceptance or be outright failures ” searchcrm.techtarget.com

“A recent National Computing Centre survey

found 87% of business intelligence projects in the UK do not live up to expectations ” cbronline.com july 07

5

Everyone’s Fault

Say NO to isolated business intelligence systems.wmv

6

Definition of Failure..in General

“Failure (fail, phail or flop) in general refers to the state or condition of not meeting a desirable or intended objective” - Wikipedia

7

Definition of “BI Project” Failure..(based on responses to questionnaire from ACS members)

Did not meet business needs (the classic "I know it's not what you want but it is what you asked for !!)

Solution is unused by users

Project is late …Is this really a failure?

Unhappy customer …How to measure?

Underachieving desired outcome

8

Causes of BI Project Failures Summary (based on responses to questionnaire from ACS members – detailed responses at end of slides)

No clearly defined scope, business requirements & benefits (Top responses)

Lack of top management support

Lack of communication between business and IT (&different objectives)

No or lack of user involvement/Ownership

No adequate funding/budget

Get BI with a Higher IQ.wmv

9

Causes of BI Project Failures Summary (Cont..)

(based on responses to questionnaire from ACS members)

No proper planning and mismanagement

Doing too much (start small and iterative approach)

Changing Scope (manage business priorities)

Politics

Technology complexity

10

What about…

Data quality No proper technology IT staff skills Vendor!

11

Lessons Learnt from Projects Summary(based on responses to questionnaire from ACS members)

Keep it simple

Well defined requirements is key

Engage the business (early and all the time)

Be prepared to alter and change specifications even half way through the exercise

Once the closing off dates for changes are reached, THAT IS IT, no last minute "little" inclusions.

Communication is crucial

IBM - Keep It Simple.wmv

12

Persuading an agile and imaginative mind is always challenging, but always profitable.

Proper allocation of resources must be provided

Consistent checks and milestones be achieved

Success is not based on technology used

Must be clear that the owner of project is "interested" in it

Release management is key to success.

Getting all interested parties (including vendors, clients etc) into early, then regular planning meetings with comprehensive minutes with "action by dates", "action by who" is costly but essential.

Lessons Learnt from Projects Summary (cont.)

13

Questions• Why there are still BI project failure in millions of dollars when we have proper BPM tools,

methodologies and structure in place?

• What would you do if you fail your BI project? Are you going to ignore your fault or realise what you have achieved?

• How do you explain to manager that BI is not the magic bullet which fix all of company's problems

• What is intelligence? Where does it reside - in data or in the process or is it something that is invented by the BI project?

• Is there a valid role for an Information Architect in designing the presentation/access of Business Intelligence products?

• I am tempted to build a API first and try to encourage users to roll their own enhancements under an Open Source model. This reduces my long term need to be creative but increases the design requirments up front. Have I lost all sense of reason?

• Has the general business community finally realised that maintenance is not free and is essential ?

• What is your experience with BI application “follow-up” needs.

• Do you agree that the cognitive component is singularly most critical component of any worthwhile BI system? If not, what is the most critical component? If you do agree, how much effort, if any, do you – the expert – put into educating the decision makers about the cognitive component?

• For a manufacturing type industry based company, what is/are the best BI tools with respect to two aspects – sales and inventory.

14

Positive talk!

1994 31% of IT projects were flat failures16% of all projects were completely successful

from cio.com

200619% of IT Projects were absolute

failure35% successful46% challenged - projects that didn't meet the criteria for total

success from cio.com

2007

8%

68%

24%

Moderately SuccessfulFailure Very Successful

Survey from Successful BI – Cindy Howson

This comparison is to bring positive atmosphere and not an exact comparison: 1994 & 2006 is for IT projects while 2007 is

BI projects

15

Details of all responses

16

Causes of BI Project Failures(based on responses to questionnaire from ACS members)

Misunderstanding of business needs, Under spec-ed, the devil is in the detail Insufficient knowledge or understanding of the business dynamics, Failing to define information in a hierarchical structure that aggregates from

performance management to aggregates (rolls up) to corporate targets, Undefined outcome, Failure to truly meet the business need, scope not defined / defined loosely) Difficult for users to articulate requirements and analysts to articulate their

understanding of the requirements Diversion due to other projects or failures taking up resource away from the BI

project BI requires process change in senior management - commitment to change

dissipates once management gets busy on other work No ownership

17


Unrealistic expectations (which leads to underachieving) Lack of communication between business and IT Poor understanding between the client and the developers and often different

objectives, the developers want "bleeding edge" technology that will look good on the resume, the users/clients want a business solution.

Often the user community think automating a poor business product/process will some how magically fix it.

Unrealistic budgets Lack of intensive training, monitoring and mentoring A failure for the business to actually define and take ownership of what

constitutes Business Intelligence

18


Lack of rollout timeframe management No staged reviews Poor planning; poor analysis or feasibility study Trying to do too much first Changing scope - once issues identified and rectified, want to move onto next issue Mismanagement Under resource Politics - power structure of the organisation wants their finger in every pie These projects fail if they start without definition of BI Sponsors not close to users to know their real requirements, solution being imposed

from above User lack of interest or authority to take action Interfacing with poorly maintained legacy systems. The mainframes/midrange systems

are not going to go away but many, if not most, are poorly maintained (often the staff who wrote/maintained

them have been retrenched, retired etc and legacy systems certainly are not considered a career

advancement option to work on). Architecture

19


There’s a serious misconception of what BI is capable of. Every BI project is doomed to fail when it is treated as a panacea to corporate ills, expected to deliver instant or near instant solutions to issues, challenges and problems which are so complex that they require serious cognitive dexterity rather than machine computational power

Implementing the BI tools is seen by most participants as the BI project When the decision makers invest their hope in the BI’s ability to relieve them

from serious thinking, the BI will fail - always. BI can never replace the need for serious thinking. Using BI as a substitution for a lazy mind or even as an augmentation to a dull mind is a trivial pursuit at a colossal cost.

Lack of understanding. Too many decision makers are under an illusion that they understand what BI is all about. Many have either a distorted view of BI or haven’t got a clue at all. Some have a reasonable conceptual understanding; however, in BI context even reasonable is no protection against project failure. BI is too complex and too important to be handled by dilettantes or mediocre

20

Lessons Learnt from Projects(based on responses to questionnaire from ACS members)

Keep it simple Well defined requirements required Document all preliminary requirements and ensure all parties agree to what

is written Thoroughly research the needs Engage the business Be prepared to alter and change specifications even half way through the

exercise Once the closing off dates for changes are reached, THAT IS IT, no last

minute "little" inclusions. Focus be given to project, otherwise it goes beyond the allocated time and

never quite gets the completion status, carries on forever Getting all interested parties (including vendors, clients etc) into early, then

regular planning meetings with comprehensive minutes with "action by dates", "action by who" is costly but essential.

Have a good team Experience matters, and matters a lot. Communication is crucial

21

Constant follow up of the BI application by expert staff - this is not a one-time shot

Think first, think hard, don’t disregard wise counsel, learn from failures and indeed from

Persuading an agile and imaginative mind is always challenging, but always profitable.

Proper allocation of resources must be provided Consistent checks and milestones be achieved Success is not based on technology used Must be clear that the owner of project is "interested" in it Today’s sophisticated BI systems can connect the dots, but that doesn’t

matter, unless an able mind is not part of the BI system. An incapable or a lazy mind will make no sense of the intelligence. Many practitioners and BI users expect BI system to be a serendipity machine as well as being able to extrapolate abstractions from fundamentally binary logic.

Lessons Learnt from Projects (cont.)

22

Role of a Release Manager, responsible for this Release and nothing else, is absolutely necessary. This individual needs to be: senior enough to be able to make decisions that are binding on all experienced enough to know all relevant Standards, Procedure etc have a "direct line" to internal and external audit so that Standards etc

can be enforced when necessary (sounds awful but individuals can become quite blinkered)

All changes (other than fixes) should only be made in scheduled releases that are migrated to Production Environments during quiet business times and then checked by the User community and signed off as meeting their requirements and able to interface with ALL relevant Systems/Processes before the System(s) are released to the general user community.

Lessons Learnt from Projects (cont.)

23

Panel Discussion Feedback Summary(Based on feedback during Panel Discussion 24/09/08)

Project failure definition: Costly, very expensive Not meeting business requirements If the BI is unusable or business don’t want to use it, then it is a clear failure

Causes of project failure: Off-shoring analysis and requirements definition is high risk for failure Conducting BI project with another larger ERP project Complexity in the OLAP and front-end design

Lessons Learnt: should involve business from the beginning and should be iterative process Methodology is very important – not using the old waterfall approach for BI projects Setting expectations is very important Set a process to prioritise changes in requirements and be clear with the business Have the consultants/BI team done it before? This is an important factor for successful

project BI Consultants can intelligently and clearly talk to the business, otherwise, sack them