MODULE 2- PLANNING PROJECTS

Defining the project scope:

Define scope, is the process of developing a detailed description of the project and product. The project
scope statement includes three things regarding the scope. Firstly the team needs to determine both what
they will deliver to the project stakeholders at the end of the project and what they need to deliver along
the way to ensure they will be successful in the end. These are the deliverables—the product scope. For
example, if a final project deliverable is a new computer program; intermediate deliverables may include
an outline of what will be included and a prototype. Second, the team should decide what work needs to
be accomplished to create the deliverables. This is the project work statement—the project scope. Third,
the team needs to determine what will limit or influence the project work—such as exclusions,
constraints, and assumptions.

Reasons to Define Scope

Scope definition is an important part of project planning because all other planning is based upon the
project scope. While the requirements collected represent the customers statement of what they need, the
defined scope is the project team’s response—asking the customer,“If we provide this, will it solve your
problem?” It is impossible to estimate how much a project will cost, how many (and what type of)
workers will be needed, how long a project will take, what risks are involved, or what quality standards
will be invoked without first understanding what work the project includes. Scope definition also is vital
in preventing scope creep. Scope creep happens for two common reasons. First, if the scope is not clearly
defined and agreed upon, it is easy to add to the project without realizing that more time and money will
be required. Second, sometimes when a project is going well, a customer is so excited that he or she asks
an innocent sounding question:

“Can the project output also do?” The person performing the project work is often flattered and agrees
without understanding the implications. In contemporary business, pleasing the customer is desirable.
However, the best time to gain customer understanding is when the project team is defining the scope—
not while working to implement it.

How to Define Scope

Scope definition can vary greatly from one project to another. On some types of projects, such as a small,
routine construction project, it may be quite simple to determine what project outputs will be created and
what work is involved in creating them. On other projects, such as one large company acquiring another,
it may be very difficult to determine the total amount of work that needs to be accomplished. Regardless
of how easy or difficult it may be to define scope and in spite of industry-specific methods that may be
helpful in doing so, all project teams need to complete each part of this process. The steps involved in
defining the project scope are as follows:
LIST DELIVERABLES AND ACCEPTANCE CRITERIA

The first step is to list project deliverables. The requirements elicited from the customer often lead to
some of the final deliverables. Project teams need to understand that there are often multiple deliverables.
For example, if a project entails constructing a house, the homeowners probably want not only the house
but also documentation on systems within it, perhaps an explanation (training) on how to use certain
items such as an innovative thermostat, and a warranty guaranteeing a properly functioning house. The
project team also needs to list intermediate deliverables—those things that need to be developed for the
project to progress. Some of these were probably listed in the charter, but others may not yet be identified.
The project team then needs to determine the acceptance criteria for each deliverable.

ESTABLISH PROJECT BOUNDARIES

The second step in defining scope is to establish the project boundaries. Think of the project boundaries
as the sidelines on an athletic field. By understanding what is in play and what is not, athletes know
clearly when to play and when to stop. Likewise, project team members need to know when to play and
when to stop. The first part of the boundary definition is to decide which features and work elements are
included (in scope) and which are excluded (out of scope). Users collectively often request far more work
than a project can deliver. Therefore, the team needs to decide what is included and what is not.
Sometimes, the sponsor makes the larger scope decisions, but the project manager and team still have
many detailed scope decisions to make. Expectations need to be managed regarding any project. The
project team members need to understand the constraints imposed upon the project. If the work must be
delivered by a certain date or if only limited resources are available, the project may be constrained,
and the team should be careful to only promise what it can deliver. In planning, people make assumptions
about dates and times, such as that a shipment of required materials will arrive by the date the supplier
promised. These assumptions should be stated. If an assumption proves to be false, it frequently increases
the project risk and may also limit the project scope.

CREATE A SCOPE DESCRIPTION

The final step is to create a scope description. This sentence or two describes the work that needs to be
accomplished to create the project deliverables. A project scope statement guides the project team during
subsequent planning and execution. On some very small projects, a well-developed charter could double
as a scope statement. On most projects, a scope statement needs to be developed prior to development
of the WBS.

Project scope checklist

Creating a project scope checklist is a crucial step in project management to ensure all aspects of the
project are clearly defined and comprehensively understood by all stakeholders. This checklist begins
with outlining the project objectives, ensuring they are Specific, Measurable, Achievable, Relevant, and
Time-bound (SMART) to provide a clear direction. It continues with identifying and documenting all
stakeholder requirements, encompassing both functional and non-functional aspects, and any regulatory
and compliance needs. Listing all project deliverables and defining acceptance criteria for each is
essential to measure success. The scope checklist also distinguishes what is included and excluded from
the project, clarifying boundaries and avoiding scope creep. Documenting assumptions and validating
them with stakeholders, along with identifying constraints such as time, budget, and resources, ensures all
potential impacts are understood.

A project scope checklist typically includes the following contents to ensure comprehensive coverage and
clear definition of all project aspects:

1. Project Objectives
 Clear statement of the project goals and objectives.
 Specific, Measurable, Achievable, Relevant, and Time-bound (SMART) criteria.
2. Project Requirements
 Detailed list of stakeholder requirements.
 Functional and non-functional requirements.
 Regulatory and compliance requirements.
3. Project Deliverables
 Complete list of all deliverables expected from the project.
 Acceptance criteria for each deliverable.
4. Project Boundaries
 Definition of what is in scope.
 Definition of what is out of scope.
 Identification of limitations and constraints.
5. Project Assumptions
 Documentation of assumptions that impact the project scope.
 Validation of assumptions with stakeholders.
6. Project Exclusions
 Clear statement of what is not included in the project.
 Communication of exclusions to stakeholders.
7. Project Constraints
 Identification of constraints related to time, budget, resources, technology, etc.
 Documentation of how constraints will impact the project.
8. Stakeholder Identification
 Identification of all project stakeholders.
 Determination of stakeholder needs and expectations.
 Definition of stakeholder roles and responsibilities.
9. Scope Statement
 Development of a detailed scope statement.
 Approval of the scope statement by key stakeholders.
10. Work Breakdown Structure (WBS)
 Creation of a WBS that decomposes the project into smaller, manageable components.
 Definition and understanding of each WBS element.
11. Scope Verification
 Definition of the process for scope verification and validation.
 Establishment of criteria for accepting completed deliverables.
12. Change Control Process
 Development of a process for managing changes to the project scope.
 Clear procedure for submitting, evaluating, and approving scope changes.
 13. Scope Baseline
 Establishment of a scope baseline that includes the scope statement, WBS, and WBS
dictionary.
 Approval and use of the baseline as a reference for managing project scope.
14. Communication Plan
 Development of a communication plan to keep stakeholders informed about scope-related
matters.
 Definition of methods and frequency of communication.
15. Risk Management
 Identification of potential risks that could impact the project scope.
 Development of risk mitigation strategies and contingency plans.
16. Documentation
 Proper documentation and storage of all scope-related documents.
 Record-keeping of all scope changes and approvals.
17. Review and Approval
 Formal review of the project scope with stakeholders.
 Obtaining formal approval and sign-off from key stakeholders.

Project priorities are crucial for ensuring that resources are allocated effectively and that the project
remains aligned with its goals. Establishing clear priorities helps in decision-making and managing trade-
offs. Some key project priorities are:
1. Scope
 Definition and Clarity: Ensuring that the project scope is well-defined, understood, and agreed
upon by all stakeholders.
 Scope Management: Managing scope changes effectively to avoid scope creep.
2. Time
 Schedule Adherence: Prioritizing adherence to the project timeline and milestones.
 Time Management: Efficient allocation of time to tasks and activities to meet deadlines.
3. Cost
 Budget Control: Ensuring the project stays within the approved budget.
 Cost Management: Efficient use of financial resources and managing cost changes.
4. Quality
 Standards Compliance: Adherence to quality standards and specifications.
 Quality Assurance: Implementing processes to ensure deliverables meet the required quality.
5. Resources
 Resource Allocation: Efficient and effective allocation of human, technical, and material
resources.
 Resource Management: Ensuring resource availability and addressing any resource constraints.
6. Risk Management
 Risk Identification: Proactively identifying potential risks that could impact the project.
 Risk Mitigation: Developing and implementing strategies to minimize or eliminate risks.
7. Stakeholder Engagement
 Communication: Regular and effective communication with all stakeholders.
 Stakeholder Satisfaction: Ensuring stakeholders’ needs and expectations are met.
8. Deliverables
 Completion and Delivery: Prioritizing the timely completion and delivery of project outputs.
 Acceptance Criteria: Ensuring deliverables meet the acceptance criteria and are approved by
stakeholders.
9. Customer Satisfaction
 Meeting Requirements: Ensuring the project outputs meet customer requirements and
expectations.
 Feedback and Adjustment: Gathering customer feedback and making necessary adjustments to
deliverables.
10. Project Integration
 Alignment: Ensuring all project elements are aligned with the overall objectives.
 Coordination: Coordinating different aspects of the project to work seamlessly together.
11. Sustainability
 Long-term Impact: Considering the long-term impacts of the project on the environment and
society.
 Sustainable Practices: Implementing sustainable practices in project execution.
12. Innovation and Improvement
 Continuous Improvement: Prioritizing continuous improvement in processes and deliverables.
 Innovation: Encouraging innovative solutions to enhance project outcomes.
13. Compliance and Legal
 Regulatory Compliance: Ensuring the project adheres to all relevant laws and regulations.
 Legal Requirements: Meeting all contractual and legal obligations.
By prioritizing these aspects, project managers can ensure that the project progresses smoothly, meets its
objectives, and delivers value to stakeholders.

Work Breakdown Structure (WBS)

A tool that is used on virtually all projects is the WBS. The work breakdown structure or WBS is a tool
that project teams use to progressively divide the deliverables of a project into smaller and smaller pieces.
The project team members start by identifying the major deliverables to be created and keep asking
“What are the components of this deliverable?” The WBS is not a list of work activities, an organizational
chart, or a schedule. Other tools that follow are used for those purposes. The WBS is a framework that is
used as a basis for further planning, execution, and control. Classically, and still today on large projects,
the WBS is created after the scope is defined. In contemporary project management, particularly on small
and middle-sized projects, the WBS may be created concurrently with the scope statement.
The WBS is normally developed by listing deliverables—first major deliverables and then progressively
smaller ones until the team feels that every deliverable has been identified.
The reasons for using a WBS are many. Planning projects requires discipline and visibility. A WBS can
be used as a pictorial representation of project deliverables. By using a systematic process for creating a
WBS, project team members can ensure that they remember all deliverables that need to be created.
Deliverables that are not planned, but need to be, often add to schedule delays and budget overruns.
The WBS is the basis for all subsequent planning of such important functions as schedule, resources, cost,
quality, and risk. It serves as an outline for integrating these various functions. The WBS is easily
modified and can thus handle the changes that often happen on projects. The impact of these changes is
then shown in the schedule, budget, and other control documents. If a problem occurs during
project execution, the WBS is helpful in understanding exactly where and why the problem occurred.
This helps to manage the quality of the project deliverables and keep all the other facets of the project on
schedule while the isolated problem is fixed.
The WBS is also helpful in project communications. Typically many stakeholders help develop the WBS,
and this effort helps them understand the project. Software such as Microsoft Project enables a WBS to be
shown in its entirety to people who need to understand the details, but it also allows project details to be
hidden so that others can see the big picture.
(PMI) defines WBS as "a deliverable-oriented hierarchical decomposition of the work to be executed by
the project team to accomplish the project objectives and create the required deliverables."

WBS Formats

There are various formats for constructing a WBS, but they all have the same purpose.

Different formats of WBS can be used based on the nature of the project and the preference of the
project team. Here are some common WBS formats:

1. Hierarchical (Tree) Format

 Description: A visual, tree-like diagram where the project is broken down into major
deliverables, which are further subdivided into smaller tasks or work packages. Ideal for
complex projects where a visual representation helps in understanding the relationships and
dependencies between tasks.

2. Outline (Indented) Format

 Description: Uses indentation to represent different levels of the hierarchy, similar to a

structured list or table of contents. Suitable for straightforward projects where simplicity and
clarity in listing tasks are important.

 1. Project
 1.1 Deliverable 1
 1.1.1 Sub-deliverable 1.1
 1.1.1.1 Task 1.1.1
 1.1.1.2 Task 1.1.2
  1.1.2 Sub-deliverable 1.2
 1.2 Deliverable 2
 1.2.1 Sub-deliverable 2.1
 1.2.2 Sub-deliverable 2.2

3. Tabular Format
 Description: Uses a table to list the components of the WBS, often including columns for WBS
codes, task descriptions, responsible parties, and other relevant details. Beneficial for projects
requiring detailed tracking and assignment of responsibilities.
 | WBS Code | Task Description | Responsible Party | Duration | Start Date | End Date |
 |---------- |--------------------------|------------------- |----------|------------|---------- |
 |1 | Project | Project Manager | 100 days | 01-Jan | 10-Apr |
 | 1.1 | Deliverable 1 | Team Lead 1 | 50 days | 01-Jan | 19-Feb |
 | 1.1.1 | Sub-deliverable 1.1 | Member A | 20 days | 01-Jan | 20-Jan |
 | 1.1.1.1 | Task 1.1.1 | Member A | 10 days | 01-Jan | 10-Jan |
| 1.1.1.2 | Task 1.1.2 | Member B | 10 days | 11-Jan | 20-Jan |

Mind Map Format

 Description: A visual format that uses a central node (the project) with branches representing
deliverables and tasks, similar to a mind map. Ideal for brainstorming and when visualizing the
project structure in a non-linear fashion is beneficial.

 Example: A central node labeled "Project" with branches extending to "Deliverable 1,"
"Deliverable 2," and further sub-branches for tasks.

Gantt Chart Format

 Description: Combines the WBS with a timeline to show the schedule and progress of tasks.
Each task is represented as a bar on the timeline. Suitable for projects where tracking timelines
and dependencies visually is crucial.

 Example: A Gantt chart with bars representing "Deliverable 1," "Sub-deliverable 1.1," and
their associated tasks along a timeline.

How to Construct a WBS

When a project team needs to construct a WBS, it needs to include in its planning team a
subject matter expert (SME) who understands how each portion of the work will be
accomplished. Teams approach this in two ways. Some teams include only the core team
members and plan the WBS as far as they can. At that point, different core team members are
assigned to assemble the SMEs they need to plan the remaining details. Other teams invite the
SMEs to the WBS planning meeting right from the start and utilize their input right away. The
choice of how to include SMEs often is determined by the size and complexity of the project
and by the cultural norms of the company.
Constructing a WBS
1. Define the Project Scope
 Gather Requirements: Collect all the project requirements from stakeholders.
 Define Objectives: Clearly outline the project’s goals and objectives.
2. Identify Major Deliverables
 Break Down the Scope: Identify the major deliverables or outputs of the project.
 High-Level Breakdown: Start with high-level deliverables that align with the project’s main
objectives.
3. Decompose Deliverables into Smaller Components
 Sub-deliverables: Break each major deliverable into smaller, more manageable components (sub-
deliverables).
 Work Packages: Further decompose sub-deliverables into work packages, which are the smallest
units of work that can be managed and scheduled.
4. Organize Hierarchically
 Tree Structure: Arrange the deliverables in a hierarchical tree structure, starting with the overall
project at the top.
 Levels of Decomposition: Ensure each level of decomposition is clear, showing the relationship
between the higher-level deliverables and the lower-level components.
5. Assign WBS Codes
 Unique Identifiers: Assign unique WBS codes to each element for easy identification and
tracking.
 Numbering System: Use a logical numbering system, such as 1.0 for the first major deliverable,
1.1 for its sub-deliverable, 1.1.1 for the work packages, and so on.
6. Review and Validate
 Stakeholder Review: Review the WBS with stakeholders to ensure completeness and accuracy.
 Validate Scope: Validate that the WBS covers the entire project scope without missing any key
components.
7. Refine and Update
 Refinement: Refine the WBS as needed based on feedback and further analysis.
 Regular Updates: Update the WBS throughout the project lifecycle to reflect any changes in
scope or deliverables.

Example of a WBS
Project: Website Development
1. Website Development Project
 1.0 Planning
 1.1 Requirements Gathering
 1.2 Feasibility Study
 1.3 Project Charter
 2.0 Design
 2.1 Wireframes
 2.2 Mockups
 2.3 Design Approval
 3.0 Development
  3.1 Front-End Development
 3.1.1 HTML/CSS
 3.1.2 JavaScript
 3.2 Back-End Development
 3.2.1 Database Design
 3.2.2 API Development
 4.0 Testing
 4.1 Unit Testing
 4.2 Integration Testing
 4.3 User Acceptance Testing (UAT)
 5.0 Deployment
 5.1 Staging Environment Setup
 5.2 Production Deployment
 5.3 Post-Deployment Support
 6.0 Maintenance
 6.1 Bug Fixes
 6.2 Performance Tuning
 6.3 Content Updates