10 Tips to Maintain Discipline in a Multi-Project BW Environment

1. Establish rules and boundaries from the beginning. You will set the tone for your whole project by instituting a defined structure right from the start We recommend that you begin with basic terminology. It is a misnomer, for example, to call your prototyping (or pre-development) environment a sandbox. The term sandbox conjures up the image of an area where project teams can play. Spending money for the hardware and maintenance of a non-essential system in the BW landscape is a luxury that most companies cannot afford.

2. Taken steps early to identify all shared objects and communicate this information.

<!-- break -->

In the BW architecture, there are a number of InfoObjects, DataSources, InfoSources, InfoProviders, and queries shared by projects developing in the same BW environment. Based on the reporting requirements of the strategic business units, functions, or user groups involved, there can be several shared data elements or objects. Because only one definition is possible for the same object, there must be clear communication between the groups regarding all development work in process for that object. Steps must be taken early to identify all shared objects in the BW architecture that more than one project team will touch in its development effort.

3. Assign individual project team members ownership of shared objects. There must be only one owner per shared object who will ensure all design, development, testing, transport, and documentation of the object (transactional or master data) is done properly. Any work done on a shared object is coordinated for all concerned projects through one point of contact – the shared object owner -- who the oversees the preparation for testing and transport (using the Change and Transport System, or CTS) after the work is performed.

4. Compare and analyze the affects of overlapping timelines. Determine the critical project components such as deadlines and go-live dates of each individual project implementing in the same phase schedule. Remember to coordinate all multi-team development on shared objects to meet the project team deliverable deadlines that will go live with the objects first.

5. Analyze secondary and tertiary relationships among objects. Perform in-depth analysis of shared objects and touch points, not just for obvious relationships, but also to determine where secondary and tertiary dependencies exist. In transactional models, there are many master data tables that provide informational support. In the master data, there are many attribute InfoObjects that have separate master data tables. It is important to know which elements multiple projects share at different levels of data, because seemingly innocuous adjustments can be made to InfoObjects that act as attributes for others can have adverse effects. Without tight communication (and evaluation of impact using where-used relationship checks), unexpected and untested changes made by one BW project group can be transported to the quality or production environments when another group promotes its designs for testing and cutover.

6. Perform subsequent inheritance planning for shared object design. Inheritance plans should be defined to transfer ownership of shared objects to a new owner, in the event that the previous owner migrates from development into the production environment and is no longer developing in BW. Any development done by the new owner, however, must be pre-approved in design prior to implementation by a project governance board to ensure that it still supports the original design intent of the previous owners.

7. Governance controls should be established early. Set up a BW governance board to oversee design and implementation reviews and ensure the quality and integrity of the architecture. This governance board should consist of permanent voting members who represent key areas of the client SAP IT team (security, data standards, documentation and training, BW architecture, and hardware), with several supporting advisory groups that provide subject matter expertise and guidance in making decisions such as technical consulting, business process, and change management.

8. Synchronize First In, First Out (FIFO) project milestone dates when testing and go-live dates do not match. Determine which project has the tightest timelines of those being implemented and establish the schedules for the overlapping projects to ensure their development schedules do not impede the success of the project phase. Once the lead project has moved its objects into integration testing in the quality assurance [QA] environment this becomes critical because no more development work should be done by any other project teams on those objects – except urgent fixes by the lead team or through the lead project data owner on behalf of the other projects.

9. Create a migration schedule that all project teams must follow. Base the implementation rollout schedule on the identified areas of project overlap, snap-to milestone dates, and individual project timelines. This schedule should indicate which groups plan to go live at specific dates and show the points of development coordination, completion of key deliverables, and inheritance of object ownership roles.

10. Review all planned models when multiple teams begin project development. All of the project teams should be allowed to work in the development environment after having thoroughly prototyped their designs in the prototyping environment. The development environment should be where proven configuration is made for unit testing. Prior to any actual development configuration, however, all conceptual models must be submitted in an overall BW landscape design plan to the BW Governance Board (see tip 7).

READ MORE