Download download

19/01/2010
10 Mistakes to Avoid in a Business In…
10 Mistakes to Avoid in a Business
Intelligence Delivery
Information Management Special Reports, September 16, 2008
Lalitha Chikkatur
Behind every success or failure are people. People are the only differentiators. Every data
warehousing (DW) and business intelligence (BI) project, whether successful or not, teaches
us something. It is generally on failures that we base our new success. Having said that, it’s
not always necessary that you fail to learn; you can also learn from other’s failures, 10 of
which are discussed here.
ADVERTISEMENT
Mistake #1: A non-BI background project manager managing the end-to-end
delivery of a BI initiative.
BI project management requires different techniques and methods to succeed. The
breakthrough in work process and methodology that form the foundation of data warehouse
delivery include such concepts as iterations and phased delivery, and from a non-data
warehouse perspective it's hard to appreciate how truly revolutionary and critical these
concepts are for successful BI delivery.
A project manager who drives the complete BI initiative from end-to-end has to at least be
educated on the basics of DW and BI to be able to deliver the BI project successfully. No
matter how successful an individual maybe or how much expertise he/she has in managing
non-data warehousing projects, he/she will never be able to deliver the DW projects
successfully if he/she does not understand the phased delivery approach of data warehouse.
Most often it becomes very challenging to convince a non-DW project manager that the
analysis and design phases in DW projects go side by side and not one after the other like
in traditional project delivery. If this important aspect is ignored, then the schedule and
budget are going to get hit, as one always encounters changing requirements in DW
projects, whether he/she likes it or not. Additionally, the fallout would be arguments and
politics rather than focusing on technical solutions.
Every project delivery requires a methodology, which a project manager uses to deliver the
http://www.information-management…
1/6
19/01/2010
10 Mistakes to Avoid in a Business In…
project successfully. A project manager who by definition plans, controls and reviews all
project activities must understand that a data warehousing project delivery cannot use the
traditional “waterfall” methodology. The data warehouse methodology must take into account
the fact that the delivery of BI projects happens in iterations. The success of data
warehousing projects is in its phased approach.
A project manager who is not knowledgeable about BI is not able to make appropriate
staffing selections for his team. The team also suffers due to lack of guidance from the
leadership role as much as the goal of the BI initiative would suffer because of the
management.
Mistake #2: Being in a “pleasing” mode with the clients rather than concentrating
on feasibility and value-add from the BI project.
The client sponsoring the DW project and end users have to accept the solution which is
being built by the implementation team; there is no doubt about this fact. At the end of the
day, the solution being built has to be liked and should demonstrate value-add to the clients.
The time and effort spent on a particular initiative should demonstrate value for money. But a
word of caution. In this process, the implementation team, which is most often a service
provider company offering offshore support as well, should not get into the “pleasing” mode
with the clients and users. It might not be practically possible to implement the client’s entire
wish list. This should be communicated in a strong but polite way. The requirements driving
the DW initiative should be validated very critically so that the best solution can be built.
What cannot be done should be communicated as clearly as you communicate what can be
done. Clients will definitely appreciate and welcome this kind of assessment in the initial
stages of a project rather than giving explanations on architecture and infrastructure just
before production or in use or acceptance testing when it’s too late.
Mistake #3: Assuming service provider companies own everything about the
successful delivery of the project.
This is yet another critical factor for a successful BI delivery. A service provider who has
signed a contract to put the BI project into production definitely has ownership on the
delivery. That being said, the delivery cannot be a success without active participation from
the client and end users having in each stage and phase of the entire lifecycle. Service
providers are specialized consultants who can give you options and best practices, much
like a professional home decorator consultant. Because it’s your home, you will have to give
the consultant your input and exact specifications. If this does not happen, then the decorator
will decorate the home according to his assumptions of your likes and dislikes, which you
may or may not approve of. And if this happens at the last minute, then not only will you end
up paying for the work that has already been done, but you will also invest more time and
money on rework. Without active and adequate client involvement at every phase, no BI
delivery can ever have an assured success.
http://www.information-management…
2/6
19/01/2010
10 Mistakes to Avoid in a Business In…
Mistake #4: Bringing in a solution architect halfway into the project and assuming
that he/she is going to magically fulfill all the deficiencies.
This is the most common scenario one sees in most of the BI projects. When things are not
happening the way they should, the management thinks the immediate remedy is to get a
solution architect. What one has to understand is that a solution architect cannot just walk in
and wield a magic wand to set things right. The solution architect’s experience will
determine how soon he/she can start delivering the value-adds. Also, the time at which you
bring in the solution architect is a driving factor for success. Often when it comes to BI
architecture, business users are from Mars and IT people are from Venus. To get them to a
common platform is in itself a premium skill for a solution architect.
Every BI delivery must have a solution architect with expertise and wide skills in DW and BI.
This is vital, as they bring a wealth of knowledge from reference architectures and similar
implementations with them. This “ready-recon” eventually reduces the cost and time to
implement technology solutions.
The best time to start their involvement is from the analysis stage itself. If not then, do it at
least before you spend a large amount of time exploring technology options and assessing
the appropriate solutions. Carefully set expectations of the value a solution architect would
deliver. If you decide to engage a solution architect when your data model is near
completion and expect the architect to do magic to make a performance-tuned and efficient
design, it might be overexpecting, as things would have already crossed certain stages
involving a good amount of time and cost. At that stage, again the issue resolution becomes
more political than technical.
Mistake #5: Lack of the right people with the right skills evaluating BI tools for the
implementation.
When a new BI tool is being evaluated, a big crowd of stakeholders is often involved in the
evaluation. This might include people who are directly or indirectly associated with the BI
initiative for which the tool is being evaluated. If a formal process is not followed, it might
lead to various arguments and different loops without ever closing the evaluation. Each
individual will come up with their own comments and wishes, and this will lead to a laundry
list of features expected from the tool. Any BI tool is just a medium helping to deliver a
definitive functionality. But what makes the initiative a success is the right people selecting
right kind of tool to deliver the right functionality.
Key people evaluating the BI tool should clearly understand that each BI tool is pretty much
designed for some kind of defined and specific purpose. No tool as such is good or bad. It’s
the decision-makers, not the tools themselves that make an implementation a success.
Imagine if a director whose area of expertise his whole career has been in infrastructure
domain is given the authority to make the decision on an analytic tool. You guessed right… It
would be a disaster.
http://www.information-management…
3/6
19/01/2010
10 Mistakes to Avoid in a Business In…
The BI tool evaluation team must include a combination of theBI team, BI solution architect,
users and the procurement team. Input from the team should be considered and analyzed to
a specified extent to avoid analysis paralysis on the evaluation. If the right people keep their
expectations straight, the evaluation process should be relatively smooth. The important
factor to consider while evaluating is what exactly the problem statement is. Answer
questions like: Is the tool expected to cater to a multiterabyte data warehouse, or its less
than a terabyte? This will be a big driving factor as your choice of tools will be dependent on
this. You don’t need a that comes at a premium price to be catering a <1TB data
warehouse. In a similar way, it might be totally inappropriate to evaluate a master data
management (MDM) tool when your first data warehouse is still being built.
Mistake #6: Business users driving the data modeling.
This could be one of the biggest mistakes which can cause the complete BI initiative to fail.
The data model is the heart of the data warehouse, which will determine all other aspects
such as performance, easy reporting, scalability etc. There is no doubt that active
participation of business users in doing data modeling is required, but the modeling should
be done by data modelers who specialize in data modeling and dimensional modeling.
Business users have to define and explore the links and dependencies between various
business areas or subject areas. Business users have complete ownership of
understanding the data. With this knowledge and taking input data, modelers have to define
the most appropriate way of placing each measure and dimension of the subject areas in a
star schema or a customized schema, whichever is appropriate for that environment. In this
exercise, data modelers have to take the ownership of designing the schema and be very
careful in defining things even if that means being hard sometimes. They have to be careful
of a situation which I once faced. A business user was pestering me to define a data field
called “premium” in investment banking as a dimension. This field was holding currency
data. It took two full days for me to explain and convince the user why that field would not
qualify as dimension and should be actually a measure.
By getting influenced by business users, data modelers easily fall into a pleasing mode.
Then they are most likely to deviate from the modeling rules, which down the line, will lead to
lot of rework and remodeling.
Mistake #7: Counting on your vendor to deliver all that they represented in the
presentation.
Avoid overdependence on vendor’s claims about their product and its performance.
Everyone wants to be the best when they are making a presentation about their products.
The value and performance of the products always look promising; they just might be. But
one must be careful to do one’s own homework about the product rather than just blindly
accepting vendor presentations and claims. The key here is that tools are not the only critical
http://www.information-management…
4/6
19/01/2010
10 Mistakes to Avoid in a Business In…
success factors for a successful data warehouse. There may be instances where the
capabilities being evaluated from the tool are not available in the current release; however,
the vendor might showcase that they’re been planned in the next release. Making decisions
based on these kinds of assumptions is very risky for the simple reason that you are building
a thorough dependency on the delivery of a separate entity over which you have no control. In
making a decision about a tool on which you are spending a fortune, collect references from
the vendor and network with them to see how the product has been doing in a similar
environment. You should leverage references where work has already been completed.
Apart from the references, it might also be worthwhile to consider the analysis of those
products done by research firms like Gartner and Forrester.
Mistake #8: Assuming data quality can be managed “somehow.”
As we speak about the maturity of the data warehouse today, there is still a lot to be
explored and learned about the severity of the data quality problem. Assuming data quality
can somehow be taken care of might lead to lot of inconsistencies in the downstream
systems. The quality of the data has to be checked and cleansed at the source or at least
before it enters the data warehouse. It is inappropriate to do any quality checks in the data
warehouse itself.
Companies depend heavily on information to make decisions regarding profits, effective
operation and customer satisfaction. Inaccuracy and inconsistency in the data will hinder the
company’s ability to perform competitively. An effective data quality program is almost a
must in these maturing systems. It would allow companies to analyze better and make more
meaningful decisions. The data quality initiative need not start as a big bang or with the
purchase of an expensive tool. It could be an initiative a step-by-step approach that could be
automated with a tool once it’s matured in organization.
Mistake #9: Overdependency on contractors and ignoring the need to build BI
capabilities in house.
Hiring contractors for specialty skills has benefited data warehouse delivery within
organizations. However, contractors may benefit specific projects, but not on an ongoing
basis. If there is overdependency on the contractors who come in, do good work and leave
upon delivery, they not only take their deep knowledge with them but also are not available
for any clarifications and fixes if a need arises. Don’t treat contractors as employees. You
should draw a very clear line for what contractors can help with and what stays internal.
Contractors can very easily be caught up in office politics. This is even truer if your
contractors are coming from a specific software vendor. It is practically not possible for them
to be unbiased about their products. This is where a knowledgeable in-house person with BI
skills is able to evaluate and advise the clients if anything is derailing or if the technology is
just not fit for their environment.
http://www.information-management…
5/6
19/01/2010
10 Mistakes to Avoid in a Business In…
Mistake #10: Assuming you are done once the data warehouse project is in
production.
As the nature of data warehouse is change and becoming more and more productive with
iterations, so is the delivery. Once the project is in production, you have just completed a
phase - you are still not done. You have a new world to explore and make continuously
improve that application. The investments in data warehousing projects are always shared
between the actual delivery and research.
With the successful completion of the implementation phase, you should research what other
systems can benefit from it and which other systems can be integrated so that you get the
best value and results. This keeps on going, both from the point of view of improvement of
the existing phase and of initiating new phases.
We all have faced the scenarios mentioned in this article at one time another during BI
delivery. I have addressed 10 common mistakes that impact a BI delivery. These mistakes I
have seen myself. I solved a few of them and was able to prevent some damage, but for
some I was just a witness and could not do anything. However, I believe these precious
lessons, learned the hard way over the years, and can help my BI peers.
Lalitha Chikkatur is an Information Management professional associated with Capgemini
Financial Services UK. She has rich experience in architecture, methodology/process,
technology and tools in the business intelligence/data warehousing domain. She can be
reached at [email protected] or [email protected].
For more information on related topics, visit the following channels:
Business Intelligence (BI)
Data Modeling
DW Administration, Mgmt., Performance
DW Basics
DW Design, Methodology
©2010 Information Management and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.
http://www.information-management…
6/6