All Too Easy to Make a BI Mistake
We all like to think we are smart enough to avoid common pitfalls and mistakes. But, beware! The common BI mistakes are only common because they are so easy to fall into, even for experienced practitioners.
The best way to avoid them is to specifically consider them in the project planning. That way, if they do occur, we know how to mitigate the potential risks.
You will see that many of the risk are related and share common causes and solutions. The first hurdle is to identify that a project is potentially tracking down the wrong path. If caught early the resolutions are often simple to implement and will have an immediate benefit to the project.
1. BI User Engagement Mistake
The BI User Engagement mistake happens when the target end users of the system stop being actively engaged in the project on a daily or weekly basis.
BI projects thrive when there is a continual cycle of communication between the BI system designers and the end users. If the BI system delivers a fixed set of requirements decided at the outset of the project it is likely to be a disappointment very quickly after its initial release. This is because BI requirements are always shaped by the capabilities of the technology which can only be evaluated properly when the users see their data in combination with the tool.
Active engagement can differ from project to project but if they are not spending at least a couple of hours a week reviewing progress and providing tangible feedback then they are not being active.
Why does it happen?
Business Analysts
In large companies the use of specialist Business Analysts can remove the end user population from the day to day development activity. The business community assume that the Business Analyst will take care of everything and the solution will appear at the end. Whilst, this may be an effective approach for traditional software development it is not ideal in BI project. Users in BI projects will only properly form requirements once they see tangible deliverables and so continuous feedback and review is essential.
Data integration phase
Most BI projects have an initial phase of data acquisition and integration. User and developers often assume that there is no requirement for interaction during this phase because it is technical and or little interest to users. Unfortunately, nothing could be further from the truth. The data integration phase is where the greatest inefficiencies can creep into the project due to lack of visibility. It is not uncommon for an ETL developer to spend several days trying to clean data that the users will later decide holds little value to them. Only when the users get plain site of the data will they be sure of the importance or usefulness.
Business community does not buy into the solution
Sometimes users will passively disengage from the project if they believe it is the wrong choice of software or incorrect approach. Regardless of whether the project team as a whole believes they are right, ignoring their unvoiced concerns is just storing up trouble. There are pragmatic fixes to these underlying concerns that can be implemented without derailing the whole project or underlying software platform.
Business community say they are too busy
Whilst all of us are sometimes too busy to concentrate on anything but the matter in hand, the most likely underlying reasons for users to claim they are too busy is that they cannot see the relative benefit of the proposed solution. If someone was to offer you $10,000 for an hour of your time you would make that hour! Whilst the benefits are unlikely to be as stark there are plenty of way to reengage your the audience without making unreasonable demands of time.
How can you avoid it?
Deliver early and often
The best way to keep a high level of end user energy and engagements is to deliver early and often. Every week there should be tangible end users deliverables so they can see the data and engage with the tools. Every week there should a show-and-tell of project progress. The involvement of Business Analysts will certainly benefit the project but they should not be used as a go between (see advice on BI Project Team)
Each phase of the project should be short and include end user deliverables which they can interpret. A maximum of 4 weeks is a good starting point (see Introduction to BI Project Management). At the end of the phase there should be review period with lessons learned rolled into the next phase. Agile methodology has many useful practices that you can employ.
Focus on business goals
Even if the project's main focus is about creating a consolidated data mart of data warehouse (see Data Integration Mistake below) there should be explicit end-users deliverables so that they have the opportunity to evaluate progress and see the capabilities of the BI user tools.
If the users are not actively engaging with the deliverables and explicit attempts to raise energy have failed then you need to discuss their concerns and listen to them. The outcome of this may be a different approach to the project or even a pause while the users concentrate on other priorities. Better to call out any underlying issues rather than continue developing in the hope that things will come together in the end..
2. BI Single Vendor or Single Product Mistake
A BI Single Vendor or Single Product mistake occurs when the requirements move away from the core capabilities of the selected BI technology but the team continue to push the technology to try and shoehorn the requirements into the technology at hand. There are several consequences that normally flow from this.
80% of the development time is used to meet the last 20% of requirements because of the need to find workarounds or technical tricks to bend the product to requirements
The end solution is unstable because the complexity of implementation and development ultimately leaves the product exposed to scenarios that it would not normally handle
The 80% of requirements that were being met by the tools core functionality take a back seat or are warped by the complexity used to meet the difficult 20%.
Why does it happen?
All singing, all dancing
There is often a perception that a single vendor BI platform is sufficient for all requirements. BI platforms from the enterprise vendors are sold on the basis that they can cater for all the normal BI requirements. While this is often true, it does not necessarily mean that the vendor has the best tool on the market for every component in the generic BI Solution Architecture. However, because it may appear that the BI platform can do everything, project sponsors are unwilling to consider other tools.
Awarnesss
Another reasons why projects can sometimes get stuck on a single vendor or product is the perception that to add another tool would be expensive and complicate delivery.
The overriding cause of the single vendor/platform approach is lack of awareness of the alternatives. No one wants to go through another procurement process with the related expense and time.
How can you avoid it?
Continuous review
The best way to ensure that you do not fall into the 80/20 trap -spending 80% of the time trying to meet 20% of the requirements - is to closely monitor the relationship between development effort and requirements. This is why close cooperation between the BI developer and business owners is so important. It is not unusual for BI developers to expend significant effort trying to get the software to jump through a hoop only to find that the business owners would have dropped the requirements had they known it was so difficult to execute.
Focusing consultancy
If a requirement is proving difficult to meet with the existing technology but it is also an essential business requirement then there are alternatives to thrashing the software in hand. Firstly, you could engage an outside consultant who specialises in your software just to ensure that nothing obvious is being missed. This need not be expensive. A single day of consultancy could save weeks of unnecessry development effort.
Power user tools
Secondly, if the project team are sure that the limitations of the software are the roadblock then it is time look at complimentary software for the specific business problem. It is often a small collection of power users who are demanding exotic functionality. The good news is that there are many specialist end-user BI tools that are cheap, easy to use, and can be deployed to specific desktops. These tool generally integrate with a variety of underlying relational or multi-dimensional databases. Thus, the core BI platform remains intact, whilst satisifying additional power or flexibility required by some users.
3. BI Data Integration Mistake
The BI Data Integration Mistake occurs when a BI project is too heavily weighted towards ETL and data integration and lacks explicit deliverables to solve end-user business problems.
Data integration and ETL does add business value but only when the fruits of these labours are exposed to end users through BI tools, reports, and dashboards. Very few business users have the time or confidence to start creating their own BI solutions from data marts or warehouses without some pre-existing templates, reports, or training to help them navigate the new environment.
With projects that focus on data integration there is a real danger that the budget for the whole project is consumed and that the promised second phase with all the analytics and business value never occurs because of a perceived lack of business value in initial deliverables.
Although it is tempting to think "build and they will come", this rarely occurs without significant promotion of the environment and end user BI tools.
Why does it happen?
In the early stages of a BI project data integration can be a comfortable place for everyone on the project. BI developers are happy to get on with the ETL coding free from feedback and revisions and feel like they are making good steady progress. Business users are happy to resume their primary business activities confident in the knowledge that all will be delivered at the project close.
The problem is, none of this apparent progress is being tested against the cold hard measure of return on investment and user benefit. Is the data accurate? Is all the integration work necessary? What exact business problems are addressed with the integrated data? Even the most thorough data integration project can be undone by a simple business question that was not considered early in the project.
How can you avoid it?
Business first
The only way to avoid this risk is to include specific business oriented deliverables throughout the project. Even if it is just a few simple reports or dashboards you will be amazed how this focuses the data integration effort and engages users. The project is no longer an intangible and abstract data modelling exercise. It is a project that can validated in terms of data accurracy and business value. The reports should be exposed to users at the earliest opportunity after the first tactical loads of data
Even if everyone agrees that data integration and cleansing is a priority, the project must still include some explicit business oriented deliverbles. If the right tools are deployed this is always a short and straightforward exercise.
4. BI Spreadsheet Replacement Mistake
The spreadsheet replacement mistake occurs when the objective of the BI project is to replace complex reports constructed in spreadsheets. Spreadsheet power users will not give up their spreadsheet use lightly and with good reason. It is almost impossible to replace the flexibility and power of a spreadsheet outside of this environment. Luckily there are alternatives.
Why does it happen?
The spreadsheet is dead!
Most people are aware of the downside of doing complex reporting and data manipulation in spreadsheets. A tangled web of macros , complex nested formulas and linked spreadsheets can lead to a situation where no one in the organisation really understands what is going on. They just hope it does not break. Then there is the ongoing manual effort involved in importing data from other sources and checking lookups and references.
Long live the spreadsheet!
Unfortunately, having correctly evaluated the disadvantages of spreadsheet use, the advantages are underplayed. Flexible layout, powerful expressions and calculations, many charting options, and most importantly, the ability for end users to make fine-tuning modifications to the data, formating, and content without involving the IT department.
What is required is a tool that provides better data management within the spreadsheet environment but still leave users with the ability to control deliverables and reports. Fortunately, there are a number of options.
How can you avoid it?
There are a number of BI tools with true integration with Microsoft Excel, the most popular spreadsheet application. Analysis Services (SSAS), PowerPivot, and Cognos TM1 enable end users to build functionality, reports, and dashboards and even data mining (SSAS) within the Excel environment, whilst avoiding the pitfalls of repeated manual data integration and complex formula and macro driven reporting. If you are not familiar with these tools you will be amazed at how they can transform spreadsheet usage.
5. Software Migration versus BI Project
A common mistake is to call a migration project a BI project, just because it uses BI technology. Typically, there will be a collection of reports and processes created in a legacy or tactical environment. The mission statement is to convert and transfer these reports onto the new technology.
The key danger of this type of project is that it delivers no additional business value. It may save the company some money in licensing fees but this saving can quickly evaporate in the development costs required to port the reports. Due to the lack of perceived business value, user engagement is likely to be low and the project will have little chance of exceeding user expectations and will quite possible fail to deliver.
Report specifications alone do not represent a good input for a BI project because we do not know if:
- the reports are used (there may be several layers between the initial report recipient and the decision maker)
- the reports are an end goal or simply a stepping stone to further analysis and data discovery
- the reports represent the best way of supporting the business process with the new BI technology
See the business intelligence cocktail. The missing ingredients in many migration projects are the involvement of the subject matter expert and the explicit identification of a business goal.
Why does it happen?
Using current report specifications to guide future deliverables seems to make perfect sense and save time. The rationale is that they are unambiguous and we can give them straight to the development team, without the need for too much stakeholder engagement. Unfortunately, this approach misses the opportunity of BI technology, which is to solve the business problem in a novel and efficient way, using the tools to their best capability.
Report specifications do not communicate the end goal, nor do they specify how the user will engage with them. People move on, but we continue to produce the reports because we always have. Suddenly the reports are indispensible in their current form because Bob must produce the report for Sue, who needs to get the report to Dave, who must send it on to Jane. Jane’s secretary then takes it from her in-tray and deposits it in a filing cabinet, or worse still, a waste-paper basket!
How can you avoid it?
It is a natural course of business to want to migrate from one software platform to another. But don't waste the opportunity!
Migration projects are an opportunity to review business requirements, and step back from legacy deliverables. Simply converting a set of reports to another technology is a missed opportunity to exploit the capabilities of a new tool set. The majority of reports over 6 months old have lost much of their initial value; this is because the data has become tacit knowledge, or simply not relevant.
Instead, stepback to the underlying business objectives and redefine the solution in the context of the new software. See our BI Requirements Strategy for more information on collecting BI requirements.