PMI PMP Project Management Professional – Project Management Components

1. Section Overview: Project Management Processes Groups and Knowledge Areas

Welcome back. In this section we’re going to look at the project management components, the different parts of a project, so things that we didn’t know as a project manager and as a PMP candidate. In this section, we’re going to look at the different components of project management and how they work together. Very important that we don’t need to just have these silos of project management, but it’s integrated that they work together. So that’s one of the things we’ll discuss is the project management process groups and the project management knowledge areas.

Recall, your PMP exam has those five exam domains and those are based on the process groups. Well, across the process groups, we have knowledge areas, and those are the different chapters in the Pinbox. So our process groups Initiating, Planning, Executing, Monitor, Controlling, and Closing are integrated or crossed with the different knowledge areas. Chapter four of the Pinbox through 13, which we have integration, management, scope, schedule cost, quality, resources, communication, risk, procurement and stakeholders. I think I got them all, but those are the knowledge areas. So process groups and knowledge areas go together.

And so we have a really important assignment where you’re going to map out those processes. So you’re going to have exposure to the entire Pinbock in detail in this section. So if you’ve been hungry to get into some deeper material or some more exam specific material, now is your opportunity. A lot of things to talk about and cover. We’re also going to look at a Pinbox concept of tailoring the processes, something that you do in any organization, adaptive environments. So this is new to Pinbox six. If you’re working in a Scrum or Agile or XP or Lean programming, those are adaptive. So we’ll talk about adaptive environments. And then we’re going to look at the project business case and a benefits management plan, two really important concepts for your exam. So you can see this is a really big section with a really big assignment that I want you to complete. So we’ll talk about that as we get to that point of the course. All right, let’s get going. I’ll see you in the next lecture.

2. Reviewing the Project Management Process Groups

Welcome back. Let’s talk about the process groups. I know you’ve already seen this, you already know the process groups, but this is some really important information for your exam. And so I’m going to walk through the process groups and the processes just to kind of gel all this up. So let’s talk about these process groups and processes and how it will relate to your exam. So first off, of course, is the initiating process group. The initiating process group. We have two processes develop the charter and identify the project stakeholders. This is 13% of your exam, so about 26 questions. So 26 questions for two processes. That’s a pretty good return on your study time, a pretty good return on your steady investment.

The planning process group has 24 processes develop the project management plan, plan scope management, collect requirements, define scope, create the work breakdown, structure, plan schedule management, define activities. Continuing on, we have sequence activities, estimate activity durations, develop schedule, plan cost management, estimate cost, determine budget. Then we have planned quality management, planned resource management, estimate activity resources, planned communications management, plan risk management, and then we’ll identify risk on a continual basis, perform qualitative and quantitative risk analysis.

And then our final ones we have here plan risk responses, plan procurement management, and plan stakeholder management. This is worth 24% of your PMP exams, so 24 processes, 24% for a total of about 48 questions. So this one is not quite as valuable as the other knowledge areas. I’m not saying ignore it, but I’m saying study smart, study for what you’re going to be tested on. So yes, you’ll have 48 questions here, but most of these processes create a plan, so you have a pretty good idea of what’s happening in planning.

Now let’s talk about the executing process group. This group has ten processes and it represents 31% of your PMP exam. So 62 questions. This is a very important group to know for your PMP exam because look how many questions we have in relation to how many processes, the processes you need to know for executing and it will cover.

In this course, we have direct and manage the project work, manage project knowledge, manage quality, acquire resources, develop the project team, manage the project team, manage communications, implement risk responses, conduct procurement, and manage stakeholder engagement. Now, let’s talk about the monitoring and controlling process group. We have twelve processes monitor and control the project work, perform integrated change control, validate scope control, scope control, schedule control, cost control, quality control resources, monitor communications, monitor risk control procurements, and monitor stakeholder engagement. Those twelve processes will equate to 25% of your exam.

So roughly 50 questions. So that’s a pretty good return for your study investment. Our last process group deals with closing. There is only one process now in closing, and that’s to close the project or phase, and that equates to 8% of the PMP exam. So 16 questions on that one project process if you do nothing else or you want a last second cram no. Closing one process, really? Look at closing. You can close the project or the phase. So pay attention to that for your exam. About 16 questions on closing. All right. Good job. I told you it was quick. Just a quick review of these process groups. Keep moving forward. I’ll see you in the next lecture.

3. Work Performance Data, Information, and Reports

Welcome back. I hope you completed that assignment. It’s really going to help you in the remainder of the course, and it will help you to pass your exam. Now, let’s talk about three new terms. You need to know these terms and their characteristics.

And I’m talking about work performance data, work performance information, and work performance reports. Reports. We’ll see these three terms in all of the knowledge areas. They’re going to be serving as inputs, they’re going to be serving as outputs. So work performance data, work performance information and reports. So let’s really get a good grasp on these terms so we don’t have to talk about them in much detail in the remainder of the course. First off, here we have work performance data. Work performance data is where we’re talking about the raw data, the facts about the project work. So as work is done, you’re able to collect this data. It’s not very usable. It’s just data, raw data, just pure data about what’s going on in the project. So, for example, how percent complete is one activity? What’s the number of activities that have not yet started? What’s the number of activities that are in progress right now?

What was the planned start date of an activity and the finish date versus the actual start in actual finish? So data is all this type of information, just raw data, just all that stuff that you collect as a project manager through your status meetings and through your work authorization system and communicating with your project team. Data can include the cost of activities, the number of change request, number of defects, and durations, planned and actual durations. So data is just raw data. It’s the first thing that you have to have in order to create information and reports. So data comes first.

 Now let’s look at work performance information. Work performance information is where we have the analyzed work performance data, where we’ve taken that data, we’ve studied it, we’ve analyzed it, and then from that we have an ability to make decisions based on that data. So data becomes information. It’s informative, it’s been analyzed and studied, and we can use it. So now we can set that data to actionable results. So our status is where we are now. Based on that data, based on that information, I can act on it. So data to information, and now I have actionable results. So in other words, I need the data, I need to understand the data, so it becomes information and then I can act on it. Then we have work performance reports. A work performance report is how you package up information. So it becomes communicatable.

So work performance information is communicatable formatting. So a status report, a memo, maybe you use a dashboard, you do project updates every week. So it’s a way of taking data that becomes information and then being able to communicate it clearly. Most often we’re talking status reports here, but it could be an exception report. It could be a variance report, it could be a risk report. It’s anything that’s packaged up based on information and data. Now, how do you remember these? It’s alphabetical. Data comes first, so raw data information is second because you need information to act upon it. And then once you have that information, you want to communicate it. So you have to put it in a report, and it’s alphabetical data, information, reports. Okay, great. That’s the end of this lecture. Now, you’ve got three new terms that you’ve mastered. Data, information, reports. Keep going.

4. Tailoring the Processes

Let’s talk about tailoring the project management processes. You already know that you don’t have to use every process on every project. But then we also have to make a determination as to what depth we should utilize the processes that are selected. And then we could even tailor those processes to fit the type of projects that we’re managing, or our organization, or what’s most important to us in our project or our endeavor. So let’s talk about tailoring the processes. First off, there are four key facts that we need to know.

The first one is what processes are we going to use on the project? So I know I don’t have to use all the processes, but which ones should I use or will we be using in this project? The second one is to what depth? So, if we know, we have to do a manage quality process, but what does that mean exactly? To what depth? To what extent? Or we’re going to do risk analysis. So, qualitative and quantitative risk analysis, to what depth? If it’s a large, high profile project, typically I’m going to go deeper and more intense in those processes. A small, low priority project, pretty high level. I don’t need to invest a lot of time in all these processes. So depending on what the project is, the priority of the project, and the process that we’ve selected, we’ll make a determination as to how intense, to what depth, to what extent do we do that process.

We already know step three, not every process is needed on every project. So that’s a given. Now we’ve got that down. Typically, though, step four, the larger the project, the more processes are likely. So the bigger the project, probably you’re going to touch a lot more processes than a small project. A few more things about tailoring in the Pinbuck guide. Throughout the Pinbuck guide, we’ll see this idea of tailoring a process or tailoring processes. And these will be in the different knowledge areas chapters, starting in chapter four on integration management, all the way to 13 on stakeholder management. So what we’ll see here, step one, will be knowledge areas.

So each knowledge area, there’ll be some Tailoring. That can happen. We know processes. Step two here, processes live inside of knowledge areas. And then step three, we tailor those to fit your project. So it’s the project, the priority of the project, the characteristics of the project that will tell us which processes we need and to what extent do we need those processes. And then step number four, the fourth thing to know throughout the Pinbox guide, as I mentioned, we’ll see an option opportunity to do tailoring. So just be aware of that. Don’t let that throw you as we move through these chapters and Tailoring comes back again, every knowledge area, every process has an opportunity to be tailored. All right, I’ll see you in the next lecture.

5. Introducing Adaptive Environments

Earlier in our course I talked about the project life cycle and the project management life cycle. Recall that the project management life cycle was the idea of initiating, planning, executing, monitoring, controlling and closing. There are some other characteristics here of the project management lifecycle and the project lifecycle. There’s almost an overlap in how the work is planned and how the work is delivered. At the Pinback Guide 6th edition we’ll have to address what’s called both predictive and adaptive life cycles.

So as we move through the Pinback Guide you’re going to see little sections where it says a consideration for an adaptive environment. So let’s nail down the difference between predictive and adaptive. First off, a predictive life cycle is typically what we have in a construction environment where it’s plan driven, where I know everything upfront or most things up front in order to get started. So it’s a pretty good idea of where we’re going to get to the end of the construction project. Predictive life cycles are also known as a waterfall approach where we start at a high level, we do work, we go to the next phase and we do work and down and down it goes. So it is a waterfall moving closer and closer to the finish. So it’s a predictive life cycle or a waterfall approach.

It predicts the project lifecycle in construction upfront we can identify the phases that will move us from the foundation all the way to closing the project so it predicts the life cycle. In a predictive life cycle we typically changes to the scope are tightly controlled that we are a bit change adverse. Not to say that changes don’t happen in predictive, just generally we try to capture all of the requirements upfront and then once we’re in motion we become change adverse. Then we have what’s called an iterative and incremental life cycles. Iterative and incremental life cycles are when we go through iterations where phases are repeated through iterations iterations create deliverables. The detailed scope is what’s created for each iteration and changes to the project are expected.

What’s the difference though between iterative and incremental? Both of these are similar, they go through phases that they’re repeated over and over and over. Incremental though means that I give you things in increments. So I’m going to create a piece of software that has limited functionality and then we’ll go through the whole process again and we’re going to add on in an increment that now you can print from that software and then we go through it again. And now in another increment you’re able to send text messages from the software or whatever it may be. So iterative are just simply you go through iterations to create the final product. Incremental means you get deliverables in increments so they’re similar but different. I got one just like that only different. All right, so incremental are tiny increments for deliverables. An adaptive life cycle can be iterative or incremental. You probably know adaptive if you’ve worked in Scrum or XP or Extreme Programming or Lean, those are all examples of adaptive with Scrum being one of the most common or agile.

So what we’re looking at here in this picture is a Kanban board. So a Kanban board shows where do we start with the number of stories, stories are requirements, user stories, what’s in motion. So what are we doing, what’s in progress, what’s going through testing all the way over to what’s finished. So this is called a sign board. We’ll see this a couple of times but this is one of the things that we can use in an adaptive environment. Adaptive environments are change driven where we don’t know everything that we’re going to create at the beginning of the project like a predictive life cycle. So what we have an adaptive and this is on general terms, I know there’s different flavors here but generally we have what’s called a product backlog. That’s all of the requirements and a product owner will prioritize with the team what’s most important.

The team then will say, okay, over the next two weeks or four weeks the next iteration sometimes called a sprint. This is what we can get done, I can get done this much work in the next four weeks. So they take the most important items and they go and work on those items. While they’re working on those items there can be no changes that we’re focused on, only these items. When we’re done with those items, we’re done with that iteration. We do some reviews sometimes called a retrospective and then we go back with the product owner and the project team and then the product owner now has a chance to reorder the list of items in that backlog and even add to it. And so you go through these iterations to continue to take the requirements and do the work.

Take the requirements, do the work and the requirements can shift in priority before each sprint or before each iteration. So that’s kind of the high level picture of adaptive but we’ll see that a few more times and yes, you’ll have a few questions on that on your PMI exam. So it’s rapid iterations of project work, backlog of requirement and we expect changes to happen. It’s just part of it that we don’t know everything upfront. So we’re adaptive to change and we welcome change in an adaptive life cycle. So we have predictive and you have adaptive and then there’s two variations, there iterative and incremental goods job. Those are three new terms for you, I guess really four new terms if you think about it. Okay, I’ll see you in the next lecture. Keep moving forward, you’re making great progress.

6. Introducing Business Documents

Throughout the Pinback guide we’ll see this term called business documents, that will be an input to some of our processes. And sometimes we’ll have to update business documents. Well what are business documents and why do I need them? Business documents, we’re talking about things like the project business case, the project charter, the project management plan and the benefits management plan, that business documents are attached to these or affect these and they are used throughout the project.

Let’s look at some opportunities here where we have some business documents. So the first one we have business documents for project performance. And what I’m talking about here are phase gates within the project. So the new term at the end of a phase, before I can move into the next phase, there’s a review of what I’ve done so far. That review is called a phase gate, that I can’t go to the next phase until the prior phase is 100% done, accounted for financially and signed off on.

So that review is called a phase gate. Well, a business document that would be attached to this would be a review of what was I supposed to spend, when was I supposed to be done with that phase, what were the deliverables? So the business documents are tied to the phase gates of that project, then we have actual performance compared against what we predicted in our business document. So estimates, so I have cost estimates and schedule estimates. Well, did I actually deliver what was promised? If I did, great. If I did not, there needs to be what’s called an exceptions report or a variance report, a way to communicate why I did not hit my target, why I did not hit my key performance indicators, my KPIs. So why was I late or over budget or both or whatever the case may be? I also have to make some decisions at phase gates at the end of phases. Remember, a phase gate is also known as a kill point because it’s an opportunity to kill the project based on performance.

So if we could have rules set up prior to the project going that if you are more than 30% of our budget at the end of a phase, then we’re going to scrap the project, we’re not going to move forward. Or if you’re more than X amount of days late and you’re likely to not hit the deadline for the whole project, so we’re going to scrap it. So it’s a kill point. So I continue to the next phase.

That can be a decision at a phase gate. So you can’t move on to the next gate or to the next phase because performance is bad and so we cancel the project. Or you can go on to the next phase, but we’re going to do a modification. So based on how much you’ve spent or the lateness, we’re going to trim the scope to fit the amount of money and the amount of time that we have left to finish the next phase, or are we going to go all the way to the end of the project? So things were successful here. We got over a big risk, a big hurdle. We have a big deliverable now. We’re going to continue and go to all the way to the end of the project, or just the opposite of killpoint. We’re going to end the project.

Are you going to remain in the phase? Are you not able to move forward because you didn’t hit your goals, that the scope was not met, that these things are not of quality and there’s some issues. So we have to complete the scope before you can move forward. So the scope for that phase, or do you have to repeat the phase? Maybe you did some testing and things were out of quality, so you’ve got to repeat the phase or certain parts of it have to be updated so the different elements of the phase. So business documents we’ll see throughout the course, we’re talking about things like feasibility, the business case, project documents, estimates, things like that, things that support the project. And that should tell us where we should be at the end of these different phases. All right, good job.

7. Project Business Case

One of the project documents that we talked about in the last lecture was a business case. Well, it’s really important to have a good understanding of the business case because that can affect your entire project, can affect whether project even is launched. So let’s look at the characteristics of a business case and how it affects the project.

First off, a project business. This case is really an economic feasibility study. It’s can we afford to do the project? Is it financially feasible? Does it make sense to invest in this project? So what’s the validity of the project? Is it really going to create something that we can use and that’s going to bring us business value? It helps to make future project management decisions and actions based on the finances and the business value that the project is going to create or that’s a risk, or that may not be a value. So we’re going to stay away from that. The business case is maintained throughout the project. So as there are new discoveries, there are new additions, there are changes, then you have to update the business case to show why that’s justified and needed more characteristics about the business case. The project sponsor is accountable for the development and the maintenance of the business case, not the project manager.

The project sponsor maintains the business case. Now the PM is responsible for making recommendations and by saying this is why we need this change, or this supports our business value, or supports the vision or strategy or what’s already been laid out in the business case, but it’s the sponsor that maintains it. And the business case could also be at a program level. Remember, a program, you have lots of individual projects, but the program oversees those individual projects. Let’s talk about the business case and business needs before a project is launched. We could go into the business case or create a business case as to why do we need the project. So what’s prompting the need for action? A business case defines the business problem or the opportunity that the project is going to solve or get.

So what’s the problem and how are we solving it? Or is there an opportunity that’s going to have some definite business value that we should go out and grab it and get it like a market window or there’s some opportunity or the customer request us to do the project. And so that’s good business value. It identifies the stakeholders that are affected. Remember that stakeholders are people or groups that are affected by the project and they can also affect the project. So we try to identify the stakeholders as early as possible. The business case often will identify the scope of the project. So it doesn’t have to create a total project scope statement, but generally it’s a high level scope of what are we talking about here? So if we were to do a business case for new software that we were going to create or the business case to replace all of our laptops in our organization, or a business case to create and build a warehouse. It would be pretty able to describe the scope of what we’re doing. We’re building software, replacing laptops, or we’re building a warehouse. So the business case would describe that project in some level of detail.

A business case is also used in project determination. Should we do the project or not? So a business case will look at the scope of the project, the value it brings. Then how does it fit with the organization’s strategies, its goals and objectives? If it doesn’t support the strategies, goals and objectives, we probably don’t need to be doing the project. What about root cause? If we’re solving a problem, what are the root cause? A root cause is just that. What’s the problem and what’s causing it? And then we can have a project to go and attack that root cause. What about an opportunity? So I talked about there’s an opportunity that we’re going to have business value. So there’s an opportunity in the marketplace or a customer request is an opportunity. What about a gap analysis? So we want to do some construction with a new type of material, but we don’t really have the skills to do that type of material. So we have a gap analysis as part of our project determination, part of our business case.

What are the known risk? So if you’re doing a project in healthcare, there are all sorts of known risk in your application area or in it or in construction, that just by being in that discipline you have some insight into what risks are there, what are the critical success factors, how do you know you’re successful? What would constitute success in this project? So really important to have that upfront, to have a vision into. If these things are true, then I know my project is successful. So the business case helps paint that picture, gives us goals to work towards as the project manager. The last one here is some decision criteria that the business case can make a recommendation on.

We should do this or should not do this as an organization. So some decision criteria, a business case can also do an analysis of a situation. So what I’m talking about here is should we do it or should we not? Based on this opportunity, based on this problem, based on a customer request. So should we do it or should we not? So we’re going to look at three elements and recommendations that we make. We have required, desired and optional. Required would be you must do it, you must do it. So what I’m talking about here is we’re creating a piece of software and the requirement is it has to be secure, the data has to be secure. So you must do it in order for the project to be successful. That’s one of the criteria is that the data must be secure. Desired is well, we would like this to come true, but if it’s not, it’s okay. So an example here of desired would be we would like for you to also make a mobile app that fits with the desktop app, but if you can’t get to it now, we could do it later or some flavor of that. So we want it to be desired. So it’s a good idea, but it’s not a deal breaker for us. And the third one is just optional. It’s not necessarily, it’s not essential. And that may be the ability to print from the mobile app.

So not really something we’re worried about. So required, desired and optional. Then we get into the recommendation for a project. This is me in the future. I have a good feeling. I don’t know, I hope not. Anyway, let’s talk about a recommendation for a project so out of the business case. We could say don’t do the project, do nothing, just keep business as usual. Do the minimum work possible, don’t invest too much, just do what the minimum to seize the opportunity, the bare minimum, or do the most you could do, do more than the minimum work possible. So seize the opportunity and really go after it with gusto. So these are three typical recommendations, often from business analysts, and they all sound kind of negative, don’t they? Do nothing, do the minimum, or just do more than the minimum work possible in your project. All right, so that’s and characteristics of a business case. Good job.

8. Project Benefits Management Plan

There is a plan that you’ll use in project management often might be created by the business analyst or contributed to your project by the business analyst. And that’s the project benefits management plan. The benefits management plan is a plan that describes how will you create benefits for the organization. How is this going to behoove the organization, how will it create value? So we have this idea of benefits for the organization, benefits realization for the organization, how will you maximize project benefits, and then how will the organization sustain these benefits? So a benefits management plan describes benefits for the organization.

But what is a benefit? Well, a benefit, it’s something that your project creates that will give value to the organization and the project beneficiaries, the end user, the customer, the public at large. So a benefit is something that’s good. You want benefits. So how will you create benefits, how you maximize benefits, and how will you sustain the benefits? The project benefits management plan has a lot of characteristics we should be familiar with for your PMI exam. First off, what are the target benefits? So what are the tangible and intangible benefits? So describe business value in tangible and intangible terms here for the target benefits, then the strategic alignment, how will the project align to the business strategies? Then we have a time frame. So when will benefits be realized? So by phases, is it a short term or long term? Is it an ongoing so once this is created, it’s going to have ongoing benefits for the organization.

So when will we have benefits realization? So those are three characteristics of the plan. Three more, what are the metrics? How will you measure to show us benefits have been realized? So before and after. So this was the speed of our network before the project and this is the speed after. So what are the benefits realized? So how will you show us this? So we want to see some results before and after or profits increased or the number of defects have gone down or helped us, calls have been diminished. So how you measure this and that helps see ROI, which is a benefit. What assumptions do you have in place? Remember an assumption, something to you that you believe to be true, but you’ve not proven it to be true. So what assumptions do you have in your project about these benefits? So what do you think has to exist or will remain in place in order for benefits to come into fruition? And then what risk may be in your project that could threaten the benefits? So the network example may be, well, more traffic, more users, because now we have more bandwidth, we’re downloading bigger things or utilizing that, so it catches up, or we have a new piece of software, that’s great, we can work faster, but it’s more complex. So there’s a learning curve. So what risk are maybe the opposite side of the benefits. All right. Good job. Job. That’s the end of this lecture. Keep moving forward.

9. Reviewing the Project Management Knowledge Areas

Let’s talk about the project management knowledge areas and I’m going to coordinate these with the different chapters in the Pinbot. So first off we have project Integration management, recall integration Management, the gears of Project Management. This is chapter four in the Pinbot Guide. It’s where we do the processes of developing the charter, developing the project management a plan, directing and managing the project work, managing project knowledge, monitor and control project work, perform integrated, change control and then close the project or phase. Then we go into scope management. Chapter five in the Pinbock, plan scope Management collect requirements, define scope, create the WBS, validate scope and control scope.

So those are the processes here in this knowledge area. Schedule management. Chapter Six in the Pinbuck Guide. Plan schedule management, define activities, sequence the activities, estimate how long those activities will take, develop and control schedule. Those are the processes in chapter six, cost Management creating that cost Management plan. This is chapter seven in the Pinbuck Guide. So our first one there, plan cost management, estimate cost, determine your budget and control cost. So those are the processes for cost management. Next up is a little pop quiz for you. Chapter eight in the Pinbach quality Management Plan. Quality Management. Manage Quality and Control. Quality So those are the processes in this knowledge area of quality management. Chapter nine, resource Management resource Management we need a resource management plan. Will estimate activity resources, acquire resources, develop the team, manage the team, and control resources. So chapter nine in the Pinball. Next up, chapter ten. Just three processes in chapter ten on Communications Management, plan communications management, manage communications and monitor communications.

Those are the processes here. Risk Management plan risk management, identify risk, do qualitative and quantitative analysis, plan our responses, implement those responses, and then monitor risk throughout the project. So that’s chapter eleven in the Pinbuck Guide. Our next knowledge area is on procurement, procurement Management. Just three role processes plan procurement management, conduct procurement, and control procurement. So this is chapter twelve in the Pinbot. And then remember this guy, stakeholder Management stakeholder management. Chapter 13, identifying our stakeholders, planning stakeholder engagement, managing stakeholder engagement, and Monitoring stakeholder engagement. So those are our processes for stakeholder management. You might be wondering, well, why are we going through these processes again and again and again in these knowledge areas again and again and again?

Because it’s important to recognize these processes. And what we’re doing is an approach that’s called the whole method, that rather than just seeing little tiny segmented portions of the course, we’re seeing an exposure to all of the information as we move through the course. Once we get into past these introductory chapters in the Pinbox, which is really where we are now, and we get into chapters four and five and so on, then we’ll be pretty isolated, or we will only talk about scope, or we’ll only talk about quality. So I don’t want you to feel frustrated that we keep seeing the same types of stuff over and over. We’re just looking at it from different angles. This is part of the learning that you really need to be able to recognize these different components and how it fits in. So keep going. You’re doing great. Stay with it. You’re learning. You’re building a solid base here. And so when we get into later chapters, it will help make the connection to how these processes are integrated. All right, I’ll see you in the next lecture.

10. PMP Coach: What’s your benefit?

I have an important question for you. Why are you pursuing the PMP? Why do you want to be a PMP? What’s it going to bring to you? Is it an ambition? It’s going to make you a better project manager? Is there a financial reward? So why are you doing the PP and P? Well, we’re talking about benefits in this section. So what benefits will the PMP bring to you and to your organization and your customers? So I want you to make a connection here between the PMP. It’s a test.

It’s a very tough, challenging test. Lots of terms to know, lots of information to know. But how is that going to make you a better person? Not just a project manager, but a better person? I think it gives you confidence in your life that you’ve overcome a challenge. And that’s great. It’s a realization of ambition. It is the ability for others to put trust and confidence in you, because obviously you’ve done the work, you have experience, and you have insight into the generally accepted practices of project management. So those are all benefits, but what other benefits might you have?

So I want you to take some time and think about that. Like, how is this really benefiting me as an individual? For me, it’s opened up a lot of doors. It’s created opportunity, but it also helped me become a better project manager to think more about just getting from A to B, but to think about getting from A to B to C to D all the way to the end. There’s a lot more moving parts and components. So over the years as a project manager, we learn it’s not always the shortest route, that sometimes we have to accommodate stakeholders and accommodate politics and other factors that can really seem to interrupt our project, when the truth is that’s part of project management. So I want you to think about the benefits as to what is this going to do in your career and in your life. All right? You’re doing great. You’re making great progress. Keep it up. I’ll see you in the next lecture.

11. Section Wrap: Project Management Components

Welcome to the end of this section on introducing the Project Management Components. I told you it was a big section. Lot of information here to talk about. You looked at the project management components, the process groups and the knowledge areas. That alone is really, really big. And then you had an opportunity to map out the processes, the 49 processes. So you were starting to learn about where processes exist in the process groups and the knowledge areas. Of course, the Pinbuck Guide and this course is structured on knowledge areas.

Your exam is cross referenced with the process groups, the initiating, planning, executing, monitoring, controlling and closing. So we talked about those, how they relate to each other. We looked at work performance data, information and reports.

We’re going to see those a lot. Throughout the course. We’ll see data as an input, sometimes information, and then we’ll see reports as an output, occasionally as an input. Something to watch for. We talked about tailoring the processes, adaptive environments, the business case and our first official plan, the project benefits Management plan.

So how will you manage the benefits that the project bring to the organization? Okay, a lot of information that you’ve covered. Good job. You are making great progress. We have a lot of information you have to cover. But look at how far you’ve come and you’re effort already as you prepare to pass the PMP. Okay? I want you to keep moving on. I’ll see you in the next section.