Database Reference
In-Depth Information
Explain to the users that this version of the solution will not include a particular set of features. Then explain
to them what will be included. Also let them know when the solution will be delivered. Explain that this delivery
date would be unattainable if the features that are being left out were added back in. If the users push back,
demanding a particular feature, then it is time to reevaluate your ability to do the BI solution at this current time
in the given timeframe. Once again, this evaluation is very important to make at the beginning of the solution.
It benefits no one if you start, rack up a lot of hours, and then fail to deliver what you said you could. Be up front
and truthful about what you can and cannot do, and your client will appreciate your honesty.
How Long Will It Take to Build?
Close on the heels of the question, “Should we build it?” is the question, “How long will it take to build?” Ideally,
the project should begin and end in the shortest time possible. That way, users can have access to the information
needed, and you can move on to creating the next version of the solution. However, the definition of the words
“shortest time possible” is open to interpretation. Are we talking months or simply weeks? Will a portion of the
solution be available sooner, as an incremental release? Or, will users have to wait until all the components are
completed before they can start utilizing it?
One means of determining how long it takes to complete a solution is to break it into its constituent parts
and assign an estimated number of hours/days it will take to complete those parts. Using rapid application
development (RAD) as a model, you can estimate that an employee can accomplish approximately six hours of
production in each eight-hour day. (If your team is accustomed to working more or fewer hours per day, then
change this number accordingly.) Therefore, for each set of six hours estimated, you can record it as one day of
work on the solution. After you have totaled up the days for the different tasks, divide it by the team members
you have working on the solution to find an estimated time of completion. On a very small solution, you might
estimate something like this:
•
Create the data warehouse (6 hours)
•
Create the ETL process (24 hours)
•
Create the cubes (12 hours)
•
Create the reports (12 hours)
•
Test the solution (12 hours)
Then add the hours for each project together to give an overall idea of days the solution will take.
•
Days 11 = (6 hr + 24 hr + 12 hr + 12 hr + 12 hr)/6-hour days
Of course, we have not taken into account the time it takes to perform the interview and identify the data,
plan the solution, obtain the final approval, or release tasks. Therefore, those items will have to be added in as
well, in addition to special considerations with your project that are unique and are not listed here.
With regard to the development team, it is unlikely that everyone will work on the same part of the solution
at the same time. Ideally, it should be a coordinated effort with the data warehouse, ETL process, cubes, and
reports all developed as close to simultaneously as possible. This can be impractical, but when achievable, the
turnaround between the planning phase and the sign-off phase is substantially shorter. For example, when the
data warehouse is created, a few test entries can be inserted into each table. From these, a cube could be built,
and reports can then be created on both the data warehouse and the cube. Keep in mind that these would be
preliminary creations. Until you have data within the data warehouse, it is unwise to consider testing and sign-off
preparations. However, even with these test values, you may uncover unforeseen deterrents to completing your
solution as you build the preliminary prototypes. That is a good thing, because you can let the customer know
about these roadblocks early on.
Transparency is crucial to team members' ability to do their jobs efficiently and in coordination with all
other stakeholders. Try to set up some mechanism for distributing information about solution progress to all
