Defining the Project
4–2
Learning Objectives
4-1
Identify key elements of a project scope statement and understand
why a complete scope statement is critical to project success.
4-2
Describe the causes of scope creep and ways to manage it.
4-3
Understand why it is important to establish project priorities in terms of
cost, time, and performance.
4-4
Demonstrate the importance of a work breakdown structure (WBS) to
the management of projects and how it serves as a database for
planning and control.
4-5
Demonstrate how the organization breakdown structure (OBS)
establishes accountability to organization units.
4-6
Describe a process breakdown structure (PBS) and when to use it.
4-7
Create responsibility matrices for small projects.
4-8
Create a communication plan for a project.
3
These are Chapter ppts only..
You MUST read the textbook for
better and complete
understanding of the subject.
4
Step 1: Defining the Project Scope
Step 2: Establishing Project Priorities
Step 3: Creating the Work Breakdown Structure
Step 4: Integrating the WBS with the Organization
Step 5: Coding the WBS for the Information System
4–5
STEP 1
• Project Scope
– A definition of the end result or mission of the project—a
product or service for the client/customer—in specific,
tangible, and measurable terms.
• Purpose of the Scope Statement
– To clearly define the deliverable(s) for the end user.
– To focus the project on successful completion
of its goals.
– To be used by the project owner and participants
as a planning tool and for measuring project success.
4–6
1. Project objective.
2. Product scope description.
3. Justification.
4. Deliverables.
5. Milestones.
6. Technical requirements.
7. Limits and exclusions.
8. Acceptance criteria.
4–7
Scope Element
Brief Description / Example
1. Project Objective
The measurable end-goal.
Example: "Launch a mobile banking app to reduce branch visits by 15% within 6 months."
2. Product Scope
Description
The specific features of the final product, detailed description.
Example: "Includes fingerprint login, real-time alerts, and P2P transfers."
3. Justification
The business case / reason for doing the project.
Example: "Retain young customers who are leaving due to poor digital experience."
4. Deliverables
Tangible (major) outputs (to be) handed over.
Example: "App (iOS/Android), admin dashboard, user manual, and 2-hr training."
5. Milestones
Key progress checkpoints (zero-duration, key events).
Example: "M1: Prototype complete (Mar 1). M2: Beta test start (Apr 15). M3: Go-live (Jun 1)."
6. Technical
Requirements
Non-negotiable technical needs /performance standards.
Example: "99.9% uptime, 1,000 concurrent users, GDPR & PCI-DSS compliant."
7. Limits & Exclusions
What is explicitly NOT included (prevents scope creep).
Example: "Excludes: Android tablets, legacy CRM integration, and data migration."
8. Acceptance Criteria
The "pass/fail" tests for customer sign-off.
Example: "Loads under 2.5 sec on 4G; passes all security penetration tests."
Stakeholder
Signature / Approval
Date
▪ Project Sponsor
_________________
______
▪ Customer Representative
_________________
______
▪ Project Manager
_________________
______
4–8
• Scope Statements
– Also called statements of work (SOW)
• Project Charter
– Can contain an expanded version of scope statement
– A document authorizing the project manager to initiate and lead the project.
• Scope Creep
– The tendency for the project scope to expand over time due to changing requirements,
specifications, and priorities.
Most Common Causes of Scope Creep
•
•
•
•
•
•
•
Poor requirement analysis
External causes (e.g., market trends, industry announcements)
Not involving users early enough / Project team miscommunication
Incomplete or inadequate scope statements, systems, or procedures
Underestimating project complexity
Lack of change control / Insufficient project monitoring
Gold plating - project team adds extra features that were not part of the original scope,
usually as “freebies” for the client (expecting ‘next’ project)
RFP (Buyer asks for bids) → SOW (Vendor details the work) → MSA (Provides the legal umbrella)
+ SLA (Defines quality) → Project Charter (Authorizes start) → WBS (Breaks work into tasks) → Change
Order (If anything changes).
4–9
Term
Definition
Key Focus
How it Relates to the SOW
A formal, narrative document detailing the
The "What" &
Statement of Work
This is the master document. It becomes
specific work, deliverables, and timeline
"When" (Scope of
(SOW)
the legal baseline for the project contract.
required from a vendor or internal team.
work to be performed).
A section within the Statement of Work that
The Scope of Work is a critical
The"Boundaries" (Pre
Scope of Work
explicitly defines the project boundaries—
subsection inside the larger Statement of
venting scope creep).
listing what is IN scope and what is OUT
Work (Full Contract) document.
A high-level, one-to-two-page
The "Why" &
The Charter authorizes the project; the
document(issued by project initiator) that
Project Charter
"Who" (Business case SOW details the work. The SOW is often
authorizes the project manager to start and
& authority).
attached as an appendix to the Charter.
spend budget.
A visual hierarchical decomposition of the
The WBS is created from the SOW. It
Work Breakdown
The "How" (Breaking
total project scope into smaller, manageable
takes the SOW’s deliverables and breaks
Structure (WBS)
work into pieces).
chunks (deliverables and work packages).
them into actionable tasks for the team.
A long-term legal contract governing general The "Legal
The SOW is a "child" of the MSA. Each
Master Service
terms and conditions between parties (e.g., Rules" (Long-term
new project gets its own SOW, which
Agreement (MSA)
payment terms, liability).
relationship).
references the overarching MSA.
A document issued by a buyer to solicit
The
The RFP asks for a SOW. The winning
Request for
detailed proposals from multiple vendors,
"Selection" (Asking
vendor's submitted SOW becomes the
Proposal (RFP)
asking for their approach, timeline, and price. vendors to bid).
final contract.
A specific agreement on performance
The
The SLA is usually a section within the
Service Level
metrics and quality standards (e.g., uptime, "Quality" (Ongoing
SOW or MSA, defining how the service
Agreement (SLA)
response time, support hours).
performance).
must perform after delivery.
A document used internally (often in NGOs
Similar to a SOW, but focuses more
Terms of
or government) to define the purpose,
The "Structure" (Roles on internal governance and reporting
Reference (ToR) structure, and roles of a specific project
& governance).
lines, whereas a SOW is often vendorcommittee or team.
facing.
A formal document used to modify an
The
A Change Order overrides the original
Change Order
existing SOW after it has been signed (e.g.,
"Amendment" (Managi SOW. Once signed, it legally becomes
(CO)
adding new deliverables, extending timeline,
ng changes).
part of the updated SOW.
or increasing budget).
4–10
In project management, defining In-Scope and Out-of-Scope is the single most critical step to prevent
scope creep—the gradual, uncontrolled growth of a project’s requirements that causes missed deadlines
and budget overruns
▪
In-Scope: The explicit list of tasks, features, deliverables, and data that a team must deliver to
successfully complete the project. If it is not listed here, it does not exist for the current project timeline.
▪
Out-of-Scope: The explicit list of items, features, or requests that will not be included in the project. This
is not just "everything else"; it specifically highlights high-probability traps, future phases, or related tasks
that stakeholders might assume are included but are actually excluded.
Marketing Campaign (e.g., Product Launch)
➢
In-Scope:
➢
Out-of-Scope:
▪ Creating five promotional social media video assets.
▪
Managing TikTok or organic influencer outreach.
▪ Managing a $10,000 paid ad budget on Meta
platforms.
▪
Redesigning the company’s main corporate logo.
▪
Coding or developing the actual landing page
layout.
▪ Writing copy for the landing page.
Why Documenting "Out-of-Scope" Matters: While defining what you will do is obvious, explicitly defining what you
won't do provides massive hidden value:
▪
Aligns Expectations: It eliminates assumptions. For example, a client may assume "website design" automatically
includes "writing the copy." Listing copywriting as out-of-scope corrects this early.
▪
Provides a Shield Against Scope Creep: When a stakeholder asks for a "quick favor" mid-project, the project
manager can point to the document and say, "This is out-of-scope for this phase, but we can draft a Change Request
or save it for Phase 2."
▪
Protects Budgets and Timelines: Keeps the team focused entirely on the core deliverables required to cross the
finish line on time
4–11
Table 4-1. Elements of the Project Charter and Project Scope Statement
Although the project charter and the project
scope statement are sometimes perceived as
containing a certain degree of redundancy, they
are different in the level of detail contained in
each. The project charter contains high-level
information, while the project scope statement
contains a detailed description of the scope
components. These components are
progressively elaborated throughout the project.
4–12
STEP 2
• Causes of Project Trade-offs
– Shifts in the relative importance of criterions related
to cost, time, and performance parameters
• Budget–Cost
• Schedule–Time
• Performance–Scope
• Managing the Priorities of Project Trade-offs
– Constrain: original parameter is a fixed requirement, the firm
limitation or immovable priority (e.g., the budget cannot exceed
a specific amount).
– Enhance: optimizing / enhance / improve a criterion over others.
– Accept: reducing (or not meeting) a criterion requirement,
willing to adjust, flex, or compromise on to protect the
"Constrained" items.
4–13
The Three Pillars
▪
Scope: The specific deliverables, tasks, features,
and requirements that must be completed to
successfully finish the project.
▪
Time: The overall project schedule, including strict
deadlines, milestone timelines, and the total duration
required for execution.
▪
Cost: The total budget allocated for the project,
encompassing financial resources, labor expenses,
equipment, and material procurement.
➢ While not a standalone boundary point on the
triangle, quality sits at the center of the model.
Quality acts as the final output that absorbs the
pressure of how effectively one can balance the three
constraints.
4–14
4–15
STEP 3
• Work Breakdown Structure (WBS)
– An hierarchical outline (map) that identifies the products
and work elements involved in a project.
– Defines the relationship of the final deliverable
(the project) to its subdeliverables, and in turn,
their relationships to work packages.
– Best suited for design and build projects that have tangible
outcomes rather than process-oriented projects.
4–16
Hierarchical
Breakdown of
the WBS
* This breakdown groups work
packages by type of work within a
deliverable and allows assignment
of responsibility to an organizational
unit. This extra step facilitates a
system for monitoring project
progress (discussed in Chapter 13).
4–17
• WBS
– Facilitates evaluation of cost, time, and technical
performance of the organization on a project.
– Provides management with information appropriate
to each organizational level.
– Helps in the development of the organization breakdown
structure (OBS). which assigns project responsibilities to
organizational units and individuals
– Helps manage plan, schedule, and budget.
– Defines communication channels and assists
in coordinating the various project elements.
4–18
4–19
• A work package is the lowest level of the WBS.
– It is output-oriented in that it:
1.
Defines work (what).
2.
Identifies time to complete a work package (how long).
3.
Identifies a time-phased budget to complete
a work package (cost).
4.
Identifies resources needed to complete
a work package (how much).
5.
Identifies a person responsible for units of work (who).
6.
Identifies monitoring points (milestones)
for measuring success.
4–20
PMBOK ®
Figure 5-6. Sample WBS Decomposed Down Through Work Packages
Three types of WBS samples –
1. WBS Decomposed Down Through Work Packages
2. WBS Organized by Phase
3. WBS With Major Deliverables
4–21
Figure 5-7. Sample WBS Organized by Phase
4–22
Figure 5-8. Sample WBS
With Major Deliverables
4–23
STEP 4:
• Organizational Breakdown Structure (OBS)
– Depicts how the firm is organized to discharge its work
responsibility for a project.
• Provides a framework to summarize
organization work unit performance.
• Identifies organization units responsible
for work packages.
• Ties organizational units to cost control accounts.
4–24
Integration of
WBS and OBS
4–25
STEP 5:
• WBS Coding System
– Defines:
• Levels and elements of the WBS
• Organization elements
• Work packages
• Budget and cost information
– Allows reports to be consolidated at any
level in the organization structure
4–26
Coding
the WBS
4–27
PBS
4–28
• Responsibility Matrix (RM)
– Also called a linear responsibility chart.
– Summarizes the tasks to be accomplished and who
is responsible for what on the project.
• Lists project activities and participants.
• Clarifies critical interfaces between units
and individuals that need coordination.
• Provide an means for all participants to view their
responsibilities and agree on their assignments.
• Clarifies the extent or type of authority that
can be exercised by each participant.
4–29
4–30
4–31
▪ A RACI matrix is a project management tool that clearly maps out roles and responsibilities
for specific tasks or deliverables.
▪ The acronym stands for Responsible, Accountable, Consulted, and Informed.
▪ It eliminates confusion by defining exactly who does the work, who owns the final outcome,
who provides input, and who needs updates
▪ Responsible (R): The "Doer." This is the individual or group who actually executes the work to complete the task.
▪ Accountable (A): The "Owner." This person has the final authority and must sign off on the completed work. They ensure
quality and standard metrics are met.
▪ Consulted (C): The "Advisor." These are subject matter experts who provide specialized feedback or essential input before
the task can be finalized. It is a two-way communication.
▪ Informed (I): The "Loop." These stakeholders are kept updated on progress or outcomes but are not directly involved in
executing or making decisions. It is a one-way communication.
To keep project workflows efficient and clear, ONE must follow these foundational rules when building your matrix:
• Exactly one "A" per task: Every task must have only one ultimate owner. Assigning multiple ‘Accountables’ leads to
confusion, while having zero means no one takes ownership.
• At least one "R" per task: Every activity needs someone designated to do the actual work.
• Minimize "C" roles: Overloading a task with too many consultants can create communication bottlenecks and slow down
delivery timelines.
➢ Prevents diffusion of responsibility: By mandating a single Accountable person, it creates a clear path for
decision-making and escalations, avoiding overlapping duties and dropped tasks.
➢ Improves communication: Clarifies exactly who needs to be consulted versus who just needs to be kept in the
loop, streamlining meetings and status updates.
4–32
RACI Matrix: Customer Portal & Mobile App (v2.0)
Project Task / Deliverable
Sponsor
(S)
Product
Owner
(PO)
Project
Manager
(PM)
Lead
Developer
(Dev)
QA
Lead
(QA)
UX
Designer
(UX)
Security
Officer
(Sec)
Operations
(Ops)
1. Define MVP scope & epics
A
R
C
C
I
C
I
I
2. Create UI/UX wireframes
I
A
I
C
I
R
I
I
3. Finalize technical architecture
I
C
C
R
I
I
A
C
4. Develop sprint backlog items
I
A
C
R
I
C
I
I
5. Conduct code reviews
I
I
I
R
C
I
I
I
6. Perform security testing (SAST/DAST)
I
I
I
C
C
I
A/R
I
7. Execute system & integration testing
I
A
C
C
R
I
C
I
8. Approve UAT sign-off
I
A
C
I
C
C
C
I
9. Plan production deployment
I
C
R
C
I
I
C
A
10. Deploy to production environment
I
I
C
R
C
I
C
A
11. Create operations runbook
I
I
C
C
I
I
C
R
12. Transition to support team
I
A
R
C
I
I
I
C
Minimum Viable Product (MVP) - It is the most basic, functional version of a new product that a company releases to early adopters. The goal is to test a
business idea, gather real user feedback, and validate market demand without investing the time and money required to build a fully finished version.
Epics are large, high-level bodies of work in Agile project management that are broken down into smaller, manageable chunks called "user stories“.
UI (User Interface) and UX (User Experience) design are two distinct yet deeply interconnected disciplines that determine how a digital product looks, feels, and
functions. While UX focuses on the structural logic, user journey, and ease of use, UI focuses on the visual presentation, styling, and interactive elements that
the user directly clicks or touches.
SAST (Static Application Security Testing - (White-Box Testing) - at rest , not running) and DAST (Dynamic Application Security Testing - Black-Box Testing):
Simulates an active hacker trying to attack a live, running application from the outside) are the two fundamental pillars of Application Security (AppSec).
4–33
Role
Description
Sponsor
Executive funding & strategic alignment.
Product Owner
Owns the product vision, backlog prioritization, and business acceptance.
Project Manager
Coordinates timelines, resources, communication, and deployment logistics.
Lead Developer
Owns technical implementation, coding standards, and build pipelines.
QA Lead
Owns testing strategy, automation, and quality gates.
UX Designer
Owns user experience, interface design, and usability testing.
Security Officer
Owns compliance, vulnerability assessment, and security approvals.
Operations
Owns infrastructure, deployment environment, and post-launch stability.
1. Accountability (A) shifts by phase – The Product Owner owns scope; the PM owns deployment logistics;
the Security Officer owns security testing. This prevents diffusion of final responsibility.
2. Developers are Responsible (R) for code but never Accountable (A) alone – Accountability for quality is
shared with QA (testing) and Security (vulnerabilities). This reflects the reality of modern DevOps where
quality is everyone's job.
3. Operations is Accountable (A) for the production environment – This explicitly
separates development from deployment, avoiding the classic "it works on my machine" handoff conflict.
4. Consulted (C) vs. Informed (I) is strategic – Note that the UX designer is Consulted on technical
architecture (to ensure feasibility) but only Informed on security testing (not needed). This reduces
unnecessary meeting fatigue.
5. The PM is Responsible (R) for transition to support – This ensures a smooth handoff, not leaving support
teams to reverse-engineer the system post-launch.
4–34
Term /
Variant
Best Used For
Insight
RACI (Stan Responsible, Accountable,
dard)
Consulted, Informed
Baseline role clarity across
all projects
The gold standard; ensures single-point
accountability (A) and prevents task ambiguity.
RAM (Gen
eric)
Responsibility Assignment
Matrix (any roles)
Umbrella term for any rolemapping grid
Strategic tool for resource alignment and
stakeholder mapping—not just tasks, but
governance.
Adds Support
Tasks requiring active help
from multiple contributors
Useful in matrix organizations where shared
resources co-deliver work; distinguishes doers
from advisors.
RACI-VS
Adds Verifier, Signatory
Regulated,
quality-sensitive, or
compliance-driven projects
Adds control gates; critical for aerospace,
pharma, or public sector where audit trails
matter.
DACI
Driver, Approver,
Contributors, Informed
Decision-intensive projects
(e.g., steering committees)
Shifts focus from task execution to decision
authority—essential for governance models.
RAPID
Recommend, Agree,
Perform, Input, Decide
High-stakes strategic
decisions with multiple
executives
Clarifies who decides vs. who advises; widely
used in corporate strategy and transformation
programs.
CAIRO
Consult, Approve, Informed,
Responsible, Out-of-the-loop
Explicitly naming who
is not involved
Helps reduce noise and manage stakeholder
expectations by formalizing non-participation.
Adds Quality review
Projects with formal QA
gates (e.g., software,
engineering)
Embeds quality ownership into the
responsibility matrix, not just as a separate
checklist.
RASCI
RACIQ
Core Roles
4–35
4–36
• What information needs to be collected
and when?
• Who will receive the information?
• What methods will be used to gather
and store information?
• What are the limits, if any, on who has access to
certain kinds of information?
• When will the information be communicated?
• How will it be communicated?
4–37
• Project status reports
• Deliverable issues
• Changes in scope
• Team status meetings
• Gating decisions
• Accepted request changes
• Action items
• Milestone reports
4–38
1. Stakeholder analysis—identify the target groups.
2. Information needs—project status reports, deliverable issues,
changes in scope, team status meetings, gating decisions,
accepted request changes, action items, milestone reports,
etc.
3. Sources of information—where does the information reside?
4. Dissemination modes—hardcopy, e-mail, teleconferencing,
SharePoint, and a variety of database sharing programs.
5. Responsibility and timing—determine who will send out the
formation and when.
4–39
4–40
Acceptance criteria
Product scope description
Cost account
Project charter
Gold plating
Responsibility matrix
Milestone
Scope creep
Organization breakdown structure
(OBS)
Scope statement
Priority matrix
Process breakdown structure
(PBS)
WBS dictionary
Work breakdown structure (WBS)
Work package
• Coal Fired Boiler
• Hotel Pulkeshi International
4–41