Continued from Part 1……
You should have continuous contact with the main users of your application. Keep in mind that they are the business analysts of your organization who are in daily use of your application. They should be encouraged to have faith and contribute to your project requirements. If they cannot be made to accept the project through conviction and direct contribution, no amount of further training will. Crisp requirements gathering and taking time to explain the requirements back to users should be an essential feature of a successful BI implementation program.
A rather common pitfall is that many BI Project Leaders carry the misconception that audits and controls are not necessary where the projects are not of an “operational” nature. This is a grave mistake that drives out your audience especially in the absence of a guarantee that your numbers are matched with those in the original. What actually needs to be done is to show that your environment can be relied upon as much as an operational one. In cases where the numbers do not match (as they invariably will), audit trails and statistics could be produced to reconcile and explain those differences.
Another very common pitfall of a BI project is its inability to sustain the confidence of the business community over the quality of data for decision-making. Obviously they would insist that it should be of the highest possible quality and expect even a higher quality than with regard to data in an operational environment. Devising and employing appropriate metrics for the measurement of data being sent out to your warehouses and marts would be the solution to restore their lost confidence and win them back over to you. I cannot emphasize more; GIGO (garbage in, garbage out) is of relevance here. Good decisions cannot be made from bad data. This has very often been a primary cause for breeding distrust that has eventually led to the abandonment of many projects. The lack of clear statements of success criteria along with a lack of ways to measure program success have led to perceptions of failure. Limited knowledge on technology, architecture and underestimating the need of quality information will certainly lead eventually to project failures. This will lead to decreasing trust of users on the information and there will not be any decisions made using that info. This is a big blow to BI. In such situations, having ‘data stewards’ and some data-cleaning tool in place is well worth the cost and effort.
Under-investment in developing BI and data warehousing core competencies can eventually lead to a BI failure. Conversely, BI investments are wasted unless they are related to specific business goals, analyses, decisions, and actions that result in improved performance. For instance, it is commonplace for BI vendor value propositions to stress on business benefits such as responsiveness, agility, customer intimacy, flexibility, information sharing, and collaboration. But investing in a Business Intelligence Implementation to achieve such business benefits may in actual fact destroy the business value unless those properties can be defined in operational terms and realized through business processes that affect costs or revenues. For example, unless a $3 million investment in a BI application results in an incremental cash flow (after-tax) of at least $3 million; the organization will suffer a decrease in assets.
In this particular business, hardly anybody builds just a solitary BI application; rather an entire environment to facilitate the decision-making process by diverse business users. This means building multiple applications, while making every new application an extension or an improvement over the immediately preceding one. These projects must be capable of being easily coordinated and for projecting a concept of reusability. This necessitates that you incorporate a program management function to fund the projects on a priority basis. This would in turn involve the creation of data models, project plans and reusable templates that need to comply with set program procedures and standards. Non-reuse of information leads to duplication of costs and efforts.
Creation of multiple projects should only proceed with a supportive architecture. It would be your Roadmap too for the determination of how and to what extent each project fits into your overall BI strategy; and their respective contributions to the environment. No supporting architecture means just the presence of some random databases that would only succeed in creating chaos in the entire reporting process. There could be multiple versions of architecture that meet different organizational needs. You may create your own to best suit your particular needs. The Corporate Information Factory is a good model emulated by many organizations.
Here are further causes in brief that led to BI implementation failures in real time:
It is hoped that the above stated common factors and pitfalls known to be very often associated with business implementation program failures will act as a forewarning to stop you in your tracks if you also seem to be treading a path to danger and breakdown. Even if you do happen to fall, being forewarned should help cushion the fall and give you sufficient time to change direction and recover to revise the project and continue with it instead of abandoning it.