An A-Z Guide to Planning,

Managing, and Executing

an SAP BW Project
Part 1
Dr. Bjarne Berg
Comerit Inc.
2004 Wellesley Information Services. All rights reserved.

What Well 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

What Well 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
3

What Well 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

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

Summary of Business Benefits of BW (1 of 3)

Area

Observation

BW

Benefit

Cost of Ownership

Maintaining custom developed

application is complex and
expensive.

SAP is responsible for

maintenance of the
product.

Substantial maintenance cost

savings

Cost Avoidance

Rehosting extract programs from

R/3 when upgrading R/3 is
expensive.

BW follows the upgrade

path with R/3

Substantial cost savings by not

having to redevelop new
extract programs for each SAP
upgrade

Web strategy

Web delivery requires rapid data

delivery of high consistency with
the source system.

BW is closely integrated
with R/3 and can deliver
data that reflects the
source system at short
time intervals.

Enables web initiatives to get

closer to the source data
both in time and consistency.

Reconciliation Effort

A substantial portion of the data

warehouse effort is spent on
reconciling information

BW is closer to the
source system and more
accurately reflects data

Users spend less time on

reconciling data and more on
analyzing it.

Information Access

Business users need a high

availability of data

Load times in BW is
reduced compared with
traditional custom
developed data
warehouses

Users get earlier access to

information

Money

Reducing Time and Effort of delivery

Strategy

Improved information quality & access

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 predelivered 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 SAPs New Dimension
product offerings

Enables closer integration

with other SAP modules

Query speed

Business users need data fast

Through use of
summaries, BWs
architecture lends itself
to faster query
performance

Users get faster access to

information

Money

Reducing Time and Effort of delivery

Strategy

Improved information quality & access

Summary of Business Benefits of BW (3 of 3)

Area

Observation

BW

Benefit

SAP Strategy

It is the organizations SAP

strategy to leverage investments
in the SAP to the fullest extent.

BW is a SAP product
that fits the
organizations strategy.
We can also leverage the
organizations 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

Microsofts 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 organizations competitors

and some of the organizations
business areas are installing BW

Increased industry
resource pool and
knowledge of BW

Enables the organization to

leverage industry solutions
and know-how.

Money

Reducing Time and Effort of delivery

Strategy

Improved information quality & access

What Well 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

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.

Note

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.

10

Defining the Scope (cont.)

1. For the first go-live, keep the scope as small as possible, i.e. Accounts
Payable, Accounts Receivable, G/L or COPA
2. You have only 3 dimensions to work with:
Scope

Resources

(people, technology
and money)

Warning

Time

If one of these dimensions changes, you have to

adjust at least one of the others
11

Prioritizing the Scope (Example)

2004
2005
2006
July Aug Sept Oct Nov Dec Jan Feb MarApr May Jun July Aug Sept Oct Nov Dec Jan Feb Mar Apr May Jun July Aug Sept Oct Nov Dec
Procurement details
& summary receipts
Contracts
Settlements
Inventory
Sales
Master Agreements
Contractor
General Ledger
A/R & Credit Mgmt
SNOP
Cost
Procurement
Inventory Planning
Source Analysis
(enhancements)
Sales opportunity
Tax-severance &
processor
Blueprinting

Realization

Cutover and go-live

Plan multiple implementations and write a long-term outline that

may change (using a formal change request process).

12

What Well 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

13

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!!

14

What Well 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

15

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
Note
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 teams
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!)

16

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.)

Project sponsor
Project Manager.
Business team

Technical team

Business analyst

BW Architect

Presentation developer

ETL developer

Basis and functional R/3 support

4-5 team members and normally

3-6 months duration depending on scope

17

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.)

Project sponsor/
Steering Committee
Project Manager
BW
Architect
Business
Analyst(s)

Extract, Transforms
and Loads

Data Management
(InfoCubes & ODS)

Presentation
Developer(s)

Sr. Business analyst

Sr. ETL developer

Sr. BW developer

Sr. Presentation developer

Business analyst

ETL developer

BW developer

Presentation developer

Basis and functional R/3 support

8-10 team members and normally
2-4 months duration depending on scope

18

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.)
Project sponsor/
Steering Committee
Project Manager
BW Architect
Portal developer(s)
Sales Team

Finance Team

Business analyst/(sub-team lead)

BW developer
Presentation developer(s)
ETL developer

Business analyst/(sub-team lead)

BW developer
Presentation developer(s)
ETL developer

Material Mgmt. Team

Business analyst/(sub-team lead)
BW developer
Presentation developer(s)
ETL developer

Basis and functional R/3 support

15-25 team members and normally
6-18 months duration depending on scope

19

What Well 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

20

Budgeting Process Steps

1. Size the BW effort based on the scope

2. Prioritize the effort
3. Map the effort to the delivery schedule

pl e a l
m
xa e re
e
h
an in t
t
k a orks
o
o
l
w ss w l d
o
e
l l n r o c w or
i
w
p
We this
w
ho

4. Plan for number of resources needed based on the scope, delivery

schedule and the effort.

Create the milestone plan and the scope statement first,

before attacking the budgeting process!!

Tip

Start the budgeting process by estimating the workload in

terms of the development effort.
21

1. Size the BW Effort Based on the Scope (Real Example)

Remember that your sizing also has to be

based on the teams experience and skill level.
22

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
23

3. Use Project Estimates & the Timeline to Create Project Load Plan

Note

There are 480 available work hours per project member per quarter.
Knowing this, we can plan the number of team members we need
24

4. Result: Good Input for the Staffing Costs and Planning

Use this information to plan for training, on-boarding and staffing
Number of team members

This spike in
resource needs is
due to an overlap
in the delivery
schedule

14
12
10
8

Now might be a
good time to
review that
decision

6
4
2
qtr 1

qtr 2

Tip

qtr 3

qtr 4

qtr 1

qtr 2

qtr 3

qtr 4

qtr 1

qtr 2

qtr 3

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.

25

What Well 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

26

On-Boarding and Training

BW Developer
ETL Developer
Presentation Developer
Project Manager
Business Analysts

Note

Ideal Yrs
Experience
(minimum)
2+

Training days In-house

(if new in the training
role)
days
15
3-5

3+

15-20

3-5

1+

5-10

3-5

5+

10-15

3-5

5+

5-10

3-5

Dont underestimate the value of in-house, hands-on

training in addition to formal SAP training classes.
27

What Well 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

28

Writing the Workplan

The Workplan
1.

Write a detailed
workplan that
references the
methodology.

2.

Make sure the

workplan is detailed
enough to be able to
track project
progress.

3.

Progress can be
measured by hours
used, vs. % of tasks
completed.

400 to 1000 line-item

workplans are not
unusual for mid-size
and large BW
implementations

29

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

30

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

31

What Well 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

32

Monitoring Progress

Note

Warning

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.

33

What Well 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

34

Monitoring BW Quality and Formal Approval Process: Example

Integration
Testing

Create Technical
specs

No

Create Functional
specs

System Testing
Complete?
No
Yes

Unit Testing

Complete?
Yes

Configuration

Yes

Peer Review

No

Approved?

Peer Review
Yes
No

Complete?
No

Yes

Approved?

Structured
walkthrough
No

Complete?

Yes

Structured
walkthrough

35

What Well 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

36

The User Acceptance Group and Its Role

Issue

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
37

What Well 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

38

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
teams 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
39

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

40

END OF PART 1. Next: How do we Deliver What we Promised?

How to contact me:

bberg@comeritinc.com
41