For organizations desirous of leveraging the benefits of a formal business intelligence environment, the creation of this environment requires active and wholehearted commitment. Anything less than full commitment is insufficient.
Admittedly, very small organizations may have some successes with spotty commitment from management due to the heroic achievements of outstanding individuals, but those circumstances are outliers in the usual course of affairs. For the majority of the real world, very little progress occurs when dedication is lacking. Commitment to the creation of a business intelligence environment means embracing a well-measured and thoughtful allocation of resources with the right skills, the right tools, the right scope, and the right timelines.
If building a data warehouse is considered “filler” work in between other things, this approach does not simply mean the work proceeds slowly. More “work” time is spent in a Groundhog-Day-like reenactment of getting up to speed, again and again. A task is started, only to have its resource reassigned to “more urgent” items before that task is completed. Later, the resource must dust off the previous work and get back to the mind-set of where things were previously. Development resources are squandered on starting up and putting things away. Progress is the one thing that does not happen, or happens at a glacial pace. Ultimately “slow” and “as filler” means the overall cost in resources is much higher than if it were done at a more upbeat cadence.
This sluggish pace has other consequences. Management is often encouraged to try to enhance the value of what is to be built by deciding to include more. Therefore, scope is increased. Even though nothing has been completed, designs must be reworked and changed. Scope becomes the proverbial “moving target.” The rationale for these expansions is that since much of the code is not complete, then altering scope is “free.” The alterations, to mapping documents, data flow diagrams, entity-relationship diagrams, data dictionaries, are often seen as invisible tasks requiring little-or-no effort.
Also ignored is the development process; since the world is an imperfect place, as the old saying goes, things happen. When the processes are built, when the tables are populated and used, that is when the unexpected rears its head. No solution, regardless of how well thought-out, is immune. Ideally, these hurdling gremlins are few, and non-fatal. But as scope is increased while things are not-yet-built, the hidey-holes for those gremlins increase as do the chances for those unforeseen things being more dangerous.
Business intelligence initiatives are often feared because they are considered overly lengthy and requiring too many resources, and often this perspective is unfair. Doing things the “right way” is not the cause of many data warehouse projects being perceived as “dragging on” and “taking forever.”
Often, what is seen as an “excessive timeframe” is the result of a lack of clarity in establishing scope, and often complicated by sometimes missing operational source knowledge. Extracting and integrating data can be done quickly and easily when sources are well-known and well-understood. When such understanding is absent, the business intelligence project bears the “blame” for expending the effort to acquire that source knowledge after the fact, even to the extent of having to extrapolate undocumented intentions by reverse engineering source system code. Accusing the BI initiative of slowness, because timelines in previous projects were cut by jettisoning documentation or training, is a biased viewpoint.
If the creation of the BI environment/architecture is not important enough to be a project with dedicated budget and resources, then it may be said that it is not truly a project at all. Instead, the BI initiative is a hobby; and as a hobby, it may likely present eternal delays, create confusion and ultimately either be left incomplete or not amount to anything substantial for the organization.