SAP BW Best Practice Tutorial - Scope Management Plan
This is a continuation of my SAP BW Best Practice Series on SAP Project Management. In this article, I review the key Scope Management Plan best practices I recommend you follow and maintain throughout the life of any SAP project.
If you are in the middle of development for your next Go-Live or doing an upgrade of an existing SAP BW or Business Objects dashboard system or working on any type of greenfield or ongoing SAP project, I recommend you try these scope management plan management techniques because I have and I found them to actually work in the field.
Even if you are not currently following these scope management plan practices, implementing them will make you look smart as well as help you turn around and regain control of any failing project. In this Article, I discuss scope management plan best practices, the Work Break Down Structure (WBS), how the WBS is an input to schedule, budget and BW project estimation and how important the scope management plan is to your project success.
Scope Management Plan Importance
Having a Scope Management Plan is a central and fundamental part of the Project Management Plan and successful projects.
In this SAP BW Tutorial we discuss the 5 major components of the Scope Management Plan:
- Define Scope
- Collect Business Requirements
- Create WBS
- Verify Scope
- Control Scope
Define Scope
Project Scope Management focuses on the work required and only the work required to complete the project successfully.
Without a properly defined Scope Statement, it is difficult to know what are the goals and objectives of the project. The project scope statement is refined over time to include ever increasing levels of detail about the project.
Project Charter is Where it Starts
Initially the project charter defines a high level project scope description. But complete knowledge and detail about a project is not initially known. Usually, only high level descriptions or expectations are set by the project sponsor.
It is up to the project manager to progressively interview the stakeholders and elaborate on the project scope in order to fill in the scope details as they become known. Limitations and boundaries will be discovered and set or negotiated away.
All this detail and supporting information is captured and documented in the Scope Management Plan. Without a scope management plan, it will be difficult to prevent scope creep as well as to know when the project is ultimately completed.
A detailed project scope statement should say something about the following:
- Project Description
- Project Deliverables
- Project Completion Acceptance Criteria
- Project Exclusions
- Project Constraints
- Project Assumptions
Collect Requirements
My previous blog article focused on Requirements Gathering Best Practices.
Remember Collect Requirements is the time consuming process of meeting with all stakeholders to define and document their particular project needs in order to meet the objectives of the project.
Don't forget data governance.
Project Charter and Stakeholder Register
The Project Charter and the Stakeholder Register are the two primary inputs for beginning the business process requirements gathering process. The Project Charter contains the high level project scope statement.
The Stakeholder Register identifies who is affected by the project and identifies the project stakeholders. Face-to-face stakeholder meetings and pen and paper rapid prototyping are your primary tools for gathering requirements.
Requirements Elicitation
Detailed Requirements documentation, sequentially numbered and submitted to a project folder are the primary outputs. Don’t forget to track all requirements via the project folder system such as Sharepoint and the requirements traceability matrix (The Tracking Sheet or Trace Matrix).
Traceability allows a person to trace every work-product such as lines of software or specific items in a BW report back to a specific requirement in the requirement document(s) allowing Auditors, Managers, Current and Future Developers to understand the entire history of that requirement and final work-product.
Having spent some time, perhaps the past few months or maybe even the past year, gathering stakeholder requirements, it is time to decide which requirements are in scope and which requirements are outside the scope of the project.
Verify Scope
Remember, the project charter states the overall high level project scope as defined by the project sponsor.
In the scope management plan we need to consider every requirement gathered so far. We need to determine if that particular requirement falls within the scope of the project, is a supporting detail to a requirement or if any particular requirement falls outside the scope of the current project and should be saved for a possible future project.
This scope review process should involve the stakeholders and sponsors so that there is agreement on the project scope. Once the scope is agreed to and frozen, any change to the scope will involve a necessary change to the golden triangle of Time, Cost and Quality.
Control Scope
Adding new requirements after the schedule and budget is set will require more time and expense to implement. Most project budgets can’t afford to ask for more time or more budget to be added without risk of complete project failure.
Changes to the scope, known as scope creep, must be carefully considered by all stakeholders and guarded against.
Create WBS
In the initial requirements gathering phase, you need to identify and consult with all stakeholders to elicit their list of requirements. In the beginning there will be many requirements flooding in.
As time goes by, new requirements that fall within the scope of this project will begin to slow to a trickle and eventually you will have identified the entire pool of requirements that are contained within this project.
This is your project scope.
Traceability Matrix
The next task in the project scope management planning process is to organize all the related requirements, categorize them and build up a requirements traceability matrix, also called a Trace Matrix or WBS Dictionary.
From the Trace Matrix, you will want to create what’s called a “Work Breakdown Structure (WBS)”.
Work Breakdown Structure (WBS)
The Work Breakdown Structure technically has to be a graphical representation of how the project will be sub-divided and broken down.
A list of requirements such as an excel spread sheet is not technically, according to international Project Management rules, considered to be a WBS.
To officially be considered a WBS, it has to be created graphically and resembles an Organization chart with parent and child relationships.
WBS Parent Nodes can be broken down into Child Nodes and each Child Node can have their own Child Nodes. Each set of Child Nodes below a Parent Node should be a breakdown of the sub-requirements necessary to achieve the higher level requirement represented by the Parent Node.
Each WBS should also have a tracking number assigned to it that maps to or traces each WBS node back to the WBS Dictionary.
I recommend that you divide each requirement into smaller and smaller parent child relationship nodes until each WBS node represents either 4 or 8 hours of work.
Once you get the requirements broken down into WBS nodes that represent 4 or 8 hours of time, you have the basis for forming a project schedule as well as a budget.
Only when you have your project planned to this point, can you begin to answer the question “how to estimate BW project durations”.
Since each WBS element represents at least one requirement, when you have all WBS elements implemented, you have a basis for recognizing project completion and Customer Acceptance.
My next blog article will discuss how to use the WBS in order to create a project schedule through the forward and reverse pass technique and project cost estimation.
Just remember with your own SAP BW Projects "Better Planning, Better Results."
People Who Read This Also Read:
How To Estimate Your SAP BW Project Durations
10 Advanced SAP BW Project Estimation Techniques
How You Can Estimate a SAP BW Project in Under 5 Minutes
10 Critical Chain Project Manager Tips
5 Mistakes You Are Making With SAP Functional Specifications
