In the first two blogs in this series, we have tried to answer the questions Why do we need Data Warehouse models and What are the main building blocks of Data Warehouse models.
This blog will explain how a structured and industry model-based approach can reduce risk, save money, increase the quality of delivery and shorten the time required.
I have heard from managers and business users hundreds of times that IT guys don’t understand them and do what they think they should do’ and not what the business really needs. On the other hand, I have heard from many IT guys that they think that ‘business users are stupid (if they were smarter, they would be computer engineers…)’, they don’t know to say what they want, and they are never satisfied with state-of-the-art solutions that IT department has delivered to them.
Speaking a different language
It is well known that business users and IT developers are speaking different languages and often they don’t understand each other. In many cases, this can lead to the tree swing situation from the famous cartoon headlining this blog; expectations will be set high and the system will have delays in delivery, quality issues, the cost will run over the budget, and the final solution will probably be incomplete and underperforming. If you are interested in engineers’ perspective, also check one of the famous Dilbert comics on that topic.
It is a very common situation that different business departments also have other business definitions. Sales and Marketing may have a different definition of ‘Customer’, or Sales and Finance may have a different definition of ‘Revenue’. Creating an analytical system without clear and unified business definitions is just not feasible.
Many articles explain why a huge percentage of Data Warehouse or Data analytics projects were not successful. Still, the answer is very simple – they were not defined and executed in a way that will assure that they will be successful. Many things that companies are doing are not successful; they fail with their strategies, fail with new products, or go bankrupt. In the same way, they can fail to implement a good analytical system.
If you don’t want your analytical system initiative to fail, there are some basic things that you need to do. First, you need to understand the following simple graph:
Setting realistic goals
Excellent solutions don’t come cheap and for large company a sophisticated and complex analytical system cannot be implemented in few weeks. It is extremely important to set the right expectations because wrong expectations are the best way to ruin the project. Let’s look at one simple example – you set the expectation that the system can be delivered in 6 months and it should cost 100 units. The real time needed for the delivery is 12 months, and the real price is 300 units. When you look for a delivery and implementation partner, any serious company will either submit a realistic proposal or not submit it at all. There will be bidders that will submit a proposal within the project timeframe and budget, but how good are those companies, their references, and the probability they will deliver? Usually, projects started in that way are finishing badly.
In this phase it would be recommended to engage experienced external consulting resource(s) to help you with the preparation of project scope and requirements, or at least to review and validate what your internal team has prepared.
Setting the right expectations
When you set the right expectations, you need to ensure that business users and the IT team are speaking the same language, and that is where the DWH model as a predefined solution comes to play. Such models should be delivered with implementation methodology, predefined business glossary, and set of industry-specific KPIs and report templates. You should also require architects and analysts for implementation and customizations with model and industry experience.
You can say that the DWH model is a data management toolkit with detailed industry content and intellectual property covering the full spectrum of business requirements. Business users and IT will be able to control and reduce the time needed to scope their requirements more effectively. Requirements will be more detailed and precise, thus reducing the risk. Subsequent customizations and any extensions of DWH and the analytical system will also be easier and more straightforward.
So, when you have the right expectations, when you have assured that business and IT are speaking the same language, when you have industry DWH model as blueprint and methodology for implementation, this is the point when you can say that you are able to control costs, risks, delivery time and quality. You are prepared to hit the point where three circles are intersecting, and you have designed everything to deliver an ideal analytical system as a result.
