In this blog, I have generally tried to focus on success factors for Business Intelligence programmes. I suppose this reflects my general character as something of an optimist. Of course failure can also be instructive; as the saying goes “we learn more from our mistakes than from our successes.” Given this, and indeed the Internet’s obsession with “x reasons why y fails”, I have also written on the subject of how Business Intelligence projects can go wrong a few times.
My first foray into this area was in response to coverage of the Gartner Business Intelligence Summit in Washington D.C. by Intelligent Enterprise. The article was entitled, “Gartner sees a big discrepancy between BI expectations and realities” – Intelligent Enterprise; I have always had a way with words!
Rather than simply picking holes in other people’s ideas on this topic, I then penned a more general piece, Some reasons why IT projects fail, which did what it said on the can. Incidentally I was clearly in the middle of a purple patch with respect to article headlines back then, I am trying to recapture some of these former titular glories in this piece.
So what has moved me to put fingertip to keyboard this time? Well my inspiration (if it can be so described) was, as has often been the case recently, some comments made on a LinkedIn.com forum. In breech of my customary practice, I am not going to identify the group, the discussion thread or the author of these comments, which were from a seasoned BI professional and were as follows:
Most BI projects fail because:
a) the business didn’t support it properly or
b) the business didn’t actually know what they wanted
I realise that I should be more emotionally mature about such matters, but comments such as these are rather like a red rag to a bull for me. Having allowed a few days for my blood pressure to return to normal, I’ll try to offer a dispassionate deconstruction of these suggestions, which I believe are not just incorrect, but dangerously wrong-headed. If the attitude of a BI professional is accurately reflected by the above quote, then I think that we need look no further for why some BI projects fail. Let’s look at both assertions in a little more detail.
What does “the business didn’t properly support [BI]” actually mean?
For a change I am going to put my habitual frustration at unhelpful distinctions between “the business” and “IT” to one side (if you want to read about my thoughts on this matter, then please take a look at the Business / IT Alignment and IT Strategy section of my Keynote Articles page).
To me there are three possible explanations here:
- The business did not need or want better information
- The business needed or wanted better information, initially supported the concept of BI delivering this, but their enthusiasm for this approach waned over time
- The business needed or wanted better information, but didn’t think that BI offered the way to deliver this
maybe there are some other possibilities, but hopefully the above covers all the bases. Here are some thoughts on each scenario:
1. The business did not need or want better information
So the rationale for starting a BI project was… ?
On a more serious note, there could be some valid reasons why a BI project would still make sense. First of all, it might be that a BI system could deliver the same information that is presently provided more cheaply. This could be the case where there are multiple different reporting systems, each needing IT care and support; where the technology that existing systems are based on is going out of support; or where BI is part of a general technology refresh or retrenchment (for example replacing fat client reporting tools with web-based ones, thereby enabling the retirement of multiple distributed servers and saving on the cost of people to maintain them). Of course it may well be IT that highlights the needs in these circumstances, but there should surely be a business case developed with some form or payback analysis or return on investment calculation. If these stand up, then an IT-centric BI project may be justifiable. While I would argue that such an approach is a wasted opportunity, if such an initiative is done properly (i.e. competently managed), then the the lack of business people driving the project should not be an obstacle to success.
Second, it could be that the business saw no need for better information, but IT (or possibly IT in conjunction with a numerate department such as Finance, Change or Strategy) does see one. While this observation is perhaps tinged with a little arrogance, one of IT’s roles should be to act as an educator, highlighting the potential benefits of technology and where they may add business advantage. Here my advice is not to start a BI project and hope that “if we build it, they will come”, but instead to engage with selected senior business people to explain what is possible and explore whether a technology such as BI can be of assistance. If this approach generates interest, then this can hopefully lead to enthusiasm with appropriate nurturing. Of course if the answer is still that the current information is perfectly adequate, then IT has no business trying to kick off a BI project by itself. If it does so, then accountability for its likely failure will be squarely (and fairly) laid at IT’s door.
2. The business needed or wanted better information, initially supported the concept of BI delivering this, but their enthusiasm for this approach waned over time
To me this sounds like a great opportunity that the BI team have failed to capitalise on. There is a pressing business need. There is a realisation that BI can meet this. Funding is allocated. A project is initiated. However, some where along the line, the BI team have lost their way.
Why would business enthusiasm wane? Most likely because delivery was delayed, no concrete results were seen for a long time, costs ballooned, the system didn’t live up to expectations, or something else happened that moved executive focus from this area. In the final case, then any responsible manager should be prepared to cut their coat according to their cloth. The BI team may feel that their project is all-important, but it is not inconceivable that another project would take precedence, for example integrating a merger.
Assuming that external events are not the reason for business disenchantment, then all of the other reasons are 100% the responsibility of the BI team themselves. BI projects are difficult to estimate accurately as I described in The importance of feasibility studies in business intelligence, but – as the same article explains – this is not an excuse for drastically inaccurate project plans or major cost overruns. Also the BI team should work hard at the beginning of the project to appropriately set expectations. As with any relationship, business or personal, the key to success is frequent and open communication.
Equally, BI projects often require a substantial amount of time to do well (anyone who tells you the opposite has never been involved with one or is trying to sell you something). This does not mean that the BI team should disappear for months (or years) on end. It is important to have a parallel stream of interim releases to address urgent business needs, provide evidence of progress and burnish the team’s credibility (I explore this area further in Holistic vs Incremental approaches to BI).
If the BI system delivered does not live up to expectations then there are two questions to be answered. In what way does it not meet expectations? and Why did it take until implementation to determine this? It could be that the functionality of the BI tool does not meet what is necessary, but most of these have a wide range of functionality and are at least reasonably intuitive to use. More likely the issue is in the information presented in the tool (which is not judged to be useful) or in an inadequate approach to implementation. The way to address both of these potential problems from the very start of the project is to follow the four-pillared approach that I recommend in many places on this blog; notably in one of the middle sections of Is outsourcing business intelligence a good idea?.
So rather than blaming the business for losing interest in BI, the BI team needs to consider where its own inadequacies have led to this problem. It is sometimes tempting to dwell on how no one really appreciates all of the hard work that us IT types do, but it is much more productive to try to figure out why this is and take steps to address the problem.
3.The business needed or wanted better information, but didn’t think that BI offered the way to deliver this
While I recognise some aspects of the first scenario above, this one is something that I am more intimately familiar with. Back in 2000, I was charged with improving the management information of a large organisation, in response to profitability issues that they were experiencing. No one mentioned data warehouses, or OLAP, or analytics. A business intelligence implementation was my response to the strategic business challenges that the organisation was facing. However I initially faced some scepticism. It was suggested that maybe I was over-engineering my approach (the phrase “we need a diesel submarine, not a nuclear one” being mentioned) when all that was required was a few tweaks to existing reports and writing some new ones.
First of all, a BI professional should welcome such challenges. Indeed they should continually ask the same questions of themselves and their team. If your proposed approach does not stand up to basic scrutiny with respect to cost effectiveness and timeliness, then you are doing a poor job. However good BI people will be able to answer such questions positively, having devised programmes and architectures that are appropriate for the challenges that they seek to meet. A BI solution should clearly not be more expensive than is needed, but equally it should not be cheaper, lest it fails to deliver anything.
A skill that is required in a situation such as the one I found myself in back in 2000 is to be able to lay out your vision and proposals in a way that is logical, compelling, attractive and succinct enough to engage business enthusiasm and engender the confidence of your potential stakeholders. In short you need to be able to sell. Maybe this is not a skill that all IT people have acquired over the years, but it is invaluable in establishing and maintaining project momentum (I cover the latter aspect of this area in three articles starting with Marketing Change).
Again, if the lead of the BI team is not able to properly explain why BI is the best way to meet the information needs of the organisation, then this is essentially the fault of the BI lead and not the business.
So far, the main conclusion that I have drawn is the same as in my earlier piece about the failure of BI projects. I closed this by stating:
I firmly believe that BI done well is both the easiest of IT systems to sell to people and has one of the highest paybacks of any IT initiative. BI done badly (at the design, development, implementation or follow-up stages) will fail.
The issue is basically a simple one: just how good is your BI team? If a BI implementation fails to deliver significant business value, then instead of looking for scape-goats, the BI team should purchase a mirror and start using it.
Let’s see if an exploration of the second suggested reason for problems with BI projects changes my stance at all.
What does “the business didn’t know what they wanted [from BI]” actually mean?
Business intelligence, when implemented correctly, helps organisations to be more successful by offering a way to understand the dynamics of their operations and markets and facilitating better business decisions. So, almost by definition, good BI has to be a sort of model of the key things that happen in an company. This is not easy to achieve.
Again I will come back to my four-pillared approach and emphasise the first pillar. There is an imperative to:
Form a deep understanding of the key business questions that need to be answered.
In my opinion, it is the difficulty in managing this process that plays into the assertion that “the business didn’t know what they wanted.” Putting it another way, the BI team were not skilful enough, engaging enough, or business-savvy enough to help the business to articulate what they wanted and to translate this into a formal set of definitions that could then form the basis of IT work. This process can indeed lengthy, tough and difficult to get right because:
- Businesses are often complex, with many moving parts and many things that need to be measured
- Different business people may have different visions of what is important – each of these may have validity, depending on context
- Both IT and business people may be unaccustomed to talking about business phenomena in the required way (one that is self-consistent and exhaustive)
- IT may not have a proper understanding of business strategy, business terminology and business transactions
- There is often a desire to start with the current state and adapt / add to this, rather than take the more arduous (but more profitable) approach of working out what is necessary and desireable
- The process is typically iterative and requires an ongoing commitment to the details, sapping reserves of perseverance
I have written about the level of commitment that can be required in defining BI business requirements in a couple of articles: Scaling-up Performance Management and Developing an international BI strategy. Please take a look at these if you are interested in delving further into this area. For now it is enough to state that you should probably allow a number of months for this work in your BI project plan; more if your objective is to deliver an all-pervasive BI system (as it was in the work I describe in the articles). It is also helpful to realise that you are never “done” with requirements in BI, they will evolve based on actual use of the system and changing business needs. You will end up living this cycle, so it makes sense to get good at it.
Sometimes it may be tempting for either IT or the business people involved to short-cut the process, or to give up on it entirely. This is s sure recipe for disaster. It is difficult to make establishing requirements a fun exercise for all those involved, but it is important the the BI team continually tries to keep energy levels high. This can be done in a number of ways: by reminding everyone about the importance of their work for the organisation as a whole; by trying to use prototypes to make discussions more concrete; and – probably most importantly – by building and maintaining personal relationships with their business counterparts. If you are going to work for a long time with people on something that is hard to do, then it makes sense to at least try to get along. It is on apparently small things such as these essentially human interactions that the success or failure of multi-million dollar projects can hinge.
Helping the business to articulate what they want from BI is extremely important and equally easy to get wrong. Mistakes made at this stage can indeed derail the whole project. However, this is precisely what the BI team should be good at; it should be their core competency. If this work is not done well, then again it is primarily the responsibility of the professionals involved. A statement such as “the business didn’t know what they wanted” simply reflects that the BI team were not very good at running this phase of a BI project.
I find myself back at my previous position. Of course the idea of finding scape-goats for the failure of a BI project can be very tempting for the members of the team that has failed. However, this is an essentially futile process and one that proves that the adage about learning from your mistakes does not always apply.
To make things personal. Suppose that I am responsible for leading project in which it is obvious up-front that extensive buy-in and collaboration will be required from a group of people. If the project fails because neither of these things was obtained, then surely that’s my fault and not theirs, isn’t it?
For some further thoughts on this issue, take a look at an article by Ferenc Mantfeld entitled: Top 10 reasons why Business Intelligence Projects fail.
21 thoughts on ““Why Business Intelligence projects fail””
Last Saturday, I went to a birthday party of the son of an Indian friend. There were refreshments, alcohol, a dinner buffet, Punjabi dances, games for kids, dance music for the guests, in the end, everybody went to the dance floor. At the background, there was the slide show of pictures of the family on the corner of one wall.
Later, when I congratulated his success on hosting the party, he told me that it took him quite a lot time to make the slide show work, getting all the pictures ready, and deciding which one should be in front of which one……
It probably is a 30 minute wonderful story about the life of the baby. I know I didn’t pay much attention to it as I was focusing my attention mostly on the dinner, cultural differences, and Indian dresses. I know most of the guests who drank or danced didn’t notice it either. I almost said, nobody would know the difference if you put only 5 pictures there and rotate them over and over again.
Isn’t that slide show BI of an organization?
It’s important to the people who live in it. Its ROI isn’t obvious. It doesn’t fit into people’s priorities if you don’t force it on them. People kind of take it for granted unless they suddenly see pictures of sexy girls.
In addition to (or put more weight to ) what you’ve said, here’s my two cents.
When there are several choices, people might choose what they are familiar with, not the fastest, especially if data quality is a potential issue.
BI is not only technology, it’s also social science, an art, You can’t always find poeple who’s passionate about it to work with.
Keep the cost down, smaller teams, less meetings and faster iterations.
If you want to be a BI professional, you have to have endurance. You’ve got to work extra hard and realize that you only make tiny improvement.
If you want to be a BI professionals, you have to be vigilance. You might need to lead the way, know your data, find “gold” in the data and show business its value.
Thank you for the detailed comments.
Obviously Peter you have never seen at data warehousing life cycle product.
When you eventually do your comments and thoughts may change.
Have a look at WhereScape RED.
Thanks for the comment.
Are you by any chance the Steve Hitchman who is
Operations Director at WhereScape Europe?
If so, perhaps it would have been sensible to disclose this when you posted.
Yes I am. I am also the managing director of MIP in Australia . Is there a problem discussing or mentioning a product that addresses your issues ?
At MIP we are driving agile data warehousing and one using a data warehousing lifecycle product is fundamental to this.
Have a look at it and then get back to me. I would love to hear your comments.
MIP and WhereScape Europe
Wow! only a year later a response – and they say that the Internet moves at the speed of light.
No problem with you mentioning your products – I am very interested in products.
However it would be very helpful if you also mentioned your affiliation at the same time lest readers assume that your comments are 100% neutral.
WOW I see I can’t respond to your slightly barbed response any reason for that Pater ?
Sorry Peter I missed typr your name wronbg there mate.
I think it took me a year to respond because I don’t get notified of additions to the blog. I have now ticked the right box.
Why don’t you join my Linkedin group ‘Agile Data Warehousing and Business Intelligence’ you will certainly get unbiased comment there as well.
Hope you do.
CEO MIP Australia &
Ops Director WhereScape Europe
Are you going to join the ‘Agile Data warehousing and Business Intelligence’ group on linkedin ?
There is lots of healthy discussion on the Agile approach and we would love you to contribute.
Also, maybe we can catch up at the November conference as we are both speaking.
MIP and WhereScape
I am one short of maxing out on my LinkedIn.com groups and need to have a bit of a clear out before signing up to any new ones.
[…] A somewhat lengthy blog post by Peter Thomas counter-arguing Why Business Intelligence Projects Fail. […]
[…] Change Management & Turnaround group and was actually in response to one of my recent articles, “Why Business Intelligence projects fail”. This led to me thinking about the area further and, inevitably to some […]
[…] way to potentially address this. I spoke about this as one of three sceanrios in my recent artcile, “Why Business Intelligence projects fail”. Part of my role in this organisation (as well as building a BI team from scratch and developing a […]
[…] “Why Business Intelligence projects fail […]
this is nancharaiah from india
iam asking one question how to important of microsoft intelligence
I wasn’t 100% sure what question you were asking.
I agree with your view of why BI projects fails. Nevertheless I have my own point of view about that too. I think companies fail to leverage good BI Projects because they tried to implement a certain level of BI that is not supported by their actual level of BI processes. This could be avoided by knowing before hand your maturity level of BI and then drawing the respective roadmap to get to the level of BI the company wants. This roadmap would contains a set of projects that implemented in batch (or in parallel) would take the BI culture to another level.
Well, I hope I was clear enough on my point.
Feel free to comments.
Thank you for taking the time to comment. There is a lot of truth in what you say.
I also think that some BI practitioners (and more BI vendors) can oversell the inherent transformational capabilities of their tools (rather that the necessary accompanying change management work), leading to disappointment; something I touched on in Limitations of Business Intelligence.
[…] pieces such as Who should be accountable for data quality?, A single version of the truth? and “Why Business Intelligence projects fail”. Perhaps the fact that they related to topical issues that people clearly wanted to discuss was a […]
[…] Some elements of the technology have changed, but the vast majority of the issues I covered in “Why Business Intelligence projects fail” hold as true today as they did back in 2009 when I wrote this […]
[…] For example as in “Why Business Intelligence projects fail”. […]
You must log in to post a comment.