Gain in-depth knowledge for passing your exam with Exam-Labs CAPM: Certified Associate in Project Management (PMI-100) certification video training course. The most trusted and reliable name for studying and passing with VCE files which include PMI CAPM practice test questions and answers, study guide and exam practice test questions. Unlike any other CAPM: Certified Associate in Project Management (PMI-100) video training course for your certification exam.

Define Project Foundations

4. Establish the Project Management Role and Responsibilities

Hi, welcome back. In this lecture, we're going to talk about establishing the project management roles and responsibilities, really nailing down what you do as a project manager. The role of the project manager is first and foremost to lead the team to achieve the project objectives. Project management is about getting things done, but you have to balance the competing objectives of the project, time, cost, and scope. You might also have competing objectives with your stakeholders. So Bob wants this room painted grayand Sally wants the room painted yellow, so they have a competing objective. You can't have both. They are mutually exclusive. So you have to communicate with stakeholders and compromise, lead, and negotiate, and make certain that the decisions you're making are contributing to business value. So those are all things that you do as the PM. We also have responsibilities and competencies that you have as the project manager that you want to satisfy. task needs, team needs, and then individual needs. Task needs entail identifying the tasks that you and your team will need to complete in order to meet project objectives. So this could mean making sure you have the right equipment, the right facilities, and the right competencies for you and your team in order to do particular activities or assignments. Team needs imply that you are looking out for and protecting your team. And you're serving as a liaison between your team members and stakeholders because you want to make sure that your team has the resources that they need in order to do the task in your project. And then you have individual needs. And that's where you have to address those individuals on your team that need some competency improvement. They need training, maybe a little hand-holding, or you have to be available for them when they have questions or issues. So we're respecting the task, the team, and the individuals. We are really the liaison between the project team and our business strategy. So you're the monkey in the middle, going to management stakeholders and understanding what they want and expect, and then ensuring that our team delivers on that. So we have to be a good communicator and a good conduit between those two entities. There are really three key values of being a good project manager: knowledge, performance, and personal attributes. Knowledge means you understand project management, and I bet you do already. You're here, you're going for your PMP, and that's what the PMP is. It's evidence that you have knowledge. Performance is your history. What have you done as a project manager? What's your success rate as a PM? And then your personality or your personal characteristics? What's your behavior, your effectiveness, your character, and your leadership style? So some of those soft skills On your exam, you will have somequestions about general management skills that arepart of being a project manager. Of course, planning is necessary. You have to be able to plan as a PM. It's something you'll be doing throughout the project. Then there's accounting, which ensures financial accountability in a project. sales and marketing. We don't often think of sales and marketing to go with the project manager, but it's inevitable that we will have sales and marketing because you have to sell people on solutions. We have to market your project to keep people invested and engaged. So, stakeholder management So sales and marketing are part of our general management ed and engaged. So,You may have to buy goods and services and deal with vendors and contracts. That's Chapter Twelve and the Pinbox; that's one that beats up a lot of people. So really pay attention to procurement when we get to that information later in the course. Logistics, lots of logistics, and project management All of the people, the activities, the sequencing, dealing with stakeholders, vendors, inspectors, and government agencies So lots of logistics and coordinating. All of that takes time and energy. And then human resources that youhave to deal with people. Probably the toughest part of project management is, in my opinion, dealing with your team and people. So you'll have to do some human resources on your exam. You'll also be quizzed on some interpersonal skills. So, do you have the ability to solve problems? And it is precisely this ability to solve problems that the PMP exam tests. So problem solving is an important key to the PMP's success. Being able to figure out puzzles And that's really what a lot of these questions are. Are you working out puzzles? Motivating. You have to be able to motivate, inspire, and get people to do the things that they don't necessarily want to do but have to do in your project. Communicating: good project managers are good communicators. So you need to be able to communicate with your team and with your stakeholders. influencing the organization. It's essentially sales and marketing to persuade people to support your ideas, proposals, and project situations. So you have to do some sales and marketing by influencing the organization's leadership. You have to be able to lead your team in aligning and motivating, directing, inspiring, and then negotiating. You have to be able to be in the middle and calmly negotiate between two sides to come to a resolution so that your project can keep moving forward. All right, great job here. I want you to keep pressing on. Actually, your next piece of activity here is a learning game, the first learning game you've encountered in the course. So check that out in the next lecture and go do this fun little learning game. Break up some of the monotony of project management by studying for your PMP. So great job! I'll pick you up.

5. Section Wrap

If you did it, you reached the end of this third section in our course and are now working towards passing the CAPM exam. Great job. You've done something that a lot of people haven't done, and that's even starting to work towards something they want to do, but yet they don't take action. And you take action, and that's great. So get some momentum; you've got some inertia, and keep moving forward. In this section, we talked about project foundations. So we looked at the fundamentals of the project. What is a project, what is a project manager, and how do those fit within an organization? We talked about the project manager rolesand responsibility, where a role is, whodoes what responsibility is who decides what. What are you accountable for? And then you took some time and hopped out, which I hope you did. And you played a quick game on some project fundamentals. So this really gives a goodfoundation of what is project management. I'm sure for most of you this was a piece of cake and probably just a quick review, and I hope that's the case. If it's not, that's fine. Everyone has to start somewhere. All right, great job finishing this section. Let's keep moving forward. Now we're getting a little bit deeper into whatyou need to know, the exam specific civics. So I'll see you in the next section. Bye.

Describe Organizational Influences and the Project Life Cycle

1. Section Overview

Welcome back. In this section, we're going to talk all about organisational influences—everything you want to know about how a project lives within your organization. So let's talk about what you're going to see. In this section, we're going to look at organisational structures in project management power.Did you know that the amount of authority that you have on a project is directly related to how your company is structured? We're going to look at five structuresin this section projectise strong, balanced andweak matrix and a functional. So we're going to look at that. You should be aware of this because how you operate on your exam is directly influenced by the organisational structure in which you operate. So you want to know the characteristics of those structures. We're also going to look at some really fun terms in this section. organisational processes as assets. Well, I'll call OPA, because it's a mouthful to say. We'll talk about where those come from—either historically or as prepared for you. So what are OPA and where do we get them? We're also going to look at another term, that of enterprise environmental factors. These are the policies and rules that you must follow in your project. and I call these EEF. The reason why it's so important to nail these down early Well, for one, they're early in the pinball game. This stuff can be found in pinball two and one five. It's mentioned in two one four andtwo one five in the pinbock. But it's important to know this because we're going to use them over and over and over throughout the course. So you're going to see OPA, organisational process assets, and EEF, enterprise environmental factors, a lot because these are inputs to a lot of processes, the bulk of the processes, and we're going to have either one of these or both be an input to do that process. So we want to really get a good understanding of these two factors and how that will help us better manage our project. In this section, we're also going to talk about project stakeholders—the people that are affected by your project or that your project affects. So we want to nail down who the project stakeholders are, what they do, and how we deal with them. And we'll talk about governance, about creating a framework, creating the rules and procedures, and how people are expected to behave in your project. Of course, when we're talking about the people in your project, we're talking about your project team. So we'll have a small, brief conversation here about the project team and what their role may be on the project. Are they dedicated or full-time, or do you have a part-time team where they're on other projects and have other duties? Again, linking that talk back to organisational structure, how much authority do you have for the team, and then how much time can the team spend on your project? We'll talk more about teams way later in the course when we get into Chapter 9 in the Pinbock on human resources. So this will be kind of a brief overview of a very important topic. A very important topic in this section is the project life cycle. This project has a unique life cycle. So we're going to compare and contrast. What about the life of a product versus the life of a project? And then we're going to look at how the project lifecycle does some very specific things. And I'm going to give you a hint. Keep an eye out for MACD M A CD in this section, something to look forward to. We'll also talk about the different types of life cycles. So we have a predictive life cycle, an iterative or incremental life cycle, and adaptive life cycles. So we're going to talk about those three different life cycles in this section. So it's a pretty big section because there's a lot of exam-specific information you'll want to know. So I encourage you to really get ready, really hone in, be focused, and know that you can do this. Be confident in what you are about to do.

2. Discuss Organizational Influences

Let's talk about organisational influence and project lifecycle power. Your power as a project manager is directly influenced by the organisation that you're operating in, the structure of your organization, and then the projects that you do, each with its own unique life cycle. So no two projects are ever the same, just like no two snowflakes are ever the same, and every project is different. And that's what we're going to look at in this conversation. So let's hop in and talk about organisational influences on project management. In this conversation, we're first going to talk about the different cultures and styles of companies and how that affects project management. And then the communications How do people communicate in the organisation where the project takes place? We might think about a corporate structure versus a not-for-profit or even a very small entrepreneurial environment, or using resources all over the world, and all of that can affect how you manage the project. And then we'll talk about the structure of the organization. Now it's really important to pay attention to this information for your exam because how you manage and the amount of authority that you have as a project manager are going to be directly influenced by which structure you're operating in and the culture and communication style. All of that affects your authority and your effectiveness as a project manager. So let's first talk about organisational culture. So we think about culture. We think about values. What's important to the organization? What do they value as far as a profit, their mission statement, their role in the marketplace, or their reputation? And then also, what about the people? What did they value? the people on your team and your stakeholders? So what's important to them? So what are their values? Also, in an organisational culture, we have the business model. Is it not for profit? Is it a very low-volatile, public type of company, like a bank, or a very old organization? Or is it more entrepreneurial in nature? because that affects the culture and how you are able to manage a project in those different environments. Then we also have the policies, the methods, and the processes that are unique to your company. I like to use the example of procurement as a good example of policies, methods, and processes. So who does the procuring? Do you do it as a project manager? We have centralised contracting. Does a senior manager actually do the procurement? So when you need to purchase something, who does that? And that gives you a good insight into the policies, the methods, and the processes. So how you do something—or how you're allowed to do something—and who actually carries out that activity differ. So that's all part of the culture that affects your ability to get things done as a project manager. And then you think about the individuals and their view of authority. So sometimes there's a real disconnect between management and you. The PM and the people on your team that you have may not have the best view of authority in your organization, but hopefully you have just the opposite. where you respect the leaders in your company. Respect the management of the authority and that they give you a certain amount of autonomy, but they also lead and get support, and they do a good job. And that's, of course, where we all want to work, and we want to feel like we have support and good leadership and good direction. But the view of authority is part of the culture that will affect your ability to manage a project, work ethic, and work hours. So, how do people feel about working? Sometimes people on your team, maybe not your team, but another team, don't want to work; they don't want to do the project because they're disengaged with the organisation as a whole, and they feel like your project is just another thing that they have to do. And they already have so many demands on their time that they aren't particularly excited about having to do your project as well, if anything. They see your project as an opportunity—not just for their work experience, but an opportunity for the organisation to become more successful. And then what are the work hours? Are people constrained between nine and five or eight and five? Or are there expectations that you work more than 50 hours per week on a consistent basis, which can lead to resentment for your project? So that's something to be aware of that affects your ability to effectively manage. Next, let's talk about the organisational structures. Now these different structures, and we're going to look at them in more detail in just a moment, really describe how the company is structured and where you fit in as the PM, as well as where your team members fit in with their roles and responsibilities on your project. So these different structures were going to be looked at; they really affect the power of the project manager. How much authority and autonomy do you have, and what kind of decision-making ability do you have as the PM? It also affects your communication demands because the more complex the structure is, the more complex the communication requirements are. You'll see in a moment that it's a very shallow structure. It's pretty easy to communicate because everyone's in one spot and everyone knows who's in charge. When we get into what's called a "matrix," where there are people coming from all over, I have a lot more people to communicate with, which creates opportunities but also some risk that communication could fall through the cracks or be just more complex and time-consuming to communicate effectively. Also, these structures affect how you manage the team. So who's really in charge? You are the functional manager, and so that can create some issues and sometimes some power struggles in your project and even with other project managers. And then stakeholder management: stakeholder management is affected by organisational structure and, first, by communication. Two, they may not always recognise who's in charge, and so they may go to the functional manager, to the project team members, to the sponsor, or to you, the project manager. and that may or may not always be appropriate. So we have to really communicate as to who's in charge and who makes decisions, and we need to communicate that with our stakeholders. Depending on the structure in which you operate, stakeholder management may become an issue. So given the different organisational structures and amounts of power at the top level, the most desirable structure for you, a project manager, is a projectized structure. In a projectized structure, the project team comes together and works only on this project for the duration of the project. They don't have day-to-day opportunities, they are not shared with other projects, they only work on your project, and you, the project manager, are in charge. So a projected list makes it very clear who's in charge. The project team only works on your project; they're dedicated to the project, and you have the most authority over the team and over functional management decisions. The project manager has the authority. As a result, it's a very desirable structure to be a part of. And communication is very shallow because you and the team communicate and the stakeholders communicate. It's really easy to see who's in charge. And communication demands are significantly lower than in the next environment we're going to look at. and it's called a matrix. As a matrix, there are three flavors. In weak, you use strong, balanced words. Now the adjective there describes the amount of authority that you, the project manager, have. So in a strong matrix, you have a lot of authority. In a balanced matrix that's shared with functional management, you have less authority than the functional managers. The matrix structure means that your project team members come from all over the company, that they come from IT, sales, marketing, manufacturing, and so on, and that all of these resources come together to be part of your project team. However, they still have day-to-day duties as part of their regular job that they have to get done. And your project team members may be on multiple projects besides yours. So it's like a web; it's a matrix where they're coming from all over and working on different projects and day-to-day activities. So there are a lot of scheduling challenges here and resource demands; competition for resources and communication gets really heavy in a matrix environment, regardless of how strong, balanced, or weak it is. So in a matrix structure, the challenge is communication and resource sharing because you have to share with operations, and you have to share with other projects. Now, the strong balance over the weak in a strong matrix means you, the project manager, have authority over the project team. You get to make more decisions about the budget and about scheduling. You still have to negotiate with other PMs and managers for resource time, but you have more authority over the team on those types of decisions. In a weak matrix, it's just the opposite. The functional managers have control over the budget, the schedule, and some other decisions on the project team's utilization. Now, this dreamy one here is a balance matrix. And I say it's dreamy because it appears to be very appealing on paper, and everyone will share and get along. The reality is it can create a lot of power struggles, and there are questions sometimes from the team or stakeholders about who's really in charge and who's making decisions here. So while a balance structure seems nice, it can really create some challenges for you, the PM. The last one here is a functional structure. Now in a functional structure, you have the least amount of authority as the project manager, and the functional manager has more authority. Also, the project team only exists in the department or organisation where the project is taking place. So, unlike a matrix, where people come from all over all of these different departments, a functional model would be that just the IT department does the project, or just sales, or just manufacturing, and that we don't bring resources in from all over, and that everything is contained in one line of business or one organisational unit. So the functional manager is in charge, and then the project manager—sometimes called a project coordinator or a project expeditor in a functional—that they don't even call the PM because the functional manager is in charge. So those are the five structures. You want to know these five structures and their characteristics. And I've got a table that you'll see in the workbook and on the next slide that will help you sort out some differences between these different structures. But be aware of these because they may tell you on your exam that you are operating in a specific structure, and then how you would respond to a scenario based on that structure. So pay attention to that on your exam. Let's look at this table here. I'm not going to read all these to you, but quickly, some important parts of the organisational structure details All right, so you can see the columns going down, functional matrix projectiles. And then in that first column are the different attributes. I want to point out a couple of important ones to you. I'm going to hop down to the third row in budget control. Notice in functional management and in weekmatrix functional management that they control the budget. And then, in a balance matrix, you share that authority. So do with it what you will. But it's mixed in a matrix with a project, and the project manager has control over the budget. I would really pay attention to that row's budget control—who's in charge of the money for your exam? The next one I want you to see is the project manager's role. You'll notice the PM is part-time and functional, with a weak matrix, but you're a full-time project manager when you're balanced, strong, and projectile. So that's great. And then the admin staff noticed that this is the idea that you, the project manager, have an administrative assistant. And I know all of you do, right? Sure. So the admin staff, though, has a functional week and balance, and you have a part-time administrator to help you out. And then, with a strong matrix and a projectile, you have a full-time administrative staff. Now, "admin staff" doesn't necessarily mean an administrative assistant. It's possible that you have a scheduler who works for you, or that you have a scribe who takes minutes and organises communications, so you're not doing all of the busy work. So it's not necessarily just an administrative assistant. and that'd be nice if it were. All right, good job. In the next lecture, we're going to talk about some more organisational factors that you'll want to know. All right? I'll see you at the next lecture. Bye.

3. Describe Organizational Factors

Throughout this course, you're going to see some terms over and over again because these terms describe the organisational factors that you can use or have to use in order to manage your project. So first off, we're going to see enterprise environmental factors. These are like the rules and processes that you must follow. And then we're going to look at organisational process assets, which is anything that was created for you in order to help you better manage your projects. So you'll see these terms: we're going to dive in and take a little bit more of an in-depth look at enterprise environmental factors, organisational process assets, and then some other elements that you can use to better manage your project. First off, right out of the pin box, this is from Section 2:1-4, organisational process assets, if you're following along there or want to go back later and check it out, organisational process assets.Now these come from two places: processes and procedures, meaning they're historical. It's already happened before you started your projector; they come from a corporate knowledge base where it's prepared for you. So here's how this works. Processes and procedures denote historical data. So you managed a project, or somebody else managed a project before your current project. So forms, plans, and the work breakdown structure from that similar project You can take it and adapt it to your current project. You aren't going to start from scratch, right? You're going to take something similar, do it, save it, clean it up, and make it good for your current project. You don't have to start from scratch every time. You're going to treat that like a template. So you take a previous project and adapt it—that information, all those forms and plans, and so on—to your current project. So that's from process and procedures, historical information, and the project you're working on. When you archive that information, it becomes part of the organisational process assets you're building for future historical data. Now somebody else can use it in the future. So that's the idea that it comes from process and procedures. It's been done before, so you're just adapting it. All right, the second one, a corporate knowledgebase, is where you might have a template or a form that you have to use. So I've done a lot of projects in learning and development, and a typical template that we use is called an LTA, a Learning Task Analysis. And so it's a form; it's not a process or procedure. It's just a form that when we go meet with the stakeholder and they want some training developed, we use this form to talk about it. It prompts us to ask questions and to get an idea of what the stakeholder wants as an end result of the project. So an LTA in my industry and training in our projects comes from the corporate knowledge base; that's a form that we use. So in your discipline, in your application area I anticipate that you have forms that are unique to your company or your industry that you fill in when you start a project or as you go through a project, and that's your corporate knowledge base, and it's prepared for you. So those are organisational process assets. Now, throughout this course, I'll often just say OPA. That means organisational process assets because that's a mouthful to say. Okay, so here are some examples of places where you can obtain historical or prepared OPA: past projects, lessons learned, processes and procedures, and the corporate knowledge base. Or you may have some guidelines and accepted practises or "best practices" in your industry. All of those are good sources of OPA. Now, a corporate knowledge base is a treasure trove of information that you can apply, use, or leverage in your project. So a configuration management knowledge base So configuration management is talking about the features and functions of the things that you create. So it's like blueprints and schematics, line drawings, and field drawings of the things that you create. Financial databases. So those can be good to help youdo estimating on time and on cost. So based on labour hours from similar projects, incurred costs from vendors or because of materials you purchased, budgets, and project cost overruns from previous projects, how can I help you to not make that mistake or make a more realistic cost estimate? historical information and lessons learned. Those are great resources from similar projects, of course. issue and defect management databases. So you go back and look at similar projects to see what issues arose; an issue is a risk that occurred. So it's something you have to deal with. It is not always or even rarely good. So how did you resolve that? Or how did another project manager resolve that in the past? So you have a defect or an issue database. So what was the problem that you had in the similar project, and how can you avoid that problem in your current project? So you can plan to avoid issues and defects and build process measurement databases. So you look at past projects and how they performed on time, cost, quality, scope management, or any one of our processes. And from that, you can set goals for how you can improve your project or learn from their mistakes so you can avoid making those mistakes in your current project. And then, of course, my favorite—and probably the most realistic—is to take project files from previous projects and adapt them to your current. Nobody likes to start from scratch, and it just saves time. Now, the caveat here is kind of dangerous. If I go pick up some project files from a similar project and adapt them to mine, if that project file isn't accurate, So I don't know who did that, or if I did it in the past, I didn't update it as I went through the project, like my time and cost were totally wrong in that past project or somebody else's that I'm adapting. Their time and cost estimates were totally wrong, and I'm setting myself up for failure. So we need to be realistic about adapting files from previous projects and making sure they're up to date and reflect what actually happened so that I can better plan and estimate this project. Now, enterprise environmental factors: these are your organisational policies, the things that you must do as a project manager, and how you are forced to operate as a PM. So they may also be industry standards or regulations in your application area. Like in construction, there are obviously some laws and regulations that you have to follow, or in a healthcare project or even an IT project, there are standards and regulations that you must follow. So that's enterprise-level environmental factors. So I'll just summarise by saying that there are rules that you must follow in your project. So think about processes in your company that you have to follow; there's no getting around that rule; it's just what you must do. and then the geographic distribution of facilities. So if your project team is dispersed, well, then there's just some logical You can't have a meeting if people aren't even awake yet. So that's an enterprise environmental factor that we have to coordinate our time and our schedule, and then maybe even overcome language barriers and things like that. Just by the geographic distribution, that affects how we'll manage and communicate. And then finally, we have marketplace conditions. So a "marketplace condition" means that if things are tight and you're not getting a lot of sales, maybe you change how you manage your project. Or if you're really busy and you have a lot of opportunity, you might bring on more workers to get things done faster, for example. So the marketplace conditions can fluctuate, and that can affect how you get to manage your project. And we'll talk more about marketplace conditions when we talk about cost management and procurement, but this just generally describes how the marketplace and the economy are where you are operating. Now, I've mentioned standards and regulations a few times. just to be clear here. Standards are really optional. Regulations are not. So standards will say, for example, if we are in a printing environment or a graphic design environment, we might use PICAS. Pica is a unit of measurement in graphic design or printing. But we don't have to use PICAS. We could use inches instead. So pikas or inches or points—those are all standards. It's kind of optional which one we use. You may have your preference, and Jill may have her preferences, and Bob may have his preferences. So no one is in trouble if they use an inch instead of a pica. All right? Now, regulations, however, are not optional. Regulations are laws. So if you're in construction in the US You have OSHA concerns, or if you're in manufacturing, you have OSHA, or in healthcare, you have regulations for safety on how you handle the equipment and deal with patients and so on. So regulations are laws that can have an impact on your project and that you must follow. So regulations are not optional. Standards are optional, regulations are not. Our next thing to talk about are project stakeholders and governance. Now, a stakeholder is anyone who has a vested interest in your project. So you think about your project team, about your customers, and about management. you, the project manager. It's really anyone who is affected by the project or anyone who can affect the project. So the most obvious ones are your project team members, because they can definitely affect your project, and they are definitely affected by your project. And you're the project manager. Yes, you are a stakeholder. So, stakeholders, like I mentioned before, this is a new knowledge area in the Pinball Encyclopedia, Fifth Edition. So we really have to pay attentionto stakeholders and stakeholder management very important. So, just to sum up, the project affects anyone who is the project.It's a stakeholder. There are three categories of stakeholders. You have positive stakeholders who want your project to be successful. Those are my favourite kind of people, the ones who are positive and happy that my project is taking place. Then we have negative stakeholders. And those are the people who don't want your project to take place. And they're opposed to your project, and they would just be happier if the project was canceled. So they are not very good people to have around. However, you have to deal with them. That's part of stakeholder management. And then we have neutral stakeholders, people about whom they don't care. a good example of a neutral stakeholder. If you're in construction, you have the city inspector who's going to come out and examine the foundation of the electrical, plumbing, or what have you; they're neutral. They're representing the home buyer by saying that you are doing this work correctly. They're just going to tell you if it's done right or not and sign off or not. So an inspector is a good example of a neutral stakeholder. a little bit more about project stakeholders. Here are some common ones that you should recognize. The project sponsor is an individual who signs the charter, and they have a fair amount of authority in your organization. In fact, they have authority over all the resources involved in the project. Your customers, obviously, and the end users if you're in it, are stakeholders. When you buy from people, the sellers become your stakeholders and business partners. So if you are dealing with other groups in your organization, or you're partnering with other companies, or you're using contracted resources, those are all stakeholders in your company. Your organisational groups that you have to interact with regardless of your structure, from project size down to functional organisational groups that are affected by your project, are stakeholders. And then functional managers, the managers of your project, team members—they are stakeholders. So those are all pretty common. Now, this is really setting us up for when we get later in the course. In our final section, we'll talk about stakeholder management. The last chapter in PMBOK Five is stakeholder management and engagement. Like I mentioned, this is an ongoing theme about engaging and managing stakeholders. So we're pretty early in the course, I know, but it's really setting us up for a continued effort to manage and engage stakeholders. Tied to this is the idea of a force field analysis. This isn't really something that you want to sharewith a lot of people, but what it does,it will show you the forces for your projectand the forces that might be against your project. The longer the line indicatesthe strength of the force. So take a look at this chart here. Who do you think has themost force in this force field? Well, if you said the CEO, you're right—it looks like that line is the longest. So that's the force against your project. So that's kind of tough to counteract what this does,a force field analysis, it just helps you begin todevelop a plan or a strategy to engage and winover and do a little bit of sales and marketingon those stakeholders that may be against your project. So it helps us to understand why have theconversation, why are they against it, and how canwe take them from negative to positive. So, force field analysis is not a made-up term. It's a real term that you should recognise for your exam. Now let's talk about project governance. Project governance is all about the rules that you have to follow for your project. So, for example, your deliverable acceptance criteria, how do you know when you've redone it and how do you know it's of high quality? What's the process to escalate issues? So a lot of that's going to depend on a functional matrix or projectile. So how do you manage issues or even risky events in your project? What's the relationship among projects, programs, your project team, and stakeholders that you're managing during that engagement throughout the project? How do you communicate information? We'll talk about that in Chapter Ten. What's your decision-making process? Do you have the authority to make decisions? Is it done collectively with your team? Or do you defer to functional management? So who decides? What role do you play within your roles and responsibilities? What's your project lifecycle approach? So what are the typical phases? We'll talk more about that coming up.Then our project, like yours, will move forward. When will you do stage, gate, or phase reviews? So typically at the end of a phase, we do a review, like in construction at the end of the foundation, and someone comes and inspects it. At the end of plumbing or electrical work, someone inspects it. So those are phase reviews, and who has the real control or oversight of the project? So these are all examples of governance. It's basically about who decides what in your project. So it's upfront. We must determine who truly has authority over this project. If we look ahead a little bit and talk about ground rules and establishing some ground rules, it ties into this idea of governance that once these ground rules have been established, it's the responsibility of the entire project team to enforce the rules, which are very important for your exam. That is all of our responsibility, not just the project managers'; all of us enforced ground rules. So pay attention to that little tip for your exam. Next, let's talk about project success. We all want to be successful as project managers. And so, we know project management is about getting things done, but we need to get the right things done in our projects. As a result, we must first define what constitutes project success. How do I know when I'm done? How do I know when I'm successful? because that then gives us goals to work towards. And we don't want any ambiguous goals. We want hard goals, we want factual goals. So we want things like: what is our scope goal? what about our cost and schedule quality? how do I manage resources? And what are the objectives? And what risk may be lurking in the project? And how do I manage those? So, those are all project objectives, and we'll talk about all of them as they come up. Each of these will be covered in its own chapter later in the course. Finally, let's take a look at the project team. Your project team, remember, based on yourorganizational structure, project is down to functional. So your project team could be dedicated, meaning they only work on your project full time, or it could be shared with operations and other projects. So if they're dedicated—sometimes we call that "colocated"—that means they're all in one spot. Or if they're dedicated, they could also be virtual, where they're not co-located and are distributed around the globe. The dedicated team reports directly to the PM, like a projectile. And the lines of authority are clear. Everyone knows who is in charge. So that could also be in a functional office, where everyone knows the functional manager is in charge. Your team is now working part-time. They have regular day-to-day work. The functional managers, like in a balancedor will strong or a weak matrix. Functional managers frequently have control over who can work on what and when. And then your project team could be using multiple resources at once. All right, good job. I know we covered a lot of information in this lecture, but you're hanging in there; you're making progress. You can do this. Let's keep moving forward.

Pay a fraction of the cost to study with Exam-Labs CAPM: Certified Associate in Project Management (PMI-100) certification video training course. Passing the certification exams have never been easier. With the complete self-paced exam prep solution including CAPM: Certified Associate in Project Management (PMI-100) certification video training course, practice test questions and answers, exam practice test questions and study guide, you have nothing to worry about for your next certification exam.

Hide