Database Reference
In-Depth Information
• Proposed dimensionality
• Data sources and elements
• Extract, transform, and loading processes both into and out of Essbase
• Automation requirements
• Security model
• Calculation requirements
• Input form requirements
• Supporting technology used for the solution, e.g., Studio, oDI, Dodeca, etc.
11.5.3.2 Status Reports
Any consulting company worth their weight should provide
timely, periodic status reports. Do not allow the Status reports to be your only form
of communication with your partner. Insist on periodic reviews of actual deliver-
ables even if they are in development. Sit down and spend some time each week
face-to-face.
11.5.3.3 Expertise and Knowledge Transfer
you hired consultants, not contractors. This
is important because, just like this topic, consultants tell you
why
they do a task in a
particular way. In this spirit, do not be afraid to ask the consultant for his professional
opinion on your project's team composition, communications plan, resources, project
plan, and any other questions you may have. They have watched this before, made the
mistakes, and are not anxious to repeat the experience. This is all part of the knowledge
transfer that was part of your rFP.
knowledge transfer should happen throughout the project. As the consultants are
designing, building, and testing, you and your team should be learning. Do not wait
until the solution is delivered, and pour over the system documentation. unless your
system is extremely simple, system documentation cannot substitute for learning dur-
ing the project. knowledge transfer should be planned and deliberate. good consultants
should be able to explain why and how they are doing something without excessive
jargon and without giving you the run-around. Delaying knowledge transfer can lead
to unnecessary expense by keeping consultants onsite longer than needed as a security
blanket and can generate vendor dependence.
11.5.3.4 System Documentation
System documentation can be a bit of a sham if not
handled in a focused manner. Forests have been sacrificed to the idea of voluminous
documentation that rarely is read if ever. you need to define what system documents
must show and keep that list short. once documentation is provided, a commitment
should be made and a plan developed to keep it current. Documentation should
include:
• A complete listing of data and metadata elements
• Descriptions of what code routines do, where, and
why
(once armed with this
information, a dissection of each code block is not necessary)
• Data flow diagrams
• Description of forms
• Description of calculations and business rules
• The automation schedule
• The automation scripts
• Security
