Section 05: Project Management Principles

Introduction to PM Principles
A principle is something that will serve as a foundational guideline. A guideline is something that
you don't necessarily have to follow. It's best practices you follow these principles, but you don't
have to. So it's going to be something that's a foundational guideline that's going to tell us how
we can strategize, what's the strategy for managing this project? These principles would also tell us
how to make decisions, or would impact the way we make decisions, and how we go about solving
problems, or problem-solving. So these principles are going to be really important throughout the
entire project from the way we schedule it, to develop that budget, to creating that scope
statement, to managing that quality, to engage in that stakeholder. These principles are your
foundational methods of doing things. Now, professional standards, methodologies, are often
based on these principles too. All the project management methods that are out there are going
to be based basically on these generic principles. Now, principles or project management provide
guidance for the behavior of the people involved in the project. People involved in the project, all
the stakeholders, from the project manager, to the project team, to the project sponsor, to the
Agile coach. All of the people involved in these projects, these principles will guide them to
ensuring the project is successful. Now, what do I mean by that? Well, think about this. If I told you
that one of the principles is to be caring, to have integrity, to be honest, to focus on value. If I told
you those are some of the principles, would you say, "Hey, we should be doing that all the time."
Correct, everyone should do that on a project. What if I was to tell you one of the principles is to
engage your stakeholders? Well, at all times, you should be doing that. Stakeholders, customers,
your sponsors, should be engaged in your project throughout the project. What if I was to tell you,
you have to treat your team correctly and build an environment so the team likes working in.
Would you say you should be doing that all the time? Of course. Our team should have an
environment that they're comfortable working in. Those are some of the principles that just went
over. Now, there are 12 of these principles, like I mentioned. You're going to want to make sure
that you're familiarize yourself with them. I don't think you need to memorize them, let's get that
right off the bat. I don't think PMI is going to be like, "So, what principle is this?" No, but they are
things you should keep in mind. They're going to probably impact the way you answer the
question. So, make sure to keep these principles in mind as you go through them. Now, I do want
to mention that these principles, maybe I said this a few minutes ago, these principles are pretty
much things that you're doing already. If you're a successful project manager right now, you're
probably following these principles. So you're going to look at them and say, "Hey, none of that is
new, I know those things already." And I'm pretty sure if you're going to say that to yourself, this
section shouldn't be too difficult.

PMI Code of Ethics & Professional Conduct

In this video, I'm going to be talking about the PMI code of ethics and professional conduct. Now,
before we get into principals and review of these 12 principles with you, I want to talk about just
really quickly on the code of ethics and conduct. Now, one thing we do want to understand is
principles can and do not necessarily reflect morals. Morals is going to be reflected right here. So
these principles could reflect these particular morals that PMI says we should have. It's not just that
PMI says we should have these things. We should just naturally have these things. Like me telling
you guys, hey, you should be honest, is not something shouldn't be something new to you. So a
code of ethics is related to morals. And that's what I just want to mention here and get this out of
1
 Section 05: Project Management Principles

the way before we get into those principles. So a code of ethics for profession can be adapted by
an individual or profession to establish expectations for moral conduct. So people should be doing
these things in order to have good expectations. When someone is managing a project for you,
you already expect them to have these things. For example, if you're in charge of an organization,
you're going to expect that your project manager, to be honest, to be fair, to respect the
stakeholders and be responsible for the work that they're doing. Isn't that so? And that's what
these professional code of ethics, professional conduct is. It's about when you're managing a
project, PMI says you're going to you should have these four values at all times. Number one, you
should be a responsible person. You know, when it comes to taking on responsibility, that's the
name of the project manager. We take on the weight of the project onto our shoulders. People on
the project depend on us to ensure that all the work is coordinated, all the communication is done
right, and all the stakeholders are happy to customers, sponsors, team members. So we're going to
have to act in a responsible manner. Respect, if there's one thing we're going to be doing on a
project, is talking and managing a whole lot of people. And because of that, we're going to want
to make sure we respect everyone on our project. We're going to give respect and hopefully we
get it back from our stakeholders. Always be respectful fairness. Always act in fairness to your team
members, to your stakeholders, to your customers, to your sponsors. Always do the right thing, but
always do the fair thing to everyone. And lastly, honesty. Not much, I'm going to tell you here. I'm
pretty sure you will all be all know what honesty is. Never, ever lie to anyone on a project. Lying to
people, especially your team members on a project will generally result in people not trust in you
and trust me when I say this, guys, when it comes to honesty and trustworthiness, if you ever lose
that trustworthiness of your team on your project, you're doomed to failure. If your team loses that
trust in you, your project is done. You're probably done, too. So let's be honest. Let's act here. Let's
be respectful to people around us and let's be responsible with our work. This is the key of my
professional conduct and ethics that we should be following when managing every single project.

The 12 Principles of Project Management

In this video, we're going to take a look at what are the 12 principles that is listed in the PMBOK
Guide Seventh Edition. Now, like I mentioned in previous videos, these 12 principles are basically
they're almost like common sense. It's nothing that's probably going to be new to you if you've
ever managed a project before. But let's go right into it now. Before I get into that, I do want to
mention that a lot of these project management principles that I'm about to go over with you or
give you a brief overview of are going to be or having a lot of overlap with general management
principle. So don't think that these project management principles are just being used by project
managers. In fact, most operational managers will utilize these principles. So if if you have ever
done any kind of general management work, you would have applied these principles because
they're just so generic. So these are just good overall principles that you can apply not just to your
project but to your operational work. And as Pennebaker tells us, the principles of project
management, of course, can have overlapped with the general management. So with that, let's go
take a look at what exactly are the 12 principles that we need to be familiar with. So this video is
just to give you the introduction to them and what is it we're going to be covering after this video?
We're going to have more videos that is going to be going into each and every one of those
principles. And I'll tell you exactly the specifics you're going to need to know for those principles.
So the first one up is we want to be a diligent, respectful and caring steward. So this one, this is
2
 Section 05: Project Management Principles

just about being a good person, having good integrity and honesty and being diligent to the work
that you're doing, creating create a collaborative project team environment. You know, when
you're managing a project, it is super important for you to build an environment that the team
feels comfortable working in. The team wants to work and give them the tools and the support the
team needs to be successful. And that's what that is. Number three, effectively engage with
stakeholders. So when you're managing a project, it is super important to make sure that you
engage your stakeholders. And this is a theme that you're going to find a lot. When I go over to
traditional project management sections that was listed in PMBOK Guide, Sixth Edition, or I'm
going to do when I go over into Agile, it's all about keeping your stakeholders engaged, keeping
them informed, keeping them keep, giving your requirements, for example, keeping them actively
participating in the project. So that would be number three. Number four, focus on value. As your
project is progressing, you're going to want to make sure that whatever the perceived value was
that the team wanted or the organization wanted from the very start, you're going to focus on that
and get it done. Actually sell. Why do we do projects? We do projects to get back some kind of
value. We do projects so we can return something valuable to the organization, whether it's rise in
revenue or decrease in expenses or increase in customer satisfaction. As this project is progressing,
you, the project manager, needs to say to yourself, okay, I need to keep focus on delivering the
value that this project was meant for. Number five, recognize, evaluate and respond to systems
interaction. You know, when you're managing a projects, there's many components within a
project the scope, the cost, the quality, the risks, the schedule. There's many components that
needs to interact. In order for the project to be successful, you're going to have to recognize that
these components will work together. For example, scope will affect cost. Cost will affect schedule.
Risk will affects cost. Scope and schedule quality would affect costs. So when you're thinking of all
these different components in a project, recognize that they will interact with each other. And you
as a project manager is going to have to make sure that they come together to interact correctly
and you produce the correct deliverables. You know, I can't emphasize this enough, demonstrate
good leadership or I should say leadership behaviors. You know, we're going to talk the difference
between management and leadership. You have to be a good leader. You have to motivate your
team. You are who the team member is going to look to for leadership. They're going to look to
you for guidance. You have to demonstrate that leader and lead that team to complete those
project deliverables successfully. The next seven now tailor based on context. So as you're going to
come to realize as this course is going to progress there basically three ways to manage a project
traditional or predictive methods, agile methods and hybrid methods. We're going to have to
tailor the processes. We're going to have to tailor the approach that we're going to use to
developing these deliverables to the actual project itself. So as this project is progressing,
sometimes you may start off doing something traditional and. He switched to a hybrid. Sometimes
you may start off with Agile and even go back to traditional, so every project might be different.
You have to know this and tailor those approaches. I can't emphasize this enough. Build quality
into processes and deliverables. No one wants a low quality product. No one wants a product that
is, Oh, this is bad quality. If I told you guys this is a poor quality product, would you buy it?
Probably not. So what I want you to do is I want you to build quality processes. That way when you
get your actual deliverables, it is of good quality. I want you to keep quality at the top of your head
as you're building deliverables. At no point is poor quality acceptable. So we need to keep this
principle as we build our deliverable projects can get very complex. You think about this, if you're
3
 Section 05: Project Management Principles

building large skyscrapers, right, giant projects, permits people, complexity of materials, digging
up the earth, not knowing what's there when you're managing a project are so many moving
components, there are so many different people. Just dealing with people is not easy that you
have to manage and you're going to have to come to realize that there is a lot of complexity in
projects, in managing projects, and you're going to have to know how to navigate that to finish
your project successfully. Everything. Number ten, everything we do in life has risk optimize risk
responses. You will face risks. Every action that you take has some sort of risk. There's a risk of me
standing here. The ceiling can fall down, the camera can shut off, the mic can break that lights can
die. There's a lot of risk. Everything we do in life has some kind of risks. You're going to have to
know what risk affect your project. You're going to have to know how to respond to those risks in
effective manner so the risk doesn't derail your project and basically push it off schedule or
increase the cost or reduce the the scope. Number 11, embrace adaptability and resiliency. So as
the project is going. Be prepared to get hit. Be prepared to get hit with a hurricane or a snowstorm
that delays your project. Be prepared to get hit. But people being out because they're sick. You will
face hits to your project. You have to be able to adapt to these hits and keep that project moving
forward. You have to be able to adapt to these threats that will happen. It's not if, it's just when it
will happen. Are you able to adapt to these threats? These things that can derail your projects and
just keep pushing on it, finish that project successfully. That's what that principle is. Number 12,
enable change to achieve the envisioned future state. Every time you create a project, you're
probably changing something. Projects are done to create new products, modify products, make
products better. They're done internally to improve the processes we follow. They're done
internally to improve people attitudes every time you basically do a project. Be prepared to deal
with changes. You're going to have to manage these changes correctly. You're going to have to
enable these changes to ensure that, you know what? The old state of the company is now in a
new state. Why? Because you can't stay in your old state forever. You can't stay still. You have to
keep progressing. And that means changes. Be prepared for a lot of pushback. And this principal
says, you know what? Let's enable these changes. Let's know what these changes are. These are
the 12 principles and this is just a high level overview of what they are. In the next series of videos,
I'm going to be going to each and every single one of these principles and give you more in-depth
information in it. One thing I do want to point out, if you're studying for your PMP exam, I don't
want you guys to memorize these principles. Don't sit there with a pen and paper and be able to
recite them. Some things to keep in the back of your mind. Some things to know when you're
answering exam questions, what these principles are. First of all, like I mentioned in the earlier
video, these principles are pretty basic common sense. In other words, when you manage a
project, you should be focusing on value. You should know how to manage change. You should be
adapting. You should be tailoring your processes. You should be knowing how the entire system is
interact. So these are not things that are going to be new to you once again. So I don't want you
guys to sit there and be able to recite all the 12 principles out of your head. That's not what this is
about. But I want you to do is to get a good understanding of what these principles are.

Stewardship
In this video, we're going to be taking a look at our first principle stewardship. Let's get right into
this. So when we're looking at the first one, stewardship, the first thing I wanted to do is I wanted
to define the term stewardship. So this principle is about being a diligent, respectful, and caring
4
 Section 05: Project Management Principles

steward. But what exactly is stewardship? So I went to oxfordlearnersdictionaries.com or the one

you basically get off of Google, and I got you the mean of it. So stewardship according to this
means the act of taking care of or managing something. So it's the what are we doing as good
stewardship? We are going to be taking care or managing something. Now you know that
something is projects, right? Because this is a project management course, and we're talking about
projects, that it goes on to say, for example, property and organization money are valuable. So
when we want to be a diligent, respectful and caring steward, that means that we should be
diligent, respectful and caring about the projects that we manage. This is something that you
should be, this is a principle that you shouldn't just apply to project management. This is a
principle you should be applying to real world management. Anytime you're given a job to do, be
a diligent, be careful, be respectful, steward, when you're doing your job. It goes on to say,
stewards act sensible to carry out actions with integrity, care, and trustworthiness while keeping
compliance with internal and external guidelines. Think about this. If I hire you to manage a project
for me, right? I would want you to have good integrity. That means like, don't lie to my people. I
would want you to be caring of my organization and my project. And of course I would want you
to be trustworthy. I want you to be able to keep the word that you give and I want to be able to
trust you with the statements that you tell me. All while staying internal and external compliance to
internal organization policies and external regulations. Stewards, they're able to demonstrate a
broad commitment to financial, social and environmental impacts of the projects they support.
When you're doing a project you're going to be spending internal organization money. I want you
to be a good stewardship and don't overspend. I want you to think of the social environment
around you and the environmental impact. You know, being a good person. If you know that your
project is going to be dumping sludge, or oil waste in a lake that's going to kill wildlife, maybe
that's not something you may want to do. I want you to have good stewardship in doing that.
Stewardship has responsibilities both within and external to the company. You should have good,
you're responsible, within my business to deliver my project. Hopefully within budget, within
schedule, or maybe even under budget would be good. But external to the business, you should
know that this project, you know, as a good person, you should know this project does the world
well. It's not something that's going to kill mankind or harm the environment, for example. Now, it
does go to say that stewardship is going to include four main things, and we just mentioned a
couple. We just mention them before. Number one, integrity. Stewards behave honestly and
ethically at all times. I don't know what else more to tell you here. I mean, if I have to make a video
that's telling you guys, hey guys, you need to be honest and ethical in doing your job. Maybe you
shouldn't be doing project management. How many of you guys would like a project manager
always lying to you? Probably not. So having good integrity is important. Caring I would love to
see all my employees, all my project managers have a caring attitudes. Now, this is going to be for
organizational matters in terms of their changes and overseeing the business itself and overseeing
the project. Trustworthiness. Stewards represents themselves, their roles, their project teams, and
their authority accurately both inside and outside the organization. You know, when somebody
says, I can trust you, it means that if I tell you something, you're going to follow through. If I say,
hey, keep this a secret, you're going to keep this a secret. And this applies to projects. A lot of you
guys may be working on R and D projects that you can't give out external information about. A lot
of you guys are going to be working with teams that where the teams have to trust you. If you lie
to the team and you lose integrity to that team, I guarantee your project will die. You need to
5
 Section 05: Project Management Principles

always maintain that trustworthiness. If that team ever loses trustworthiness in you, you're
probably not going to succeed as a project manager. Compliance, not much here. I can tell you
stewards comply with laws, rules, regulations, and requirements. You should already know if you
are not staying in compliance, you are breaking the law. If you are breaking the law, you're
probably going to go to jail, you and your company. So as a good steward, if you know that this
project, hey, you know what is against the law, it's probably not a project you should be working
on, and maybe it's a project you like. If it's going to be dumping sludge in the in the environment
or it may cause harm to people, you probably want to report that to your government authorities.
A holistic view of stewardship includes financial, social, technical, and sustainable environment
awareness. So when you take a look, when you're managing a project and again, this is not just for
project, this is operational too. Managing a project, you're doing your operational work, you take a
high level overview, you look over the work that you're doing and you say to yourself, oh this is
great. I have a high level overview. I know I'm being a good steward. I'm taking care of the money.
I'm having good social impact. I'm doing the technical work correctly, and of course, I'm not
harming the environment. Okay, so this is stewardship. This is something that you're going to
apply to every single project you've ever worked on. Always be a good steward, always act with
integrity. Have care and be trustworthy. Maintain your compliance. Whether you're doing
operational work, remember operational and these operational and project management
principles, they overlap, right? So doesn't matter what you're doing, projects, operation, it doesn't
matter the type of project. Always be a good steward.

Team
In this video, we're going to be taking a look at our next principle, create a collaborative project
team environment or the principle is basically known as team. Let's get right into this. So, we went
over this already. Who does the work on the project? Who creates the deliverable? Who paints the
wall? Who programs the application? Who lays down the dirt? Who pours the concrete? The team
does. The project team or the folks that would actually do the physical work needed to create the
deliverable. So, if you think about this particular principle, it's like, okay, we need to create a
collaborative project team environment. So, we need to build an environment where the team likes
to work, where we support the team. Let's go into the specifics now and see what this one is about.
As I just mentioned, projects are done by teams, right? They create those deliverables. Teams,
project teams are made up of people who have a diverse skills, knowledge, and experience. The
teams are the expert. They're the ones that expertly knows how to code. Now, I'm not a coder, but
I could manage coders, so that means the coders are the expert. I'm not a painter or a carpenter, I
don't even know how to put a nail on the wall most of the time. That I'm going to leave to my
project team to do when renovating that kitchen. So, the team is made up of a set of folks with this
large amount of skillset. Project teams work collaboratively. They must work together, right?
Project teams that work collaboratively can finish a shared objective more efficiently and effectively
than individuals working on their own. One of the things we want to prevent is something called
silo work. When you're managing the team, the team should work as a unit, not individually. Like,
you have Peter and Paul working not together. They're not collaborating with each other. They're
not sharing information. What Peter does, Paul doesn't do. But remember, in the project, work
depends on each other. The deliverable is not a set of different work, it's a set of collaborative
work. Everyone must work, you can't... For example, a painter can't just be painting wall without
6
 Section 05: Project Management Principles

knowing when the furniture guys are coming. A painter wouldn't be able to paint if the the
furniture guy hasn't moved the furniture out or the tech guy hasn't disconnect all the wires. They
must work together in order to effectively, that means get the work done correctly and efficiently,
get it done efficient. They need to work together to get that done. Project teams work within
organizational and professional cultures, guidelines, often establishing their own culture. One of
the things that project teams are going to do, so you build a team, you gather people from
different parts of your business, you put them together, and you know what happens? Even
though they come from different cultural backgrounds, they come from different organizational
culture within the company itself, when they come together, they will promote and build their own
culture. The team will have their own methods, their own ways of communication, and that that we
considered their culture. Now, a collaborative project team facilitates team environment. To get
this done, if we have a good environment that facilitate good collaboration, we're going to be able
alignment with other organizational cultures and guidelines. So, when your team is working
sufficiently, they still have to comply with your organizational culture. If the organizational culture
is to be ad hoc and all over the place, maybe your team would be ad hoc. If your organizational
culture is very process-oriented, very organized, then the team should follow that culture too. It
should promote individual and team learning. Optimal contributions to deliver desired outcome.
We want to ensure that everyone contributes as effectively and efficiently as they could so the
project achieves its main objectives. Now, what can we do to affect teams? One of the things that
when you create a team is to have a team agreement. Now, I'm going to cover team agreements
more in depth when I get to the resource management section of PEM box six when I go over
traditional project management. Also you have team agreements on agile projects. Team
agreements is basically a set of guidelines or, quote-unquote, "Rules," that your team should
follow in order to have good behavioral patterns. So, you're going to want to make sure you do
that. You're going to want your team to come put a good agreement. This is the team comes
together and they're like, "Okay, guys, we're not going to curse at each other. We're not going to
over talk each other." Those would be good things to put in team agreements so everyone is on
the same page. The organizational structure. Project teams use, tailor, and implement structures
that help. They're going to have to build a certain structure within the team itself for them to be
contributing more efficiently. Processes. Project teams define processes that enable completion of
task and work assignment. Now, I do want to mention, particularly you notice it says here, the
teams define processes. So, the team is going to make up their own processes in order to
accomplish the work, in order to finish the work. You don't want to do that. One of the things that
you guys are going to eventually learn in this course is being a good servant leadership. Nurture
the team, support the team, give the team the right environment. We want them to define the
process of how to complete the work, not you. You're not the expert at this. You're managing
people. I'm not the expert at renovating the kitchen. If a carpenter comes to me and says, "This is
the best way we should do it," I'm probably going to say, "Okay," because he's the expert at that.
Now, one of the things that we should have when managing a team is transparency. Transparency
on roles and responsibilities can improve team culture. That's one of the main things you're going
to be doing. All right, you have to be transparent. People should know, "This is my role, this is my
responsibility when working on a team." Now, as I get more into the course and we talk more
about teams, I'm going to talk more about what roles and responsibility different team members
are playing. Authority, oops. Authority, the order of having the right within a given context to
7
 Section 05: Project Management Principles

make relevant decisions, establish or improve procedures, and apply project resource, expend
funds, or give approvals. So, let the team have the ability to be authoritative in their work. Let the
team make the relevant decisions. The team shouldn't feel like they're dependent on you all the
time. Remember this, and I keep mentioning this, servant leadership is really important. So, let the
team know that you know what? You're empowered to make decisions. Have the team know that
you could make relevant decisions that can affect the project. That way, you know when you want
someone to collaborate well, when you want someone to feel like they're part of a group, they
should feel like their opinion matters. If every time the team says, "We want to do it this way," you
shut them down and say, "No, you can't do that. It's my way or the highway," you're probably not
going to be a good project manager and the team is going to lose faith in you and they're just not
going to say anything anymore and just follow your directions. So, this is not a good environment,
that's not a good collaborative environment. Accountability. The condition of being answerable for
an outcome, accountability is not shared. So, now we have generally, you know, you learn other
management things before you learn about only a single person can be held accountable. The
team is going to be held accountable for the work and they should understand that if they mess
up the work, it's going to be on them. Responsibility. The condition of being obligated to do so or
fulfill something, responsibility can be shared. Responsibility, so accountability, so this guy's hold is
going to be held accountable for getting this work done, but he can have other people do the
work behind him. For example, I'm a project manager, I'm going to be held accountable for
ensuring this project gets done successfully. And if the project goes belly up or bad, I'm going to
get blamed for it, right? And I can't share that blame. But with with responsibility, I'm going to hire
a lot of people to help me conduct the work. So, I'm going to make you responsible for that and
you're responsible. So, responsibilities can be shared, you can have multiple people doing work,
but only one person can be held accountable if the work isn't done correctly or is done correctly. A
diversified team can help develop the project atmosphere by bringing together different
perspectives. Keep a team of diversified personalities and skillset. Teams should incorporate
practice standards, ethical codes, and other guidelines as part of their professional work. Follow
good guidelines. The team should, of course, follow ethical standards, right? We talked about
stewardship before. This is going to help get different perspectives. I mean, if you have a team that
doesn't follow ethical standards or ethical codes, they could be doing illegal stuff, and you don't
want that. A collaborative project team environment promotes the free exchange of information
and individual knowledge. You think about this, if you build a team, if you build an environment
where, we're done here with this one, if you build a team, I should say an environment, that is
promoting the ability to learn between members, the ability from members to communicate with
each other and not be prosecuted, the free flowing of information between these people can drive
that project farther. You think about this for a second. If you ever worked on a project and people
were scared to talk to each other because the project manager will get upset, or management
doesn't want this guy talking to this guy, or people are prosecuted for exchange of information or
talking to each other, people become very scared and no one talks anymore. And if I may have a
solution to a problem that you have, but I'll never tell you because I never, I don't really speak to
you. It's super important to build a team environment and nurture an environment that allows
people to share information, allow the team to collaborate efficiently so your project can be
successful.

8
 Section 05: Project Management Principles

Stakeholders
In this video, I'm going to be talking about our next principles, effectively engage with
stakeholders. Now, I can't emphasize this enough, and this is going to be a topic that's going to be
repeated throughout this class that we have to keep our stakeholders engaged. Now, I do want to
point out that stakeholders or anyone that's impacted by the project will positively and negatively
impact this we covered earlier. Stakeholders includes your project manager, the project team, the
customers, the senior managers, the sponsors, the product owners, basically anyone that's
impacted by the project. But keep in mind, a lot of times in the PMBOK uses when the word
stakeholder, I should say more likely your exam uses the word stakeholder. They're not really
referring to the project manager and the team that mostly refer to the customers. So keep that in
mind as we go through this. So as they say, engage your stakeholder. Well, obviously the project
manager and the teams are engaged, but what they're talking about is keeping other stakeholders
engaged, such as the project team. I'm sorry, such as the customers. So let's get into this particular
one. So stakeholders now, I can't emphasize this enough. You're going to want to engage your
stakeholders. Now, what does it mean by engaging your stakeholders? It means keep them
participating, speaking to them, gathering their requirements, gathering their feedback, asking
them, Hey, how is this? Do you like this? Do you not like this? Should I change this? Should I
change them? Keep them proactively engage to engage stakeholders proactively and to the point
needed to contribute to project success. So we want to do it proactively and don't wait for them to
ask you, why don't you go and ask them how to requirements, how the requirements look and if
there's any improvement needed? You want to consistently do this throughout the project. This is
not, you know, stakeholder engagement. It's not something you do at the beginning. It's
something you can do all throughout the project. Stakeholders, they impact the project because
they're going to give you those requirements. The impact, the performance. They may slow you up
or they may slow you up or speed you, I should say speed you up or slow you down because they
may say something is good or something is not good. You may have to redo a lot of work or you
may just keep going fast. They affect the outcome because remember, it's the customers that
really defines if the project is going to be successful or not. Stakeholder engagement is something
that's done proactively and it will help improve delivery value. Value delivery. So. If we engage
them throughout the project consistently, consistently, I am sure that the value of the end of the
project that they're going to get is going to be high. Why? Because there were more participating
in the development of the product. If I make a product, if I. If I told you, I'm going to build you a
car, but I don't engage you in building the car, like asking you what color and what size and what
type of seat and what type of features you want. And I just build a car for you. You might not like it
because you might not see value in it because you never got you never had an input into what
features you want. Stakeholders can influence many aspects of a project, and I have a list here.
They can influence the requirements because they'll give it to you. They can tell you when they
want something, the schedule, how much they want to spend, the cost they can influence the
team. They can say members should be doing this. They influence plans. They may have input into
plans themselves. Of course they're going to influence the outcome because they're the one that's
going to accept it, the deliverable at the end. They have to determine culture. They have to
determine and realize the benefits of the project. Remember something. The team builds the
deliverable for the stakeholder. The team does. The team may or may not use the deliverable at
the end, but definitely the customer's does at the end of the project. Does the actual does the
9
 Section 05: Project Management Principles

actual output give them value? Is there any benefits to the output? The customers will tell you that.
They'll tell you whether this thing was beneficial to them or not. They can affect risk. They can help
identify risk. They can help lower risks. They'll give you the quality requirements and of course,
they'll tell you to success. We want to throughout the entire project, we want to be able to identify,
analyze and proactively engage with stakeholders. And I mentioned this earlier, know who your
stakeholders are, identify them, analyze their need, and engage them throughout the project from
start to end of the project. Don't forget, the project team I mentioned earlier is a group of
stakeholders. All right. But most of the time, when we're talking with stakeholders, guys, we're
going to be talking with the customers. Now, this particular principle consists of defining how,
when and how often and under what situation stakeholders want to be engaged. We have to
define how we're going to engage someone, when we're going to engage someone, and how
often. So, for example, your CEO, we're going to want to make sure that we define how we want to
engage the CEO. Maybe we're going to do a meeting when and how often we're going to do it
every Friday, every other Friday. So every other Friday is the how often and Friday being the win.
But under what situations does the CEO want to be engaged? Maybe when there's major
accomplishments or major issues that the CEO may want to know about. So you're going to have
to define this. You're going to have to go through all your stakeholders now. When I get to
communications, let me let me go to the knowledge of communications. I'm going to we're going
to talk about the communication management plan and the stakeholder engagement plan all
coming up later. And, of course, that's going to really help you with this. This relies on I can't
emphasize this enough. This is going to rely on a lot of interpersonal skills, including taking
initiatives, integrity, honesty, collaboration, respect, empathy and confidence. I can't emphasize
this enough when you're engaging your stakeholders, keeping them proactively participating.
Keeping them actively, I should say, participate in on your project interpersonal skills, the ability to
talk to people, the ability to communicate with people, the ability to understand empathy or
understand other people's problems or feelings. So or you have an empathy on others. So this is a
skill that all project managers should have. You know, a lot of times people ask me, Andrew, what
can I do to improve my project management skills? And I only send them one word improving
interpersonal skills. Project management is all about talking with people, and not just your team
members, but also your customers. So have good interpersonal skills because that's how you're
going to keep them engaged. The engagement helps the project teams detect, collect and
evaluate information. So the project team is going to help. And by engaging the stakeholders, the
project team is going to detect who they are, is going to detect what information they want, what
requirements they want, is going to collect these things and is going to get opinions from them,
get feedback from them. Teams actively engage other stakeholders throughout the project. We
want to minimize potential negative impacts and maximize positive impact. So, for example, if the
team is proactively if the team is proactively engaging your stakeholders, the team of find out
these features the stakeholders don't want remove them. This is going to minimize negative
impact. The customers love these features. Let's add more of these features, maximize positive
impact. So this is something that you want to keep doing. All right. The team should keep doing.
Always engaging your stakeholders. Now, once again, I'm done here with this one, but I want to
keep I want to keep you guys reminded, engage in stakeholder. I'm going to be a broken record
on this. You're going to hear me say this many times. In fact, we have a whole knowledge area.
PMBOK Guide, sixth edition. In the whole Agile section, we're going to talk about keeping your
10
 Section 05: Project Management Principles

stakeholders. Agile is all about keeping your stakeholder engaged. It's always getting feedback
from them and seeing if they like this and if they want to change this and get in requirements
throughout the project. I highly believe if you want to have a successful project, you must keep
your stakeholders engaged.

Value
In this video, I'm going to be talking about our next principle, which is focus on value. And the
principle is really known as value. Let me ask you guys a question. Why do you buy things? Why do
you spend money on things? Why did you buy this course? Why did you buy that car? Why did
you buy the shirt? Because it has value to you, consumers and people that buy things. I guess the
reason why we basically do anything is because we pass. There's some kind of perceived value to
it. You're going home and watching a video on YouTube has some kind of value to you, calms your
nerves, makes you happy. That's the value you see on a project. We must understand value. We
must understand that the output of the project will deliver some kind of value that your
stakeholders want. For example, your company be making a new product to sell to the market that
value the company sees is generated revenue. The value the customer sees is being able. Maybe
you're making a new smartphone, it's being able to affect more effectively. Surf the Internet, put a
bigger screen, people purchase on value. Companies tries to deliver value to their customers. We
as project managers, needs to ensure that the products and services and results coming out of our
project is delivering value to our actual customers. And that's what this principle is about. Let's get
into it. So value remember now value is something that they want. It's something that we have to
consistently focus on. Ask yourself this question Is your project consistently delivering value? Has
your project been derailed? In which case it's lost that value proposition? Is your project derailed
to the point where it's just not delivering value anymore to the customers anyhow? This can, of
course, can be a problem. We want to continuously evaluate and adjust project alignment to
business objectives and intended benefits, benefits and value as this project is progressing. I want
you to always keep an eye and ask yourself the question Is this project still delivering value in the
way the business wanted it? What was the intended benefit? Maybe the value of the project was to
lower expense. Well, is the deliverable going to achieve that in the end, or are you seeing that this
deliverable is going to increase your expenses? Is this deliverable going to increase our revenue?
Maybe. But if you find to the point where this thing is just not going to be sold in a marketplace,
maybe it's time to stop the project because there's no value here. Value is the ultimate indicator of
project's success. Every project will deliver value of some sort that your sponsor wants, your
customer wants. Ask yourself the question did when the project was done, did it actually give them
that value? Did it decrease the revenue, the expense like they wanted? Did it increase the revenue
the way they wanted? Did it increase the customer satisfaction the way they want it? And if it did,
then, you know, your project was successful because if it didn't, then your project was a failure.
Value can be realized throughout the project at the end of the project or after the project is
complete. So when you're doing project management, if you use that traditional methods, that
waterfall development, in which case you build the whole thing and you release it all at once, the
customer may not see value till the end to the project is released in the product is done. But if
you're using Agile methods and you're building the product this time is progressing, then they
may see value throughout the project and not just at the end value. And the benefits that
contribute to value can be defined in quantitative and or qualitative terms. So quantitative terms
11
 Section 05: Project Management Principles

means numerical analysis, numerical value gain, versus just a subjective gain. So for example, this
project, the output of this project, increased revenue by $10 million. That would be a quantitative
value gain. A qualitative value gain could be something very subjective. It could be like, well, it's
increased customer satisfaction when you can't put a number on that, or it's going to lead to more
revenue, but you don't put a number on it. So that be qualitative. A focus on outcomes allows the
team to move to support the intended benefits that lead to value creation. You know, the team, a
lot of times the team is just focused on making the the deliverable. But if the team changes its
focus from just creating deliverables to the value, then the team can see they're not just building
the deliverable per requirement, they're building it to meet the value. So if the value was
decreased revenue, I'm sorry, decrease expenses, you never want to decrease revenue. Decrease
expenses. And as the team is building the deliverable per requirements, the team may come to say,
you know what, this is not going to really do anything in terms of expenses. If the team has the
same vision as the customers of what the value proposition is, then the team can now maybe they
can change the deliverable. Maybe they can talk with the customers and say, Hey, you know what?
This is probably not the thing you want. Project teams evaluate progress and adapt to maximize
expected value. So they're going to change, right? They're going to see there's a problem here.
They're going to change. What is it, the processes they need or even change the work in order to
enhance the value. Intended outcomes from the perspectives of the customer or end user is the
ultimate success indicator. One thing I do want to mention, and I put this here because from the
perspective of the customer, end user, you know, there's one thing we have to understand is that
value is something that is subjective. All right. Value is the worth importance or usefulness of
something. It's subjective in the sense that the same concept can have different values for different
people. And I want to point that out. Because I want you guys to remember something. Value is
very subjective. What I find value you may not see in value. What I find highly valuable in my life is
not valuable to you. It's highly subjective. For example, I drive a big pickup truck. Well, you may
not find value in that. You may say, Oh, it's too big, it drinks too much gas, it's hard to park, but
you may drive a small car. I don't see value in those two. I'm just not comfortable in it when I
purchase. Some people may purchase this course and the value they're getting is learning about
project management, not just passing a test. Some people, the value to get out of this course is
just passing a test. Everything that we purchase, everything that we want, that that we see value in
is because of a perspective that we have, that this gives me value and you may not see it that way.
So it's something that's very subjective and it's all based on different perspectives. So come back
to the top here. We want to know what the perspective are. We want to know what the value
they're going to be seeing because that's going to be the ultimate success. Now, another thing I
want to mention is something called a business case. A business case. Is there a business case?
When doing value? You have to say to yourself, is there a business case that leads to value? So the
business case is going to be like, okay, this is the business case is going to outline the value itself,
the business case. Why do we need it? Can we justify why we need this? So the business may say
we need it to increase revenue. We're going to justify it by saying, well, we need to increase
revenue because all the products are not selling. And the strategy of how we're going to get it by
doing a business case you can have justified a value, can lay out what the value is to support value
realization from projects. Project teams shift focus from deliverable to the intended outcome.
Something I mentioned earlier. All right. Don't let the team just create deliverables. Have the team
know the value. Have the team understand this is the intended outcome. This is the value the
12
 Section 05: Project Management Principles

customers are going to get and have them keep focus on that doing. So a lot of team to deliver on
the vision or purpose of the project rather than just making a deliverable. Right? Remember, if the
value is to increase revenue by 10%, decrease or decrease expense by 10%, increase customer
satisfaction, whatever the value is, the team should know this. The team has input. Remember, the
team is the expert. At the end of the day, every project must deliver value. Every product we make,
every service we make, every time we re-engineer a product or service, we have to ask ourselves,
what is the value here? If you can't if you can't answer that question, you may not be able to sell
the product or service. You may not be able to get approval to get that project done. As the
project is progressing, you must keep an eye on value. You must focus on this value. You must
always say, Are we still delivering this value? Sometimes projects can take many years to dumb to
be done because guys, at the end of the day, if customers don't see value in your project, at the
end of it, your project is going to fail. But if the value is always there, you focus on it, I'm pretty
sure, and you actually accomplish the value that the customer wants. Then you have a successful
project.

Systems Thinking
In this video, I'm going to be talking about systems thinking principle. So let's get right into this.
So if you think about a project, the project has many individual components. The component of
risk, quality, scope, schedule costs. What we need to do is we need to, quote unquote, build the
system that allows all the different components of a project to interact and be able to act in a
unified way to produce those deliverables. For example, when you paint a room, it's not just one
thing. It's not just about costs. It's about no one went to paint the room. It's about knowing how to
paint the room. So just something as simple as that has a system of interrelated components. Let's
take a look at this principle and get more into it. So this principle is known as recognizing value
and respond to system interaction. So we need to understand how the different components of
our projects will interact. First of all, a system is a set of interacting and independent components
that function as a unified whole. So what what exactly is it? Well, it's a set of components that are
interdependent, but they need to interact. So they're they're basically even though they're
independent, they're going to need to interact together, to function in order to get the project
done. A project itself is a system of interdependent and interacting domains of activity. We're
going to have to make sure we manage our scope right or quality or schedule or cost to make this
project successfully or make the project complete successfully. Recognize and evaluate and
respond to the dynamic circumstances within and surrounding the project in a holistic way to
positively affect project performance. So one of the things we have to do is I really want you guys
to look at it in a holistic view. You know, a project manager doesn't see a project as a single
component. A project manager sees a project as a series of components or a set of components
that acts together. It's not just one thing. So we can't have a single. We can't be focused just on
scope and forget about your quality and your risk and your schedule and your costs. You must see
it all to take a holistic view system. Thinking entails taking that holistic view of how the project
parts interact with each other and with external systems. Your projects will use external support
such as I.T. support. How does your project interact with that? So it's not just your individual
components, but it's also external components. Systems are constantly changing. Requirements
consists of requiring constant attention to internal and external conditions. The organization
changes. They're going to cut your budget. They're going to want new requirements. They're
13
 Section 05: Project Management Principles

going to want you to modify this. Being responsive to system interactions to allow projects seems
to leverage those positive. We're going to have to respond to the interactions within them. We're
going to have to understand that you add more scope. You're going to you're going increase your
time, you can increase your costs. We have to be able to respond to these changes. The team
themselves should acknowledge this holistic view of a project. The team can't just be focused on a
single component. Seeing the project as a system within its own parts. They can't just have one
single component. They have to look at the entire project. Everyone needs to look at the project as
a unified set of components. A project. A project works within larger systems such as the entire
organization. Every company has a system of how it produces its products and services, how it
sells, how it advertises, how it does its sales, how it brings in its customers. So a project works
within a larger system, which is that business, and the deliverable will become part of a larger
system. So your deliverable may only be a small component within a larger project that's getting
done or a larger program that's getting done. You have to understand that your component may
be valuable, maybe only 10% valuable to a larger system. How did your project fit into your
business? As the project unfolds, internal and external conditions are continuously changing. A
single change can create several impacts you think about as you're managing your project.
External things that can happen are going to be like regulations that can take place and derail your
project. The organization management can change directions. Stakeholders, shareholders can can
want new things from them. System thinking applies to how the project team views itself and its
interactions within the project system. So we're going to see how the team has to view this view.
The project is one big system and how it interacts with the project. The project system often brings
together the diversified team engage in working for a common objective. Yes, the system should
bring the team together, let them see all the components and make sure they work. Well, you
know this domain I don't want you to worry too much about yet, because when we get to the
processes of managing agile, the processes of managing traditional project, then you'll see the
whole system come together. Then you'll say, okay, so if I'm doing a traditional project, I need to
have this system in all these processes. If I'm doing an Agile project, I need to have this system at
these processes. The point here I want you guys to know right now is understand the concept that
when you are managing a project, you got to see the thing as one whole thing. Don't be focused
on one one concept over and over. And in this section, Pembroke seven is telling me, make sure
we have that holistic view, not just you, but the project. But the team themselves too needs to view
the system as one whole thing. So don't worry too much about and I don't want to get into all the
processes here as I move into the course and we get more into the when you look over your data,
all those 49 processes in PMBOK six and all those Agile ceremonies and methods and processes,
then you don't understand, okay, these are our system. Just keep in mind when you're managing a
project that all these components must work as one for your project to be successful.

Leadership
In this video, I'm going to be talking about a principle called leadership; demonstrate leadership
behaviors. You know, when managing a project, one of the most critical skill that you're going to
have is leadership skills. Are you a good leader? Do you consider yourself to be a good leader?
And that's what this principle is about. Whether you're managing a team on a project, you're
managing a team in operational activities like sales or finance, you must demonstrate good
leadership skills. So in this domain, in this principle, we're going to take a look at this. Let's get into
14
 Section 05: Project Management Principles

it. So leadership, one of the things that we have to do throughout our project is we have to
demonstrate and adapt leadership behaviors to support individuals and team. There are different
leadership skills and techniques to keeping team motivated, understanding their requirements,
being able to lead them to success. There's many different ways of doing this. We're going to have
to adapt the way that best suits our team and the organization we're working for. Effective
leadership promotes project success and contribute to the positive project outcome. How many of
you guys are familiar with projects that fail because of poor leadership? How many of you guys are
familiar with companies that has great success or companies that fail because of leadership? Any
project team member can demonstrate leadership behavior. We want to promote not just good
leadership behavior from us, but also from our project team. Keep in mind, leadership is different
than authority. Authority is making someone do something. Leadership is motivating people.
Effective leaders adapt their style to the situation. We modify our style and change our style. We're
not just always using the same leadership method. The leadership method that works on this
project with this team may not be the same that works on this. For example, if you're having a
project that's highly regulated and a deliverable must be produced in this way, your leadership
style may be different than a deliverable that is highly customizable. Effective leaders recognize
differences in motivations and motivations amounts to different team members. You know what
real leaders good at? Motivating people. What can I do to keep my team motivated? And not just
the team, but we got to understand that different people are motivated by different things. Some
people are motivated by additional money. Some people are motivated by more days off. So we
have to know what keeps the team motivated. Leaders demonstrate desired behavior in areas of
honesty, integrity, and ethical conduct. A good leader will have to be trustworthy, right? We talked
about this in previous principle of stewardship. We should know, hey, we're going to be honest.
We're going to have good integrity. We're going to have good ethical conduct. On a high-
performing project, multiple people may show or exhibit effective leadership skills amongst a
project. Don't forget, you're not the only one on the project. There's going to be leaders on the
team, team leads. There's going to be leaderships on the project management team. And of
course, you being the leader. It's important to remember that more conflict and misunderstanding
can emerge when too many participant attempts to employ project influence and multiple
misaligned. So you got to understand, yes, you're going to have different leaderships on the team.
But think about this. You ever worked on a project where the team got split into two and ended up
fighting with each other on two different fronts? Because one leader on the team, you, let's say,
had a team of 12 people and one guy started influencing five people and another guy started
influencing another five people. And now you have a problem. Now you have two leaders that are
splitting the work apart, creating misunderstanding. Something you got to keep in mind as you
manage your team. Leadership should not be confused with authority. Okay, so what is authority?
Authority is the right to exercise power and control individual. Authority is you have to do it this
way because I said so. Authority is do this work. Now, there are times when authority might be
needed, maybe not on a project all the time, but in operational work, you may need to exert
authority. For example, for the the payroll department to produce paychecks. It takes leadership to
motivate people towards a common goal, inspire them to align their individual interests in favor of
collective effort, and achieve success as a project team rather than an individual. You know, one of
the things that we're going to do is we want to make sure that we motivate people towards a
common goal. We want to make sure that the team sees themselves as a team and keep the team
15
 Section 05: Project Management Principles

unified. Great leaders are able to motivate people to produce great work. Great leaders don't
actually produce the work. They motivate people to produce that work. Keep in mind that team
members will become leaders themselves. Team members develops leadership wisdom by adding
a practice in a variety of different things including by being able to focus the team on an agreed
goal, articulating or having a motivating vision of the projects. Other team members motivating
other team members. Generating consensus. So a good leader on a project team or team
members developing leadership skills will learn how to come together to form consensus.
Overcoming obstacles. Negotiating and resolving conflicts. Great leaders are amazing at solving
problems and resolving humanly conflicts amongst each other. There's never going to be a time
when you put a bunch of humans in a room and there's not conflict. Good leaders are able to
overcome that and solve that. Adapting communication styles to stakeholders. Coaching and
mentoring, other team members. Having self-awareness of one's own biases and behaviors.
Managing and adapting to changes. So these are going to be some things that team members are
going to be doing. Projects work best when leaders understand what motivates people. I bold this
as you can see. I can't emphasize this enough. Do you know how to motivate people? Do you
know how to keep people going? Long projects, maybe even sometimes even on short projects,
you're going to have where people are just not motivated to get the work done. Do we know how
to keep them motivated? Project teams can flourish when project team members use suitable
leadership trait, skills, characteristic that match the needs and expectation of stakeholders. If the
stakeholders understand that the team is being managed right, they have good leadership skills,
the stakeholders themselves are going to be satisfied with what's happening. Effective leadership
promotes project success and contribute to positive project outcome. I can't emphasize that
enough. You have good leadership skills, without a doubt, your project is going to be more
successful than poor leadership. I don't think I need to tell you, guys, that. You probably knew that.
Way too often, do we see fail projects because of poor leadership. By mixing styles, leveraging
motivators, any team member or stakeholder can motivate or influence and in turn, grow the team
regardless of role or position. You know, we have to remember that when you're managing a
project, all right, when you're managing a project, good leadership is the single key to good
project success. It's the single key to keeping that team motivated. If your team is not motivated,
your team feels like it's being poorly managed, you're probably going to fail. So make sure you
always use the right leadership skill. Adapt your leadership skill in order to keep your project team
motivated so you can be successful.

Tailoring
In this video, I'm going to be talking about a principle called tailor based on context. And this one
is just called tailoring is the main principle name. So when managing a project, as you guys are
going to learn here when studying, for example, your PMP exam, you're going to learn that there
are really a variety of different approaches you can use to develop your deliverable. You can use
that traditional predictive waterfall approach, you can use an Agile approach. And when you say
Agile approach, you mean Agile itself is an umbrella term for many different approaches such as
scrum and Kanban and lean development and extreme programming and many others. And then
you have hybrid approaches where you can just combine a whole bunch of different approaches,
whether that's multiple Agile approaches or it's a combination of Agile and hybrid. The point of
this is there are many, many approaches to developing your deliverables. Whether you want your
16
 Section 05: Project Management Principles

deliverable all at the end, you want it throughout the project, you want to do iterations of it,
there's just too many to talk about. So the point of this principle is going to tell us that you know
what? We have to tailor the approach to the actual project. What approach is best for your
project? And you may not know what approach is best until you actually dig in and start to work
and you may have to customize it. So that's what this principle is. Let's get into it. So tailor based
on context. First thing we got to say, hey, every project is unique. So don't think that one approach
or one method or framework is right for every project. Every project is unique. They generate
unique outputs. Remember that's part of the definition of a project. Remember, what is a project?
A temporary endeavor to create a unique product, service, or result. Remember that? Design the
project development methods based on the needs of the project and its objectives, stakeholders,
governance, and environment. So when you are coming up with those development methods,
think to yourself, what is the needs of this project? What is the objectives? What does the
stakeholders want? What is the management or the organization or even the environment it
supports? One thing we have to do is use the just enough process to accomplish the desired
outcome while maximizing value, managing costs, and enhancing speed. So it says just enough.
You don't want to implement a cumbersome framework or method that is too complex or just
gives you way too many things that you don't need. Projects should use a development approach
or method that is just enough to get the work done. This way, value is realized early fast. Project
success is based on adapting to the unique context of the project. One of the main thing about
success is knowing what that approach is. It's about adapting those approach. Tailoring the
method is iterative. In other words, you can come up with a method right now and you're going to
say, we're going to use this. But then don't stick with it if it doesn't work. Change it. Make it better.
Change the process. And therefore, as a continuous throughout the project. So throughout the
project, I've seen projects that starts in traditional and move to Agile. I've seen projects that starts
in this method of Agile and then change to another method of Agile. I've seen projects starts with
this method of Agile. Then incorporate all the methods to create hybrid systems. Project teams
tailor the proper framework that would enable flexibility to consistently produce positive outcome.
The project team will tailor a framework. They'll modify it. Way too often people ask me the
question, Andrew, what's the best framework or method or approach to developing this product?
And I'm like, there's no best. It's the one. It's whatever framework that produces your deliverable
successfully. There's no best one that suits every project. Project team discuss and decide on a
delivery approach and resources on a project by project basis. The team should not be committed
to only using one framework on everything. They shouldn't say, we're going to use this Agile
method on every project you've ever worked on. The team should say, okay, every project, let's
customized a framework. Let's see what framework works best. Is scrum best for this project? Is
extreme programming best? Is waterfall methods best? Tailoring the project approach to suit the
unique characteristics and its environment. All right, you got to tailor it. You got to say this
environment, this project, this approach. A tailored project approach can produce benefits such as
deeper commitment from team, reduction in waste in terms of actions or resources. Remember,
the right process will minimize the actions to produce those deliverables. If you're taking too many
actions to produce something, you're wasting time. It's customer focused. It's more efficient use of
project resources. As we go through the course, you're going to learn a variety of different
approaches. We're going to learn a whole lot of Agile approach. You're going to learn about your
49 processes traditional approach. At the end of the day, you got to tailor it. You got to choose
17
 Section 05: Project Management Principles

what's best for your project. Never think that one method is best, and that's what this particular
principle is about. Always tailor it. Find the best development approach to ensure that your project
is successful.

Quality
In this video, I'm going to talk of another principle about quality, build quality into processes and
deliverables. Now let's be realistic, no one wants poor quality on anything that you get. You don't
want a poor quality class, do you? You don't want a pour quality car, you don't want a poor quality
shirt, you don't want a poor quality desk, you don't want a poor quality book, you don't want a
poor quality cup, and I could just keep going on and on. Everybody wants good quality stuff. There
is never an excuse for poor quality on anything that is sold by any company, period. That's all I'm
going to say about that. Now, the principle itself. So obviously, we need to build quality into the
processes we follow. It doesn't matter the project you're doing. Whether you're managing projects
or you're doing operations, you must have good quality practices. Now, we're going to talk a lot
about quality when we get to the specifics of managing quality, when we get to the quality
management knowledge area in PMBOK 6. We're going to talk about quality more, especially in
Agile, Agile really promotes good quality products, when I get to Agile. But let's take a look at
what this principle is going to be about. 'cause this is something that's going to be applied to all
your projects. I don't care what method, I don't care what you're doing, you should always follow
good quality. Quality. Quality is about meeting the acceptance criteria for deliverables. When you
gather the requirements for those deliverables, the things you're making, you should ask the
customer, "When we finish the product, when we finish making our deliverables, what would it
take for an acceptance? Does it need to perform in this method? Does it need to complete this
function? Does it need to look this way?" Quality is going to be about knowing what those things
are and meeting them. Project quality is about satisfying stakeholder's expectations and fulfilling
projects and product requirements. Knowing what those expectations are and meeting them. If a
product doesn't meet certain expectations that you're looking for, one of the first things you're
going to say, "Hey Andrew, this thing is poor quality." Stakeholders will have to maintain a focus
on quality that produces deliverables that meet the objectives and align to the needs set forth by
the stakeholders. So we are going to have to focus on quality throughout the production of the
deliverable. Any part of that deliverable that fails or doesn't meet these quality objectives can have
consequences such as poor quality. Project quality ensures processes are appropriate and effective
as possible. When I get more into quality later in the course, you'll see more of why these
processes are important. Qualities have different dimensions that can affect the way quality is
done. It includes, you know, when you're thinking of quality you're thinking of, does it perform
right? Poor performing products like my phone taking too long to log me in can be poor quality.
Does it confirm to certain requirements? If your project doesn't meet a certain requirement, it's
probably poor quality. Is it reliable? Poor, reliable products are considered poor quality. Is it
resilience? Can it take a hit? Does it satisfy my needs? Is it efficient? Is it sustainable? Teams
measure quality using metrics and acceptance criteria. Now, when I get into managing quality,
later on in the course, we'll talk about metrics and how metrics are used in order to meet quality
requirements. So, for example, if the metrics is the website has to load in one second and the
website take takes 10 seconds to load, then you'll say, "Okay, this is a poor performing website."
The team needs to know what these metrics are in order to meet them. The objective is to help
18
 Section 05: Project Management Principles

ensure that what is delivered meets the objectives of the customer and stakeholders. If we don't
meet the objectives of a stakeholder, if you don't know what the stakeholder wants, there's no way
you can produce good quality products. Quality is something that's been in every version of
PMBOK since the beginning of PMBOK. Quality is something it's always produced in almost every
product you want. And any product that has poor quality, even services has poor quality, will go
out of business or will not be bought. So we want to make sure to emphasize quality on all of our
project deliverables to make sure that the customers will accept it and they're going to be happy
with the products , or I should say, with the deliverables that we're making.

Complexity
In this video, I'm going to be taking a look at another principle called complexity or navigating
complexity. You know, I've been managing projects since I was very small. You, too. We've all been
managing projects since we were very small. Maybe we painted our room at one point. Maybe we
built a little toy when we were small kids. That technically is a project, right? As we got older and
we managed more complex projects, things became more complex. You know, if you think about
managing a project, think of it this way. You got a lotta different people you have to deal with and
just managing people itself is a complex thing. Different, quote unquote, attitudes, different
perspectives, different views, just managing people. Then you have so many different processes
and systems within an organization that has to be followed. So many different regulations that
needs to be met. So many different requirements that needs to be met. I have to deal with
requirements and talking with customers. Complexity is the nature of project management, and I
don't care what project you're working on, whether you're painting a room in your apartment or
you're building a complex application. Complexity exists everywhere. So in this domain, we're
going to have to tell you, or PMBOK is telling us, that you know what? You have to navigate the
complexity. You have to be prepared to deal with it, and you're going to have to make sure you go
through it in order to finish your project. Let's take a look. So complexity. Complexity is the
outcome of human behavior, systems interactions, uncertainty, and ambiguity. Where does
complexity happen? Jane can't get along with Mary. Bob is having a problem with Peter. Human
behavior. System interactions. This system doesn't work with this, even technological. That
software doesn't interact with that. This process doesn't output to this. High uncertainty of risk
happening. Knowing that a snowstorm can affect your project. How do you navigate that? Or it
might not, or maybe it will have a drastic impact. Complexity can arise at any point during the
project. You can go to bed, everything is perfect. You wake up in the morning, and now the
forecast is like, "Yeah, we're about to have 10 inches of snow "and shut the whole city down." Or
you may go to bed one day and wake up to find there's a pandemic happening, and it may have a
drastic impact on your entire company. Constantly evaluate and navigate project complexity so
that approaches and plans enable the team to successfully navigate. So always look for the
complexity. Always anticipate complexity happening. Look for ways of how this can affect your
project. Complexity can be introduced, I mentioned, by events or conditions. Sometimes they're
predictable; sometimes they're not. Project teams can stay vigilant in identifying elements of
complexity and use a variety of methods to reduce the amount of impact. For example, good risk
management methods are able to somewhat forecast that risk may happen and come up with
responses ahead of time. -: Sometimes that's not possible because project teams often cannot
forecast complexity emerging because as a result of many conditioner events. The pandemic,
19
 Section 05: Project Management Principles

COVID-19. How many people could have forecast that? I'm pretty sure many projects, many
organizations, was hit with something of a global scale that many people never predicted woulda
happened in their lifetime. It had a drastic impact on many people lives, companies, businesses,
and countries around the world. Could you have predicted them? That's a complex thing that
needs to be navigate through in order to finish a project. Some of the more common sources of
complexity, human behavior. Remember, just managing people is a complex thing, right? Just
keeping team members from not fighting with each other is a complex thing. Dealing with people
is a complex thing. System behavior in the way they interact. Uncertainty but of risk. Technological
innovations, complexity, a lot of tech is hard to use. Being vigilant for indications of complexity
allows the team to adapt their approaches and plans to potential disruption. The team should be
able to, "Okay, here is an issue. "Here is a problem. "Here is how we're going to fix it. "So just
change our plan. "Let's get around this. "You know, pandemic happens. "Okay, let's just all work
from home." Then they have to find ways. At the end of the day, we still have to efficiently deliver
the project deliverables. I don't think I've ever met a project that didn't have complexity. Project
management itself is not an easy thing, right? Managing people, managing vendors, well,
managing your team members, managing vendors, managing your senior managers, managing
your customers. That's just people, right? Managing this software to interact with this software.
Make sure those deliverables are done. Make sure that's checked. Oh, I could keep going on and
on. All of these things have to work together. There's always going to be complexity that arises,
and we must find ways to navigate them to ensure that our projects can complete successfully.

Risk
In this video, I'm going to be talking about a principle called Optimize Risk Responses. So
everything we do in life has risk. Every action we take has risk. Driving a car. Tons of risk there,
right? It's one of riskiest things you can do. You can die. Standing here, the ceiling can fall on me.
Standing here, the floor can collapse on me. Standing here, the computer could die. Every action
we take walking down the street, fly in an airplane- Sitting on the desk, a chair can break. Every
action has risk. Everything we do on a project, every- every day, I should see that your project is
progressing, is going. There are certain events that can negatively, a threat, impact your project
and derail it. New regulations, a snowstorm can happen, team members can quit, people can get
sick and be out for extended period of time. But risk can also be positive. And also known as
opportunities. A permit showing up earlier. There is no snowstorm. Work finishing faster. One of
the things we have to do on a project is we have to be able to identify these risks, assesses these
risks, come up with potential response monitor the project as its progressing, and to see these
risks take place, and then respond appropriately. Now, I'm going to get more into risk
management when I get to the risk management knowledge area in PMBOK 6 and when I talk
about Agile Risk Management section, that's where we're really going to talk about risk registers
and risk management plans. Terms you're going to see if you're taking the P&P test. Now, in this
one I'm just going to go through the basic principles of risk. So let's take a look here at risk. So first
of all, what exactly is risk? A risk is an uncertain event or condition that, if it occurs, can have a
positive or negative impact on one or more objectives. So if your project objective is to increase
revenue, right? If that was the main objective, when certain risks can impact it, and the project may
never get done. So you never get that revenue. You may have positive impact, in which case it
gives you even more revenue. So risk can be positive. These are known as opportunities. And it
20
 Section 05: Project Management Principles

could be negative. These are known as threats. Now you're probably saying, if this is the first time
you're hearing this, you're probably saying what? Positive risk? Yeah, there is positive risk. Now, I
don't want you guys, I don't want to lose you here but we're going to be, again, we're going to
talk much more about risk management and the risk management processes that you should be
following later on in this course. So remember, a positive risk is an opportunity. Think of a permit
showing up late, early. That's a positive risk. Think of a permit showing up late in order to start
your work. That's a negative risk. A positive risk is work getting done faster than anticipated. A
negative risk is work taking longer than anticipated. The project team seeks- Seeks to maximize
positive risk, right? Maximizes opportunities. Oh, the permit showed up early? Then get the work
started faster. Maybe you can finish it quicker and decrease the exposure to the threats. Anticipate
that snowstorm so we can have processes in place to manage that. Consistently evaluate exposure
to risk, both opportunities and threats to maximize those positive impacts and minimize those
negative impacts. So look at your exposure to risk. Are you highly exposed to certain risks? Is the
project moving in a direction that's going to that's putting us more in the way of the risk
happening? We have to say to ourselves, "Okay we need to get out of that situation or we need to
change course." Risk is something that is addressed continuously throughout the project. Risk
changes every day. Every day you wake up, there is a new risk on this planet that can take your life.
Every day you wake up there's a new risk that can derail your project. You must identify risk on a
daily basis, on a weekly basis, on an hourly basis, on a yearly basis, and see how they're going to
affect your project. Risk response should be appropriate for the significance of the risk. If the risk is
highly going to derail your project then make sure the response is adequate. Make sure response
is cost effective. Listen to me guys. You can't spend $10 protecting $5. You can't buy a car for $500
and then buy a lock for a thousand dollars. The risk is you get the car stolen, but you're going to
spend more money protecting it than it's worth. Be realistic with the project and how the
responses are. Make sure it's agreed to by stakeholders and is owned by a responsible person that
can implement those responses. The project team members engage with relevant stakeholders to
understand their risk appetite. So this concept of Risk Appetite is important. An organization's risk,
attitude, appetite, and threshold influence how risk is addressed. So this concept of Risk Appetite is
this. All of us have a certain threshold of how much risk we're willing to accept for a reward. You
go into a casino, some of us pay $20 some of us pay a hundred dollars, some of us pay a thousand
dollars, right? It depends on the risk itself. So we want to be able to look at those risks. We want
to be able to say, "Okay, this is the risk appetite that we're willing to accept." And this is going to
implement, affect, how we're going to respond to those risks. Right? Now, I don't want you guys to
get too much into this because I'm going to cover risk assessment, in depth, coming up later in the
course. I'm going to go over all the risk processes that you should know, qualitative, quantitative
the risk register, all the different methods of risk response later on in the class. We're going to get
into that when I get PMBOK 6 and those traditional processes. So for now, just understand risk
responses.

Adaptability & Resiliency

In this video, I'm going to be talking about embracing adaptability and resiliency. When managing
a project, you should be prepared for changing things within the organization. Change in
processes or change in external environment such as new regulation, change in of personnel
because somebody got sick or somebody somebody got hurt and can't work on your project. You
21
 Section 05: Project Management Principles

also should be able to be able to take a hit and keep on going. You should be able to adapt your
processes and your project team should be able to mold approaches in order to anticipate when
there's a mix, a big snowstorm and the whole project gets hit and it can't proceed as you way you
had planned. Nothing in this world that I am aware of ever proceeds its plan when it comes to
project management. Very rarely have I ever planned a project and it ever went as planned. I don't
think I've ever did a project that went exactly as planned. There was always some weird thing that I
didn't plan for, some weird thing that happened that hit my project but I needed to make sure that
I was able to adapt to it. I was able to change my processes and I was able to keep going forward
and that's what this principle is about. So it doesn't matter the project you're working on:
traditional, hybrid, it doesn't matter. You're going to face this. Let's see what this is about. So what
is adaptability? Adaptability is the ability to respond to change in conditions, change in personnels,
change in environments, change in regulation. Resiliency is the ability to absorb impacts such as
somebody being out for extended period of time that you couldn't predict, such as a major
weather event that derailed the entire construction project and to recover from these impacts
quickly without having a setback of failure. What you want to do is you want to build adaptability
and resiliency into the organizations and project team approaches. You want to be able to build
how the company responds and the team responds. A focus on the outcome rather than the
outputs facilitate adaptability. So, just don't look at just the output, just the deliverable. Look on
what was the intended main outcome of this project. What was the intended value they we're
getting? A project rarely performs exactly as initially planned. Like I said guys, and maybe you're
with me. Maybe ask yourself, have you ever managed a project that was that went exactly as
planned? Hmm, I haven't. I can't remember a project where I planned it right and went exactly as
planned. Projects are influenced by internal and external factors such as change in requirements in
your requirement, issues such as people being out, software failing, computer is dying, right? So
stakeholder influences are changing things amounts other factors which exist in a system of
interaction In a project environment, capabilities that supports the ability to have change or adapt
and do resiliency. Things that we could do as short feedback loops to adapt quickly. So we want
to build, if we could build our products in increments and get feedback from our customers, this
would be a great thing to do because this would now allow us to change the method. Continuous
learning and improvement. There's nothing like having the right skillset to adapt and change.
There's not only having the right skillset to fix a problem but that means we have to continuously
learn, regularly inspect the work, open and transparent planning that engages stakeholders. So
stakeholders should know how we plan on our project. Small prototypes and experiments. This is
going to help with those feedback. Open conversations between all stakeholders. A diversified
team with a broad set of skills, cultures and experience can give you a broad overview and
different perspectives on how to do work, how to... how to tackle obstacles or hits on our project.
Understand from past learning such as lesson learned from previous projects. Building adaptability
and resilience in a project keeps the teams on track to the desired outcome. When internal and
external factors change and it helps to recover from setbacks. The more we build this into our plan,
the more we expect it, the more we're able to adapt quickly, the more we're able to absorb these
impacts quickly, the faster we can get back to work and we can be successful. These features also
help teams learn and improve so that they can quickly recover from failures or setbacks and
continue making progress towards delivering good value. Every project we work on will have a hit.
Every project we work on will have unexpected consequences or problems. Every project we work
22
 Section 05: Project Management Principles

on will encounter a change or some kind of thing in the environment, some kind of new regulation
or something that we have to adapt to. Be prepared for it. So in this particular principle they're
saying hey, embrace it. Know it's coming because when it shows up, I want you to be able to
absorb it. I want you to be able to manage it so your project can keep moving forward.

Change
In this video, I'm going to be talking about enable change to achieve the envisioned future state.
This is a principle by itself. You know, when you're managing a project, changes are going to
happen. People are going to ask for changes. People are going to want to modify the scope,
modify the schedule, modify the quality requirements, modify the budget, and that's just on the
project. One of the things we have to do though when we're managing a project, when we think of
changes is we have to change people attitude towards accepting changes. You see, when a project
is finished and the output is there, the deliverable itself, it's changing the organization from one
state to another. Organizations do projects to change its state, it's state of selling two products to
its state of selling three products. It's the state of selling this product in this method to selling the
same product in another method. How does an organization change its state? By doing projects.
Projects are ways for the organizations to change its current state. And in today's world, you know
organization must change its state on a consistent basis to stay relevant. And that's what this
principle is about. It's about enabling the changes and envisioning what the future state would be
and ensuring that we meet it. Let's get into this. So one of the things we're going to be doing in
this principle here is we want to prepare those impacted for the acceptance to go from the
current state to the intended future state created with project output. Now, we want to come up
with like a structured way. A structured approach would help individuals, groups and organization
transition from that current state to the future state, right? Because not a lot of stakeholders are
going to want to embrace change. Every time, let's say you do a project in an organization that
modifies processes to make it more efficient, or at least you hope to make it more efficient. A
project in that nature is changing a lot of the way work is done. And you're going to have
resistance from stakeholders. And it's going to be a challenge for them to embrace it. Some
people don't want to change. Changes can originate from internal or external sources. Changes
can originate because a new CEO says we have to change these processes. Or a new regulation
says we have to change the method we develop this product. Enabling changes without a doubt
can be challenging. It's not all stakeholders wants to embrace it. There's a lot of people that just
doesn't like to change, they don't like to modify the way they work. They're very happy doing
something. If you're happy doing something and I come to change it, you don't want me to
change it because you don't know the new way, you'll be happier. It's the state of unknown, right?
If you're doing something in this method and you're happy doing it, and I say, "Okay, "let's change
that method to make it in my mind better." You might say, "Well, I don't want to change "because I
like the way I'm doing it. "I'm happy doing it this way." This, of course, can lead to a lot of
contention. Attempting too much change in a short time can lead to change fatigue and
resistance. We want to implement changes in a business in small increments. Don't do a massive
change quickly. You get a lot of resistance. So let's say you're a worker at a business following a
process, and I come in and I change the entire process very quickly. You might be resistant to that
because now you're not too sure what I'm doing. But if I implement little steps here and there and
roll out the change over a small period of time, roll out those new processes over a small period of
23
 Section 05: Project Management Principles

time, and you see, okay, okay, change this one step and then you change it and you try it. Okay,
that works well. Okay, change this next step now. You might be more willing to accept it.
Stakeholder engagement and motivational approaches is what you should be doing, you should
motivate people to change. Remaining relevant in today's business environment is a fundamental
challenge. For you to remain relevant in today's environment, businesses must change. Change the
product, change the delivery method, change the sales method, change the people that's making
it if it's not meeting requirements. Change in an organization can originate from internal sources.
Enabling changes can be challenging. Effective change management uses a motivational strategy
rather than a forceful one. So I already said it can be challenging. We want to motivate people.
When I want you to change the way you're doing something or change the process you're
following, I should be utilizing more motivational strategies, not just, hey, do this because I said so,
but show you why the process is better. Show you why this deliverable is better. Show you why this
product, and then you'll be motivated yourself to change. Knowing and addressing the needs of
stakeholders to embrace change throughout the project cycle, project life cycle helps to integrate
the result in change of the project work, making a successful outcome. So you knowing that your
stakeholders are going to need to embrace this change can set up the right expectations
throughout the project lifecycle. Make them more involved. Then they'll really see the benefit.
That'll keep them motivated about the change itself. When it comes to managing changes, guys,
it's something that you're going to encounter. Almost all project will change an organization from
whatever state it's in right now to some type of a new state. Almost all projects, especially large
projects and businesses, will face the resistance of changes from particular stakeholders. What
motivational strategy can you use to keep them motivated, to make them embrace the change?
How can we roll out the deliverables in a short manner? In other words, short changes versus a big
change manner. How can we basically make them acceptance of the changes? Remember
something, guys, if we don't change, we go out of business. And this principle is saying we need to
embrace this. We need to envision it because we got to go from that current state to that new
future state to even survive in today's world.

24