10 Mistakes to Avoid in a Business Intelligence Delivery

Artigo muito bom. Antes de começar um projeto , passe este artigo para a equipe.

Pelo menos não se vai errar no básico ....

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.

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

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.

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>

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

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.