Chapter 1

Project Management Fundamentals

and Core Concepts
1.1 Recognize core terminology

1.1.1 Define a project, product, program, portfolio, etc.

1.1.2 Define project management
1.1.3 Define a business case
1.1.4 Define project scope
1.1.5 Define deliverables
1.1.6 Define a milestone and task
1.1 Recognize core terminology

1.1.7 List components of a project

1.1.8 List components of a business case
1.1.9 Define issues, risks, assumptions, and constraints
1.1.10 Identify features of traditional plan-based delivery
1.1.11 Identify features of agile delivery
1.1.12 Identify project management ethics (refer to PMI
code of ethics)
1.1 Recognize core terminology
1.1.1 Define a project, product, program, portfolio, etc.
The purpose of this study guide is to prepare candidates for the
PMI Project Management ReadyTM exam. For greater detail on
the terminology and concepts contained in this study guide, refer to
"A Guide to the Project Management Body of Knowledge
(PMBOK) 7th edition", which was published by the Project
Management Institute® (PMI) in August 2021.
Project or Program, what's the difference?
Project
PMI's PMBOK Guide defines a project as “a temporary endeavor undertaken to
create a unique service or result.” In other words, a project has the following three
characteristics:
A project is temporary, with a start date and end date.
A project closes on the completion of the work it was chartered to deliver.
A project creates either a “product, service, or a result”.
Project or Program, what's the difference?
Program
PMI's Standard for Program Management defines a program as “a group of related
projects managed in a coordinated way to obtain benefits and control not available
from managing them individually. Programs may contain elements of work outside of
the scope of the discrete projects in the program.” In other words, programs involve
the coordinated management of two or more projects. For example, a disaster relief
effort is a "program" because it involves coordinating several interrelated projects.
The terms Project and Program are often confused and misused
interchangeably. For example, most disaster relief efforts are
mislabeled as "projects", when in fact they are an ongoing program of
work to realize a benefit (i.e., a return to normality). In other words,
disaster relief programs include more than one project, whereas a single
project is focused on the efficient creation of a defined deliverable, such
as building a house.
A program's objective of realizing benefits is a very different one than
that of a project, which is focused on the delivery of products, services,
or results—also called, "deliverables". A regularly used short
description of the difference is the following:

Projects are focused on the efficient creation of outputs. For example,
creating a product such as a tiny house. The person responsible for
overseeing the creation of this single house would be called a Project
Manager.

Programs are focused on delivering outcomes. For example, building
an entire village of tiny houses to provide temporary shelter for people
left homeless after a flood and all the aspects of housing those people,
such as acquiring funding assistance, providing security, possibly
coordinating with local businesses to provide food and clothing, then
transitioning the homeless guests out of the tiny house village into
more permanent housing, these are all separate but related
projects within an overall Program. The
person responsible for overseeing these
related projects and integration of their
outcomes is called a Program Manager.
Other Related Terminology
Other terminology associated with projects and programs are the terms
Portfolio and Product. What do these terms mean?
Portfolio - is a collectively managed set of programs and projects, which are related
through administration. In the previous example of disaster relief, a portfolio could
be the collection of programs and
projects managed by FEMA, which is the Federal
Emergency Management Agency (FEMA) of the
United States Department of Homeland Security. The portfolio of programs and
projects managed by FEMA supports their overall role of helping communities
prepare, respond & recover from disasters across the USA.
Product - is a good, service, platform, application, system, etc. that is created,
maintained and supported by solving problems for a specific customer-type.
1.1.2 Define project management
Project Management - is the application of tools and techniques on a set of
requirements to create a "deliverable". For example, building a house or
developing a video game would be creating a deliverable.

PMI defines Project Management as "The application of knowledge, skills,

tools, and techniques to project activities to meet the project requirements." In
other words, project management is to achieve all project goals within a set of
given deadlines.
1.1.3 Define a business case
Business Case - is a document written for executive decision makers that
discusses potential outcomes, risks and costs of a project. The validity and
reasoning are usually gathered from a feasibility study. The business case
estimates how a project will affect the future value of a business and justifies
the reason(s) for starting the project.
PMI defines Business Case as "a way to explain why you want and need to
start your project."
1.1.4 Define project scope
Project Scope - defines what a project is meant to achieve and describes the
deliverables expected. The scope of a project constitutes everything it is
supposed to accomplish in order to be deemed successful to deliver a product,
service, or results.
Project Scope Statement - is a written description of the project scope, major
deliverables, and exclusions. It includes such items as the following:
• Project Description
• Description of Deliverables
• Exclusions
• Constraints
1.1.4 Define project scope
Scope Creep - refers to gradual changes in project scope that occur without a
formal scope change procedure. Scope creep is considered negative since
unapproved changes in scope affect cost and schedule but do not allow
complementary revisions to cost and schedule estimates. In other words,
Scope Creep is "running over budget"!
1.1.5 Define deliverables
Deliverable - is a final product or product component that must be
provided to a client or stakeholder according to contractual stipulations.
1.1.6 Define a milestone and task
Milestones - indicate specific progress points or events in project
timelines. They mark progress needed to complete projects successfully.
For example, if the project is developing a new software solution to
meet a client's need there would be milestones identified in the schedule
to initiate, plan, execute, and close the project.
1.1.7 List components of a project
What are the components of a "project"?
There are five key items needed for all projects using a Waterfall
(linear) Life Cycle Model (Traditional or Predictive).
1. Project Charter/Vision - is a concise document of one to a few
pages. There may also be some attachments, such as a business case
analysis and/or a feasibility study. Two key inputs needed to prepare the
Project Charter are the business need for the project and the project
alignment with the organization's strategic plan. That's why the Project
Charter is one of the five key items needed on all projects; it ensures the
project is creating value for the organization and the project team is not
wasting their time! It includes developing quantitative success criteria
for both the project and product. Project success criteria typically
includes items such as cost, schedule, quality and functionality.
Product success criteria can include items such as achieving specific
planned benefits, user satisfaction and quantitative acceptance criteria.

PMI defines the Project Charter as "a document, issued by the Project
Owner or Sponsor, that formally authorizes the existence of a project and
provides the Project Manager with authority to apply resources to the
project activities."

A Project Sponsor is a person or group who provides resources and

support for the project, program or portfolio for enabling success.
The Project Charter states the objectives of the project, as well as goals,
project team members and responsibilities, stakeholders, milestones,
budgets, risks, and constraints.

2. Project Requirements - a requirement is “a condition or capability

needed by a stakeholder to solve a problem or achieve an objective".
Requirements describe "what" is needed, and the project scope is "how"
the project team will meet the requirements. Requirements are the
foundation upon which the scope and project plan is developed, and if
the requirements are incomplete and/or incorrect the rest of the project
plan by default will also be incorrect.
3. The Work Breakdown Structure (WBS) - defines the project scope in
terms of deliverables. The WBS must define the entire project scope since
it is the key input to other project management planning processes such as
schedule, cost, resources, risk, procurement and quality. The WBS also
provides a baseline for change management and for project status and
progress reports. A poorly constructed or incomplete WBS results in
scope creep, unclear work assignments, schedule dates slippage, and cost
overruns. Be careful of breaking a project into too many WBS levels. A
general guideline for the number of WBS levels is:
 • Small projects (few months duration, ~US$100,000): 3-4 WBS
levels
• Medium projects (6-9 months duration, ~US$500,000): 4-6 WBS
levels
• Large projects (>1 year duration, >$1 million US): 6-9 WBS Levels

Note these are general guidelines and the specific needs of each project
must be considered when deciding how many WBS levels are required
to completely define the project scope.
4. Plan - Once the scope is defined, a plan is needed for successfully
completing the project. At a minimum, the Project Plan document
should include a Schedule and a Resource plan. To create these
documents, simple spreadsheets may be sufficient. A more complex
project may require the use of scheduling software. If the project
requires funding approval, a Budget needs to be prepared. It is
important that all documents supporting the Project Plan are based on
the Work Breakdown Structure (WBS).
5. Communications - are verbal and written exchanges of information
to make requests, reach understanding, make decisions, influence
others, and provide feedback. This starts by identifying all stakeholders
and understanding their project interest. Once this is analyzed, the
communication needs for the project can be determined. This includes
deciding what information to share, who should get specific
information, how to distribute the information, and when to share
information.
1.1.8 List components of a business case
What are the components of a "business case"?
A "business case" is a document written for executive decision makers
that discusses potential outcomes, risks and costs of a project. It
estimates how a project will affect the future value of a business and
justifies the reasoning for starting the project.
A Business Case contains three main elements:
1. Product Scope Description –There is a description of the product, service, or
result that is being proposed to be produced by the project. This answers the
question “What” objective is the project going to create.

2. Business Need –what is the benefit or business value that is going to be

created as a result of the project. This answers the question “Why” is the project
going to create its objective. From the standpoint of the stakeholder who will
receive the benefit of the project.

3. Strategic Plan –what strategic goal or objective that will be achieved by

doing the project? This answers the question “Why” is the project going to
create its objective from the standpoint of the organization doing the project.
The PMI lists the components of a business case using the easy-to-
remember acronym, SARIE.

The SARIE method is based on SWOT analysis, which identifies the

organization's Strengths, Weaknesses, Opportunities, and Threats.
These are each addressed in the Business Case document of a proposed
project.
1.1.9 Define issues, risks, assumptions, and constraints
Issues, Risks, Assumptions, and Constraints
Issues - are anything that can cause problems for a project. The term
refers to major problems that cannot be tackled by the project team on
their own.
Risks - are events that affects the pursuit of objectives. Risks are not
negative by definition. In project management, opportunities are also
considered risks.
Assumptions - are factors deemed to be true during the project planning
process, though proof of their validity is not available. A project’s
assumptions can affect its risks and outcomes, so you must consider
them carefully.
Constraints - are limitations on a project. Among other things,
constraints may be financial or based on time or resource availability. In
traditional project management, there are three primary constraints,
often depicted in a "Triple Constraints Triangle":
• Time (i.e., Schedule)
• Cost (i.e., Budget)
• Scope (i.e., Size)

These three constraints always affect the Quality of a project's

outcomes.
1.1.10 Identify features of traditional plan-based delivery
Project Management with Traditional Plan-based Delivery
Traditional Plan-based delivery uses a Waterfall
Model (linear). The flow of development is
unidirectional, from requirements to design and
then to development, then to testing and
maintenance. Traditional approaches are suited
when requirements are well understood – for
example, in industries like construction, where
everyone clearly understands the final product.
1.1.11 Identify features of agile delivery
Project Management with Agile Delivery
Agile delivery uses an Interactive Model (loop).
Unlike the traditional approach, Agile is
considered more customer friendly because
customers can make changes throughout
project development phases. New software
features can be developed in "mini-projects"
called Sprints. Requirement gathering, design, development and testing
of Sprints can start in parallel, so the entire team can be engaged in their
respective areas which increases productivity and speeds up the
development process.
It is common that this process is repeated several times as adjustments
are made to refine the outcome. This means it is possible Agile delivery
can take longer to complete than Traditional delivery. Agile
methodology is most used with software development.

There are several Agile approaches for software development. Some of

the better-known are Extreme Programming (XP), Scrum, and
Kanban.
1.1.12 Identify project management ethics (refer to PMI code
of ethics)
Project Management Ethics
Ethics is about making the best possible
decisions concerning people, resources and
the environment. When someone's behaviors
are not aligned to acceptable values, they are
said to be "unethical". The PMI has determined
that honesty, responsibility, respect and
fairness are the values that drive ethical
conduct for the project management
profession.
Responsibility - is our duty to take ownership for the decisions we
make or fail to make, the actions we take or fail to take, and the
consequences of that result. For example, if a team member makes a
mistake, it is responsible to bring that mistake to the attention of a Team
Lead or Project Manager as soon as possible before it impacts someone
else.
Respect - is our duty to show a high regard for ourselves, others, and
the resources entrusted to us. Resources entrusted to us may include
people, money, reputation, the safety of others, and natural or
environmental resources. For example, an environment of respect
engenders trust, confidence, and performance excellence by fostering
cooperation—an environment where diverse perspectives and views are
encouraged and valued.
Fairness - is our duty to make decisions and act impartially and
objectively. Our conduct must be free from competing self-interest,
prejudice, and favoritism. For example, if someone asks to have first
choice of assignments it may be best to wait until the next meeting and
discuss assignment choices as a team or distribute the work to the most
qualified.
Honesty - is our duty to understand the truth and act in a truthful
manner both in our communications and in our conduct. For example, if
you think you might miss a deadline it would be your responsibility to
take ownership for those actions within the project and let your Team
Lead or Project Manager know as soon as possible.