YT YouTube2Text

YouTube2Text → Transcripts → Fundamentos de la Dirección de Proyectos El PMBOK Guide y sus principales procesos

Fundamentos de la Dirección de Proyectos El PMBOK Guide y sus principales procesos — Transcript

by EALDE Business School · 7,701 words · 1,215 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:11Well, hello. Well, thank you very much,
0:14Gaetano, for this introduction, and
0:16good afternoon to everyone. Or good
0:19morning, I hope. I hope you are well,
0:23and yes, indeed, as Gaetano mentioned,
0:26today I am here to talk to you a bit
0:29about the project phases and project
0:32management. This is me, I am Charo
0:37Frisneda, and well, I am a PMP and also
0:42an authorized training partner for the
0:46PMI for PMP training. I am certified in
0:51Change Management, Lean Management 3.0,
0:53have initial training in architecture
0:56from the Polytechnic University of
0:57Madrid, and a postgraduate degree in
0:59strategic project direction and
1:01management from IE Business School.
1:05Well, my career in project management
1:07is quite extensive. Coming from an
1:10architecture background, I started
1:12doing projects from a very young age,
1:15so my professional and personal life
1:17are totally project-oriented. So,
1:22welcome, and I hope you enjoy these 45
1:26minutes that Gaetano has given me for
1:30this class. Welcome to my students if
1:35you are here, because we are right at
1:37this moment covering the phases and
1:40processes of a project. Well, let's get
1:43started. So, what are we going to see?
1:46We are going to look at the influence
1:47of the organization and the project
1:48life cycle. And here we are going to
1:51break down two points that are very
1:53important when considering a project,
1:55which are the business environment and
1:57then we will talk a bit about the
1:58project life cycle. Next, we will
2:01explain and look at the project
2:03management processes from a very high
2:06level. I want to state beforehand here
2:10that, regardless of the PMBOK version
2:13changing—with the seventh edition
2:16about to be released—project
2:18management is a profession, and as such
2:21, regardless of how the exam is
2:23structured, every project is managed
2:26with best practices, and those best
2:30practices have a lot to do with what we
2:33are going to see here today in a
2:35general way. This is not a course, this
2:40is not a webinar about certification or
2:44the guide for PMP training. It is,
2:50however, a webinar that talks about
2:52project management from a general point
2:54of view and focused on the PMBOK. Of
2:58course, as I say, regardless of this,
3:00the PMBOK can change versions as much
3:03as it wants, but in the end, the
3:05essence remains the same, which is what
3:07I am going to briefly explain to you
3:09today. Well, a project operates in a
3:14business environment, and you have to
3:16keep that very much in mind when
3:19starting a project, right? The project
3:23needs the organization to reach its
3:25objectives, to reach its results, and
3:28to reach, let's say, its management.
3:33Well, the characteristics of the
3:36organization in which a project
3:38operates, which influence it, affect it
3:40, and so on, are determined, as you can
3:43see here, by the characteristics of the
3:46organization itself. We are talking
3:50about rules, conditions, systems,
3:52tolerances, codes of conduct,
3:54environments, hierarchy, and
3:56organization. We are talking, let's say
3:58, from the general point of view of
4:00what a company is. It is not the same
4:02to start managing a project from an
4:04agile perspective in a hierarchical
4:07organization, because it would not make
4:09much sense. Furthermore, the
4:11characteristics of the organization and
4:14the organization itself influence and
4:16adapt to the projects, excuse me. Well,
4:19let's look a little closer at what this
4:22business environment is like in project
4:25management, what factors a project
4:27relies on, and how project management
4:30and direction help us. In other words,
4:32when we start a project, where do we
4:33begin? Well, we start here, we start
4:37with the so-called project management
4:39influence factors, which are the
4:41Organizational Process Assets, which in
4:43the project environment we call OPAs,
4:45and the Enterprise Environmental
4:47Factors, which in the project
4:49environment we call EEFs. Let's see
4:52what each of them is. Well,
4:54Organizational Process Assets, the
4:57so-called OPAs, are everything that is
5:00written down and helps us, let's say,
5:02to manage, define, plan, execute,
5:05monitor and control a project, and
5:07close a project. That is to say, they
5:10are those policies and procedures that
5:13are made to carry out the project work.
5:16They are the databases of historical
5:18information. For example, let's give an
5:21example such as procurement, when we
5:24have to buy something for the project.
5:28We have to make purchases, we have to,
5:30yes, buy directly, enter into contracts
5:32. Well, if the company has a policy
5:35adapted to all procurement management,
5:38our project will have to adapt to that
5:40policy. So, in addition to that
5:43historical information, there's a
5:45number of suppliers we can reach out to
5:48. These are knowledge bases with
5:51records of learning from other projects
5:53, such as lessons learned, nothing more
5:55, nothing less. Ultimately, these
5:59answer the question of what information
6:02, tools, documents, or knowledge our
6:04company possesses that can help us plan
6:07, manage, and, let's say, carry out our
6:10project—everything that is written
6:13down. And then there are the enterprise
6:18environmental factors, which is what is
6:20not written down—that is, the
6:22condition and market situation in which
6:25the project finds itself, in order to
6:27move forward or decide whether to
6:29launch it or not. The organizational
6:32culture has a huge impact when it comes
6:34to carrying out projects. The
6:36infrastructure. This is a project being
6:40carried out on-site, a project on a
6:44global level, meaning no team member is
6:48, let's say, in an on-site location to
6:52manage the project. In other words,
6:55enterprise environmental factors are
6:57not under the project's control, but
6:59they influence and affect the project,
7:01and it is something we must take into
7:02account. Ultimately, EEFs are not under
7:05the control of the project, but they do
7:07have an effect. We have two
7:10environments, internal and external,
7:12which, as I was mentioning in the
7:15previous slide, are what you see here:
7:17culture, infrastructure, resource
7:19availability, and personnel
7:21availability. And then the external
7:25ones, like legal restrictions, market
7:28conditions, government and industry
7:31standards—the regulations we must
7:34follow when undertaking a project,
7:37right? Well, and how does the
7:41organization influence projects? The
7:43organization has a huge influence on
7:46projects. Here I’ll show you a chart
7:50that illustrates how, depending on the
7:53project’s characteristics and the
7:55organizational structure we are in, a
7:58project manager will have more or less
8:01authority regarding the direction or
8:03leadership of a project, right?
8:08Regarding this structure, for example,
8:11the functional one—which we see here
8:15in Spain, for instance, in the entire
8:18public administration sector, like
8:22ministries—they operate by
8:24departments and are very characterized
8:28by silos, meaning communications are
8:31very, very, very complicated, and the
8:38project manager's authority is little
8:40to none because, in the end, they
8:42report to a department head, right?
8:45Resource availability is also low
8:47because it’s the department head who
8:50manages, not the budget controller, and
8:52the project manager's role is part-time
8:55precisely because projects are usually
8:58not departmental or strategic in nature
9:00, right? And the administrative staff's
9:04dedication to the project is part-time,
9:06just like the project manager's role.
9:09As we move into matrix structures, we
9:12find the Balanced one, where there is a
9:1450%split in authority with a boss, a
9:17manager, a department head. And here we
9:20move into what is a private
9:21organization, that is, a private
9:23company. Depending on where we are, in
9:27the strong matrix, the project
9:29manager's authority is very much
9:32aligned with how much trust or project
9:35structure or project maturity the
9:38company is starting to have, right?
9:41Resource availability is likewise
9:43moderate to high. Who controls the
9:45budget? The project manager, meaning
9:48it's not the department head, but the
9:50project manager. The dedication is
9:52full-time; they are dedicated to the
9:54project, and the administrative staff's
9:56dedication to the project is also
9:57full-time. This means the project has
10:00scope, that projects are important
10:02within the organization, and that the
10:05role of the project manager is
10:07officially established as such. When I
10:10talked about the functional, or well,
10:12the weak structure, which is more or
10:14less the same, let's say that the
10:18project manager figure is simply a mere
10:21coordinator or a facilitator of
10:24information, right? So, it's important
10:28to know, when we are in an organization
10:31and they call us project managers,
10:34whether you are truly a project manager
10:37who will have, let's say, the authority
10:40of a project manager, or if you will
10:43simply be a coordinator, a coordinator
10:46with no authority at all, acting more
10:48like an information facilitator than
10:51anything else. Then there is the
10:55project-based structure, for example,
10:57which are companies, let's say, the
11:00typical—excuse me—the typical
11:02consultancies that work by projects and
11:05for projects, where the role of the
11:08project manager is totally relevant,
11:10right? And also has full authority as
11:13such. Well, it is important that we
11:16know what environment we are operating
11:19in, as we said, meaning what culture,
11:21what policies, and what are not. And
11:25within the company's matrix
11:26organizational structure, what project
11:29maturity the company has, to know, well
11:31, what authority you will have as a
11:33project manager. This is ultimately the
11:38first thing to know the moment we start
11:40getting into project environments,
11:42right? Well, when we were talking
11:47earlier about a project manager in a
11:53company, usually when they want or need
11:55resources for their project, in matrix
11:58organizations—it could be weak,
12:00though less so, but certainly balanced
12:03or strong. Let's say there has to be an
12:07agreement between the project manager
12:10and the functional manager, because, in
12:12the end, the project manager—the
12:14resources don't belong to the project
12:16manager; they are resources allocated
12:19for a certain time, and the project
12:21manager has to tell the functional
12:23manager what is needed and when, and
12:25the functional manager will provide the
12:28who and the how. You are not the owner
12:32of the resources at all, and the who
12:36and the how are very, very, very
12:39dependent on how important and
12:41strategic the project we are going to
12:45manage is. If it is a strategic project
12:49, the functional manager will know that
12:51the who and the how will have to be key
12:53figures because it is an important
12:55project, and the functional manager
12:57will also benefit from that project. If
13:00it's not a strategic project, it will
13:03be given to whoever has the least
13:06workload, and as a project manager,
13:09since your ultimate goal is to reach
13:12that result, you will have to train and
13:16develop the members assigned or
13:19allocated to your project. So, this is
13:22important. In the end, there is always
13:26an agreement between the project
13:28manager, if they cannot hire directly
13:30and must rely on the functional manager
13:33or department head. Well, regarding the
13:38project environment, uh we have one
13:43more variable, in addition to what we
13:45have already discussed, which is the
13:46stakeholders. Stakeholders, as many of
13:49you know, are individuals, groups, or
13:51organizations that can affect, be
13:53affected by, or perceive themselves to
13:55be affected by a decision, activity, or
13:57outcome of the project. Let's say that
14:00when we start or initiate a project, we
14:02have to identify who our project
14:05stakeholders are within the project
14:07environment. So, these entities, these
14:11people, these groups—identifying them
14:14from the start is fundamental because,
14:16ultimately, within the project
14:19environment, stakeholders will have a
14:21significant influence. In fact,
14:25stakeholders help us define the
14:27requirements of the project to then,
14:30let's say, begin defining the scope. No
14:35, the project scope isn't the topic
14:37today, but let's stick to what the
14:39environment, processes, and phases of a
14:42project are. But well, as an
14:45environment, and knowing it is very
14:47important to know who the stakeholders
14:49are, well, here you have them. Then
14:53there is the environment, which also
14:57includes the sociocultural aspect.
15:01Meaning, how the way people and
15:03organizations relate can influence
15:05things, along with the international
15:07political aspect, such as what
15:09legislation is in place, the climate,
15:12time zones, holidays, etc. When
15:14managing a project, it is very
15:16important to know which environment we
15:18are operating in among these three. The
15:21physical environment, right? I mean,
15:23how much impact can the project have on
15:25the population? Because, in the end,
15:28they are everything we see here, they
15:31are, uh, important aspects: from a
15:33demographic point of view, from an
15:35economic point of view, from an
15:37environmental point of view, from the
15:40point of view of the regulations we
15:42operate under, the political climates
15:44we move in, and. And this, well, we
15:48must also take it into account within
15:49the project environment. So, as you can
15:53see, I haven't talked about the project
15:56yet; I am talking about what is
15:58important to consider before starting a
16:00project. Well, let's enter the project
16:04life cycle. And what is a project life
16:07cycle? It is the series of phases a
16:09project goes through from its inception
16:12to its closure. That's all there is to
16:14it, right? Ultimately, each
16:16organization determines the life cycle
16:18of its projects, okay? And based on its
16:20own needs, which has a lot to do with
16:23the industry or the technology being
16:25used. In the end, life cycles, as they
16:28say, are a series of phases, and these
16:30phases can be sequential, they can be
16:33concatenated, they can take different
16:35forms, right? This adapts, let's say,
16:39to the industry, the company, and so on
16:43. Normally, the transition from one
16:47phase involves the delivery of some
16:49product or partial result, okay? No, it
16:52is not the project's final result. Here
16:55you can see the life cycle of an IT
16:56project, including the analysis phase,
16:58design phase, construction, testing,
17:00and implementation. The deliverables of
17:03a phase can be—must be—approved,
17:06sorry, before starting the next phase.
17:09In this case, that's how it is, right?
17:12I mean, surely once I conclude the
17:15analysis of an IT project, well, this
17:18analysis deliverable must be approved
17:21before starting the design, and so on
17:24until I complete the project phases.
17:28And this is nothing more than the life
17:30cycle. Take note of project management
17:33versus a project life cycle. Project
17:36management is based on the processes of
17:39initiation, planning, execution,
17:41monitoring, control, and closing. And
17:45the life cycle, as we saw previously
17:47for an IT project, has these processes
17:50with these phases, excuse me. So,
17:54imagine this: within analysis, the
17:56project management team proposes that
17:58we likely need to go through all the
18:00phases; that is, through all the
18:02processes of initiation, planning,
18:05execution, monitoring, and control to
18:07complete this analysis phase, and so on
18:09with design, construction, testing, and
18:12implementation. That is what it
18:14ultimately means when we talk about a
18:16sequential phase. Here I bring you,
18:21let’s say, what each process includes
18:23within project management. And in the
18:27initiation, as we have seen before in
18:30the stakeholder environment, we
18:32identify the stakeholders, we clarify
18:35the objectives and expectations of the
18:38project itself; that is, what the
18:40objective is, what result it will have,
18:43and regarding strategic alignment, what
18:46benefits it will bring to the
18:48organization, and what the acceptance
18:50criteria are for the project to be a
18:53success or not. The organizational and
18:56decision-making scheme, that is, the
18:58governance body. And in the end,
19:01launching this project means, well,
19:03bringing everything together, and in
19:05this case through a project charter,
19:08keeping everything quite clear, at a
19:10high level, of course, but having it
19:12very clear, right? What is it that the
19:15project must achieve at a high level,
19:18right? Regarding planning, here we
19:20begin to outline the scope with respect
19:23to the project charter that has been
19:24formalized. Furthermore, the initiation
19:28charter is the document by which a
19:31project is launched and authorized by
19:33the project sponsor. Therefore, if a
19:37project manager launches a project and
19:39does not have a signed project charter,
19:42I think that, according to project
19:44management best practices, if they have
19:47problems in the future, it is likely
19:49because they do not have the formal
19:51authorization to start the project.
19:55This is the important thing about a
19:57project initiation process, right? In
20:01planning, as you can see, we begin to
20:03define the scope and the requirements,
20:05and the requirements are defined for us
20:07by, among others, the stakeholders. We
20:11then begin to fit the project lifecycle
20:13, that is, how this project will be;
20:15whether it will be from a waterfall
20:17environment or if it will be agile. I
20:21mean, because in the end it comes to us
20:22very well defined, let's say, from the
20:24project charter. A project manager
20:27already knows where the project is
20:29headed, right? Especially because they
20:30also have to take the organization into
20:32account. Well, quality assurance, the
20:35use of metrics, everything is
20:37ultimately defined in the planning. Uh,
20:40we get into execution and start to
20:42execute everything we have planned,
20:44that is, all the diagnostics. Uh, and
20:47here we already start to have, let's
20:49say, information to perform that
20:51project monitoring and control based on
20:53what was planned, right? If we are
20:56deviating from the project or not, well
20:59, we start, let's say, making changes
21:02to get back to executing. And
21:04monitoring and control serves precisely
21:07to monitor what is being done in
21:09execution with respect to what was
21:12planned. And then there is the closing,
21:14which is very important, where, let's
21:16say, the result and all the project
21:18deliverables are evaluated and the
21:20formal project closure is done. So
21:23these are the processes of what project
21:25management is, of the management of a
21:28project. Well, these are the types of
21:32life cycles. Uh, because, uh, there are
21:35three, uh, well, actually there are
21:37four, that we are going to see now,
21:39which are predictive, adaptive, and
21:40iterative-incremental. Here you have,
21:43let's say, what the characteristics of
21:46each one are. The predictive is the
21:49waterfall model, in which the scope,
21:52time, and costs are defined as soon as
21:54possible, and usually the scope or the
21:57deliverable product is quite well
21:59defined, right? Incremental starts from
22:04a global vision, and through the phases
22:07and iterations, one gets closer, let's
22:10say, to the project, right? And above
22:14all, what they have to see here is that
22:17they add functionality to the product
22:19in each iteration. It is used in large,
22:22complex projects or with changing
22:24objectives and scopes. And then the
22:27adaptive is what we, and what you
22:29surely know well, is. Which is, let's
22:31say, Scrum, right? Very fast iterations
22:34through sprints, where the duration and
22:36cost are the same. The global scope is
22:40broken down into a set of requirements
22:42which is the backlog, where we start to
22:45prioritize through this backlog and
22:47where, through the sprints, we provide,
22:50let's say, functionality to the product
22:52through the minimum viable product,
22:55right? The iterative, incremental, and
22:58adaptive are very similar. Look, here
23:00I'll show you a more graphic example of
23:04what each one means. Do you see the
23:06waterfall model? Well, for example, the
23:09waterfall model, you see that we've
23:11seen, just like the IT lifecycle, it's
23:13related to requirements, design,
23:15implementation, testing, and
23:17maintenance. Right, well, in the
23:19requirements, just the requirements
23:21part, look at that, right? To initiate,
23:23plan, execute, monitor, and then
23:25there's the incremental one where you
23:28start from that vision and you make,
23:31well, you make approximations, right?
23:34Iterative, the global vision directly,
23:36and through approximations we are,
23:37let's say, obtaining what is the final
23:39product. And the iterative incremental,
23:42well, it has it from the incremental
23:45point of view, that is, we are making
23:47approximations from the global point of
23:50view, and these are the lifecycles,
23:52right? Which one do I work with? Which
23:54is the best? It depends, I mean, in the
23:57end it depends, I mean, the lifecycle
23:59of a project is largely marked by the
24:01type of project, it's marked by the
24:04organization we work for, and it's
24:06marked by the scope, right? If it's
24:09defined, if the project objectives are
24:12changing or not, if it's a fast project
24:15or not, or if it's a project that needs
24:17a very, very, very close plan, right?
24:21To get it to get it started. It depends
24:24, it depends. Well, in the end, this
24:27cycle has a lot to do with the
24:29influences, right? The VUCA environment
24:33we move in has quite a lot to do, let's
24:36say, with what the project lifecycle is
24:39within the complexity. Well, in the end
24:42, for us, the constant, let's say, is
24:44change and not the other way around.
24:47And this is what gives us many
24:49influences when it comes to managing a
24:52project, when deciding what a project
24:55cycle is, and when executing a project,
24:58right? Look at this one, for example,
25:01by Ralph Stacy. It is, let's say, a
25:05good, it is a good, it is a good
25:10indicator, let's say, that depending on
25:13the degree of complexity or the degree
25:15of uncertainty of the project, we go to
25:18one type of project or another, right?
25:21For example, the waterfall, which is
25:23low, it's a very low degree of
25:25uncertainty, which is predictable, and
25:27the complexity is low, in quotes. When
25:31we talk about complexity, this means
25:33that the scope is more or less defined
25:36and we know perfectly well what we want
25:38, okay? It's an obvious environment, so
25:41we just do it, right? This is the case,
25:42for example, of a house, right? Or
25:44something where we know perfectly well
25:46where we need to go, where the goals
25:48aren't constantly changing, okay? Uh,
25:51then in a complicated environment, we
25:54use Kanban, which is perfect for—
25:57besides, these are complicated
25:59environments where we don't have a very
26:02well-defined scope, and it’s also an
26:04excellent framework for that first
26:07approach to project management, okay?
26:11Meaning, we don't have much knowledge,
26:13but we do have to outline things; then
26:15there's Scrum in a complex environment
26:17where we keep doing iterations and
26:19seeing what happens. And this has to do
26:21with technological projects, right? Why
26:25are agile methodologies used in
26:27technological projects? Because, uh,
26:29technological projects have to be very
26:31fast. Because if we, uh, don't give a
26:35technological project enough time, when
26:37we launch it, it’s already totally,
26:40uh, out of place and off the market; so
26:43that’s the, the difference, right?
26:47But Scrum, even if we think it's easy,
26:49is not easy at all because it has a lot
26:51to do with these ceremonies and
26:53artifacts that have to happen. And
26:56carrying out an agile project, just
26:58like a waterfall project, requires
27:01project knowledge, of course, knowing
27:03where we are operating and knowing, of
27:06course, where we want to end up, right?
27:09And then there's Lean Startup, where
27:11the environment is chaotic, and here
27:14it’s assumed that projects are done
27:16for, let's say, transformation and in
27:18complex business environments, right?
27:21Where there are no scopes; Lean Startup
27:23can't be brought in from the point of
27:25view of agile methodologies, but also
27:27from the waterfall point of view, and
27:29well, it’s already about changes in
27:31important organizations. Well, these
27:35are the influences, right?,that in the
27:38end we handle in a, in a, in a project.
27:42That we can do one part of the project
27:44from an agile perspective and another
27:47from a predictive point, half and half
27:49agile and predictive. We define this
27:51for ourselves, right? Here, let's say
27:54we are talking about what are, uh,
27:56hybrid projects, right? Which is
27:58usually what we are working with. Now
28:01we can start a project by defining the
28:03planning from a waterfall point of view
28:05, defining a good scope. In fact, I
28:08find it fundamental to define the scope
28:10of a project, and then from there we
28:12can execute it more agilely, right? I
28:15mean, from a more agile environment,
28:17right? I mean, in the end we decide
28:19what percentage of agile the project
28:20has, what percentage of predictive the
28:22project has, right? In the end, it is a
28:25very good tandem, right? The, the, the
28:27mixtures, right? What percentage it has
28:30of, or what percentage of predictive it
28:32has. Well, the management processes and
28:35the production processes of the project
28:37. Management processes are the
28:39processes that are oriented to
28:41coordinate all project work, including
28:43the production processes. And here we
28:45are. Let's say the processes, let's say
28:48, there are initiation, planning,
28:49execution, monitoring and control, and
28:51closing processes that we saw before,
28:53okay? They are oriented to coordinate
28:56all project work, okay? And they are
28:59performed at least once in each phase
29:00and are repeated in all phases of the
29:02project life cycle when we talk about
29:04sequential ones. And then there are the
29:07production processes, which are
29:09processes oriented to create the
29:10product, service, or result that
29:12justifies the undertaking. They are
29:14oriented to the creation of the
29:16deliverables. And here, for example,
29:18you see the graphic I am showing you,
29:20on one hand, there is the warehouse and
29:21the processing. What is the product?
29:24The product in the end is the little
29:25can of tuna, nothing more, nothing less
29:27, right? And they are precisely
29:29oriented to that; the products are
29:31homogeneous within each phase of the
29:33project life cycle and different from
29:35other life cycles. Of course, because
29:38managing, for example, the management
29:40process of a warehouse is not the same
29:42as the management process—that is,
29:44how I am going to manage processing
29:46versus a warehouse, right? That is the
29:48difference, but in the end, it leads me
29:51to a result. The relationship between
29:53product and project life cycles, well,
29:55they are these, right? In the end,
29:57projects are there from the point of
29:59view of conception. There are projects
30:01in growth, there are projects in
30:03maturity, there are projects in decline
30:05, and there are projects in withdrawal.
30:07So, imagine, within the entire life,
30:10the product life cycle, from when we,
30:13let's say, put the idea into motion
30:15until it reaches its withdrawal process
30:18, right? And growth, when this product
30:22might need an update, right? Well,
30:26project phases. Project phases are a
30:30set of logically related project
30:32activities that culminate in the
30:34completion of one or more deliverables.
30:37Look at this, for example, the graph
30:40that I'm showing you here is an example
30:43of a single-phase project, okay? The
30:47number of phases will depend on the
30:48size and complexity of the project.
30:50Let's look at more now. This one has
30:54three sequential phases, as you can see
30:57, within the dismantling of a facility,
30:59cleaning, landscaping, or overlapping
31:02phases. That is, I start with a phase,
31:06which is the design phase, through all
31:08the project processes, that is,
31:11initiation, clarification, etc., and at
31:13the same time, they are overlapping, I
31:16begin with the construction phase.
31:19Agreed? So it depends, I mean, I can
31:21perfectly do it if the project allows
31:23me to. In fact, I decide how I'm going
31:25to do it, agreed? And normally they do
31:27overlap, some do and some don't. These
31:31are more examples, right? The example
31:33of the single-phase project, well, the
31:36installation, the two-phase project,
31:38and the three sequential phases, as we
31:41saw in the other one. Then there are
31:44the conceptual and construction phases,
31:46that is, the definition of a product
31:49where finally, and as a result, where
31:51notice the phases, let's say, viability
31:53on one hand, analysis on another, and
31:55design. And there is a point that is
31:59the exit gate, which is, let's say, an
32:01exit door. Like we said before,
32:03likewise, until I verify that it is
32:06viable, I don't enter into the, let's
32:09say, analysis phase, and so on. And
32:12what it requires to mean the product
32:14elaboration, likewise, in construction,
32:16testing, the bottom part, there are
32:18points called checkpoints, which are,
32:20well, red points, right? Where, in the
32:23end, until I finish one thing, I don't
32:24start with another. Notice that none of
32:26the phases we see here in the project
32:29—that is, feasibility, analysis,
32:31design, construction, testing,
32:33deployment—carry the name of any
32:35process group, such as initiation,
32:37execution, or planning. None,
32:40absolutely none. That is the difference
32:44. Well, the project effort in each
32:49phase, here you can see, and eh, on the
32:52graph on the left, which is the start
32:55of the project—I mean, the effort
32:58varies—the execution of the work is
33:01where there is the most effort, and
33:04notice the gates, right? The project
33:08charter acts as a gate to start
33:09planning the project management plan,
33:11which is what gives me the kickoff. To
33:13begin, I deliver, I move to work
33:16execution on the accepted deliverables,
33:19eh, based on project monitoring and
33:22control, and then I close the project,
33:25right? And then, the project documents
33:28are archived with lessons learned, etc.
33:30And then here is risk and uncertainty.
33:33Ultimately, at the beginning of a
33:35project, eh, a project itself is
33:37already uncertainty. We manage
33:39uncertainty. Eh, as project managers,
33:43we manage uncertainty because when we
33:46start to manage, initiate, and plan a
33:48project, we gain information as we
33:50advance through the project; therefore,
33:53risk and uncertainty are much higher at
33:56the start of the project. And that is
33:59what we ultimately have to take into
34:00account, right? That at the beginning
34:04there is much uncertainty, but as we
34:06advance, eh, the uncertainty is lower,
34:08and this means that ultimately the cost
34:11of changes is low. When I am planning
34:15the project it is very low, and when I
34:17am executing, well, the cost of changes
34:19costs me time and it costs me money. So
34:22, that is an advantage, let's say, of
34:25doing good project planning regarding
34:28risks. Identifying them is fundamental.
34:32Throughout the entire life of the
34:33project, because eh, we may have many
34:35risks at the beginning that, as we gain
34:37information about the project, those
34:39risks are mitigated as we keep planning
34:41, right? And what is a process? Well, a
34:47process—we have spoken about phases,
34:48so now let's talk about processes. A
34:50process is a set of interrelated
34:52activities necessary to obtain the
34:54product, service, or result of the
34:56project. That is, the project in the
34:58PMBOK. All processes are defined in the
35:01following way. Inputs, which are the
35:04documents I will act upon, and tools
35:07and techniques, which are the
35:10mechanisms that will help me produce
35:13that output or resulting item, okay?
35:17And that is how the process of a
35:20project is, was, or still is based,
35:23let's say, from the perspective of time
35:26, regardless of whether there is a
35:31quality plan or process improvement
35:33plan, because those still exist within,
35:35uh, a project, uh, let's say that the
35:38next PMBOK, the new 7th edition version
35:40, will no longer have these inputs,
35:42tools, techniques, and outputs
35:44incorporated by that name. But you will
35:48still need to know what each one is,
35:50because they are indeed integrated
35:52within what a project is. Well, the
35:55PMBOK establishes five process groups,
35:57which is what we have been looking at:
35:59initiation, planning, execution,
36:01monitoring and control, and closing.
36:03And it is the project effort that we
36:06saw just a moment ago. These are the
36:11process groups, and they are linked to
36:13each other through the outputs and how
36:15they work, right? In the end, the level
36:18of interaction between processes over
36:21the life of the project. Initiation
36:26groups, having the authorization to
36:28formally start the project; planning,
36:30establishing the project scope,
36:32refining objectives, and defining the
36:34course of action and all the plans that
36:36I will take into account, planning it
36:38out. Execution processes, carrying out,
36:41let's say, putting into action all the
36:44work I have defined in the planning;
36:47monitoring and control, reviewing and
36:49regulating the project process and
36:51performance based on the execution.
36:56Taking as a starting point what I am
36:58planning, and the closing process, that
37:00is, formally closing the project
37:02through, well, those deliverables, the
37:04acceptance of the deliverables, lessons
37:06learned, and the administrative and
37:08financial closing of the project. How
37:13do the process groups work? Look, at
37:16the beginning, as we saw before, the
37:18effort of the cost of change without
37:20uncertainty, we work virtually in
37:22planning, meaning the cost of changes
37:24costs nothing because I am planning, I
37:26am getting information, and I am going
37:28from high uncertainty to low as I gain
37:30knowledge. And then there is the real
37:34one, which is when I start executing a
37:36project, so the real one is where, as I
37:39mentioned before, time and money have a
37:41lot to do with it. Here there is
37:44already a change control board that has
37:46to evaluate the changes that occur in
37:49the project, uh, to move forward, and
37:51well, it ultimately involves changes of
37:53corrective and even preventive actions,
37:56so, take note, right? In other words,
37:59in the end, you have to have, from the
38:01point of view of planning and project
38:03initiation, well, the most possible so
38:06that when we start executing a project,
38:08we try to have the fewest changes. A
38:10project will always have changes, one
38:12way or another. And we enter the 10
38:15project management knowledge areas,
38:17which are, let's say, the activities
38:21that make up a professional field, a
38:23project management scope, or an area of
38:25specialization. Here we have the
38:28management of scope, time, quality,
38:30cost, risk, human resources,
38:31communications, procurement, and
38:33stakeholders. All these knowledge areas
38:37are implicit in project management. In
38:40a project, regardless of whether we
38:42call it an area or not from now on in
38:45the PMBOK, we have to know where we
38:47stand, right? And scope management will
38:50definitely be in all projects. Time
38:53management will definitely be in all
38:55projects, as will quality and cost;
38:58they are knowledge areas inherent to
39:00the direction and management of a
39:02project. Each one, of course, defined
39:08and adapted to the project. Not all
39:12knowledge areas in this case have to be
39:14fully defined; they must be adapted to
39:17a project. Integration management
39:20describes processes and activities that
39:22are part of the various elements of
39:25project management. That is, this is
39:27viewing it as a whole. Here we have,
39:29let's say, the management of how the
39:31project is planned, how it is directed,
39:33how project knowledge is managed, how
39:35project changes are managed,
39:37configuration management, and project
39:39closure. In other words, integration
39:42management is integrating the project
39:43and viewing it as a whole when I am,
39:45let's say, planned. Integration
39:47management, if you like, is the core of
39:49the project. Scope management, the
39:52definition of all activities and work
39:54packages of the project, absolutely all
39:56of them. We say that what is not in the
39:59scope is not part of the project, and
40:01here lies the skill in determining what
40:04is part of a project or not. In scope
40:09management, in my opinion, it is the
40:12most, let's say, complicated part of a
40:15project; because from here, you already
40:18, um, manage, you manage all the
40:21resources, you manage the schedule, you
40:24manage, you manage, but the scope is
40:27what, let's say, gives you that vision
40:30of what my project is like. Furthermore
40:34, scope management is a fantastic
40:36communication tool, precisely because
40:39you can see yourself reflected in where
40:41you are working, in each project work
40:43package. Time management is schedule
40:46management, how long the project lasts
40:49and how it will be, how the project
40:51time will be managed, how resources
40:54will be managed, how long the
40:56activities will take. Cost management
40:59is simply the project budget. That is
41:02to say, in the end, it is putting an
41:04amount and money to the project
41:06activities that I have previously
41:09defined through the work packages in
41:11the scope, in the activities, in the
41:14schedule; well, putting a cost to this.
41:18And, besides, well, cost management
41:21also gives you, let's say, it is very,
41:23very, very good information about the
41:26project's cash flow, let's say. That is
41:30to say, in the end, a project is an
41:32investment and as such we have to know
41:34what the cash flow is, that is, how
41:35much we are going to, when we are going
41:37to spend more money on the project.
41:40Quality management. Now we say that the
41:44project has a triple constraint, in
41:46reality it has a fourth triple
41:48constraint which is quality management
41:50and it is inherent to the whole project
41:52. Resource management is precisely
41:55about that, right? Leading, motivating,
41:57developing, solving people's problems,
42:00right? We manage resources, we develop
42:02them and in the end we deal with people
42:04, which means we deal with resources.
42:07And that is the skill, when do they
42:09enter the project? When do they leave?
42:12What do they need so that the
42:14activities we have to manage for the
42:17project, do they know, do they not know
42:19, etcetera, etcetera. To have that
42:22project team tending, communications
42:25management is transversal to the whole
42:27project. This is like, let's say,
42:29imagine the project is the body and,
42:31well, the blood that circulates
42:33throughout the body is the
42:35communication transversal to the whole
42:37project. Who do I have to communicate
42:39with? What? When? and risk management
42:43is fundamental. As I said before, we
42:46identify risks from the very beginning
42:48of the project. Well, apart from
42:52identifying them, we have to qualify
42:54them, know how severe a risk is,
42:56quantify it based on that severity, and
42:59plan its response and control.
43:04Procurement management, what do we need
43:07in our project? legal and budgetary
43:10consequences in planning. That is to
43:13say, those legal consequences under
43:14regulations, what kind of contracts we
43:16are going to make. We have a
43:18procurement department, a purchasing
43:20department that will take care of this.
43:23We have to do it ourselves. uh
43:27knowledge about what procurement is,
43:29and this has a lot to do with tenders,
43:31contracts, and so on. And stakeholder
43:35management, we have already seen it at
43:37the beginning of this webinar, the
43:39project environment and the
43:41stakeholders. Stakeholders are
43:44fundamental in our project. Managing
43:47stakeholder expectations is essential.
43:50We have to know who the most important
43:52ones are within our projects and
43:54involve them in our projects.
43:57Stakeholders have influence, they have
44:00power in our project, and that is what
44:02we have to do: analyze them to know
44:05what kind of power and influence they
44:07have or do not have, and know how to
44:10manage them and provide the appropriate
44:12responses and involve them in the
44:15project, in such a way that they help
44:17us. Let's say, a stakeholder helps us
44:20in the project, right? and managing
44:22their expectations. Those expectations
44:25that we all have very high, right? But
44:27in the end, the reality of the project
44:29is different. We manage expectations
44:32and stakeholders help us define the
44:35requirements of the project. Well, to
44:41finish, I wanted to show you here that
44:44the new, let's say, the new PMP ECO,
44:47that is, the contents that now,
44:50starting in July, although the exam is
44:53already being done this way, it is,
44:56let's say, aligned with version six,
44:59that is, with everything we have seen
45:02now. Uh, now it refers instead of,
45:06let's say, processes as such, well, it
45:08refers to people, process, and business
45:11environment, okay? So I wanted to bring
45:15it here as what is going to change and
45:18what is changing, but believe me, what
45:21we have seen here is not a
45:23certification course, but an
45:25introduction to the PMP certification.
45:30What we've seen here is what to keep in
45:32mind regarding project direction and
45:35project management, uh, what, uh,
45:37knowledge areas and what is part of a
45:39project, because in the new versions of
45:42the PMP or the PMBOK, even though there
45:44are domains (people, process, and
45:46business environment), uh, resource
45:48management, communication management,
45:51stakeholder management, and scope
45:53management are within these domains: in
45:55the people domain, the process domain,
45:59and the business environment we’ve
46:01also been looking at. And, well, I just
46:05wanted to wrap up with that. Thank you
46:09very much.
46:14Uh, I have 5 minutes, I think, to
46:16answer questions. Thank you all very
46:20much, and I'll go see what questions
46:23you have here. Let's see. Uh, yes,
46:45Felipe, it will be possible. Sure, yes,
46:48it will be uploaded. Joan Triana asks
46:51me, "How to adjust when last-minute
46:54changes or improvements become
46:56necessary without critically affecting
46:58the planning?" Well, uh, whether it's
47:02critical depends on the change.
47:05Normally, when you are in execution,
47:07according to best practices, you don't
47:09just make a change for no reason. This
47:12change must always be reflected in the
47:15project, because in the end, you have
47:18to perform change control; it’s a
47:21different matter if you have to, let's
47:24say, take that change to a committee.
47:29The project manager has authority, and
47:31depending on the threshold and
47:33tolerance—for example, imagine the
47:35project manager has the authority to
47:37manage up to an amount of € 3,000,
47:39just as an example, okay? Uh, well, if
47:42this change is less than € 3,000,
47:44then the project manager can manage it.
47:47What you can't do, for example, is do
47:50it without the project manager knowing,
47:53for starters, because perhaps a change
47:55that implies nothing now might imply a
47:58lot further down the line, so you have
48:00to be careful with project changes.
48:09Okay, thank you very much, Luis. Uh,
48:13Luis Adolfo, uh, good morning. Warm
48:16greetings from Lima. What is your
48:17opinion on risk development? Should
48:19these be addressed at every stage? Well
48:22, uh, risks in—well, risk development
48:24, the phrasing isn't exactly "risk
48:26development." Here in a project we
48:30identify risks; it’s not that they
48:32exist in every project stage, rather,
48:34we identify risks from the beginning
48:36and we manage risks throughout the life
48:38of the project, absolutely throughout.
48:43And we are qualifying and quantifying,
48:45if the case arises, as it’s a
48:46critical project at all times. Yes,
48:49risks are very important. In the end, a
48:53project manager—let's say a project
48:55manager is a good project manager when
48:57they are a good risk manager, right?
49:00Because they are mitigating and
49:01providing responses to risks, right?
49:04They are taking them into account. Okay
49:08? Which is—I don't have time to
49:10answer everything—what is the general
49:13factor that can affect the most when—
49:15what is the general factor that can
49:17affect the success of a project the
49:19most? Which general factor? What do you
49:22mean by general factor? I don't really
49:25understand, Adam Mauricio, what do you
49:27mean by general factor? Are you talking
49:30about environmental factors, about
49:32organizational process assets? It just
49:35depends on the environment. Are you
49:36talking about the political environment
49:38, the socioeconomic environment? It
49:40really depends on the project. A
49:42project is unique and a project is
49:44unique with a unique result. Two very
49:47similar projects ultimately have
49:48different results. Think about that. In
49:52the end, a project, I mean, it’s not
49:54that—what general factor can affect
49:55it most—it’s not that; each project
49:57is affected by one thing or another, it
49:59depends on the nature of the project.
50:02Okay, Carla, it is strictly that the
50:05director manages the project area well.
50:10Uh, well, Carla, it is fundamental. The
50:13project manager is the project leader,
50:15the one who has the project vision, and
50:17the one who will lead the project and
50:18deliver the result, of course. And yes,
50:22thank you. A user can be both at the
50:27same time. I don't understand,
50:29Alexandra, what do you mean by that? Uh
50:32, Nereida, uh, good morning. The
50:34process phases can be divided into
50:36sub-phases. Uh, if each sub-phase has a
50:40group of processes uh, of initiation,
50:44planning, monitoring and control, as
50:46well as closing. Hm, well, the phases
50:49of a project have, well, their
50:52sub-phases. I don't know what you mean:
50:55if in the initiation part, you mean if
50:57in the, uh, initiation phase, uh, in
50:59the phase, for example, of, uh, let's
51:01say requirements, there's the
51:02initiation, planning, uh, monitoring
51:04and control, and closing phase, and
51:06within that initiation phase there is
51:08initiation, planning, monitoring and
51:10control, and closing. No, that doesn't
51:13make much sense, honestly. When we set
51:16out to do the project phases, we start
51:18by initiating the project and planning
51:20that that that project phase based on
51:22that phase, right? We create sub-phases
51:25, right? Uh, what we do do, let's say,
51:27if maybe, uh, you might be thinking of
51:29that, are the work packages, let's say,
51:31which are broken down into activities
51:33and those are the ones we manage. What
51:39is the difference, Alexandra? What is
51:41the difference between the project
51:43manager and the sponsor? Can a person
51:44be both at the same time? Uh, no, they
51:47cannot. The project manager is the one
51:51who leads a project, is in the
51:53day-to-day of the project, and the
51:56sponsor is the one who provides, let's
51:59say, the resources, the one who
52:01controls, let's say they are the
52:03project manager's boss; they are, uh,
52:06the person who, when important changes
52:09to the scope, time, or costs need to be
52:12made that affect the project baselines,
52:15the sponsor is there. They are the one
52:17who provides the financial resources,
52:19that is, the one who tells you: "You
52:21have, uh, to get started, to start
52:25planning this project," and they are
52:27the person who, when the project
52:29manager is at a loss, let's say, with a
52:31serious problem, well, in the end, they
52:34turn to the project sponsor. The
52:38project manager reports to them, uh,
52:40it's the sponsor, that's who the
52:42project manager reports to, and, and
52:44the sponsor is usually not in the
52:46project. Nor are they in the day-to-day
52:49, they are outside, they are involved
52:50in other things. Well, imagine it could
52:52be the CEO of a company, the general
52:54manager of a company, they could
52:56perfectly well be a sponsor. The
52:58sponsor is the one who handles the
53:00steering committee, let's say, the
53:02reports, and it's not the project
53:03manager, unless it's necessary. Okay?
53:05Is that clear to you? No. Well, I'm
53:09afraid we can't continue any longer. It
53:11has been it has been a pleasure for me
53:14to have you all here. I hope this point
53:19was clear, and well, see you soon in
53:23the next one. Greetings to my students
53:27and to everyone else as well, and happy
53:29morning to those in the morning and
53:31good afternoon to those in the
53:33afternoon. Thank you very much. Best
53:35regards.

About this transcript

This page contains the full transcript of Fundamentos de la Dirección de Proyectos El PMBOK Guide y sus principales procesos by EALDE Business School, generated from the public captions YouTube serves with the video. The transcript has 7,701 words across 1,215 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.