19/01/2022 12:56 Exploring Project Management, Then and Now (2021 Update) Transcript

Exploring Project Management, Then and Now

(2021 Update)
The history of business is the history of project management. Just as our ideas of how to conduct business
continue to evolve, so do our conception of the project manager's role, the characteristics of a project, and the
project life cycle itself. Traditional project management had its time and place, but today's landscape calls for
innovation and adaptive leadership.

In this course, you'll explore how project management approaches have evolved to address changing project
environments. You'll learn about the transition from purely empirical, waterfall models of PM to more
adaptive, hybrid, and agile project management techniques. 

Table of Contents
1. Exploring Project Management, Then and Now (2021 Update)
2. History of Project Management
3. Evolution of the Project Manager Role
4. Comparison of Project Life Cycles
5. Characteristics of Traditional and Agile Approaches
6. Agile Characteristics
7. Hybrid Project Management Approaches
8. Triple Constraints of a Project
9. Structure of the PMP Exam
10. Domains, Tasks, and Enablers

Exploring Project Management, Then and Now (2021 Update)

[Video description begins] Topic title: Exploring Project Management, Then and Now (2021 Update). Your
host for the session is Barb Waters, MBA, PMP. [Video description ends]

Projects have been around since the beginning of recorded history. Over time, we have experienced an
evolution of how projects are managed. In this course, you'll learn about the history of project management
and how project management approaches have evolved to address business objectives and deliver value in a
rapidly changing environment.

History of Project Management

[Video description begins] Topic title : History of Project Management. Your host for the session is Barbara
Waters. A brief history of project management. [Video description ends]

Before the profession of project management was defined, there were projects, but they didn't share many of
the standard procedures or techniques that we use in project management today. The pyramids of Egypt were
constructed around 2500 B.C., and even back then there were records. There's an ancient log book on display
at the Egyptian Museum in Cairo and written in hieroglyphics by the person in charge of the 200 person
team. The logbook details several months worth of activities and processes that were followed. Fast forward
to the 19th century where we had a need for processes in construction, manufacturing and transportation.
This led to the concept of project management as we know it today.

Examples include the building of the transcontinental railroad. Its construction was considered to be one of
the greatest American technological feats of the 19th century. While there might not have been scope
management, task boards or resource considerations at the time, there was certainly leadership and there
must have been some structure. Over time, we've established more of a structure and discipline around
https://cdn2.percipio.com/secure/c/1642651850.72cd0603081bc40c0f3476912caf4faaf21bcecb/eot/transcripts/89709afa-3818-4a62-8af8-03213b… 1/8
19/01/2022 12:56 Exploring Project Management, Then and Now (2021 Update) Transcript

project management. The mid 1950s marked the beginning of the modern project management era, where
core engineering fields came together to work as one. Tools and techniques for modeling, estimating and
planning the project schedule and cost became best practices that are still in use today.

Then, in 2001, a group of software developers met and collaborated on an agile approach to project
management. They recognized that in a rapidly changing world, they needed to adapt and welcome change at
any time in their projects. They focused on customer satisfaction through a cycle of frequent product
releases, gathering feedback and quickly adapting. You may have noticed that your own projects are affected
by the rapid speed of change in modern society. Some have called it a constant state of white water, like
navigating a turbulent river. Adaptation is essential. You can't wait for everything to calm down, and you
can't be an observer. You must be an engaged participant in your environment. Planning too far ahead isn't
helpful because you may not know the changes that are coming and how you'll need to respond. Teams may
need to address what's important now and stay ready to pivot at a moment's notice.

Evolution of the Project Manager Role

[Video description begins] Topic title : Evolution of the Project Manager Role. Your host for the session is
Barbara Waters. [Video description ends]

Just as project management approaches have evolved, so has the role of the project manager. Traditionally, a
project manager might have led a team through a directive approach. The manager was focused on the tasks
and the workers were a means to getting things done. Managers weren't necessarily open to hearing their
ideas and left it to the employees to do the heavy lifting.

Today, we have a much different perspective when it comes to management and leadership, and we
recognize them as two different things. Management is focused on tasks. Leadership is focused on people. A
servant leader is there to provide for the team. This includes removing roadblocks that are getting in the way
of the team's productivity and making sure the team has the tools it needs to be successful. Even the title
itself, project manager, may have evolved to something that doesn't include the word manager in the title,
such as team lead, facilitator, scrum master or coach.

Another concept that has evolved is the way we deliver value. [Video description begins] A diagram displays
a Process circle inside a bigger People circle, inside a bigger Business Environment circle, inside an even
bigger Value Delivery Framework circle. [Video description ends]

Imagine an organization that regularly performs projects. The projects reliably deliver a product, service or
result; the goals of the project were met, and the project is considered a success. However, this is no
guarantee that value has been delivered. In fact, there are many cases where the completion of a project and
the delivery of organizational value aren't connected or even tracked. What could cause a project that looks
successful by all measurements to actually fail to deliver value? It could be a number of things, including a
misunderstanding of stakeholder needs, measuring the wrong things or producing a product, service or result
that nobody uses.

We know that the success of a project is based on value and that a product, service or result that a project
creates isn't automatically valuable. So, if the product, service or result from a project is not proof of value,
what is? Value is the result of the processes we follow, the people performing the work and the business
environment that provides context for the project. Organizations must be thoughtful about who determines
value and who has the authority to make decisions or influence the processes. They must also create a
process to verify and validate the benefits to ensure value has been created. Value is determined by the
worth, importance or usefulness that a stakeholder perceives from the results of the project. The tricky thing
is that we all have different opinions of value. It is subjective. It depends on the stakeholders point of view,
and it can change depending on our circumstances and what we need right now.

Comparison of Project Life Cycles

https://cdn2.percipio.com/secure/c/1642651850.72cd0603081bc40c0f3476912caf4faaf21bcecb/eot/transcripts/89709afa-3818-4a62-8af8-03213b… 2/8
19/01/2022 12:56 Exploring Project Management, Then and Now (2021 Update) Transcript

[Video description begins] Topic title : Comparison of Project Life Cycles. Your host for the session is
Barbara Waters. A graph is displayed, with Time on the x-axis, and Cost and Staffing Level on the y-axis.
The different stages are Starting the project, Organizing and preparing, and closing the project. The curve
goes up in the first two stages, then down on the last one. Sub stages are Project charter, Project
management plan, Accepted deliveries, and Archived project documents. [Video description ends]

Project life cycles depend on the project management approach being used. Let's distinguish between the
traditional and agile project life cycles, starting with the traditional approach. Traditional project
management can also be referred to as waterfall, plan driven or predictive. In a traditional project lifecycle,
once the project is chartered, the team spends a significant amount of time creating the plan. Once there is an
agreed upon course of action, execution of the project activities will begin. This is usually when the costs
and staffing levels are at their peak. Toward the end of the project, the customer will accept the deliverables
and then the project can close.

The flow from beginning to end is driven by the plan, and change is considered an exception to the rule.
[Video description begins] An agile graph is displayed, with Time on the x-axis. The stages are Starting the
project, Planning, Carrying out the work, Planning, Carrying out the work, Planning, Carrying out the work,
and Closing the project. The curve goes up on the Carrying out the work stages and down on the Planning
stages. [Video description ends]

Agile project management is characterized by iterations or repeating cycles of planning, execution and
delivery. Each phase of planning is brief and only includes enough information to proceed with a small
increment of work. At the end of each iteration, the project team can demonstrate what they've been working
on, gather feedback, adapt and do it again. The flow from beginning to end is driven by the customer
feedback and change is welcome throughout. The traditional and agile project life cycles are very distinct,
and there's no right or wrong approach. The best approach depends on the type of work being performed.
Sometimes it may be critical to clearly lay out a plan before moving ahead with project work, while in other
situations it may be better to elaborate the plan as we go.

Characteristics of Traditional and Agile Approaches

[Video description begins] Topic title: Characteristics of Traditional and Agile Approaches. Your host for the
session is Barbara Waters. [Video description ends]

When comparing traditional and agile project management approaches, we can use the example of archery,
or using a bow and arrow to try to hit the bull's eye of a target. Using a traditional or predictive approach, we
must plan carefully, treating the arrow as if it's the only one we have. We won't get another chance. We'll
spend a lot of time planning, possibly checking the wind speed, taking careful aim, and finally, when we're
confident that this is the best plan, we will release the arrow. If the arrow misses the bull's eye, we may
consider it a failure. Also, once we agree on the placement of the target, making adjustments would not be
encouraged. Using an agile approach, we won't spend much time planning.

As soon as we release the first arrow, we'll assess the results, learn from it, adapt and try again. We aren't
concerned about using multiple arrows, we're focused on getting it right. Also, if our customer says, "Wait a
minute, I've decided that I would like to move the target. Things have changed and now I would like to move
it over here instead", we will welcome that change and adjust our aim to the new goal. So, which types of
work lend themselves better to traditional and which are better for agile? Let's consider a construction
project. This type of project uses a lot of materials, equipment and supplies, and the final deliverable is a
physical structure.

Once we start building, it becomes difficult to make changes. Usually a change means undoing some of the
work we've already done and possibly wasting materials. That can get expensive and time consuming. So,
construction projects generally require a traditional approach. Now let's consider a knowledge related
project, like creating slides for a new training course. If we develop the first few slides and then the customer
tells us that they would like us to use a different design, no extra money is spent on equipment or supplies.
After another round of developing slides, the customer tells us that they would like us to make a few edits.

https://cdn2.percipio.com/secure/c/1642651850.72cd0603081bc40c0f3476912caf4faaf21bcecb/eot/transcripts/89709afa-3818-4a62-8af8-03213b… 3/8
19/01/2022 12:56 Exploring Project Management, Then and Now (2021 Update) Transcript

Sure, it will take a little time to incorporate the feedback and adapt, but ultimately we'll have a better chance
of hitting the bull's eye and creating exactly what the customer wants, because we've gathered feedback and
made course corrections along the way. Applying what we've discussed in the archery example, we can
observe the characteristics of the phases in a traditional project and in an agile project. In traditional projects,
the phases of a project proceed in a linear, forward direction. This is also known as waterfall. It's plan driven
and the phases are separated by handoffs from one to the next. You cannot begin one phase until the previous
phase is completed. This is a great approach for well-known products when the scope is well defined and you
can predict the project outcome. You already know what you're creating because it's familiar and similar to
projects that you or others have performed before.

In agile projects, the phases of a project proceed in an overlapping manner, characterized by feedback loops.
We perform the smallest possible increment of work, gather feedback, and if necessary we may iterate or
repeat that increment until we get it right. We are able to adapt as we go, and the scope of our product may
evolve through modifications along the way. Agile is also characterized by empiricism, which means that the
performance is based on facts and evidence. We can assess progress and acceptance of each product
increment by demonstrating the product increment and placing it in the customer's hands. Agile is a great
approach for products where the scope isn't well defined. We may have a vision for what we want, but we
haven't defined exactly how the product will look, feel and function yet. We're making those decisions as we
go.

Agile Characteristics
[Video description begins] Topic title: Agile Characteristics. Your host for the session is Barbara
Waters. Characteristics of project life cycles. [Video description ends]

The project management, methodology you choose for your project will often determine the structure of its
phases. You may choose a methodology that has a traditional approach. In this type of lifecycle, the scope is
well-known in advance. The activities for the project are performed once for the entire project. Ideally,
there's no repeated work. One phase is fully completed before the next phase starts. The product is delivered
once at the end of the project, almost like a "ta dah" moment, because the customer hasn't sampled
increments of the product yet and the ultimate goal is to manage the schedule and the budget.

Another methodology is the iterative approach. In this type of lifecycle, the scope is not well-known in
advance - it evolves as the project progresses. The activities for the project are iterated until the deliverable is
correct. Rework is expected. Like a traditional project, the product is delivered once at the end. The ultimate
goal of an iterative approach is the correctness of the deliverable. In the incremental approach, the scope is
not well-known in advance. Like the iterative approach, it evolves as the project progresses. The activities
for the project are performed once for each increment. The product is delivered incrementally and frequently
throughout the project. The ultimate goal of an incremental approach is the speed of delivery.

The agile approach combines characteristics of both the iterative and incremental approaches. The scope
evolves as the project progresses. The activities for the project are iterated until the deliverable is correct.
The product is delivered incrementally and frequently throughout the project, and the ultimate goal of the
agile approach is customer satisfaction through frequent delivery and customer feedback. We've said that one
of the characteristics of agile project management is that it's incremental, but what does that mean? You're
building the pieces of your final product bit by bit. In the first increment, you might initially build the
minimum features that are required for your products, such as log-in functionality.

Then, once you've tested that functionality, in the next increment of work you may build more robustness
into that feature. So you're incrementally adding different features to your end product and adding robustness
to the features that already exist. Agile approaches are additionally characterized as iterative. So not only are
you building the pieces of your final product incrementally over time, you're also doing the work within
defined time boxes of just a few weeks at a time. An iterative approach gives the team an opportunity to
make changes and to add or reprioritize features as product development proceeds.

[Video description begins] Agile characteristic: incremental. Four diagrams show the same five steps:
Requirements, Design, Development, Testing, and Delivery. [Video description ends]

https://cdn2.percipio.com/secure/c/1642651850.72cd0603081bc40c0f3476912caf4faaf21bcecb/eot/transcripts/89709afa-3818-4a62-8af8-03213b… 4/8
19/01/2022 12:56 Exploring Project Management, Then and Now (2021 Update) Transcript

So we've discussed in length how agile is both iterative and incremental. There's another feature of agile
though, which is empiricism. To explain empiricism, let's use an example. Do you like spicy food? I thought
I did, but now I'm not so sure. I've met plenty of people who can tolerate much more spice in their food than
I can. You might be wondering what this has to do with empiricism. Actually, a lot. How spicy you prefer
your food is a matter of opinion. We are all individuals and that means there is a lot of subjectivity when we
evaluate what we like or don't like. This complicates things for an agile team working to understand and
meet a customer's needs.

So let's get back to the definition of empiricism. Empiricism is a fact-based, evidence-based approach that
removes subjectivity from a process. This can be applied to product development or any situation where
we're trying to be fact-based versus opinion-based. For instance, in 1912, Wilbur Scoville developed the
Scoville scale, which measures the heat units of different types of chili peppers. This is an example of
empiricism. An agile team can embrace empiricism by creating an objective definition of done that clearly
outlines the checklist of items that can be evaluated objectively with a simple Yes or No, or along a scale of
acceptable results.

Hybrid Project Management Approaches

[Video description begins] Topic title: Hybrid Project Management Approaches. Your host for the session is
Barbara Waters. [Video description ends]

With some projects, the work may not lend itself to a traditional approach or a purely agile approach. In these
cases, a hybrid approach may be the best solution. We'll explore four examples of traditional agile hybrids.
The first example in the upper left is a parallel use of traditional and agile methods. Within a single
organization, different functional groups or departments often have their own way of performing work. Some
departments always use traditional methods, while others always use agile methods.

For instance, in a project to create a new benefits enrollment user interface, the Human Resources
Department may use a traditional approach, while the software development team uses agile methodologies.
Both teams make vital contributions to the deliverable, but the development life cycles could look very
different. Let's explore a case study of this parallel use of both traditional and agile methods. In this project, a
cell phone company had a new customer billing project. It's a multi-year project designed to replace its aging
billing system with a new user interface and system integrations.

The project used an agile approach with continual input from the business. Since taxes vary by region and
can change at various times, the tax tables had to be retrieved, encoded by a separate team. Both teams
collaborated on the input variables required for the calculation, and how to consume and display the output
values. But beyond that, the tax team worked in a largely predictive manner. When the tax team's portion was
complete, the outputs from the tax calculations were available to display on the user screens and in reports.
Then, the business users provided feedback on that appearance and use of the information. These teams
basically worked on two subprojects and interacted as needed to bring the information together for the
customer.

The next example in the upper right, we'll explore an example of agile development, followed by a
traditional rollout. In this case study, we'll explore a hybrid lifecycle project used by a candy manufacturer.
The candy company was developing a new flavor and used agile methodologies. However, it was required to
work with a government agencies such as the Food and Drug Administration in order to demonstrate
compliance with regulations and receive approvals. The government agency utilized traditional project
management methodology. The candy company utilized agile methodology when performing taste tests. This
would be ideal because the agile methodology allows teams to develop and learn incrementally and to make
changes as necessary to reach the best level of customer satisfaction.

Based on customer feedback, the candy company made slight changes in ingredients and product packaging
features. The more rapidly the development team could implement these changes, the faster they would
receive valuable feedback from the customers. The customer taste tests included levels of uncertainty, and
the results and data led them to change their formula frequently until they got closer to what would please the
https://cdn2.percipio.com/secure/c/1642651850.72cd0603081bc40c0f3476912caf4faaf21bcecb/eot/transcripts/89709afa-3818-4a62-8af8-03213b… 5/8
19/01/2022 12:56 Exploring Project Management, Then and Now (2021 Update) Transcript

greatest number of consumers. During this development phase, an agile approach was ideal. When it was
time to roll out the new product, because of regulations the product needed to shift to traditional project
management.

Before selling the new candy, the company had to submit information to a regulatory authority providing
information such as ingredients, nutritional information and allergy information. This is a more traditional
process. A hybrid approach allowed the candy company to carry on with their agile methodology while
successfully integrating their deliverable with the traditional regulatory approval process. New high tech
products may also lend themselves to this hybrid approach, particularly if the rollout affects thousands of
users who need to learn how to use the product. So a high tech development team may come up with a new
concept that customers will love, but only after they learn what it's all about.

The customer marketing and communication may need to mirror that of a traditional project. The bottom left
example shows a small agile element within a traditional project. There is a portion of the project that has an
amount of uncertainty, complexity or risk of scope creep. Handling this portion in an agile way will help to
shield the remainder of the project. In this example, we have a manufacturer who is using a new component
or raw material and would like to roll out the deliverable on a trial basis. This allows the manufacturer to
experiment with a few different installation and production methods in order to identify defects and correct
them incrementally through iterative processes.

The manufacturer can adapt the best raw material, production and installation methods earlier in the project
and reduce the need for rework. In the bottom right example, we have a development team using primarily
agile practices, but there is an element of traditional project management thrown in. This may be appropriate
when working with an external vendor or partner who is unable or possibly unwilling to take an agile
approach. There is one single delivery at the end of the project because of this. Sometimes your project team
may need to explore hybrid approaches to best align with the type of project work you're performing.

Triple Constraints of a Project

[Video description begins] Topic title: Triple Constraints of a Project. Your host for the session is Barbara
Waters. [Video description ends]

In traditional project management, a great deal of time is spent creating the scope and committing to a scope
baseline for the project. The project scope is then used to estimate the time and cost, which can also be called
the schedule and the budget. During planning, there may be a need to modify the scope to meet constraints
with time and cost. But once there is a cohesive plan and the scope, time and cost all agree, the project
management plan will be approved and the project can begin. These three baselines are also known as the
triple constraints of a project. Just like the sides of a triangle, if one of the sides changes, then one or both of
the other sides will have to change.

For instance, let's say the executive team approaches you mid project and tells you that your budget will be
cut. It follows that you may need to de-scope or remove features from the deliverable. Likewise, if you're
told that your deadline is being moved up and you need to finish sooner, you'll likely need to spend more
money on resources in order to make that happen. The triple constraints of a project interact much differently
in an agile project. Since the scope isn't well-defined and must evolve as the project progresses, then the
scope cannot be the driving force. Instead, the project team will work closely with the customer to establish a
budget that is available for the next iteration of work.

For instance, perhaps there's a fifteen thousand dollar budget for the next two weeks of product development.
Based on this budget, the team can determine how many features or what the new functionality from the
scope can realistically be developed. I can tell you from experience that this agile model can be a source of
discomfort for those who are new to agile.

A common question is, are you saying that you want the customer to commit to pay money when they don't
know what they're getting? Not exactly. The team and the customer will work closely and they'll agree upon
what features or functionality will be developed in the next few weeks. In that short period of time, the
customer will have a product increment that can be demonstrated and is usable. Then, based on feedback, the
https://cdn2.percipio.com/secure/c/1642651850.72cd0603081bc40c0f3476912caf4faaf21bcecb/eot/transcripts/89709afa-3818-4a62-8af8-03213b… 6/8
19/01/2022 12:56 Exploring Project Management, Then and Now (2021 Update) Transcript

team and the customer will agree together what the next iteration and its associated budget will be used for.
The relationship between the development team and the customer is close and collaborative. Although the
scope doesn't drive the project, it is definitely negotiated and revisited frequently throughout the project, and
it's allowed to evolve to best meet the customer's needs.

Structure of the PMP Exam

[Video description begins] Topic title: Structure of the PMP Exam. Your host for the session is Barbara
Waters. [Video description ends] [Video description begins] Exam preparation. [Video description ends]
Now we'll turn our focus to the PMP exam and information about this credential. You can find all of this
information by visiting the Project Management Institute's website at pmi.org. PMP stands for Project
Management Professional. The PMP is designed for experienced project managers. Let's discuss the
prerequisites.

If you have a bachelor's degree or the global equivalent, you'll need to have 36 months managing projects in
the last eight years, and 35 hours of project management education, which you'll receive from this course. If
you don't have a bachelor's degree, a high school diploma is also fine. You'll just need to offset it with more
project management experience. You'll need 60 months managing projects and again, the 35 hours of project
management education that you'll receive from this course. You can register at pmi.org and start your
application process while also beginning this training. While you're on the PMI website, it's recommended
that you also download the exam content outline and the PMP handbook.

These are great resources for any candidate and it would be worthwhile to review both of them. The Project
Management Institute recommends a reference list with 10 titles for PMP candidates. However, PMI states
that it should be noted that the references identified are one element [Video description begins] The titles are:
Agile Practice Guide, by Project Management Institute. A Guide to the Project Management Body of
Knowledge (PMBOK Guide) by Project Management Institute.

Project Management: A Systems Approach to Planning, Scheduling and Controlling, by Harold Kerzner.
Effective Project Management: Traditional, Agile, Extreme, Hybrid, by Robert K Wysocki. Fundamentals of
Technology Project Management, 2nd edition, by Colleen Garton, with Erika McCulloch. Project Managers
Portable Handbook, 3rd edition, by David Cleland and Lewis Ireland. Information Technology Project
Management, 7th edition, by Kathy Schwalbe. Essential Scrum: A Practical Guide to the Most Popular Agile
Process, by Kenneth S Rubin. Project Management: The Managerial Process, by Erik Larson. And The
Project Management Tool Kit: 100 Tips and Techniques for Getting the job Done Right, by Tom Kendrick.
[Video description ends] of a broader set of educational resources and texts that might possibly be testable
content on the exam.

So even these 10 titles are not guaranteed to contain all of the information you need to know. Before you
purchase and read all 10 of these titles or search for exam related content, it may be helpful to know that this
course will compile all of the information in one place. I would recommend that you have your own copy of
the latest version of The PMBOK Guide, which is also known as the Project Management Body of
Knowledge. If you decide to join PMI and become a member, an electronic version of the PMBOK Guide is
generally included with your membership.

One misunderstanding about the PMBOK Guide is that the exam is based on this publication, but that is not
really accurate. New versions of the PMBOK Guide do not automatically mean that the exam will be
updated. As we move from the PMBOK 6th edition to the 7th edition, don't worry too much about the impact
it may have on the exam. The exam content outline and handbook from the previous slide will guide you, as
will this course. Here is an example of the type of information you can find in the PMP exam content outline.
There are three high level knowledge areas called domains that make up the 180 questions on the exam. 42%
of the questions come from the People domain, 50% from the Process domain and 8% from the Business
Environment domain. The 180 questions that one candidate receives will likely be different from another
candidate's questions.

PMI maintains a large bank of questions, and they're randomize for each candidate. Also, a certain number of
questions are considered experimental and will not count. PMI does not communicate a passing score for the
https://cdn2.percipio.com/secure/c/1642651850.72cd0603081bc40c0f3476912caf4faaf21bcecb/eot/transcripts/89709afa-3818-4a62-8af8-03213b… 7/8
19/01/2022 12:56 Exploring Project Management, Then and Now (2021 Update) Transcript

exam or how many questions you must get correct in order to pass. Instead, participants will pass if they
achieve a score that is considered target or above target. This is a recommended road map that you can
follow when taking this course. We are at the intro bootcamp right now, and from here you can follow the
remaining courses in order on your learning platform. We'll walk through the domains one by one, and you'll
notice that the process domain includes some extra curriculum, very focused on the tools and techniques
from traditional project management and then agile project management. So that content will be split by the
project management approach. [Video description begins] Course flow. [Video description ends] Then we'll
come back together with a bootcamp style deep dive into the most complex content.

Domains, Tasks, and Enablers

[Video description begins] Topic title: Domains, Tasks, and Enablers. Your host for the session is Barbara
Waters. [Video description ends]

I've mentioned that there are three domains in the PMP curriculum: People, Processes and Business
Environment. Next we'll introduce tasks and enablers. A task is an underlying responsibility that the project
manager may have within the domain. In this example, one of the tasks within the process domain is to
assess and manage risks. No matter what type of project you're performing or what type of approach you're
using, every project manager should make it a point to assess and manage risks. But how exactly do you do
that? That's where the enablers come in. An enabler is an example of the work associated with a task. So if
you have the task or underlying responsibility to assess and manage risks, one type of work you might
perform is to determine your risk management options. Now that we've discussed domains, tasks and
enablers, and the purpose of each, we'll explore the process domain as an example.

In the process domain, there are nearly 20 tasks that a project manager may need to perform. [Video
description begins] The list of tasks for the Process domain is: Execute project with the urgency required to
deliver business value. Manage communications. Assess and manage risks. Engage stakeholders. Plan and
manage budget and resources. Plan and manage schedule. Plan and manage quality of
products/deliverables. Plan and manage scope. Integrate project planning activities. Manage project
changes. Plan and manage procurement. Manage project artifacts. Determine appropriate project
methodology/methods and practices. Establish project governance structure. Manage project issues. Ensure
knowledge transfer for project continuity. Plan and manage project/phase closure or transitions. [Video
description ends]

The people domain and business environment domain will each have tasks of their own. During this course,
this will be incorporated into the curriculum. Sometimes we'll take a deep dive, and in other tasks we won't
spend much time at all, depending on how complex the topic is. We know that you may need more help
when it comes to formulas and new concepts, so we'll make the best use of our time. So, back to the tasks.
Let's choose one from this list: Assess and manage risks. What comes next? When performing the task assess
and manage risks, the project manager may use two different enablers. One is to determine risk management
options and the other is to iteratively assess and prioritize risks. Once we have decomposed this domain
down to an enabler, there's even one more level, and that is the tools and deliverables.

An example of a tool may be an organizational process asset. We sometimes call these OPAs. You'll learn
that this can include any documents or lessons learned that belong to your organization. This can include
invoices, old emails, calendars or anything you may have created in a previous project that can help you with
this project. Throughout this course, we may also refer to the tools as tools and techniques. Deliverables
usually include tangible items that we've created during this project. For instance, when assessing and
prioritizing risks, we may create and use a risk register. Throughout this course, we may also refer to the
deliverables as documents or even outputs. Now that you've had your intro and orientation to this course, you
can continue your journey on your learning platform. I'll check in with you periodically and take deeper
dives into the most testable content.

https://cdn2.percipio.com/secure/c/1642651850.72cd0603081bc40c0f3476912caf4faaf21bcecb/eot/transcripts/89709afa-3818-4a62-8af8-03213b… 8/8