21 Tips for Managing a Multi-ProjectBW Implementationby Michael Loveless, BI Strategic Architect, Sapiex, Inc.Brian McCartan, Associate Partner, Business Analytics Lead,IBM Global ServicesOctober 1, 2004

SAPexperts/BI/Project ManagementAt some point, your BW project team may be faced withseveral implementation projects occurring at the sametime. Because of the highly shared nature of objects inthe BW architecture, this scenario can cause significantproblems for the project management team. The authorsshare their expertise in coping with such situations andoffer tips to help you avoid many of the pitfalls commonin a multi-project implementation.

Key Concept

The BW project management team is responsible for themany important aspects of a project such as resourcerequirements, timelines and deliverables, testing, training,change management, go-live, and production support. Butwhen multiple project groups want to develop in the sameBW system at the same time with different timelines anddeliverables, this project management team can bedistracted from its project goals.

In a perfect world, all project teams that wish to enter thecorporate BW environment perform all the necessary pre-implementation research and planning. They identify andprepare all members of their extended project team and waitpatiently in queue for their turn to implement. This situationwould be a true luxury for a central BW project managementteam.

Unfortunately, it rarely works out that way. Figure 1 showswhat an ideal project timeline looks like compared to a typicalmulti-project timeline for BW implementations. BW projectmanagement teams are generally forced to accommodatemultiple, urgent implementation demands in SAPenvironments. Some teams are taking the first step from themonolithic R/3 reporting environment into BW, while others,either due to an outdated or incorrect design or an old BWrelease, are struggling with poor BW system performance.

Figure 1

Ideal multi-project timeline versus typicalmulti-project timeline

On the surface, this may seem like merely an inconvenienceto the BW project management team. It is easy to assume thatyou can direct and track every project team’s activities byadding more members to the project management team.However, many complexities make it crucial for the BW projectmanagement team to manage the major parts of theimplementation. It should monitor the inflow to and outflowfrom the development environment, identification of sharedobjects, timeline overlap, and divergence in scope.

If the BW project management team is out of the loop, thenmany problems can occur in the BW design and migration tothe production environment. For instance, one project teamcould overwrite another’s work on objects they share in theirimplementation design. Untested design flaws can slip into anintegration unnoticed and affect testing cycle results. Whentimelines overlap, a project team may test and close itsdesigns unaware that other project teams are still indevelopment and changing shared objects. These untestedobjects can be transported inadvertently to production.

How can the BW project management mitigate the risks andmeet the demands of more than one overlapping project teamworking in the same BW environment? The following tips andrecommendations will help you survive and even thrive in amulti-project BW implementation environment.

Maintain Discipline in the BWEnvironment

1. Establish rules and boundaries from the beginning. Youset the tone for your whole project by instituting a definedstructure right from the start. We recommend that you beginwith basic terminology. It is a misnomer, for example, to callyour prototyping (or predevelopment) environment a sandbox.The term sandbox conjures up the image of an area whereproject teams can play. Spending money for the hardware andmaintenance of a non-essential system in the BW landscapeis a luxury that most companies cannot afford.

2. Take steps early to identify all shared objects andcommunicate this information. In the BW architecture, anumber of InfoObjects, DataSources, InfoSources,InfoProviders, and queries are shared by projects developingin the same BW environment. Based on the reportingrequirements of the strategic business units, functions, or usergroups involved, there can be several shared data elements orobjects. Because only one definition is possible for the sameobject, communication among the groups regarding alldevelopment work in process for that object must be clear.Take steps early to identify all shared objects in the BWarchitecture that more than one project team will touch in its

development effort.

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

4. Compare and analyze the effects of overlappingtimelines. Consider staggering the timelines as much aspossible. Determine the critical project components such asdeadlines and go-live dates of each individual projectimplementing in the same phase schedule. Remember tocoordinate all multi-team development on shared objects tomeet the project team deliverable deadlines that will go livewith the objects first.

5. Analyze secondary and tertiary relationships amongobjects. Perform in-depth analysis of shared objects andtouch points, not just for obvious relationships, but also todetermine where secondary and tertiary dependencies exist. Intransactional models, many master data tables provideinformational support. In the master data, many attributeInfoObjects have separate master data tables. It is importantto know which elements multiple projects share at differentlevels of data, because seemingly innocuous adjustmentsmade to InfoObjects that act as attributes for others can haveadverse effects. Without tight communication (and evaluationof impact using where-used relationship checks), unexpectedand untested changes made by one BW project group can betransported to the quality or production environments whenanother group promotes its designs for testing and cutover.

6. Perform subsequent inheritance planning for sharedobject design. Define inheritance plans to transfer ownershipof shared objects to a new owner in the event that theprevious owner migrates from development into the productionenvironment and is no longer developing in BW. Anydevelopment done by the new owner, however, must be pre-approved in design prior to implementation by a projectgovernance board to ensure that it still supports the originaldesign intent of the previous owners.

7. Establish governance controls early. Set up a BWgovernance board to oversee design and implementationreviews and ensure the quality and integrity of thearchitecture. This governance board should consist ofpermanent voting members who represent key areas of theclient SAP IT team (security, data standards, documentationand training, BW architecture, and hardware). Severalsupporting advisory groups provide subject matter expertiseand guidance in making decisions in areas such as technicalconsulting, 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 establishthe schedules for the overlapping projects to ensure theirdevelopment schedules do not impede the success of theproject phase. This becomes critical once the lead project hasmoved its objects into integration testing in the qualityassurance (QA) environment, because no more developmentwork should be done by any other project teams on thoseobjects, the exceptions are urgent fixes by the lead team orthrough the lead project data owner on behalf of the otherprojects.

9. Create a migration schedule that all project teams mustfollow. Base the implementation rollout schedule on theidentified areas of project overlap, snap-to milestone dates,and individual project timelines. This schedule should indicatewhich groups plan to go live at specific dates and show thepoints of development coordination, completion of keydeliverables, and inheritance of object ownership roles.

10. Review all planned models when multiple teams beginproject development. All project teams should be allowed towork in the development environment after having thoroughlyprototyped their designs in the prototyping environment. Thedevelopment environment should be where provenconfiguration is made for unit testing. Prior to any actualdevelopment configuration, however, all conceptual modelsmust be submitted in an overall BW landscape design plan tothe BW governance board.

Move Projects from Prototypeinto Development

11. Build your design in the BW developmentenvironment. Once all design models are tested in theprototyping environment and are approved, the project teamcan begin to implement them in the BW developmentenvironment. Note that these designs are intended for unittesting, not proof-of-concept work. In other words, tinker withyour designs in the prototyping environment until you aresatisfied with the functionality.

12. Unit test in the BW development environment. Asarchitectural designs are implemented in the BW developmentenvironment, they should be thoroughly tested (and resultsdocumented) in scheduled unit testing cycles. The projectteam with the strictest deadlines should control theseschedules, at least for shared objects. Typical preparation forand execution of unit testing is about four to six weeks fromthe initiation of the realization phase according to SAP’s ASAPmethodology.

13. Request a BW governance board review of alltransports prior to release from development. Oncedevelopment has started and configuration changes have beencaptured into transport (CTS) requests, submit them to the BWgovernance board prior to release. The governance board

should ensure that the transfer adheres to the defined projectscope, milestones, unified deadline dates, and objectownership rules. Take great care during the transport processso that all necessary development objects are collected but noadditional or untested elements are present that may causeproblems during the transport and integration testingprocesses.

14. Perform impact analysis of all scheduled transportsfor all groups. Evaluate all submitted transport requests fortheir potential effect on all implementing project teams in agiven phase. Only after the analysis is complete should yourelease the transports into the integration environment forfurther testing.

15. Execute transports during a development moratoriumacross all project teams in development. During atemporary development blackout window, the transportsshould be moved along the development pathway in the BWenvironment. This moratorium period is intended to controldevelopment activities in the BW development environment(but not in production or support) to protect shareddevelopment areas from accidental modification and transport.

Development to Production —and Beyond

16. Identify the new shared object owners and continuedevelopment work after the first go- live. If go-live datesare not synchronized, when a go-live occurs among thegroups in the current implementation phase, execute theinheritance plans to transfer ownership of shared commonobjects to the next owners that continue development in theBW environment.

17. Maintain consistency throughout your projects.Continue your methodology until you are ready for the nextplanned implementation phases. Your approach to BWimplementation should continue until the final project group inthis phase is completely migrated and cut over to the BWproduction environment. At that time, the next phase ofplanned BW projects should move into the implementationpipeline. This restarts the previously discussed managementprocess.

18. Ensure that mid-cycle projects follow the samestandards as other projects. It is important to control theprojects that enter the implementation environment. When youestablish the next project implementation timeline, also set alltimelines, milestones, deliverables, and go-live dates. In allcases, when a project attempts to join the implementationwindow after it has already begun, require the team to apply tojoin at that specific phase (as approved by the BWgovernance board). If approval is granted, then they shouldfollow the aforementioned tips. In all cases, if they are going todevelop in the same development environment as existingprojects. then they must abide by the same timelines and

Figure 2

Optional split-instance developmentenvironment pathway

deliverable dates. They must also respect the BW projectteam’s ownership of the BW environment objects. You mayfind that in practice you need to be flexible in some cases,however.

Design and Support for ParallelArchitecture

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

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

21. Break the BW project group release schedules into

Figure 3

Synchronize the production support forparallel development environments

relatively equal segments (e.g., three- or six-monthrollouts) when managing subsequent BW rollout releases.This enables the tightest possible working relationships amongthe project groups. This way, all project groups that are willingto adhere to the same time window and milestone dates canall exist in the same development environment. In addition,closely monitor the parallel development environments toensure that production support is available to each project asneeded (Figure 3).

Our approach may not be popular with your developmentteams and may even add a degree of effort and time into theimplementation process. But when organizational reportingneeds dictate that more than one project should develop inthe same BW environment concurrently, strict adherence toarchitectural controls and processes is not a luxury — it’s anecessity.