Practical Advice from the Experts

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
Everyones 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)
IBM - Keep It Simple.wmv

• 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

12
Lessons Learnt from Projects Summary (cont.)

• 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.

13
Questions
14
Positive talk!

• 1994
• 31 of IT projects were flat failures
• 16 of all projects were completely successful
• from cio.com

2007

• 2006
• 19 of IT Projects were absolute failure
• 35 successful
• 46 challenged - projects that didn't meet the
  criteria for total success from cio.com

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
Causes of BI Project Failures(based on responses
to questionnaire from ACS members)

• 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
Causes of BI Project Failures(based on responses
to questionnaire from ACS members)

• 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
Causes of BI Project Failures(based on responses
to questionnaire from ACS members)

• Theres 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
  BIs 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 havent 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
Lessons Learnt from Projects (cont.)

• Constant follow up of the BI application by
  expert staff - this is not a one-time shot
• Think first, think hard, dont 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
• Todays sophisticated BI systems can connect the
  dots, but that doesnt 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.

22
Lessons Learnt from Projects (cont.)

• 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.

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 dont 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