Five Ways to Fail BI projects

A new report from market research firm Gartner says that 70 to 80 percent of all corporate business intelligent projects fail. According to the report, the reason for those failures is a combination of poor communication between IT and the business, the failure to ask the right questions and the failure to think about the real needs of the business. While an Accenture survey of managers in Fortune 500 Companies found that 59% cannot find valuable information they need to do their jobs; 42% accidentally use the wrong information about once a week and 53% believe the information they receive is not valuable to them.

But business analytics is listed at the top of most CIOs’ project agenda, so how to learn from others’ failure lessons, besides avoiding the pitfalls for traditional IT project, what are specific failures BI projects need avoid:   

1. Approach BI as Engineering Solution

Remember, BI project is always related with business. Usually the failure is caused by not well-defined project requirement, or the project is not aligned with strategies needs as a result of bad communication between IT and business.

"If you don't ask the right questions, BI is not a crystal ball that pops out the answer," Some industry analysts warn. "People in IT need to stop approaching BI as a vendor or engineering solution or as a tool. They need to understand what business they are in. They are in the information and communication business”.

• Collect requirements agreed with business stake holders and end users. These should then be adhered to and delivered without compromise. When business does not know what they want and give some abrupt requirement. And at the time of delivery, they come and say this was not our requirement. Then for sure the project is failed.

• Define your plan, then follow it. Any BI tool will only deliver what is required , if the project team have clear requirements. Not the other way around. Time spent on a well documented plan with defined requirements, metrics, functionality, scope, and a chosen methodology combined with a feasibility analysis concerning budget and time should be set in stone before doing ANYTHING. Find out what the client needs, set up lines of communication, gather a competent team, and follow a written guideline. This over-simplified explanation should give insight into how you can lessen the impact of any negative factors.

• When approach BI as Engineering solution, it always fails. Business does not understand (nor really care about) technology, and vice versa for IT. Need a strong liaison to start with the business and drive through to technology in a reasonable manner for BOTH areas. Business will better understand and trust what they can "reasonably" get and IT will be better able to deliver what is "reasonable".

• Reconciliation. If your numbers don't reflect the numbers that are represented in trusted sources, the business will neither believe nor trust the BI source. It has represented a huge waste of time and money on many projects.

• The Golden Rule of software development: Don’t let enthusiasm cloud judgment. Recognize the importance of working closely with the application end users.  It's also critical to invest time and effort that all parties put into a successful project.

2. Data is Not Good Enough

It’s all about data: data manage­ment is the number-one challenge companies face in their use or adoption of business analytics. The detailed data Issues include data qual­ity, consistency, integrity, complex Data Model/Cubes and data ac­cess.

“Department silos” also ranks high in the challenges busi­nesses face in their business analytics deployments. In the majority of companies, information is not shared consistently & coherently across the organization, nor is data readily available to those who need it. Companies are also con­strained by a lack of integrated processes—operating within the department/functional unit level—which is a death knell to effective analytics across the organization.

3. Lack of Sufficient Business Governance 

• Lack of sufficient governance framework supported by the leadership/decision makers of the enterprise and socialized to the user community. 
• Irregular/non-existent stakeholder cadence to review and accept the changing needs of the enterprise with engaged stakeholders. 
• Unclear understanding or top-down acceptance of who the key stakeholders are. 
• Insufficient acquisition/understanding/agreement of the business objectives. 
• Too much and too complex solutions too soon. Larger releases in the beginning as opposed to smaller incremental value. 
• Failure to engage stakeholders and data stewards from across the departments /divisions. 
• Absence of a "control model". Business plans, business models and action plans are not enough. 
• Lack of interest ("fear", weak data maturity, etc.) from Management in modern BI-tools. 
• Lack of understanding from Management when it comes to the need for involvement in the requirements on the BI-systems. 
• Shortcomings in communication to end-users, why, when, how, etc.. 
• Constantly changing demands and priorities. 
• "Politics" and poor personal relationships between in and around Management. 

4. Lack of Architectural Consistency     

• Lack of architectural boundaries and accepted patterns of implementation. 
• Long initial delivery cycles that are not iterative and adaptive to business needs. 
• Inconsistent requirement tracking/meta-data management and prioritization. 
• Lack of consistent mechanisms to track and manage integrity, quality, and currency of data in BI as compared to the source providers. 
• Little or no management of service level or interface agreement between source providers and (internal systems or external systems alike) 
• Limiting meta-data models with little training to report authors and business analysts on how to properly construct information using the models.

5. Treat BI as Traditional IT Project

Why shouldn’t BI be treated as a traditional IT project... because it’s more dynamic to adapt to constant changes and it’s extremely business focused. You can never guess/speculate what question will come next from your users - you just have to make sure you can react as quickly as possible with a flexible solution that does not take months to change something.

One of the main causes of failure to BI Projects has been that the technical requirements haven't been pinned down, and the client adds to the scope as the project is in the development phrase. Scope creep is a killer - the client says "the developers got it wrong" when they are working towards a moving target due to constant changes.

The client will want the perfect solution with everything they could possible need to reporting and also hope it "future proofed", but in reality, some specific BI roadblocks include:

-  Ownership by Client / Insufficient User Involvement
- Large Scope
- Data Integrity/Quality
- Budget Hogs/Funding
- Corporate rivalries
- Poorly defined or incomplete KPI’s
- Complex Data Model/Cubes
- Strong coupling between EDW and BI environment
- Lack of right talent to deliver project on value

Learning from failure is bitter, but it helps business & IT become healthier and improving. As one of authors well put, when facing failure, one shouldn’t tiptoe around them, or just rename them "teaching moments" or "issues.", one shouldn’t play blame games, the right attitude is to lay their mistakes bare so that their teams can improve.

To learn more from failures:

• Success is Failure Inside Out,
• Five Pondering Why IT Projects Fails,
• Five Pitfalls Why Strategy Fails
      
      

<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

Posted in: Business Intelligence,GRC,Lessons from Failures,Project Management