Note: This article is based on and an update of Tom Mochal’s
article, Mini-glossary: Project management terms you should know.
Every
discipline has its own vocabulary, and project management is no exception. Part
of the process of successfully deploying project management in your
organization is to standardize the terminology. That way, when one person talks
about risks, scope, issues, requirements, and other project management
concerns, everyone else knows what he or she is referring to. This glossary
contains common terms used in project management and can help start the
standardization process in your organization.
Assumption
There
may be external circumstances or events that must occur for the project to be
successful (or that should happen to increase your chances of success). If you
believe that the probability of the event occurring is acceptable, you could
list it as an assumption. An assumption has a probability between 0 and 100%; that
is, it is not impossible that the event will occur (0%), and it is not a fact
(100%) — it is somewhere in between. Assumptions are important because they
set the context in which the entire remainder of the project is defined. If an
assumption doesn’t come through, the estimate and the rest of the project
definition may no longer be valid.
Client / customers
The
person or group that is the direct beneficiary of a project or service is the
client / customer. These are the people for whom the project is being
undertaken (indirect beneficiaries are stakeholders). In many organizations,
internal beneficiaries are called “clients” and external beneficiaries
are called “customers,” but this is not a hard and fast rule.
Constraints
Constraints
are limitations that are outside the control of the project team and need to be
managed around. They are not necessarily problems. However, the project manager
should be aware of constraints because they represent limitations that the
project must execute within. Date constraints, for instance, imply that certain
events (perhaps the end of the project) must occur by certain dates. Resources
are almost always a constraint, since they are not available in an unlimited
supply.
Cost variance
The cost variance (CV) is used to measure the cost difference
between a project’s earned value (EV) and the actual cost (AC) to deliver
progress to date (CV = EV – AC). In application, positive CVs indicate the
project is under budget, since it is delivering more value than incurring cost.
If the project has a negative CV, it is over budget. Even positive CVs should
be examined for root cause.
Critical path
The
critical path is the sequence of activities that must be completed on schedule
for the entire project to be completed on schedule. It is the longest duration
path through the workplan. If an activity on the critical path is delayed by
one day, the entire project will be delayed by one day (unless another activity
on the critical path can be accelerated by one day). (Read: Why critical path is critical to project management)
Deliverable
A
deliverable is any tangible outcome that is produced by the project. All
projects create deliverables, which can be documents, plans, computer systems,
buildings, aircraft, etc. Internal deliverables are produced as a consequence
of executing the project and are usually needed only by the project team. External
deliverables are created for clients and stakeholders. Your project may create
one or many deliverables.
Earned value
Earned value (EV) is an EV management term used to determine
the total work completed at a specific point in time. A project’s EV is determined
by adding up all the budgeted costs for every task in the project schedule. The
actual EV calculation can use a variety of calculation methods, including
0-100%, 50-50%, or an actual percentage to determine a task’s credited value.
Functional manager
The
functional manager is the person you report to within your functional
organization. Typically, this is the person who does your performance review.
The project manager may also be a functional manager, but he or she does not
have to be. If your project manager is different from your functional manager,
your organization is probably utilizing matrix management.
Gantt chart
A
Gantt chart is a bar chart that depicts activities as blocks over time. The
beginning and end of the block correspond to the beginning and end-date of the
activity.
Issue
An
issue is a major problem that will impede the project’s progress and that can’t
be resolved by the project manager and project team without outside help.
Project managers should proactively deal with issues through a defined issues
management process.
Lifecycle
Lifecycle
refers to the process used to build the deliverables produced by the project.
There are many models for a project lifecycle. For software development, the
entire lifecycle might consist of planning, analysis, design, construct/test,
implementation, and support; this is an example of a “waterfall”
lifecycle. Other lifecycles include iterative development, package
implementation, and research and development. Each of these lifecycle models
represents an approach to building on your project’s deliverables. (Read: Project managers need to understand lifecycle work)
Milestone
A
milestone is a scheduling event that signifies the completion of a major
deliverable or a set of related deliverables. A milestone, by definition, has
duration of zero and no effort. There is no work associated with a milestone.
It is a flag in the workplan to signify that some other work has completed. Usually,
a milestone is used as a project checkpoint to validate how the project is
progressing. In many cases there is a decision, such as validating that the
project is ready to proceed, that needs to be made at a milestone.
Objective
An
objective is a concrete statement that describes what the project is trying to
achieve. The objective should be written at a low level, so that it can be
evaluated at the conclusion of a project to see whether it was achieved.
Project success is determined based on whether the project objectives were
achieved. A technique for writing an objective is to make sure it is Specific, Measurable, Attainable/Achievable,
Realistic, and Timebound (SMART).
Program
A
program is the umbrella structure established to manage a series of related
projects. The program does not produce any project deliverables — the project
teams produce them all. The purpose of the program is to provide overall
direction and guidance, to make sure the related projects are communicating
effectively, to provide a central point of contact and focus for the client and
the project teams, and to determine how individual projects should be defined
to ensure that all the work gets completed successfully.
Program manager
A
program manager is the person with the authority to manage a program. (Note
that this is a role. The program manager may also be responsible for one or
more of the projects within the program.) The program manager leads the overall
planning and management of the program. All project managers within the program
report to the program manager.
Project
A
project is a temporary structure to organize and manage work and ultimately to
build a specific defined deliverable or set of deliverables. By definition, all
projects are unique, which is one reason it is difficult to compare different
projects to one another.
Project baseline
The project baseline is used to establish the original set of
budget and schedule estimates based on the approved project scope prior to
project execution. Effective project managers compare the project baseline to
the current project status to determine specific cost or schedule variances.
Project definition (charter)
Before
you start a project, it is important to know the overall objectives of the
project, as well as the scope, deliverables, risks, assumptions, project
organization chart, etc. The project definition (or charter) is the document
that holds this relevant information. The project manager is responsible for
creating the project definition. The document should be approved by the sponsor
to signify that the project manager and the sponsor are in agreement on these
important aspects of the project.
Project
Management Office
The Project
Management Office (PMO) is an organization within a company that develops and
enforces project management processes, tools, and techniques. A PMO may
form at a program level, a department level, or at an enterprise level. A
PMO typically provides support for program or portfolio governance, project
portfolio management, resource management, and issue and risk management.
Project manager
The
project manager is the person with the authority to manage a project. The
project manager is 100% responsible for the processes used to manage the
project. He or she also has people management responsibilities for team
members, although this is shared with the team member’s functional manager. The
processes used to manage the project include defining the work, building the
workplan and budget, managing the workplan and budget, scope management, issues
management, risk management, etc.
Project phase
A
phase is a major logical grouping of work on a project. It also represents the
completion of a major deliverable or set of related deliverables. On an IT
development project, logical phases might be planning, analysis, design,
construct (including testing), and implementation.
Project plan
The project plan (not to be confused with the project schedule)
is the document that describes the processes, tools, and techniques used to
manage and control the project. Common processes include specific project level
processes such as change management, issue management, risk management,
document management, and time management for project schedule updates.
Project schedule / work
schedule
The project schedule is commonly associated with Microsoft Project or a
similar scheduling tool. The project
schedule is the series of tasks with durations, resources, and specific
dependencies that forecasts the project end date.
Project team
The
project team consists of the full-time and part-time resources assigned to work
on the deliverables of the project. They are responsible for understanding the
work to be completed; completing assigned work within the budget, timeline, and
quality expectations; informing the project manager of issues, scope changes,
and risk and quality concerns; and proactively communicating status and
managing expectations.
Request for proposal
The request for proposal (RFP) is a formal request used by organizations to identify potential
solutions and services from a list of vendors. Based on the RFP, the
organization will identify a smaller list of vendors to issue a request for
quotation. (Read: Five tips to a better Request for Proposal)
Request for quotation
A request for quotation is a formal request for a vendor to
provide actual costs for a specific service or scope of work. The client
typically provides a vendor with a set of requirements and instructions on how
to respond to the request. The vendor provides its response, including details
about the solution, assumptions, and pricing.
Requirements
Requirements
are descriptions of how a product or service should act, appear, or perform.
Requirements generally refer to the features and functions of the deliverables
you are building on your project. Requirements are considered to be a part of
project scope. High-level scope is defined in your project definition
(charter). The requirements form the detailed scope. After your requirements
are approved, they can be changed through the scope change management process.
Risk
There
may be potential external events that will have a negative impact on your
project if they occur. Risk refers to the combination of the probability the
event will occur and the impact on the project if the event occurs. If the
combination of the probability of the occurrence and the impact to the project
is too high, you should identify the potential event as a risk and put a
proactive plan in place to manage the risk.
Schedule variance
The schedule variance (SV) is an EV management term used to
measure the project’s schedule performance by comparing the project’s EV to the
project baselined planned value (PV). The formula is SV = EV – PV. A positive SV
indicates the project is ahead of schedule, while a negative SV indicates the
project is behind schedule.
Scope
Scope
is the way you describe the boundaries of the project; it defines what the
project will deliver and what it will not deliver. High-level scope is set in
your project definition (charter) and includes all of your deliverables and the
boundaries of your project. The detailed scope is identified through your business
requirements. Any changes to your project deliverables, boundaries, or
requirements would require approval through scope change management.
Scope change management
The
purpose of scope change management is to manage change that occurs to
previously approved scope statements and requirements. Scope is defined and
approved in the scope section of the project definition (charter) and the more
detailed business requirements. If the scope or the business requirements
change during the project (and usually this means the client wants additional
items), the estimates for cost, effort, and duration may no longer be valid. If
the sponsor agrees to include the new work in the project scope, the project
manager has the right to expect that the current budget and deadline will be
modified (usually increased) to reflect this additional work. This new
estimated cost, effort, and duration become the approved target.
Sometimes
the project manager thinks that scope management means having to tell the
client “no.” That makes the project manager nervous and
uncomfortable. However, the good news is that managing scope is all about
getting the sponsor to make the
decisions that will result in changes to project scope. (Read: Learn the secret of effective scope change management)
Sponsor (executive sponsor and project sponsor)
The
sponsor is the person who has ultimate authority over the project. The
executive sponsor provides project funding, resolves issues and scope changes,
approves major deliverables, and provides high-level direction. He or she also
champions the project within the organization. Depending on the project and the
organizational level of the executive sponsor, he or she may delegate
day-to-day tactical management to a project sponsor. If assigned, the project
sponsor represents the executive sponsor on a day-to-day basis and makes most
of the decisions requiring sponsor approval. If the decision is large enough,
the project sponsor will take it to the executive sponsor.
Stakeholder
Specific
people or groups who have a stake in the outcome of the project are
stakeholders. Normally stakeholders are from within the company and may include
internal clients, management, employees, administrators, etc. A project can
also have external stakeholders, including suppliers, investors, community
groups, and government organizations.
Steering committee
A
steering committee is usually a group of high-level stakeholders who are
responsible for providing guidance on overall strategic direction. They don’t
take the place of a sponsor but help spread the strategic input and buy-in to a
larger portion of the organization. The steering committee is especially
valuable if your project has an impact in multiple organizations because it
allows input from those organizations into decisions that affect them.
Waterfall
methodology
A waterfall
methodology is a predictive life cycle methodology with sequential phases,
which include Analysis, Design, Development, Testing, and Deployment.
Predictive methodologies work well when the requirements and design are well
defined, as found in the construction or manufacturing processes. For
software projects, an agile methodology is recommended despite the abundance of
waterfall methodologies found across industries.
Work breakdown structure
The work breakdown structure (WBS) is a list of major
deliverables that the project team will complete during the project. The WBS is
organized in a hierarchy and is typically decomposed into several sub-levels. A
WBS can be used to visually define the project into smaller chunks, so the team
can better understand and plan the activities needed to complete the
deliverables. Diagramming tools
such as Microsoft Visio
or mind mapping tools such as Mindjet
or MindGenius
can be used to build a visual WBS. (Read: Five tips for building a work breakdown structure)
Workplan (schedule)
The
project workplan tells you how you will complete the project. It describes the
activities required, the sequence of the work, who is assigned to the work, an
estimate of how much effort is required, when the work is due, and other
information of interest to the project manager. The workplan allows the project
manager to identify the work required to complete the project and also allows
the project manager to monitor the work to determine whether the project is on
schedule.
Agile project management terminology
Agile
methodology
An agile
methodology is an adaptive systems development lifecycle methodology that
delivers software in incremental chunks known as iterations or sprints. In
agile development, time is fixed, and scope is allowed to float from one
iteration to another based on the team’s user story progress. An agile
methodology is best used when requirements are not well defined. (Read: Five agile project management migration tips)
Burn down chart
A burn down chart is a graphical view of the remaining work
left versus the time in an iteration.
A project backlog or hours can be expressed on the vertical axis, while
time is indicated on the horizontal axis. A burn down chart is often used to
determine when work will be completed on a project or an iteration.
Epic
An epic is a set of related user stories. They are also
considered a “really big user story.”
Iteration
An iteration is an iterative development concept that
establishes a short time frame to deliver a set of software features or user
stories. Each iteration includes typical waterfall activities such as analysis,
design, development, and testing, yet they are time boxed within a one to four
week window. At the end of an iteration, the progress is reviewed with the
business customer, and recommended changes can be incorporated into future
iterations.
Planning Poker
Planning Poker
is an estimation game created by Mike Cohn of Mountain Goat Software. Planning
Poker is used to estimate individual user stories as a team activity. The
team gathers and reviews user stories one at a time. As stories are presented,
the team discusses the user story and provides an estimate of the work from
their own deck of cards. All estimates are presented and discussed until the
team arrives at a consensus.
Release
A release is a set of working software delivered to the
business customer resulting from a set of iterations. During release planning,
teams will review a product backlog to organize user stories into the specific
releases and iterations that deliver a functional product to the business
customer.
Scrum
Scrum is an iterative development methodology used to manage software
projects. In scrum-based projects, there isn’t a specific project manager
directing project team tasks; the team is self-directed, with co-located team
members relying on communication over documentation for effective project
delivery. (Read: Get an overview of the Scrum agile project approach)
Sprint
A sprint is a scrum-based agile methodology concept that is
similar to an iteration. A sprint is time boxed to deliver a specific set of
user stories and produce working features within a set time period. During
sprint planning, the business customer or product owner specifies the user
story priority, and the development team commits to the scope for a given
sprint. During a sprint, user stories can be removed from the sprint scope, but
new stories cannot be added; this allows project teams to focus on the goals of
the sprint and deliver rapidly.
Story points
A story point is a relative estimation method used to determine
the size of user stories so teams can determine how much work can be done
during an iteration. Story points can be expressed in a simple Fibonacci sequence,
t-shirt sizes, or a relative number. By adding up the number of user stories
and associated story points, the project team can establish its velocity for
future iteration planning.
User story
A user story is an agile version of a project requirement. A
user story is comprised of a couple of sentences that defines who, what, and
why for a given requirement and can be documented on index cards or sticky
notes. User stories are written by the business user to communicate the
software need or want. User
stories are intended to be concise, as communication between the business and
development team is used to elaborate the user story and develop working
software. Example from Mike Cohn: “As a <role>, I want <goal/desire>”.
(Read: User stories: The starting point in agile development)
