Why Business Intelligence Projects Fail Due to Lack of Planning and Buy-in

1
Why Business Intelligence Projects Fail
Chandra VennapoosaExforsys.com
Author:Chandra Vennapoosa Published on: 24th May 2013
Why Business Intelligence Projects Fail ...................................................................................................1
Just Implement, Don't care of Planning ...........................................................................................2
Just Implement, Don't care of Business............................................................................................3
Just Implement, Don't care of TCO..................................................................................................4
Just Implement, Don't care of Future Issues....................................................................................5
Just Implement, Don't care of Data Quality.....................................................................................6
Just Implement, Don't care of Future Changes ...............................................................................8
Just Implement, Don't care of Future Needs....................................................................................9
Just Implement, Don't care of Shopping ........................................................................................10
Just Implement, Don't care of Dash Boards...................................................................................11
Just Implement, Don't care of Work Quality.................................................................................13
Just Implement, Don't care of Performance...................................................................................14
Business intelligence projects are designed to allow organizations to make better long term
strategic decisions. In theory, BI allows organizations to collect organize and use data in a
manner that increases their market share. However, reality is often different from theory, and this
is certainly true in the case of most business intelligence projects.
Previous studies have shown that about 80 percent of all BI projects fail, while only 20 percent
are a success. When you factor in the high costs necessary to implement such projects, it is easy
to see why many organizations have lost faith in BI. However, it would be simplistic as well as
inaccurate to say that the problem lies with BI itself. Many prominent corporations have
successfully implemented business intelligence projects to great effect. This is an indication that
the failure of most BI projects lies elsewhere.
Just Implement, Don't care of Planning
Just Implement, Don't care of Business
Just Implement, Don't care of TCO
Just Implement, Don't care of Future Issues
Just Implement, Don't care of Data Quality
Just Implement, Don't care of Future Changes

2
Just Implement, Don't care of Future needs
Just Implement, Don't care of Shopping
Just Implement, Don't care of Dash Boards
Just Implement, Don't care of Work Quality
Just Implement, Don't care of Performance
Just Implement, Don't care of Planning
It is important for stakeholders to understand that BI implementation is a long term process and
develop a clear cut plan which is compatible with the BI tools they intend to use. Implementation
of BI project should not be done haphazardly since adequate planning as well as time duration is
essential for BI applications to function properly.
BI planning should take place "before" the company begins searching for a BI vendor. Many
stakeholders and upper managers believe that if they simply purchase the application, and begin
using it, they will be successful. However, this is like buying a car in Philadelphia with the goal
of driving it to New York, without having any clue how you will get there. It isn't enough to just
buy the car; you need a map, knowledge of how to drive the car and a detailed plan on how you
will drive it from Philadelphia to New York. Otherwise, you will get lost.
This is precisely what happens to most organizations that attempt BI implementation. They
purchase BI application, but they have no plan as to how they will use it. As a result, they get
lost when trying to implement it, and this leads to frustration which eventually causes them to
give up. Because they give up, the BI project becomes little more than a very expensive paper
weight.
In order for a BI project to be a success, an organization must do more than just purchase an
application with the expectation of it being a magic bullet. Such expectations will lead to
disappointment. Any company that wishes to master BI must develop a plan in advance, and this
planning must involve the transformation of the entire firm in such a way which is compatible
with the application they intend to use.
First and foremost, the implementation of a BI project must have the endorsement of upper
management. Without this endorsement, the project will be doomed from the start. When
deciding to implement a BI project, upper management should also plan the creation of a training
tool which is designed to teach employees the usage of the app. It isn't enough for a handful of
employees or managers to understand a BI project; everyone in the organization must understand
it and how it will make the firm more profitable. It is also important for organizations to
understand "why" they need a business intelligence project in the first place. It isn't enough to
just say that the project is needed because competitors are using it; this is unacceptable. A more
detailed "why" should be given, as this will lead to the proper planning which is necessary for
successfully implementing the project?
An expression I will use to describe this phenomenon is called "why leads to how." What I mean
by this is that a company must first decide why they need a BI project. Once they have a why,

3
they next need a how. The why and how are closely correlated, and one naturally follows the
other. It is the "how" that will lead to the decision of which vendor to use, because once you have
a why and a how, you will have a plan, and this plan will allow you to purchase an app from a
vendor who meets your needs.
Just Implement, Don't care of Business
Because large organizations are often compartmentalized, conflicts can occur between
departments, especially when one department makes a decision that negatively impacts another.
For instance, while the IT department may see a clear need for a BI project, other departments
may see no such need, and may refuse to adapt to the project. As a result, a scenario is created in
which IT embraces a BI application, while other departments or upper management are less
enthusiastic about it.
Without the full support of the other departments, the BI project is not utilized across the
organization, and its implementation is ultimately a failure. The necessity of an organization
fully supporting a BI project is directly correlated to the proper planning of the project. When the
project isn't fully supported, the planning for its implementation will likely be insufficient, and
this lack of efficient planning will make it difficult for the project to succeed.
BI project failures can often be attributed to a lack of synergy among the different departments
that comprise a firm. It simply isn't enough for the IT department to embrace it; the project must
be embraced by the entire organization in order to succeed, and this embrace starts with the
leadership.
There are a number of reasons as to why an organization may need a BI project. Many of these
reasons are often technical in nature, and may only be fully understood by the IT department. For
example, there could be a situation where there are multiple reporting systems, and each of these
systems needs the support of IT. Because such systems are becoming outdated, there may be a
need for updates. There could also be a need to replace reporting tools which are fat client with
newer ones that are web based. Such a replacement will require the removal of numerous
servers, which would save a lot of time as well as money for the people that need to manage
them.
However, these technical issues will often be poorly understood by the other departments and
upper management. When an IT department desires a BI project, they should focus less on the
technical reasons for its implementation, and emphasize more on business reasons. The other
departments will be concerned with their own affairs, and upper management will be concerned
with the bottom line. Unless a ROI (return on investment) or cost benefit analysis can be clearly
demonstrated, it is unlikely that the other departments or upper management will fully embrace a
BI Project. This relates to the "why leads to how" expression that I stated previously.
Companies will often find themselves in situations where one department will see a clear need
for better information, while another department may see no such need. For this reason, the goal
of IT or any other department that wishes to initiate a BI project should be the education of the

4
other departments and stakeholders. They should be able to fully articulate the benefits and needs
of the project, and how it will better the entire organization, as opposed to just their department.
Many departments that decide to implement a BI project operate with the assumption that once
they implement it, the people will come. This is a faulty assumption that should be discarded.
Instead, these departments will want to communicate with senior management, explaining to
them how BI technology can be utilized in a manner that increases the organization's bottom
line. The technical details of the project are best left at the door, as it may confuse senior
managers who are primarily concerned with results, and not how those results are achieved.
There is always the possibility that upper management will not see the need for such a project,
and if they don't, you can be sure that other departments won't either. Therefore, if the IT
department chooses to press forward with the implementation anyway, they should be held
accountable for its failure (which is likely). A business intelligence project simply cannot
succeed when it doesn't have the full support of senior management and other departments.
Just Implement, Don't care of TCO
Regarding business intelligence, there seems to be a perception that the BI component doesn't
have a cost, since it is already included within the database. Additionally, many stakeholders
factor in the costs for the infrastructure and the need to service it, without considering the TCO
(total cost of ownership). This is yet another reason why many BI projects fail.
In order for a BI project to be a success, the TCO must always be considered. There have been
cases where companies used their BI applications to acquire data from Excel, and then managers
spent hours each day working with it, trying to decide which products they needed to promote
more often, and in which stores they needed to promote them. Because more than two dozen
managers spent a quarter of their business day doing this, it was estimated that the company
actually spent over half a million dollars each year. In three years, that would grow to $1.5
million. Over 10 years, that would grow to a staggering $5 million.
However, what if this organization had a BI tool that allowed its managers to get their
information in seconds, rather than hours? In that case, the company would save $500,000 a
year. When a company is considering the implementation of a BI project, they must look beyond
the license fees. Equally (and some would argue more important), is the need to look at TCO.
Factoring in TCO will better allow the organization to get a ROI which is more accurate.
One common mistake which increases the costs of a BI project is a failure to properly handle
data integration, especially when multiple applications are involved. This one issue will often
single handedly determine the success or failure for a BI project. Many companies simply don't
understand the challenges of managing data with BI until the project is initiated. Even in cases
where IT has the ability to deal with these challenges, the cost for the company can be very high.
This is true regardless of whether a company relies on their internal IT department, or an outside
source.

5
Some of the other challenges that organizations will face in successfully implementing BI is the
delivery of the tool to multiple end users, enhancing ease of use for users that are nontechnical,
and developing capabilities for BI which are customized. Unless the organization is able to
achieve all of these things successfully, a scenario can occur in which users fail to adopt the BI
app, a problem which is consistently seen. Even in cases where end users are willing to adopt the
application, any issues with the three aspects mentioned above will make the problem worse.
Companies that succeed with BI often do so because they start small. Once the BI
implementation reaches an enterprise level, any problems that do occur can be serious ones.
Just Implement, Don't care of Future Issues
Many organizations initiate BI projects without first running a RACT test. RACT is acronym
which stands for Relevant, Accurate, Consistent, and Timely. Unless a business intelligence
project can pass this test, then it should be considered a failure, and the creators of the project
should go back to the planning phase.
The R (relevant) of RACT answers the question of who needs the deliverables. Additionally, it
asks one of the most important questions of all, which is what problem is meant to be solved by
the project implementation? Once an organization has an answer to these two questions, this will
better allow it to figure out the cost. When factoring in costs, the organization will want to
emphasize TCO rather than other fees which are more obvious.
The A (accurate) of RACT indicates the accuracy of the reporting, as well as the dashboards. If
this information is inaccurate, then the organization should go back to the beginning. The reason
for this is because inaccurate reporting is a sign that the project is already unsuccessful, and
pushing forward anyway will make things worse(and more expensive).
The C (consistent) of RACT indicates that all the information and reporting must be consistent.
The T (timely) of RACT means that the information must be available when needed. It isn't
enough to just have access to information; that information must be made available in a timely
manner.
Unless a BI project can pass this stringent test, then an organization has no business going
forward with it, as doing so will only ensure the project's failure.
The RACT test is important because it will better allow organizations to differentiate "corporate
data" from "strategic data." Corporate data is the data that is usually raw, data which is often
readily available. Strategic data, on the other hand, is data which will give organizations business
wisdom, wisdom which will allow them to grow their profits consistently. Put another way,
corporate data is transactional in nature; strategic data deals with long term strategy and
planning.
While corporate data is crucial for dealing with the logistical aspects of a business, such as the
supply chain or accounts receivable, it is insufficient to carry out the marketing process, as well

6
as the management of sales. As a result, corporate data alone will not allow an organization to
grow its market share, nor will it allow for an increase in revenue and thus profit.
The reason for this is because the corporate data is merely a byproduct for the ERP (order entry
system), which is created mainly for the purpose of shipping orders within a timely manner. The
ERP is not designed to use strategic data in a manner that makes it useful for marketing.
The problem with most BI projects is that they combine complex software with raw ERP data.
This is insufficient since the data from the ERP will generally not contain information which is
related to marketing intelligence. This is why many BI projects do not readily offer the strategic
direction which is needed to expand the business, which would essentially leave the marketing
team in a situation where they're struggling to get the data they need in order to increase
revenues. This is also why many marketing and sales teams frequently abandon BI projects.
The RACT test is best thought of as a screening tool which allows one to determine whether or
not a BI project should even be initiated. Without such a test, an organization or department will
be unable to spot the problems that will eventually lead to a costly failure. It is important to see
BI as being more than just a piece of software. It is better thought of as a process, one which will
allow a firm to transform corporate data into strategic data that will be accurate and relevant.
When considering BI, the goal of an organization should be the integration of corporate and
strategic data. This will comprise things such as the customer segmentation, sales projection and
competitive analysis. This process is best completed by running a RACT test first. In a nutshell,
this test will allow an organization to determine whether or not it is ready for BI. While there is
no question that business intelligence is effective in allowing organizations to increase their
bottom line, they can only accomplish this if they are prepared for BI. Business intelligence
projects are often long and complex, and this requires preparation and changes on the part of the
firm.
Just Implement, Don't care of Data Quality
When it comes to a BI project, the quality of the data is critically important. When the data is
wrong, then the decisions made based on that data will also be wrong. These wrong decisions
will eventually cause the department or organization to lose faith in the project. In cases where a
data warehouse is being utilized, it will be necessary to filter out data which is incorrect. This
should be done during the ETL (Extract, Transform and Load) stage.
The proper management of the data is closely correlated to a data warehouse which has good
data. The best way to deal with problems in data quality is to mitigate the problem at its source.
In this case, the source would be the source systems, as this is where information is placed.
A number of studies indicate that companies lose almost $10 million each year as a result of poor
data. Other studies have also shown that bad data leads to an increase in customer dissatisfaction,
which will consequently lead to a loss in customers, increasing the losses further. When
organizations attempt to implement BI, some of the problems that they face are an inability to

7
find the information necessary to perform their tasks, as well as mistakenly using the wrong
information.
As you can see, the quality of the data is not something that should be taken lightly. An
additional cause for concern is an increase in the corporate data that companies must digest;
studies indicate that this corporate data is growing at a rate of over 40 percent per year. The
fundamental challenge of business intelligence software is that such software is much more
advanced than the structure and quality of the data. Many firms find that after spending millions
on such software, the only thing they have to show for it is an ocean of data, much of which they
can't make much use of.
It isn't uncommon for a BI app to be completely inept when it comes to providing strategic data
or analysis. It will often be necessary for a large team of analysts to download the corporate data,
place it within spreadsheets like Excel, and then manipulate and clean the data in such a way that
it can be useful. This process can take hours or days, and it costs companies huge amounts of
money.
Even when it is known that transactional (corporate) data has errors, oftentimes these errors are
not fixed, and they are then placed within the BI systems, making a bad problem worse.
It doesn't help that many departments within organizations fail to communicate with each other.
The marketing or sales departments will often assume that the problem lies with IT, and they will
expect IT to resolve the issue, while the IT department will assume that it is a business issue, one
which should be corrected by the sales or marketing team. As a result, neither side takes action,
nor the data is rarely corrected. This will eventually cause employees to give up on the BI
implementation, and they continue to place incorrect data within the BI system, compounding
the problem until it becomes too difficult or expensive to solve.
When an analyst uses the typical BI system to answer a question regarding profits or market
share, they will often have to wait days in order to get a response. The reason for this is because
they will need to process the queries, send them to the spreadsheet, and then cleanse the errors
(often manually), while using look ups from external sources of data. Last, they will need to
construct pivot tables that will assist in finding the needed answers. Each time the analyst wants
an update, they will need to start the entire process over again.
Not only is this method highly inefficient, it also creates a scenario where the correction of the
data is based on the assumptions of the analyst, which itself can lead to problems. Many
departments have team meetings where much of the time is spent bickering about whose version
of the data is right, rather than dealing with the issues that are more important. The numbers that
are presented by finance often won't match those offered by marketing. What everyone needs is
one version of the facts, but because different sides are running distinct queries, with different
assumptions, this is easier said than done.
Though the IT department may control the physical storage and security of the data, it is the
marketing and sales departments that must control the strategic meaning of this data, and they

8
must be able to audit and manage its quality. Analysts who spend a lot of time cleaning the data
should focus instead on being data stewards who clean and structure corporate data through the
usage of market intelligence which is external. This should be done prior to placing this data in
the data warehouse of the BI system. This should be done on a weekly basis.
Just Implement, Don't care of Future Changes
Many of the requirements which are necessary for a BI project this year will be outdated by next
year. It is crucial to understand that BI systems evolve, as with all complex systems. Therefore,
users will need to adopt the application in a manner which will allow them to handle the new
requirements which will come.
It is necessary for stakeholders to ensure that their organization is not only prepared for this
change, but also capable of displaying the flexibility which is needed to properly harness it.
However, having an organization which is prepared is not enough. It is also important to be
selective in the BI application that will be utilized. The application which is chosen should match
the flexibility of the users, as well as the inevitable changes which will occur in the market. The
budget for the BI implementation should also allow for this.
One common mistake that enterprises make is the manner in which they approach BI
implementation. It is best to see business intelligence as being cyclical. Each cycle of the project
must provide greater insight; a new angle for the firm which will raise more questions that must
be answered. In other words, there is no such thing as "finishing" a BI project. Like night and
day, one naturally gives way to the other, in a cycle which is endless.
Many firms fail to receive a return on their investment, because they choose BI tools which are
inflexible. Even if an organization has the preparation and flexibility which is necessary to
successfully use a BI app, they will still fail if they choose an inferior application. A good
analogy to describe this is an expert electrician who chooses inferior tools for his job. Regardless
of his skill and preparation, the quality of his work will still decline.
The new generation BI tools are user friendly, and they can assist companies in exploiting the
jewels of information which can be found in their respective markets. Many of these "jewels"
will be hidden within sands of data. Good BI tools will allow casual users to become power
users. One feature which is commonly seen in high end BI applications is advanced data
visualization.
This emphasis on visualization is due to the fact that much of human sensory perception is based
on vision, while only a smaller portion is based on the other senses. In fact, the human brain is
better at detecting trends within shapes and patterns as opposed to gaining such data using
spreadsheets.
Some firms have chosen to embrace these applications without consulting with their IT
departments first. However, it would be a mistake to think that these applications are IT free, or
that the IT department is no longer useful. Building and maintaining a strong relationship

9
between the marketing, sales and IT department is always important. The reason for this is
because it is necessary to be sure that the quality of the data is high. Furthermore, it is necessary
as it ensures that there is a single version of the facts. The self-serving function seen in some BI
applications allows for the user to carry out exploration for the data, without the need to ask the
IT department for data marts or reports which are predefined. The reason for this is because it
would slow down the analysis.
Just Implement, Don't care of Future Needs
The compartmentalization of large organizations often gives rise to scenarios where the needs of
one department will conflict with those of another. When this happens during a BI project
implementation, it can cause that project to fail. When speaking of business intelligence, we
often hear the expression "one version of the truth." What this implies is that successfully
implementing BI involves more than just high end software; there is also a need to deal with the
politics and conflict that will inevitably occur between departments.
The effort that is required to properly model data is formidable. This task becomes more arduous
when you consider the fact that the truth is rarely in plain view. Business information which is
highly valuable will often need to be mined, and it will need to be taken from data which is
disparate. The data from which the needed info will be taken will also exist in multiple databases
and programs, much of which are incompatible. Because of this, it is important to realize that it
could take months (and extreme attention to detail) in order to combine and prep the data in a
way that will allow you to get the valuable info you need.
One large pharmaceutical company found it necessary to take data from fourteen different
systems, and each of these systems handled a portion of its business which was distinct. The goal
was to gain a solid financial picture of the multibillion dollar firm. The IT department for this
company started the process by designing numerous software interfaces, which would be
responsible for connecting the fourteen distinct systems to the data warehouse, which was used
as a single place for information.
The challenge that this company faced was that the terms for the business and the financial
aspects of the organization were designated differently in each of the systems which contributed
the data. In other words, though the pharmaceutical company was able to bring all the data
together, it ultimately failed. The reason it failed is because data standards were not properly
utilized.
Acquiring data from a single location is only one part of successfully implementing BI.
Companies must learn to place a greater importance on information content, as opposed to how
this content is delivered. In the case of the pharmaceutical company mentioned above, they
needed to spend months creating a new collection of standards which would allow them to cut
the data into the proper context. While the reporting tools are a necessary component of BI
implementation, they are useless if they aren't combined with the correct data structure and
information.

10
When it comes to establishing standards for business and finance, it is important to realize that
this process doesn't end. To reach a single version of the truth, it will be necessary to ask
questions. And this process of asking questions is something that should be seen as an ongoing
process. When a firm implements a BI project, even with established reports and definitions,
situations may still arise in which people will want different definitions.
For instance, one department may need depreciation factored into their calculations, while
another department may not need it at all. Sometimes, upper management may want to have
costs taken from the portion of business where they are reported, and recorded in a standalone
mode. Most companies handle these requests by designing a lot of reports which are ad hoc to
deal with each request. This will eventually lead to problems, problems which could eventually
cause the BI implementation to stagnate.
It is better to design a way in which the requests for change can be channeled through a
committee, which would be responsible for reviewing them, and then accepting or denying them
after review. That way, changes can be done within a central database, which will allow for the
newer reports to be created.
In situations where the numbers may be divided into different departments, they will still be
placed into one number for the whole company, a number which will represent the bottom line. It
does require more work, but it is much better to spend more time altering things within the
database. The truth should always be seen as a phenomenon which constantly moves, and
because it is in constant movement, you must be able to do the necessary work for altering the
database, as opposed to allowing each user to make adjustments within their reports.
Just Implement, Don't care of Shopping
It is a mistake to believe that there is a standard for BI implementation, and organizations which
hold this belief are liable for making mistakes when shopping for an application. Many
companies think that the best way to approach a BI implementation is via a purchase through
their current vendor. They believe that the ERP, CRM or analytics tools offered by these vendors
are sufficient for their needs.
The chosen vendors will often have an advantage over their competitors since they will be able
to offer various cost incentives, not to mention the ability to leverage their current relationship
with the firm. Many of these vendors will also take advantage of the fears and uncertainty that
stakeholders will generally hold with regard to implementing BI. However, after using the
products offered by these vendors, many organizations will find out later on that integrating their
entire organization within the BI tools offered by these vendors is very expensive, more
expensive than if they had carried out a proper analysis of the available tools, comparing them to
their needed requirements.
Even for a small business, the usage of BI can increase its growth and profits, but only when it is
properly deployed. In order for this to occur, the business can't just use the products offered by
any vendor, even if that vendor already has a solid relationship with the company. Unfortunately,

11
many companies simply don't shop wisely when it comes to choosing a vendor for their BI
implementation, and this mistake will often cause the project to fail later on.
Prior to searching for a vendor, it will first be necessary for a company to have a deep
understanding of the regions, customers or products which are profitable to their business.
Having this information will better allow them to choose a vendor who will help them expand.
Additionally, it will also be important for the company to have knowledge of the customers or
segments which are causing the company to lose cash.
If the business has more than a few dozen customers, then the Pareto Principle (80/20 principle)
will be revealed. In such cases, a few of these clients will bring in about 50 percent of the profits,
while the rest will generate much less. It is difficult for many companies to figure out which
clients belong in each category. By strategically using business intelligence applications, they
will be able to answer these questions, and more.
However, businesses will need to look for vendors that can provide them with complete
solutions. This includes client support which involves training from the vendor, as well as vendor
representatives who are locally available. Regarding the product itself, businesses should only
choose those applications which have the flexibility to sustain multiple types of data. The
processing speed and ability to perform several operations simultaneously should also be a
factor.
Is the application stable? Will it remain reliable in the years ahead? Basic security should be
included, such as usernames and password systems. The application should also be functional,
with the ability to drill through what if scenarios or queries which are ad hoc. As simple as it
may sound, many companies have difficulty implementing BI because they choose apps with
interfaces that are too difficult to use. Not only should the interface be easy to use, but the
learning curve should be simple as well. The last thing that should be factored in is the cost.
Unfortunately, for many businesses this is the first item on the list. They look at cost first, and all
the other features second. However, high quality BI applications will be worth the price, and
attempting to choose an application purely based on price can lead to major problems later on
which are much more costly.
The best method for choosing a BI application is to do so by quantifying the needed criteria.
Businesses should build a matrix which transforms the answers received into a percentage based
answer which can be quantified.
Just Implement, Don't care of Dash Boards
The dashboard is best thought of as the "eye" which allows organizations to peer into their data,
and it is the wisdom they gain from this data which will allow them to make progress. However,
most of the dashboards offered by BI vendors today are little more than bar charts which have
been placed on a page. Additionally, many of these dashboards are less intelligent than they
should be. While the graphics have certainly improved, and users are better able to interact with

12
the charts, the simple presentation which is shown on the screen has not been vastly improved,
and the charts are less useful than they should be.
The dashboard is the most basic tool for providing business intelligence. The first dashboards
appeared during the 1980s, and while some say they have improved since then, others argue that
they've largely remained the same. It can be problematic to place pie and bar charts on a screen,
and expect that the viewers will be able to understand their meaning and what is important. It is
risky to assume that the viewer has the ability to interpret these charts, and draw the proper
conclusion. Many BI vendors believe that pretty or interactive dashboards are the key to success;
that they will assist viewers in making better decisions.
However, the failure to adopt BI tools, as well as the billions which have been spent (and lost) on
these applications indicate that there is a need for change. It is inaccurate to say that the
technology has failed; it is better to look at the reasons that more firms aren't successfully using
the technology. One good place to start is looking at the dashboards which are used to display the
information.
Another problem with most contemporary dashboards is their inability to prioritize information.
It is one thing to show charts which are geared towards a certain context. It is another thing to
prioritize information in a manner which makes it similar to the news, with stories or headlines
that people can watch in order to decide if they want to take a certain action. One reason why
newspapers have stood the test of time, whether in an electronic or print form, is because they
are shown in a format which the human mind can understand. How many BI dashboards are able
to communicate the tale of its charts the way newspapers do?
The third problem that many organizations will encounter with BI dashboards is their inability to
assist people in taking actions based on the info received. Most dashboards which are action
enabled place an emphasis on the discovery of data, and they also analyze by looking at root
causes. However, these features cannot compete with the traditional process where people
collaborate via dialogue, discussing certain issues or opportunities.
Regardless of the visual appeal of a dashboard, it will need a great deal of planning. A dashboard
which shows info that is inconsistent, or which doesn't properly flow with other organizational
data, may eventually cause a loss of confidence in the application, which will eventually cause
departments to stop using it. The data comprised by the dashboard must be verified and analyzed
for accuracy, because if it isn't, it will be little more than a nice looking picture with no value.
The implementation of the dashboard must play an important role in the project.
The development of service oriented architecture and other web based services is another way to
improve dashboards. Organizations are now gaining the ability to construct their own
dashboards, which will allow them to get the data they need to make decisions, and show the
data in a manner that is appealing and easy to understand. Mobile apps can also be offered which
will give easy to use data for mobile platforms. The solution to the problem of BI dashboards
may be the adoption of BI tools which are self-service.

13
Just Implement, Don't care of Work Quality
The success of a BI implementation will be heavily dependent on knowledge of how the
organization functions. Those who work to implement business intelligence apps will need to
know the location of the data, and how this data is used. Working with analysts who have this
information can save the company millions of dollars over the long term. At the same time, many
companies choose to outsource their BI projects to others.
The danger of outsourcing a BI project is that few outside sources will understand the policies,
history, or customer demographics of a given firm. While these vendors may be capable of
making up for a shortage of skills, they won't be able to replace the knowledge of employees
who have worked with the firm for years. When a company chooses to outsource its entire BI
project, it will often find itself in a scenario where it will be necessary terminate the project,
working in-house instead. This transition can be both time consuming as well as expensive.
Often, consultants will not be able to understand a business within a span of few weeks,
especially if the business is large and established. Consultants are best utilized for providing
resources that a company doesn't have, with the goal of transferring this knowledge to in-house
employees. Not only will this allow companies to reduce their dependence on consultants, it will
also allow them to increase employee morale, as they gain the knowledge that will allow them to
adopt the new processes.
In many companies, you will find few employees who actually understand the inner workings of
their firm. Fewer understand the data and culture which is necessary for proper BI
implementation. As a result, many companies find that they must depend on an outside source
for this process, a consultant that will work with them during the project's implementation.
However, it can be extremely difficult to find a consultant who is truly interested in the business,
and not just lining their own pocket. Even harder is finding a consultant who sees your business
as being their business.
In this context, consultants are similar to mercenaries. While they may be highly trained, their
loyalty to the organization which employs them is always in question. The reason it is in
question is because they are outsiders, merely hired to complete a task. Their primary incentive
for completing this task is money, and because of this, the quality and outcome of their work
may be lower than it should be. At the end of the day, the consultant is there to do a job, and that
consultant makes his or her money by working with multiple clients. As a result, their
concentration will often be divided.
The problems mentioned in the above paragraphs are compounded when companies choose
consultants based on cost, rather than quality. When planning a BI project, many companies
focus too much on the consultant's hourly rate. A greater emphasis should be placed on the
deliverable. It is important to remember that price is what you pay, and value is what you get.
Paying a lower price doesn't guarantee that you will get greater value (and the same can be said
for paying a higher price as well).

14
Many companies choose to emphasize price over value, and as a result, they often lose far more
money over the long term than they would have if they had focused on value. For example, let us
say that a firm decides to a hire a consultant for their business intelligence project. The firm
chooses this consultant primarily because he is "cheaper" than the others. Little attention was
paid to the value of his work.
After the BI project is completed and the consultant is on his way, the company then begins
having problems. Not only did the consultant do a poor job during the implementation, he is no
longer available and fails to respond to emails and phone calls. The problems with BI continue to
grow, and the company spends huge sums trying to fix them (unsuccessfully). The problems
begin to affect the customers, and as a result, they begin using rival companies. Eventually, the
company abandons the BI app, and the amount of money they lost in customers and trying to
repair the problem are ten times higher than the rate they paid the consultant.
This is what happens to companies that emphasize price over value. A price is a price. It may be
high and it may be low. But it shouldn't been seen as an indicator of anything, unless it is
compared to the value that is being offered. When choosing a consultant, it is important to look
at value and deliverables first, rather than price.
The first step towards successfully implementing BI is to insource rather than outsource. It is
much better to use an internal source for implementation as opposed to an outsider who has very
little stake in the project. The loyalty and quality of a consultant will always be questionable, and
they will never have the insight that long term employees will have. An in-house team will have
a much greater stake in the project, as they are a part of the company and its outcome will help or
hinder them.
If an in-house team doesn't currently exist, then the company should create one. Employees
should be recruited or trained who have the ability to implement the BI project. If a consultant
must be used, he should always be regarded with caution, and the firm should seek to extract as
much knowledge from them as possible so they are no longer needed. The goal should be to
transfer this knowledge to the in-house team, where it can be used for the creation of a BI project
which is home grown. Creating an in-house team for BI may be time consuming up front, but the
strategic wisdom that the company will gain over the long term will be well worth it.
Just Implement, Don't care of Performance
When showcasing their products, vendors will typically show their applications processing data
which is no more than a hundred thousand records. The problem with such demonstrations is that
they're often insufficient for the needs of a large company, and this isn't discovered until the
production implementation is started. Most large enterprises need applications which are capable
of handling hundreds of millions of records, and there are a few enterprises which need
applications capable of handling billions of records. Clearly, an application that can only handle
a few hundred thousand records isn't useful to these organizations.

15
Despite this, many organizations choose to use such applications anyway, and the end result is
inevitably disaster. Even if an application is capable of handling the data a company currently
has, what about a year from now? Two years? BI applications must be scalable, because the
inflow of data will be. While some companies wisely choose products which can support larger
volumes of data, they fail to factor in both the volume of users as well as the concurrency.
It is important to understand that business intelligence involves a great deal of data, raw data that
will have to be integrated within multiple systems. Only then can this data be turned into
information. Performance management is an important consideration because it allows an
organization to leverage this information. In many respects, the information is far more valuable
than the actual data, since the process of data transformation and integration will result in info
that can be used to make strategic decisions.
While numerous executives have acknowledged that BI can provided data in the form of reports,
dashboards, and querying, they still felt that most of these mainstream products were inefficient.
The reason for this lack of content is because simply reporting information will not lead to
improved results. Actions must be taken based on the information which will allow the company
to grow. While having access to BI is crucial, it often comes at the expense of departments
requesting enhancements that IT simply can't provide.
The ability to extend BI throughout the company is critical, and will determine the company's
profitability. However, management and improvement are not identical. It is possible for a
person to manage and break even. Improvement, by contrast, is the way in which you win.
Performance involves the ability to deploy BI. Without performance considerations, business
intelligence has no direction.
Business intelligence is the platform that will allow for queries and reports. It should be
considered the foundation. However, performance management is the mechanism by which
strategy will arise, and it will give businesses the ability to leverage the systems and processes
that can ultimately enhance their performance. A failure to consider performance management is
one of the key reasons why BI implementations fail. BI only works when data is attached to
decisions, and performance management in conjunction with BI is the way in which this
happens.
Performance management and business intelligence should never be implemented in isolation.
When they are integrated, the success of the project will grow. While software can enable you to
do many things, it is the thinking that will ultimately decide the outcome. It is necessary to be
able to visualize the possibilities to take full advantage of PM and BI.
The first step in successfully managing performance is to choose a vendor/app that is capable of
handling the data a company already possesses. Additionally, the chosen product must also be
scalable. Once a vendor/app has passed this test, the company must also ensure that the product
will be capable of supporting both user and data volumes. Because runaway queries are a
problem for many departments, the chosen product should include safety mechanisms which are
capable of arresting them.

16
This is crucial as not every company has the resources to use DBA monitoring which is
dedicated. Though this type of monitoring can find and destroy negative query threads, doing so
can be very costly. Success with a BI project will ultimately be determined by making the proper
choices, as well as choosing the proper technology and processes. However, the importance of
people should never be underestimated it. It is the people who will ultimately make or break the
project.
While business intelligence is one of the key components in obtaining performance management,
this is only possible when the business intelligence is available across the enterprise. Companies
today are tasked with making business decisions which are effective; however, these decisions
must also be made within a timely manner, and they must be made throughout the key areas of
the business.
In the past, it was possible to handle company challenges within departments; today, both
managers as well as executives must be able to handle changing conditions within the level of
the enterprise. The ability to properly utilize information throughout the enterprise will allow one
version of the truth to emerge; one which is actionable.
I hope you enjoyed this white paper. Please add any additional things that can impact BI Project
Implementation. You can reach me @Linkedin or Google+.
Reference - Thanks to RaedAlhadhoud for sharing the base for this white paper

Why Business Intelligence Projects Fail Due to Lack of Planning and Buy-in

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Why Business Intelligence Projects Fail Due to Lack of Planning and Buy-in

Similaire à Why Business Intelligence Projects Fail Due to Lack of Planning and Buy-in (20)

Dernier

Dernier (20)

Why Business Intelligence Projects Fail Due to Lack of Planning and Buy-in