1. Dr. Bjarne Berg Comerit Inc.
An A-Z Guide to Planning, Managing, and Executing an SAP BW Project Part 1
Dr. Bjarne Berg
Comerit Inc.

2. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

3. What We’ll Cover (in part 2)…
The blueprinting phase
Leveraging the standard content
Modeling for your solution
Deliverables
The realization phase
Best practices for managing the implementation of ODS and InfoCubes
Managing the environments and transports
Managing unit, system, integration & stress testing of BW
The implementation phase
Executing the cut-over to production
Conducting end-user and power user training
Establishing the end-user support organization
Post-implementation review and next steps

4. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

5. Writing the Business Case
The business case must be aligned with some concrete business benefits.
The best way to write a business case is to align it with one of these areas:
Money
Strategy
Reducing time and effort of delivery
Improved information quality and access for
end users

6. Summary of Business Benefits of BW (1 of 3)

7. Summary of Business Benefits of BW (2 of 3)
Area
Observation BW
Benefit
Faster Deployment
Need to increase time to delivery of new applications and enhancements to existing areas
Use of 60-80% of pre-delivered content increased development speed
Reduced development time for new decision support areas
Integrated Products
SAP is offering a variety of new products and modules that the organization might want to leverage in the future
BW is the “corner stone” in SAP’s New Dimension product offerings
Enables closer integration with other SAP modules
Query speed
Business users need data fast
Through use of summaries, BW’s architecture lends itself to faster query performance
Users get faster access to information

8. Summary of Business Benefits of BW (3 of 3)
Area
Observation BW
Benefit
SAP Strategy
It is the organization’s SAP strategy to leverage investments in the SAP to the fullest extent.
BW is a SAP product that fits the organization’s strategy. We can also leverage the organization’s Basis and ABAP people in BW projects.
Strategic fit and synergy with SAP.
Tool Standardization
The organization must be able to leverage industry standards to enable business users to access data in a variety of ways
Microsoft’s ODBO application interface and Java (BW 3.5) are supported by a variety of major presentation and web tools.
Simplifies user access to data and provides higher flexibility to leverage presentation and web tools as well as making own tools.
Industry Trend
The organization’s competitors and some of the organization’s business areas are installing BW
Increased industry resource pool and knowledge of BW
Enables the organization to leverage industry solutions and know-how.

9. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

10. Defining the Scope
First determine what the business drivers were and make sure you meet these objectives.
Define the scope in terms of what is included, as well as what is not included.
Make sure you obtain approval of the scope before you progress any further. All your work from now on will be driven based on what is agreed to at this stage.
As part of the written scope agreement, make sure you implement a formal change request process. This typically includes a benefit-cost estimate for each change request and a formal approval process.
Change management is done to manage scope, timelines and competing business requirements.

11. Defining the Scope (cont.)
For the first go-live, keep the scope as small as possible, i.e. Accounts Payable, Accounts Receivable, G/L or COPA
You have only 3 dimensions to work with:
Scope
Resources
(people, technology
and money)
Time
If one of these dimensions changes, you have to adjust at least one of the others

12. Prioritizing the Scope (Example)
Plan multiple implementations and write a long-term outline that may change (using a formal change request process).

13. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

14. Writing the Milestone Plan
Use milestone plan to illustrate dependencies and high-level tasks:
Post this plan on the walls in the hallways, don't hide it in the PM's office!!!
Keep it under 30 items!!

15. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

16. (we will take a second look at this when we do the budgeting!)
Timelines and Staffing Plan: Lessons Learned…
Developer training should start early for all project team members
SAP R/3 skills are not easily transferable to BW; hands-on experience is needed (it is very hard to learn while being productive)
The quality of the team members is much more important than the number of members. A skilled BW developer can accomplish in one day what 3 novice developers can do in a week (the tool has a steep learning curve).
Project time and cost estimates should be based on team’s experience level
Plan on formal knowledge-transfer from external resources from day one. Link inexperienced members with experienced ones
Have identified “go-to” resources available in all areas (make a list)
(we will take a second look at this when we do the budgeting!)

17. Example: Small BW Project for Single Subject Area (e. g
Example: Small BW Project for Single Subject Area (e.g. Billing, Inventory or Accounts Payable).
These are roles, not positions. (Sometimes one
team member can fill more than one role.)
Basis and functional R/3 support
4-5 team members and normally
3-6 months duration depending on scope

18. 8-10 team members and normally 2-4 months duration depending on scope
Example: Mid-sized BW Project for Single Complex Subject Area (e.g. Cost and Profitability, Internal Billing).
These are roles, not positions. (Sometimes one
team member can fill more than one role.)
Basis and functional R/3 support
8-10 team members and normally
2-4 months duration depending on scope

19. Example: Large BW Project for Multiple Subject Areas (e. g
Example: Large BW Project for Multiple Subject Areas (e.g. Sales, Finance and Material Management)
These are roles, not positions. (Sometimes one
team member can fill more than one role.)
Portal developer(s)
BW Architect
Business analyst/(sub-team lead)
BW developer
Presentation developer(s)
ETL developer
Sales Team
Finance Team
Material Mgmt. Team
Project Manager
Project sponsor/
Steering Committee
Basis and functional R/3 support
15-25 team members and normally
6-18 months duration depending on scope

20. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

21. Budgeting Process Steps
Size the BW effort based on the scope
Prioritize the effort
Map the effort to the delivery schedule
Plan for number of resources needed based on the scope, delivery schedule and the effort.
We will now look at an example how this process works in the real world
Create the milestone plan and the scope statement first, before attacking the budgeting process!!
Start the budgeting process by estimating the workload in terms of the development effort.

22. 1. Size the BW Effort Based on the Scope (Real Example)
Remember that your sizing also has to be based on the team’s experience and skill level.

23. 2. Prioritize the Effort
The next step is to prioritize and outline the effort on a strategic timeline
Make sure your sponsor and the business community agree with your delivery schedule

24. 3. Use Project Estimates & the Timeline to Create Project Load Plan
There are 480 available work hours per project member per quarter.
Knowing this, we can plan the number of team members we need……

25. 4. Result: Good Input for the Staffing Costs and Planning…
Use this information to plan for training, on-boarding and staffing
This spike in resource needs is due to an overlap in the delivery schedule
Now might be a good time to review that decision…
Many companies plan a 60%- 40% mix of internal and external resources for a first go-live. Also, most use $50-$90 per hr for internal budgeting and $90-$170 per hr for external resources.

26. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

27. On-Boarding and Training
Don’t underestimate the value of in-house, hands-on training in addition to formal SAP training classes.

28. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

29. Writing the Workplan
400 to 1000 line-item workplans are not unusual for mid-size and large BW implementations
The Workplan
Write a detailed workplan that references the methodology.
Make sure the workplan is detailed enough to be able to track project progress.
Progress can be measured by hours used, vs. % of tasks completed.

30. Writing the Workplan (High-Level Example, pg. 1)

31. Writing the Workplan (High-Level Example, pg. 2)

32. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

33. Monitoring Progress
Manage the workplan from a percent complete standpoint on a weekly basis
Create weekly status reports with core progress metrics and send to all team members (keep it high-level and tangible)
Require monthly status reports from all team members in a fixed format
Keep a close eye on the deadlines for the deliverables and make to follow-up personally on late tasks
BW is a complex environment that has many dependencies. Late tasks can have significant impacts on the overall project.

34. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

35. Monitoring BW Quality and Formal Approval Process: Example
Integration
Testing
Create Technical
specs
Create Functional
specs No
System Testing
Complete? No
Yes
Unit Testing
Complete?
Yes
Configuration
Peer Review
Yes
Peer Review
Approved? No
Yes
Approved? No
Structured
walkthrough
Complete?
Yes No
Structured
walkthrough
Complete? No
Yes

36. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

37. The User Acceptance Group and Its Role
Create a user acceptance team with a total of 5-7 members from the various business departments or organizations.
Keep the number odd to assist with votes when decisions are made. With fewer than 5 members it can be hard to get enough members present during a certain meeting time
Make them the focus of the requirements gathering in the early phase and later let this team become the user acceptance team (testing) in the realization phase
Meet with the team at least once a month during realization to refine requirements as you are building and have something to show the team
This approach is hard to execute when also managing scope, but is essential to make sure the system meets the requirements

38. What We’ll Cover (part 1)…
Writing the BW business case
Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring BW quality and a formal approval process
The BW user acceptance group and its role
Wrap-up

39. 7 Key Points to Take Home
Write the business case around the areas of greatest benefit to your users. Do not use a “shot-gun” approach but keep it focused.
Define your scope in-terms of what is included and state what is not included.
Establish a formal change control process that is well communicated.
Plan your project based on the hours required for the effort and the project team’s skill level.
Establish milestone dates and map the work hours required to these dates.
Establish a resource on-boarding plan.
Establish a formal process for quality control and approval of deliverables

40. Resources
Five Core Metrics: The Intelligence Behind Successful Software Management – by Lawrence H. Putnam & Ware Myers
Waltzing With Bears: Managing Risk on Software Projects - by Tom Demarco & Timothy Lister
Mastering the SAP Business Information Warehouse by - Kevin McDonald, Andreas Wilmsmeier, David C. Dixon

41. END OF PART 1. Next: How do we Deliver What we Promised?
Questions?
How to contact me: