Once the timing of the upgrade or new implementation has been planned, the next logical step is to determine and document the scope requirements.
4.3 Scope Documentation
There are several important documents that need to be part of every BW project. Each project has many internal and external parties or organizations.
Understanding these stakeholders helps to ensure project success. Thus, after completing the scope document, the next vital document is the one that for-mally identifies the stakeholders in the BW project.
4.3.1 What Is a Stakeholder?
A stakeholder is an individual or group who has a vested interest in a project and can gather resources to affect its outcome. Project stakeholders usually include the project manager, business users, and team members on the project. However, there are other stakeholders in any BW project.
When thinking about stakeholders, you must include those stakeholders who can affect the attention and resources committed to the project, both now and in the future. These stakeholders typically have individual agendas that may differ from those of other stakeholders.
Failure to meet the needs of one powerful stakeholder at a critical time can have significant adverse affects on a project. Thus, proper documentation of stakeholders’ interests and expectations is critical to understanding and com-municating with these individuals or organizations.
4.3.2 Stakeholder Document
The stakeholder document should include all organizations and individuals expected to use BW, along with all those affected by its use. The challenge with the stakeholder document is to understand the influence and impor-tance of each of the stakeholders and their individual impacts on the project.
Of course, it is important to recognize that stakeholders change, as do their interests and impact on the project. This is a living document and can be updated as the various roles in the organization change and evolve.
The stakeholder document serves as a vital input to the communication plan because the communication plan can be tailored to keep the various stake-holders informed of the project and its progress.
Scope Documentation 4.3
4.3.3 Communication Plan Document
Developing a strong communication plan is vital to any BW project. The communication plan should include all plans and steps to keep the various stakeholders informed of the project. Some common elements included in the communication plan are:
왘 Project website
왘 Issue tracking lists
왘 Meeting minutes template
왘 Position paper template
왘 Status report template
왘 Training plan and templates
4.3.4 Integrated Project Plan
All BW projects require a project plan to track the different tasks involved. A sample project plan provided by SAP can be used as a template for starting a project. This plan is part of the ASAP methodology and can be found on the SAP Service Marketplace website.
This sample plan is useful for tracking the tasks needed to complete a suc-cessful BW project. Remember, however, that because of the many project integration points between a BW project and other simultaneous implemen-tations, an integrated project plan is necessary. This would include but is not limited to the following:
왘 Integration and timing with the technical group for the installation and delivery of systems
왘 Coordination with the process teams for completion of configuration and sample master and transactional data
왘 Coordination with any outside source system dependency
왘 Integrated testing plan in coordination with the transaction systems
왘 Integrated cutover planning
4.3.5 Naming Standards Document
Naming standards are vital to identifying custom objects and SAP-developed objects, and to ensure consistency in finding and recognizing objects in the BW system. When a project starts, it is very easy to do without a naming
Project Planning in BW
4
standards document. This is a mistake, because it is very hard to rename objects after go-live to get them in line with new standards.
Thus, the best approach for any BW project is to make sure that a sound nam-ing-convention document is in place before any development occurs. These naming conventions are only necessary for objects that are created in the de-velopment system and intended for transport to the production system.
It is not necessary to use and enforce the naming standards on the sandbox system because this system is designed for ad-hoc testing. Any sandbox pro-totype should be redeveloped in the development system using the naming convention document. The use of standard naming conventions will provide key benefits:
왘 Enhancing the usability of the system by providing a logical grouping of objects
왘 Providing a framework to develop appropriate security and authorization models (if needed)
왘 Ensuring consistency for all the layers of BW instances, thus making future developments more consistent
왘 Adherence to these standards allows for tracking of modifications and transformations of data, which leads to faster troubleshooting of issues The naming standards document addresses the following areas of BW:
왘 InfoAreas
왘 InfoCubes
왘 DataStore objects and DSOs
왘 InfoObjects
왘 InfoSources and DataSources
왘 InfoPackages
왘 Process chains
왘 BEx queries
왘 Other objects such as custom tables, variables, etc.
The naming structure for each BW object is based on a series of logical codes, which can have a number of permitted entries. SAP by default begins all delivered objects with the number 0. This quickly separates the SAP objects from the project-created objects. Projects cannot develop objects starting with 0.
Scope Documentation 4.3
The naming standards document is only intended for those objects that are custom developed. When SAP standard objects are used, the naming stand-ards document does not apply, and the standard object names should be used.
The naming standards document should be considered a living document that can be changed as new object types are added or as different releases of BW are implemented. A sample naming document is found in Appendix E.
4.3.6 BW Development Standards Document
The development standards document is used to document the various strat-egies that will be used on a project regarding the BW implementation. This may be one document or a series of documents that can be used to help new project team members understand the implementation standards of the project. These contain many of the following standards:
왘 Data Strategies
How should an ODS or InfoCube be used to provide reporting? What fea-tures and functionality should be used during the loading process?
왘 Source System Strategies
How can we determine when an external source of data should be loaded into BW? What is the process for transforming that data? Should it occur in BW or in the external system?
왘 Loading/ETL Strategies
When should transformation occur? At what level should this occur?
Should data go into an ODS first or to an InfoCube?
왘 Query Strategies
Should users plan to create queries in the production environment?
Should there be many smaller queries or fewer large queries?
왘 Performance Strategies
How should performance be evaluated and tested? What should be imple-mented in the data model to ensure that performance is optimal?
왘 Transport Strategies
How will transports be collected and handled? What is the process to send transports?
Who will prepare all this documentation and who is responsible for the var-ious tasks in the project? The next section describes the typical roles in a BW project.
Project Planning in BW