Lay-down the business requirements documents
Post the business requirement sessions, one has to now start filling the Data Warehouse Requirements Report . This will ensure that all aspects of business requirements are captured. This Execution-MiHPractice Tool will not only capture the business requirements, but also capture the DW strategy at a high level.
Requirements for Data Warehouse now go down to the level of :
- Exact business queries
- Historical data requirements
- The detailing of the key views & transaction reports.
- The business hierarchies
- The business questions OR the analytics a data warehouse should address. (PLEASE REFER Functional Domain section for a wide variety of examples).
Business requirement will also include a high level assessment of:
Data Warehouse Scope Re-Assessment, Estimation and Prioritization
Like a typical business systems project, more detailed business requirements will lead to a re-assessment and estimation and finally the re-prioritization. As stated before, Data Warehouse is unique as the business requirements have a high propensity to change.
The re-assessment, estimation & prioritization process will be almost the same as during the project initiation phase. The stake-holders will be presented with the re-estimated effort, as well as the re-prioritization from business perspective. The two revised calculations have to be weighed together to come out with a final decision.
TIP- Due to high propensity to change, the Data Warehouse estimation phase may start with lot of surprises. You may realize that your estimates as well as what business wants has changed significantly. Here are some tricks:
- If you see a significant deviation between what business stated during business themes prioritization and during business requirements phase, bring it up early on and get it clarified. It will be a good idea to escalate it. It is important for the same set of people to be involved in both the stages, to maintain the continuity.
- We don't recommend to break-down some key foundation elements, to save time. For example, establishing the foundation and conformed dimensions and having sound extraction and transformation design. It is possible that business may not buy or appreciate the investment needed in setting up the right fundamentals, and you still have the pressure to deliver within the same budget. One way to handle it is to provide a stop gap arrangement by which you can agree with business to provide top 10-15 analytical needs, which are getting delivered by DW. This stop gap arrangement could be establishing queries and exporting the summarized data to SQL server along with excel front-end.
- When you are estimating, you will find the pareto principle at work. As per pareto principle, 20% of the effort will deliver 80% of the functionality. The estimation and the scope can be reduced by splitting the functionality elements and prioritizing at more granular level. For example- Let us say that I can cut my cost by 30% by not giving the analysis around the training allowance (for which I have to get data from an unstable training system, which is not owned by IT). It may be worth to keep it out of the scope and use an offline system (excel with SQL server or a light platform, including open source BI).
PLEASE REFER Execution-MiHPractice Tool Data Warehouse Business Requirement Assessment Report |
