Database Reference
In-Depth Information
Beyond these soft skills, development teams can fail for two reasons. The first is inexperience with the
technology. This failing can be addressed through study and research. For example, learning how to use the SQL
Server BI tools by reading and performing the exercises in this topic greatly increases your solution success rate.
(And telling you this gives us a chance to promote our topic!)
The other common failure is harder to prepare for, that is, failure to understand the business process that
is being reported. For example, if your solution consists of reporting against the repair rate of computers, you
will need to know about the repair centers, the warranty terms, the components that are in the computer, the
manufacturers that made the different components, and any internal designation of a group (generation)
of components. You will also need to know whether the computers start aging once they are shipped from
the factory or whether your business considers their lifetime to begin the first time they are turned on. The
users expect the reports to be correct, meaning they answer the question people believe is being asked. If you
misunderstand the question even though you provide a legitimate answer, you will not get credit for your answer
because it is not the question that was asked.
From this single example, you can see how easy it can be for a solution to fail if your client's business
processes are not understood. Once again, transparency is fundamental to the success of your solution. Keep
stakeholders informed of your progress, ask for their validation, and—with the client's input—properly determine
whether the generated reports do indeed meet the needs of the company. If you can catch these errors early in
the development cycle, you will save both time and money.
Stakeholders can be a good choice as project sponsors. A project sponsor is responsible for communicating
the progress of your solution to the end users and in turn is able to provide specific feedback to the development
team about any misunderstandings. A good stream of communication with a sponsor will affect the final user
acceptance at the release of your solution.
Unfortunately, this communication highway can also deliver change requests. Resist the desire to make
everyone happy by changing the definition of the solution while it is in progress. If indeed you do find that one
of the questions your solution is trying to answer was incorrectly interpreted, then this must be fixed, but you are
not looking for new or different questions to answer. New questions can be asked in the next version of your BI
solution.
In RAD development, you typically focus on small teams consisting of between six and eight people. Often
you try to find team members who have a diverse set of skills so that they are assigned several roles. Some key
roles to define include the following:
•
Solution sponsor
•
Solution manager
•
User acceptance coordinator
•
Solution planner
•
Technical writer
•
Programmer writer
•
Data warehouse developer
•
ETL developer
•
Cube developer
•
Report developer
•
Tester
•
Technical trainer
