Database Reference
In-Depth Information
vendor and you, the client's representative, need to acknowledge reality. This
will result in either allocating more money for the necessary resources or nego-
tiating removing something from the plan and re-allocating those resources.
3. For whatever reason, the project is behind schedule. The drop-dead date has not
changed. The easy way to make the remaining tasks within the timeframe is to
state that, despite previously agreed upon durations, the tasks will now face 50%
less time. If the estimates of task duration were good, how will these tasks be
accomplished in less time? Everyone already knows the answer; those tasks will
not magically complete in less time. once again, you must either negotiate a com-
promise on deliverables or allocate more money to bring in more project resources.
11.5.3 Business Requirements Document
A Business requirements Document (BrD) is a document used in a project to define
in detail what needs to be done in the solution to meet the project objectives. Though
clients tend to want to shun the responsibility of creating the BrD and pass it to the
consultants, it should be created and owned by you. It details the features and function-
ality within the proposed solution. more likely than not, your organization has a BrD
template. This does not mean that it is any good or that it will meet the needs of your
project and facilitate your getting solid requirements. Because business users will need
to sign off on it, the BrD has to be written in such a way that the business users who do
not have technical knowledge can easily understand it. It is important to keep the BrD
free of too much techno speak. The building of the BrD should be a collaborative effort
between you, the users, and the stakeholders.
The key components of an Essbase project's BrD:
• Functional requirements
• Data requirements
• Data-cleansing requirements (if known by the time the BrD is constructed)
• reporting requirements
• Performance ranges
• Security
• Availability of application
Investing the time to create a thorough and complete BrD saves time and money.
much like the project charter keeps the project manager on task throughout the project
and answers the various questions that develop over time, the BrD does the same for
the development team. With a proper BrD, the development team will have 90% of
their business questions answered before they even start the project work. With a robust
BrD, the technical Design Document (tDD) creation can begin immediately.
11.5.3.1 Technical Design Document
The tDD is supplied by your partner. While you
will still rely on the project plan for task identification and time duration, you must
marry those up against the Essbase project's design document to determine if the proj-
ect plan comprehensively addresses all of the project deliverables. This discussion is
predicated on traditional waterfall methodology. given the more mainstream approach,
a tDD should identify:
• Application goals and objectives
• reporting requirements
