Ensuring Rich Reports based on Cubes

Often when beginning business intelligence development, specifically within data warehouses, a team may inefficiently “reinvent the wheel” rather than leverage existing reports and processes which may prove valuable to the organization.
When cubes are designed, even new ones, the following steps will help to ensure the data they produce will support your existing report needs as wells future requirements.

Business Requirements

Gathering business requirements is usually the first step for any project, but far too often a business analyst (or developer functioning in that role) will do so from the standpoint of their understanding of the project instead of requirements the organization already uses, and does so quite successfully.
Codifying current requirements by including the perspectives of stakeholders already involved protects the project from delivering a product with low quality. User perspectives are best obtained by spending time observing them throughout their normal work day, analyzing current reports tools and processes currently in place, and by requesting feedback from those users on your results as well as capturing the essence of their suggestions.

Brief Documentation

This concept has been abused in projects, particularly within large organizations where has become the focus instead of a deliverable. Thankfully, more relevant project management methodologies such as Scrum restate the purpose of documentation with a proper perspective and highlight when it’s abused.
A team should use documentation only to capture, understand, and convey only what it needs to deliver the next requirements before feedback may be obtained from the stakeholder’s update perspective.
When the effort to document requirements exceeds the effort and value of the entire project, the purpose of documentation should be reevaluated.
This documentation should include the use of your preferred modeling tool (Visio, Erwin). However as with tradition documentation, modeling the current requirements should not become a “rabbit hole” in which a person becomes lost – users do not see value in behemoth diagrams illustrating all future history, only the deliverable you next promised them.
The models you work on should focus on smart discrete parts of reports which constitute the next deliverable. For example, if your team has promised as the next deliverable a cube which supports a Pivot table illustrating certain sales division, focus only on the measures (facts) necessary along with the supporting dimensions which provide their meaning, along with its properties and any transformations necessary.
When designing the cube, begin with dimension attributes satisfy report requirements, then add facts to support those dimensions.

Feedback till Acceptance

A deliverable should be reviewed at the soonest feedback may be given by stakeholders at which point this entire process iterates until the team gains acceptance by the user, then the next deliverable would be started.
Gaining early, rapid feedback decreases the amount of time and number of iterations from the beginning of a deliverable till the user formally offers acceptance. The last two decades have proven throughout all project-intensive industries the longer a team waits till receiving feedback, the more likely they are to extend the duration of a project, meet less of its goals, and exceed budgetary limitations.