According to Gartner (Predicts 2012: business intelligence still subject to non-technical challenges), in 2014, less than 30% of business intelligence (BI) initiatives will successfully align their deliverables with enterprise business goals. We have also seen some other numbers about the failure rate of data warehouse projects.
On the other hand, we have also seen data warehouse projects that do succeed. This blog post lists the key lessons we have learn't on several projects. Hopefully you can learn from them and avoid these 5 mistakes on your own project.
Quick Overview of Our Company
Te is a Sydney based consulting firm that helps that specialises in the Microsoft BI stack as well including SQL Server, Sharepoint, Excel Power Pivot & Power View and Office 365 self service reporting features. We have also partnered with Telstra and other vendors to provide cloud services as well as planning, budgeting & forrecasting solutions. chlogi x
Part I - (Mistakes 1 - 3)
Mistake # 1 - Assuming everyone und erstands what is being delivered
There are always going to be multiple stakeholders involved in a BI project. It is a mistake to assume that it is "obvious" what each stakeholder expects from a project. This will come back to "bite you" at the end of the project when you deliver the solution only for some stakeholders to criticise your project.
For example, Gartner has confirmed that BI platform requirements are shifting from being reporting-centric to analysis-centric. So in that case it would be a mistake to assume that everyone wants a reporting platform or that everyone wants to do adhoc analysis. Other deliverables that might be expected are dashboards, support for predictive analytics as well as budgeting and forecasting capabilities. In addition to this there can also be misunderstanding about whether new capability is the objective or if it's including a wider coverage of operational data and metrics.
The diagram below also shows the different capabilities that might be introduced depending on maturity of an organisations systems, processes and usage of data.
On the other hand, we have also seen data warehouse projects that do succeed. This blog post lists the key lessons we have learn't on several projects. Hopefully you can learn from them and avoid these 5 mistakes on your own project.
Quick Overview of Our Company
Te is a Sydney based consulting firm that helps that specialises in the Microsoft BI stack as well including SQL Server, Sharepoint, Excel Power Pivot & Power View and Office 365 self service reporting features. We have also partnered with Telstra and other vendors to provide cloud services as well as planning, budgeting & forrecasting solutions. chlogi x
Part I - (Mistakes 1 - 3)
Mistake # 1 - Assuming everyone und erstands what is being delivered
There are always going to be multiple stakeholders involved in a BI project. It is a mistake to assume that it is "obvious" what each stakeholder expects from a project. This will come back to "bite you" at the end of the project when you deliver the solution only for some stakeholders to criticise your project.
For example, Gartner has confirmed that BI platform requirements are shifting from being reporting-centric to analysis-centric. So in that case it would be a mistake to assume that everyone wants a reporting platform or that everyone wants to do adhoc analysis. Other deliverables that might be expected are dashboards, support for predictive analytics as well as budgeting and forecasting capabilities. In addition to this there can also be misunderstanding about whether new capability is the objective or if it's including a wider coverage of operational data and metrics.
The diagram below also shows the different capabilities that might be introduced depending on maturity of an organisations systems, processes and usage of data.
The solution to this is easy but if not done properly it can have great consequences. Take the following steps to avoid this mistake on your project:
BI means different things to different people. Make sure there is a common understanding of what is to be delivered in your own organisation and what's in it for each stakeholder.
Mistake # 2 - Biting off too much
So you have managed to avoid mistake number 1 by doing a good stakeholder analysis and then documenting what everyone wants. The 2nd mistake is trying to be everything to everyone. Just because a requirement is documented doesn't mean it should be fulfilled.
Projects that bite off too much or over promise always end up in trouble when eventually they work out that they cannot deliver everything that was promised. I have seen projects whereby the Finance department, HR, Customer Service, Sales and manufacturing all have a different view of the world and therefore different requirements fro your project.
There are multiple reasons for not being to deliver everything, e.g. not enough resources, not enough time, the tools that you can afford don't have all the features required.
Again, avoiding this mistake is not difficult but if ignored it will most certainly lead to failure. Take the following steps to avoid biting off too much:
The end result is well though out project scope and high level estimate. This is a good basis for creating a more detailed estimate and project schedule.
Mistake # 3 - A loose road map
OK, now you have everyone on the same page with regards to what will be delivered and how much will be delivered within the given constraints.
The next question is what happens to all the requirements that cannot be delivered in the short term? Simple, put it all in a road map so everyone is clear that it will be delivered in the future. The mistake to avoid here is to not spend some time thinking about what exactly will be delivered and roughly when?
- Identify the different stakeholders e.g. Senior Managers, Subject Matter Experts, Operational Staff, IT staff, 3rd Party Organisations, Customers etc.
- Document the requirements of each group of stakeholders. This step should be a two way process where the project team also educates stakeholders on what is intended and what is possible.
- Setup a governance group that resolves conflicts and assigns priorities to requirements.
- Agree and document the critical success factors of the project.
BI means different things to different people. Make sure there is a common understanding of what is to be delivered in your own organisation and what's in it for each stakeholder.
Mistake # 2 - Biting off too much
So you have managed to avoid mistake number 1 by doing a good stakeholder analysis and then documenting what everyone wants. The 2nd mistake is trying to be everything to everyone. Just because a requirement is documented doesn't mean it should be fulfilled.
Projects that bite off too much or over promise always end up in trouble when eventually they work out that they cannot deliver everything that was promised. I have seen projects whereby the Finance department, HR, Customer Service, Sales and manufacturing all have a different view of the world and therefore different requirements fro your project.
There are multiple reasons for not being to deliver everything, e.g. not enough resources, not enough time, the tools that you can afford don't have all the features required.
Again, avoiding this mistake is not difficult but if ignored it will most certainly lead to failure. Take the following steps to avoid biting off too much:
- Setup a steering / governance group to prioritise requirements.
- Estimate the amount of work that can be done with the given constraints e.g. cost, time, scope, risk, quality etc.
- Ensure estimates have been peer reviewed and they are realistic.
- Present to the steering / governance group for consideration and approval.
The end result is well though out project scope and high level estimate. This is a good basis for creating a more detailed estimate and project schedule.
Mistake # 3 - A loose road map
OK, now you have everyone on the same page with regards to what will be delivered and how much will be delivered within the given constraints.
The next question is what happens to all the requirements that cannot be delivered in the short term? Simple, put it all in a road map so everyone is clear that it will be delivered in the future. The mistake to avoid here is to not spend some time thinking about what exactly will be delivered and roughly when?
The road map can be a simple one page document (like the one above) or it can be a bit more detailed but in order to avoid making it too loose and therefore not useful consider the following when preparing it:
Like any good map, the BI road map should indicate where we are going, what it will look like when we get there and how we will get there.
Part II - Mistakes # 4 and 5
Part II of this article will discuss the implications of letting IT take the lead in BI initiatives as well as focusing on traditional IT technology and methodology debates. We will discuss questions like:
More Information
For more information on how your organization can get started building a successful BI Roadmap, connect with us at tino.tsuro@techlogix.com.au or call 1300-799-321
- Ensure it aligns with organisational objectives.
- It should be clear to each stakeholder group what they will get out of it. So test it on the stakeholders, if they don't understand it then it is not ready.
- Don't just focus on the technical releases. Be sure to indicate the business benefits.
- Include a realistic timeline. A road map is not a schedule so it is not going to be detailed, however in order to gain the trust of stakeholders it is still important to do some work to ensure that what is being proposed is realistic given the known constraints.
Like any good map, the BI road map should indicate where we are going, what it will look like when we get there and how we will get there.
Part II - Mistakes # 4 and 5
Part II of this article will discuss the implications of letting IT take the lead in BI initiatives as well as focusing on traditional IT technology and methodology debates. We will discuss questions like:
- Should we implement Kimball, Inmon or Data Vault?
- Which vendor's database and tools should we use
More Information
For more information on how your organization can get started building a successful BI Roadmap, connect with us at tino.tsuro@techlogix.com.au or call 1300-799-321