Scope Management

Plan

[Wissal system ]
[CRM Implementation]
[Insert Department/Project Logo] [Insert Department Name]
[Insert Project Name]

VERSION HISTORY
Version # Date Author Key Differences

Scope Management Plan [Insert Version Number] | Page 2

[Insert Department/Project Logo] [Insert Department Name]
[Insert Project Name]

TABLE OF CONTENTS
1 Introduction.....................................................................................................................5
2 Approach..........................................................................................................................5
3 Roles and Responsibilities.................................................................................................5
4 Scope Management Processes..........................................................................................6
4.1 Definition of Scope..................................................................................................................6
4.2 Creation of the Work Breakdown Structure (WBS) and Dictionary..........................................7
4.3 Deliverable Validation and Acceptance.................................................................................10
4.4 Control Scope........................................................................................................................10

Scope Management Plan [Insert Version Number] | Page 3

[Insert Department/Project Logo] [Insert Department Name]
[Insert Project Name]

1 Introduction

Le but du plan de gestion de la portée est de s'assurer que le projet est composé de tout le travail requis,
et uniquement du travail requis, pour mener à bien le projet. Les processus définis dans les sections
suivantes fournissent un schéma directeur de la manière dont la portée sera définie, développée, vérifiée
et contrôlée. Ce plan de gestion de la portée documente l'approche de gestion de la portée, définit les
rôles et les responsabilités, les processus et les procédures de gestion de la portée et sert de guide pour
la gestion et le contrôle de la portée du projet.

2 Approach

Ce plan de gestion de l'étendue traite des processus suivants :

- Définition de la portée

- Création de la structure de répartition du travail (SRT)

- Validation de l'étendue

- Contrôle de la portée

Ces processus interagissent entre eux et avec les processus des autres plans de gestion définis dans le
plan de gestion du projet. Lorsqu'ils sont correctement mis en œuvre, les processus de gestion de la
portée permettent de gérer efficacement les trois éléments de contrainte que sont le temps, le calendrier
et le coût, afin de soutenir un projet de haute qualité.

3 Roles and Responsibilities

Name Role Responsibility

Belkacem benzaim Project Leader As project manager, we lead the project by:
Yanis chabane  defining the project plan and following it up
 focusing on the main objectives
 onboarding the SPoC (Single Point of Contact)
on the project
 using the right resources and anticipating the
risks

Scope Management Plan [Insert Version Number] | Page 4

[Insert Department/Project Logo] [Insert Department Name]
[Insert Project Name]

Name Role Responsibility

As business analyst and product expert, we
keep things simple by:
 deciding how to implement specific needs
 challenging the customer’s demands and
managing their expectations
 configuring Odoo
 migrating the required data
 writing the specifications (if any development
is required)

-Majid Henine Project Director Their role is to keep decision makers

informed and committed to the project by:
 reporting project progress to the steering
committee
 tracking the efficiency of the project
 offering solutions to fix inefficiencies on how
the project is handled (on both sides)
-Wissam Abdesselam App Expert They perform peerreviews, working across all
-Belkacem benzaim projects of the company. In addition to
-Yanis chabane supporting business analysts on complex
issues, their objective is to reduce the volume
of custom developments in projects. To do
so, review ROI analyses by providing smart
solutions on standard, challenging the “Must
Have”/”Nice to Have” or phasing split, and
ensure we don’t develop things that are not
really necessary
- Amina Developer  Develop new features and app for
Bouchekhchoukh customization
 Configuration, installation and maintenance of
-Oualid bergas server and multi database Odoo/Ubuntu
environments.
 Keeping different projects/versions under
control using SVN or Git.
 Other development tasks in systems developed
in Python other than Odoo.
 Q web report creation
 Debugging modules
-Ilhem sellami Customer: Single Point As project manager, the SPoC works closely
of Contact (SPoC) with the Odoo Project Leader by:
 following up with the project
 being an ambassador who convince the end-
users (Change Management)
 making sure that the project plan aligns with

Scope Management Plan [Insert Version Number] | Page 5

[Insert Department/Project Logo] [Insert Department Name]
[Insert Project Name]

Name Role Responsibility

the company’s agenda and constraints
 Acting as "super key-user".
 training the end-users with the support of the
Project Leader

4 Scope Management Processes

4.1 Definition of Scope

This process takes the high-level product descriptions, assumptions and constraints, as documented in
the Project Charter, and uses them to create a more detailed scope in the Project Scope Statement. The
result of the process is a detailed definition of the product and/or service the project will produce.

This section details the process of developing a detailed description of the project and its deliverables.
The Scope Statement details the project’s deliverables and work necessary to create these deliverables.

The project Scope Statement can contain, but is not limited to, the following components:

 Executive Summary – Brief summary of the project

 Business Objectives – Should be stated in business terms
 Product Scope Description – Describes what the project will accomplish
 Project Deliverables – A detailed list of deliverables the project will produce
 Product Acceptance Criteria – Describes what requirements must be met for the project to be
accepted as complete
 Project Exclusions – Description of work that is not included in the project and therefore outside
the scope
 Project Constraints – Lists limits on resources for time, money, staff, or equipment
 Project Assumptions – Describes the list of assumptions under which the project team and
Stakeholders are working to complete the project

Note: The scope statement can be refined after requirements are identified and defined. Refer to the
main documents developed in the requirement definition process: Requirements Management Plan,
Requirements Documentation, and the Requirements Traceability Matrix.

4.2 Creation of the Work Breakdown Structure (WBS) and Dictionary

[Discuss how the project scope is to be sub-divided into smaller deliverables in a Work Breakdown
Structure (WBS) and WBS Dictionary, and how these smaller components are managed during the
project. Provide the WBS and the WBS Dictionary. A WBS Dictionary should accompany the WBS to
provide more detailed information about the work elements of the structure and a more detailed
description of deliverables identified in the WBS. The following table shows an example format for a
WBS Dictionary.

The fields associated with a WBS Dictionary include:

Scope Management Plan [Insert Version Number] | Page 6

[Insert Department/Project Logo] [Insert Department Name]
[Insert Project Name]

 WBS Level – The decomposition (break down) level of the WBS element in X.X.X format
(extended to the level needed)
 WBS Code – A code associated with the specific WBS element
 WBS Element Name – The name of the WBS Element
 Description of Work – The work represented by the WBS Element
 Deliverable(s) – Deliverables produced by doing the work represented by the WBS element
 Committed Resources – Resources committed to do the work represented by the WBS element
 Comments – Any additional information needed to explain the WBS element]

Level 1 Level 2 Level 3

1. Widget Management 1.1 Initiating 1.1.1 Evaluation and Recommendations
System 1.1.2 Develop Project Charter
1.1.3 Deliverable: Submit Project Charter
1.1.4 Project Sponsor Reviews Project Charter
1.1.5 Project Charter Signed and Approved
1.2 Planning 1.2.1 Create Preliminary Scope Statement
1.2.2 Determine Project Team
1.2.3 Project Team Kickoff
1.2.4. Develop Project Plan
1.2.5 Submit Project Plan
1.2.6 Milestone: Project Plan Approval
1.3 Executing 1.3.1 Project Kickoff Meeting
1.3.2 Verify and Validate User Requirements
1.3.3 Design System
1.3.4 Procure Hardware/Software
1.3.5 Install Development System
1.3.6 Testing Phase
1.3.7 Install Live System
1.3.8 User Training
1.3.9 Go Live
1.4 Closeout 1.4.1 Audit Procurement
1.4.2 Document Lessons Learned
1.4.3 Update Files/Records
1.4.4 Gain Formal Acceptance
1.4.5 Archive Files/Documents

Scope Management Plan [Insert Version Number] | Page 7

[Insert Department/Project Logo] [Insert Department Name]
[Insert Project Name]

WBS Committed
WBS Code WBS Element Name Description of Work Deliverable(s) Comments
Level Resources
1 1 Widget Management System to Manage IVD System Project Manager
System Widgets Technical Analyst
SMEs
2 1.1 Initiating Initiation of Project to Charter and S1BA Project Manager
build Widget [include additional Business Analyst
Management System deliverables] SMEs
3 1.1.1 Evaluation and Evaluation of options Evaluation and Project Manager
recommendations and recommendations Recommendations Business Analyst
Report

Scope Management Plan [Insert Version Number] | Page 8

[Insert Department/Project Logo] [Insert Department Name]
[Insert Project Name]

4.3 Deliverable Validation and Acceptance

Les produits livrables et les produits du projet seront acceptés par le biais des processus d'acceptation
formels du projet. Ces processus sont conçus pour garantir que les produits livrables et les produits
individuels ne sont acceptés que s'ils répondent à leurs critères d'acceptation respectifs.

4.4 Control Scope

Décrire le processus de changement pour apporter des modifications à la base de référence de la portée.
Le plan de gestion du contrôle des changements doit inclure les détails de la demande, de la révision et
de l'approbation des changements apportés à l'énoncé de la portée ou à la structure de répartition du
travail après leur approbation initiale.

Toute demande de modification de la portée du projet sera traitée par la procédure de gestion des
changements du projet. Les changements proposés seront examinés. Si le gestionnaire de projet et le
commanditaire du projet estiment que la demande est valable, elle sera analysée pour déterminer son
impact sur le temps et les coûts du projet, et une évaluation des risques liés à la modification de la
portée sera effectuée. Si la modification est approuvée, la SRT et le dictionnaire de la SRT du projet
seront mis à jour et re-baselinés, le calendrier du projet sera mis à jour et pourra être re-baseliné, et
l'ensemble des exigences du projet sera mis à jour.

Scope Management Plan [Insert Version Number] | Page 9