Project Management and SAP

Scope Management
3

(M3)

Maria Maddalena Ruggini, PMP

CC ERP Roma

www.eng.it

Scope Management

1. 2. 3. 4.

Introduction Collect requirements Define scope Create WBS

www.eng.it

Introduction
A project needs a leader (project manager) to answer the questions: "What? Why? and How?". That is to say:

What is it that we are trying to do? Why are we doing it? And, How are we going to get it done?

You might also ask another four questions, namely: "Who? Where? When? And How Much?" But these four are secondary and will come later.

M3_Scope Management

www.eng.it

Introduction
The purpose of the Scope Management process is to facilitate an initial understanding of the project scope (What, Why, How) and associated projectrelated assumptions and constraints. The project scope statement evolves through the initiation and planning of the project and clearly and explicitly defines the deliverables of the proposed project. This information and supporting documents align key stakeholders around what the project is going to deliver to facilitate project scope control, user acceptance and compliance resolution. M3_Scope Management
Customer requirement s

Collect requirements Review scope Statement with customer

Create WBS

Create WBS Create WBS Dictionary Share with customer

Share deliverable list Share milestones list Refine acceptance Share test case and strategy
criteria

Obtain customer sign-off

Project scope statement issued and signed Project objectives and Scope Baseline shared

Control Scope

Integrated change control

Verify Scope

User verification criteria User Acceptance and project closure

www.eng.it

Scope Management
With a solid understanding and application of requirements management practices, you can reduce project and program failure and more fully meet the needs of both your customer and your entire organization

M3_Scope Management

www.eng.it

Collect Requirements
The purpose of this activity is to collect and document both process-related as well as project-/non-process-related customer requirements, which in summary and as appendix become part of the scope statement.
Project success is directly influenced by active stakeholder involvement and the accuracy of the activity. Requirements must be: Elicited Analyzed Recorded in enough details to be included in the scope baseline and to be measured once project execution begins.
6 M3_Scope Management www.eng.it

Collect Requirements

Project/Product requirements are the foundation of the WBS.

Requirements, to be included in the baseline, must be unambiguous (measurable and testable), traceable, complete, consistent and acceptable

Collect Requirements
Requirements can be grouped into classifications. These classifications include:

Business requirements (eg. The reason why the project has been undertaken Stakeholder requirements

Solution requirements (functional/non functional)

Transition requirements (data conversion, training, OCM (*), ) Project requirements (action, processes, )

Quality requirements
(*) Organizational Change Management

M3_Scope Management

www.eng.it

Collect Requirements - Output

The Requirements Traceability Matrix (RTM) is a tool to help ensure that the projects scope, requirements, and deliverables remain as is when compared to the baseline. Thus, it traces the deliverables by establishing a thread for each requirement- from the projects initiation to the final implementation.

M3_Scope Management

www.eng.it

Collect Requirements - Output

The Requirements Traceability Matrix (RTM) is a tool to help ensure that the projects scope, requirements, and deliverables remain as is when compared to the baseline. Thus, it traces the deliverables by establishing a thread for each requirement- from the projects initiation to the final implementation.

10

M3_Scope Management

www.eng.it

Define Scope
The Scope Statement is an essential element of any project. Project managers use the Scope Statement as a written confirmation of the results your project will produce and the constraints and assumptions under which you will work. Both the people who requested the project and the project team should agree to all terms in the Scope Statement before actual project work begins.

The Preliminary Project Scope Statement is developed in the Project Preparation phase

11

M3_Scope Management

www.eng.it

Define Scope
A good Scope Statement includes the following information:

Product scope description: The characteristics of the products, services, and/or results your project will produce. Acceptance criteria: The conditions that must be met before project deliverables are accepted Deliverables

Project Exclusions
Constraints restrictions that limit what you can achieve, how and when you can achieve it, and how much achieving it can cost

Assumptions statements about how you will address uncertain information as you conceive, plan, and perform your project.

12

M3_Scope Management

www.eng.it

Define Scope
Think of your Scope Statement, when viewed together with the other components of your project plan, as a binding agreement in which:

You and your team commit to producing certain results. Your projects requesters commit that theyll consider your project 100 percent successful if you produce these results. You and your team identify all restrictions regarding your approach to the work and the resources you need to support your work. Your projects requesters agree that there restrictions other than the ones youve identified and that theyll provide you the support you declare you need. You and your team identify all assumptions you made when setting the terms of your Scope Statement. Your projects requesters agree that, if any of these assumptions prove to be invalid, you may have to modify some or all of your project plans.
www.eng.it

are no

13

M3_Scope Management

Define Scope
A well-written Scope Statement is an important resource for helping to manage stakeholder expectations.

Of course, predicting the future is impossible. In fact, the farther into the future you try to look, the less certain your predictions can be. However, your Scope Statement represents your project commitments based on what you know today and expect to be true in the future.

14

M3_Scope Management

www.eng.it

Define Scope

If and when situations change, you have to assess the effect of the changes on all aspects of your project and propose the necessary changes to your Scope Statement. Your projects requesters always have the option of either accepting your proposed changes (and allowing the project to continue) or refusing the change or canceling your project.

15

M3_Scope Management

www.eng.it

Define Scope
Once the Project's Scope" is determined, we know what is involved and, just as importantly, what is not involved. Hence, we can determine the amount of work required.

One of the best ways of defining what you intend to do is to adopt a project management technique called a "Work Breakdown Structure" (WBS).

16

M3_Scope Management

www.eng.it

Create WBS
The work breakdown structure (WBS) for the project, is a deliverable-oriented, hierarchical decomposition of the work to be executed by the project team to complete the project. It is the basis (foundation) for the organization and coordination of the project.

17

M3_Scope Management

www.eng.it

Create WBS
A WBS consists of WBS elements that
describe project tasks and subtasks to perform within a defined time period

0.0 Retail Web Site 1.0 Project Management 2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation

Summary activity Comprise a set of Subordinate items

Work package deliverables or consistent portions of the work to be done

4.2.2 Middleware Development

4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production

18

M3_Scope Management

www.eng.it

Create WBS Decomposition logic

Decomposition of project scope generally involves the following activities:

Gather information on major project deliverables and analyze related tasks Start development of work breakdown structure (WBS) at the highest level Decompose the upper WBS levels into lower level detailed components (WP)

Identify each work package & WBS components with unique code Verify if the degree of decomposition of the work is necessary and sufficient No. of Levels of WBS need not be same for all deliverables
19 M3_Scope Management www.eng.it

Exercise Creation of a WBS Duration : 30 min

20

M4_Time Management

www.eng.it

Create WBS Standard WBS

For SAP projects, once the PM Team have defined the project life cycle (standard project, global roll out, upgrade, etc), you can have a standard WBS and WBS Dictionary.
The application of a standard WBS, even if not mandatory, is strongly recommended because:

The templates are improved over time and collect the experience of several projects Avoid the risk of forgetting important activities/deliverables Define a common vocabulary Facilitate the standardization of the documentation

21

M3_Scope Management

www.eng.it

Create WBS
.

When do I stop decomposing?

When you feel that your WBS can be a valuable tool for communication with various stakeholders on the project
and

When you feel that the decomposition can allow easy control and monitoring of project status

There are no right or wrong WBS, but WBS more or less useful.
22 M3_Scope Management www.eng.it

Create WBS General rules for WBS decomposition

. 100% rule
The WBS must include no more than 100% of the work defined by the project scope and capture all measurable deliverables internal, external, interim in terms of the work to be completed, including project management.

8/80 rule No work package should be less than 8 hours or greater than 80 hours. Notice that the work package is the lowest level of the WBS. Activities and tasks are not included in the WBS. They will be planned from the work packages once they are assigned.

Reporting period rule

No activity or group of activities at the lowest level of detail of the WBS should be longer than a single reporting period. Thus if the project team is reporting progress monthly, then no single activity or series of activities should be longer than one month long.
23 M3_Scope Management www.eng.it

Collect requirements
.

24

M3_Scope Management

www.eng.it