Chapter 4. Project Planning and the Project Scope

4.4 Project Scope Management

Before starting the implementation of any project activities, the project team needs to know exactly what work has to be done. Therefore, the team needs to plan first to provide guidance and direction on how the scope will be managed throughout the project[1]. In this very beginning process, the project team creates a scope management plan that documents how the project and product scope will be defined, validated, and controlled. Project managers should coordinate the responsibilities of each team member. In order to do so, they should know exactly what they’re going to do to meet the project’s objectives. Therefore, the scope planning process is the very first thing to be done. Project scope planning is concerned with the definition of all the work needed to successfully meet the project objectives. Project managers and teams should have a clear picture of all the work that needs to happen on their projects, and as the project progresses, they should ensure that the scope is up to date.

4.4.1  Defining the Scope

We already have a head start on refining the project’s objectives in quantifiable terms, but now we need to plan further and write down all the intermediate and final deliverables that we will produce over the course of the project. Deliverables include everything that we produce for the project (i.e., anything that the project will deliver). The deliverables for the project include all of the products or services that we are performing for the internal or external clients, and/or the end-users and customers. They include every intermediate document, plan, schedule, budget, blueprint, and anything else that will be made along the way, including all of the project management documents that are put together. Project deliverables are tangible outcomes, measurable results, or specific items that must be produced to consider either the project or the project phase completed. Intermediate deliverables, like the objectives, must be specific and verifiable.

All deliverables must be described in a sufficient level of detail so that they can be differentiated from related deliverables. For example:

  • A twin-engine plane versus a single-engine plane
  • A red marker versus a green marker
  • A daily report versus a weekly report
  • A departmental solution versus an enterprise solution

In our case of m-commerce project carried out by Grocery LLC, there are two main deliverables which are:

  1. A mobile application that can be installed on Android and IOS smartphones.
  2. A mobile website optimized for Android and IOS smartphones.

We should also define what is not included in the project’s scope. M-commerce project doesn’t directly target tablets since their screen size would allow them to display the regular desktop website. Besides, the smartphone application can be used in tablets. Besides, smartphones with operating systems other than Android and IOS are excluded.

One of the project manager’s primary functions is to accurately document the deliverables of the project and then manage the project so that they are produced according to the agreed-on criteria. Deliverables are the output of each development phase, described in a quantifiable way to assure measurability. In our case study, project objectives have been provided to ensure measurability:

  1. To redesign the website in 2 months so it’s more responsive and easier for the customers to place orders on their smartphones.
  2. To create a new mobile application in 2 months that can work in both operating systems (Android and IOS).

The process of defining scope generates a “Project Scope Statement”[2]. It is the description of the project scope, major deliverables, assumptions, and constraints. The project charter contains high-level information while the project scope statement contains a detailed description of the scope components. The project scope statement documents the entire scope, including project and product scope. Project Scope Statement is composed of the components as outlined below[3]. Readers should always keep in mind that they should create a long and detailed statement when they work as a project manager or a team member on a project in their organizations.

  1. Product scope description

The mobile application and the mobile website will have the same functions that allow online customers to conveniently do their shopping by browsing, searching, and locating the items they want to purchase, adding them to the cart, specifying the number and weight of the items, choosing the delivery and shipping options, checking out via their payment option, and tracking the items they ordered. The mobile application will work on smartphones having Android and IOS. Customers will use the same username and password they use to access the desktop version. If they leave the application or the website, the items in their cart will not be removed and synchronized with all the interfaces (mobile application, mobile website, and desktop website). If an item’s price changes or this item is sold out, they will be notified of this when they access their carts.

  1. Deliverables
  • A mobile application
  • Optimized mobile website
  1. Acceptance criteria

The mobile website and the smartphone app will be subject to alpha testing first. Then, beta testing will follow, where customers can install the beta version on their smartphones and do their online shopping. During the implementation of the beta version, all the feedback from customers and their mobile devices will be evaluated and the bugs and problems will be corrected. When the mobile website and the app are fully functional, customers should log in with their usernames and passwords, browse items, add them to their carts, proceed to checkout, and complete their payment.

The sponsor must approve the sign-off after they receive the inspection and acceptance report.

  1. Project exclusions
  • This project doesn’t directly target tablets since their screen size would allow them to display the regular desktop website. Besides, the smartphone application can be used in tablets.
  • Smartphones with operating systems other than Android and IOS are excluded.

4.4.2  Work Breakdown Structure (WBS)

After defining deliverables and requirements, and creating a Project Scope Statement, the next step would be to create a Work Breakdown Structure (WBS) that defines all the activities required to complete the project. The WBS defines the scope of the project and breaks the work down into components that can be scheduled, estimated, and easily monitored and controlled. The idea behind the WBS is simple: dividing a complicated task into smaller tasks until we reach a level that cannot be further subdivided. We stop breaking down the work when we reach a low enough level to perform an estimate of the desired accuracy. At that point, it is usually easier to estimate how long the small task will take and how much it will cost to perform than it would have been to estimate these factors at the higher levels. Each descending level of the WBS represents an increased level of detailed definition of the project work. A WBS also provides the necessary framework for detailed cost estimating and control, along with providing guidance for schedule development and control.

The purpose of developing a WBS is to allow easier management of each component, accurate estimation of time, cost, and resource requirements, easier assignment of human resources, and easier assignment of responsibility for activities.

WBS is a hierarchical decomposition of the project into phases, deliverables, and work packages. It is a tree structure, which shows a subdivision of effort required to achieve an objective. In a project, the WBS is developed by starting with the end objective and successively subdividing it into manageable components in terms of size, duration, and responsibility, which includes all steps necessary to achieve the objective. An example of this hierarchical decomposition can be starting from the highest level which is the project and moving downwards along the systems, subsystems, components, tasks, and subtasks, and stopping when we arrive at the lowest level which is work packages.

The WBS creation involves:

  • Listing all the project outputs (deliverables and other direct results)
  • Identifying all the activities required to deliver the outputs
  • Subdividing these activities into subactivities and tasks
  • Identifying the deliverable and milestone(s) of each task
  • Considering the usage of all the resources (personnel and material) required to complete each task

WBS formatting can be made through various approaches such as the top-down approach, the use of organization-specific guidelines, and the use of WBS templates[4]. The WBS can be developed in different ways to represent the second level after the highest level, the project. The second level can represent the phases of the project life cycle or major deliverables. Below illustrates a WBS with major deliverables at the second level.

0 Project Name

1 Major Deliverable

1.1 Sub Deliverable

1.2 Sub Deliverable

1.3 Sub Deliverable

2 Major Deliverable

2.1 Sub Deliverable

2.1.1 Work Package

2.1.2 Work Package

2.1.3 Work Package

2.1.4 Work Package

2.2 Sub Deliverable

2.3 Sub Deliverable

3 Major Deliverable

3.1 Sub Deliverable

3.1.1 Work Package

3.1.2 Work Package

3.1.3 Work Package

3.2 Sub Deliverable

3.2.1 Work Package

3.2.2 Work Package

3.3 Sub Deliverable

4.4.3  Case Study 4.1: WBS of Grocery LLC’s M-Commerce Project

Based on the Project Charter we developed in Chapter 3 as well as the requirements and the scope detailed in this chapter for Grocery LLC’s M-Commerce Project, we can create a WBS for the mobile application as below[5]. Optimization of the mobile website is not included in this WBS. Different from the generic WBS above which has been developed based on the major deliverables and sub deliverables, the WBS below displays the phases of the project in the second level (e.g., scope, analysis/application requirements, deployment). This WBS has three levels including the highest level which is the project itself. In Chapter 7 “Scheduling”, we will have an exercise regarding the fourth level for “1.3 Preparation of Project Charter” in the “Defining Activities” section. Although some WBS components such as “1.6 Initiation stage complete” and “2.7 Analysis Complete” are on the Activities column, they are milestones with zero duration which show

Table 4.2: WBS for the Mobile App Development Project
WBS Activities
0 Mobile App Development
1 Scope
1.1 Clarify project purpose and determine project scope
1.2 Secure project sponsorship
1.3 Preparation of project charter
1.4 Approval of project charter by the sponsor
1.5 Secure core resources
1.6 Initiation stage complete
2 Analysis/App Requirements
2.1 Conduct needs analysis
2.2 Draft preliminary stakeholder specifications
2.3 Review specifications with team and stakeholders
2.4 Incorporate feedback on the specifications
2.5 Develop preliminary budget and delivery timeline
2.6 Obtain approvals to proceed (concept, timeline, budget, resources)
2.7 Analysis complete
3 Design
3.1 Review preliminary stakeholder specifications
3.2 Develop solution (functional and non-functional) specifications
3.3 Develop transition requirements
3.4 Develop design mockups based on specifications
3.5 Review specifications
3.6 Incorporate feedback into specifications
3.7 Obtain approval to proceed
3.8 Design complete
4 Development
4.1 Review solution and transition specifications
4.2 Assign development staff
4.3 Develop on SDKs (Software Development Kits)
4.4 Developer testing (primary debugging)
4.5 Development complete
5 Testing
5.1 Develop a test plan based on specifications and SDK
5.2 Conduct automated test plans
5.3 Conduct performance and stress tests
5.4 Conduct regression testing
5.5 Conduct localization testing
6 Training
6.1 Develop training specifications for end users
6.2 Develop training specifications for helpdesk support staff
6.3 Develop training materials
6.4 Finalize training materials
6.5 Training materials complete
7 Documentation
7.1 Develop Help specification
7.2 Develop Help system
7.3 Review Help documentation
7.4 Incorporate Help documentation feedback
7.5 Develop user manuals specifications
7.6 Develop user manuals
7.7 Review all user documentation
7.8 Incorporate user documentation feedback
7.9 Documentation complete
8 Pilot
8.1 Identify test group
8.2 Develop software delivery mechanism
8.3 Install/deploy software
8.4 Obtain user feedback
8.5 Evaluate testing information
8.6 Pilot complete
9 Deployment
9.1 Determine final deployment strategy
9.2 Develop deployment methodology
9.3 Get approval from Android and Apple stores
9.4 Train support staff
9.5 Deploy software
9.6 Deployment complete
10 Post Implementation Review
10.1 Document lessons learned
10.2 Archive all documents
10.3 Complete all pending payments
10.4 Create software maintenance team
10.5 Final meeting with stakeholders to close the project
10.6 Disband the team


  1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.
  2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.
  3. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.
  4. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.
  5. Adopted from Microsoft Project Professional 2019 Software Development Plan Template


Icon for the Creative Commons Attribution-NonCommercial 4.0 International License

Project Management by Abdullah Oguz is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License, except where otherwise noted.

Share This Book