Databases Reference
In-Depth Information
DANGERS OF GATEKEEPERS
(continued)
based upon what is being asked today. Superior analysts have an
understanding of why reports are run, but many others do not. They simply run
reports that are already put in place and deliver the results to the appropriate
person.
Over time, the business community gets a reasonable understanding of how
long it takes to get different types of reports, so business people filter what is
requested. If an answer is needed this afternoon but it always takes three days
to get the data, it will not be requested. In addition, some reports require so
much effort that the business community does not ask, as it would divert
resources from other required work.
These business analysts can actually become a roadblock for a data
warehouse project. The ability for individuals to access data directly can be
perceived as a threat to their jobs. It is important to ensure that these people
understand that the goal is to free them from manual data gathering so that
they can spend time actually performing analysis.
To get true business requirements, talk directly to the people who receive
reports and results of analyses. These gatekeepers provide good insight that is
needed for the data warehouse, but don't limit the input for the project to their
perspective.
Now that the business requirements have been collected and documented,
it is time to revisit the objectives of the project.
Setting Attainable Goals
Before moving to the next step, take a moment to look again at the project
charter and scope. Those project documents were created without the in-depth
insight that has been gleaned during the requirements gathering process.
In many instances the original project intent is reinforced by the business
requirements. If so, then there is no need to go through the steps described
next. However, there are also many cases where the business requirements do
not align with the project charter. Rather than forge ahead with the original
plan, now is the time to reevaluate the charter and scope.
This mismatch between requirements and the project charter is often identi-
fied by members of the project team. This discrepancy must be communicated
to the business champion, DW manager, executive business sponsor, and IT
sponsor. In order to address the situation, the requirements findings can be
used to propose other possible project(s), exploring the potential business
value of each. In a joint effort between key IT and business managers, the
different alternatives can be prioritized, and finally the project charter and
scope must be modified to reflect the new direction. This would certainly be a
