In a perfect world, all project teams that wish to enter the corporate BW environment perform all the necessary pre-implementation research and planning. They identify and prepare all members of their extended project team and wait patiently in queue for their turn to implement. This situation would be a true luxury for a central BW project management team.

Unfortunately, it rarely works out that way. Figure 1 shows what an ideal project timeline looks like compared to a typical multi-project timeline for BW implementations. BW project management teams are generally forced to accommodate multiple, urgent implementation demands in SAP environments. Some teams are taking the first step from the monolithic R/3 reporting environment into BW, while others, either due to an outdated or incorrect design or an old BW release, are struggling with poor BW system performance.

Figure 1

Ideal multi-project timeline versus typical multi-project timeline

On the surface, this may seem like merely an inconvenience to the BW project management team. It is easy to assume that you can direct and track every project team’s activities by adding more members to the project management team. However, many complexities make it crucial for the BW project management team to manage the major parts of the implementation. It should monitor the inflow to and outflow from the development environment, identification of shared objects, timeline overlap, and divergence in scope.

If the BW project management team is out of the loop, then many problems can occur in the BW design and migration to the production environment. For instance, one project team could overwrite another’s work on objects they share in their implementation design. Untested design flaws can slip into an integration unnoticed and affect testing cycle results. When timelines overlap, a project team may test and close its designs unaware that other project teams are still in development and changing shared objects. These untested objects can be transported inadvertently to production.

How can the BW project management mitigate the risks and meet the demands of more than one overlapping project team working in the same BW environment? The following tips and recommendations will help you survive and even thrive in a multi-project BW implementation environment.

Maintain Discipline in the BW Environment

1. Establish rules and boundaries from the beginning. You 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 predevelopment) 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. Take steps early to identify all shared objects and communicate this information. In the BW architecture, a number of InfoObjects, DataSources, InfoSources, InfoProviders, and queries are 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, communication among the groups regarding all development work in process for that object must be clear. Take steps 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 that 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 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 effects of overlapping timelines. Consider staggering the timelines as much as possible. 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, many master data tables provide informational support. In the master data, many attribute InfoObjects have separate master data tables. It is important to know which elements multiple projects share at different levels of data, because seemingly innocuous adjustments 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. Define inheritance plans 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. Establish governance controls 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). Several supporting advisory groups provide subject matter expertise and guidance in making decisions in areas 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 timeline and establish the schedules for the overlapping projects to ensure their development schedules do not impede the success of the project phase. This becomes critical once the lead project has moved its objects into integration testing in the quality assurance (QA) environment, because no more development work should be done by any other project teams on those objects, the exceptions are 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 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.

Move Projects from Prototype into Development

11. Build your design in the BW development environment. Once all design models are tested in the prototyping environment and are approved, the project team can begin to implement them in the BW development environment. Note that these designs are intended for unit testing, not proof-of-concept work. In other words, tinker with your designs in the prototyping environment until you are satisfied with the functionality.

12. Unit test in the BW development environment. As architectural designs are implemented in the BW development environment, they should be thoroughly tested (and results documented) in scheduled unit testing cycles. The project team with the strictest deadlines should control these schedules, at least for shared objects. Typical preparation for and execution of unit testing is about four to six weeks from the initiation of the realization phase according to SAP’s ASAP methodology.

13. Request a BW governance board review of all transports prior to release from development. Once development has started and configuration changes have been captured into transport (CTS) requests, submit them to the BW governance board prior to release. The governance board should ensure that the transfer adheres to the defined project scope, milestones, unified deadline dates, and object ownership rules. Take great care during the transport process so that all necessary development objects are collected but no additional or untested elements are present that may cause problems during the transport and integration testing processes.

14. Perform impact analysis of all scheduled transports for all groups. Evaluate all submitted transport requests for their potential effect on all implementing project teams in a given phase. Only after the analysis is complete should you release the transports into the integration environment for further testing.

15. Execute transports during a development moratorium across all project teams in development. During a temporary development blackout window, the transports should be moved along the development pathway in the BW environment. This moratorium period is intended to control development activities in the BW development environment (but not in production or support) to protect shared development areas from accidental modification and transport.

Development to Production — and Beyond

16. Identify the new shared object owners and continue development work after the first go- live. If go-live dates are not synchronized, when a go-live occurs among the groups in the current implementation phase, execute the inheritance plans to transfer ownership of shared common objects to the next owners that continue development in the BW environment.

17. Maintain consistency throughout your projects. Continue your methodology until you are ready for the next planned implementation phases. Your approach to BW implementation should continue until the final project group in this phase is completely migrated and cut over to the BW production environment. At that time, the next phase of planned BW projects should move into the implementation pipeline. This restarts the previously discussed management process.

18. Ensure that mid-cycle projects follow the same standards as other projects. It is important to control the projects that enter the implementation environment. When you establish the next project implementation timeline, also set all timelines, milestones, deliverables, and go-live dates. In all cases, when a project attempts to join the implementation window after it has already begun, require the team to apply to join at that specific phase (as approved by the BW governance board). If approval is granted, then they should follow the aforementioned tips. In all cases, if they are going to develop in the same development environment as existing projects. then they must abide by the same timelines and deliverable dates. They must also respect the BW project team’s ownership of the BW environment objects. You may find that in practice you need to be flexible in some cases, however.

Design and Support for Parallel Architecture

19. Maintain two parallel development pathways to synchronize and protect your work. If you do not have the luxury of scheduling and implementing one project at a time in the BW environment and multiple projects overlap in their BW development efforts, split the projects into a dual implementation. Two concurrent development projects can have two separate instances that follow the same procedures, as seen in Figure 2.

Figure 2

Optional split-instance development environment pathway

20. Move the first project into integration testing (QA 1) and base the second development configuration on the first before the second project enters the second development environment (DEV 2). While communication among project groups must be dutifully managed, this allows the second project to enter its development phase before the first project has completed integration testing and advanced to production.

21. Break the BW project group release schedules into relatively equal segments (e.g., three- or six-month rollouts) when managing subsequent BW rollout releases. This enables the tightest possible working relationships among the project groups. This way, all project groups that are willing to adhere to the same time window and milestone dates can all exist in the same development environment. In addition, closely monitor the parallel development environments to ensure that production support is available to each project as needed (Figure 3).

Figure 3

Synchronize the production support for parallel development environments

Our approach may not be popular with your development teams and may even add a degree of effort and time into the implementation process. But when organizational reporting needs dictate that more than one project should develop in the same BW environment concurrently, strict adherence to architectural controls and processes is not a luxury — it’s a necessity.