Pass CompTIA Project+ Certification Exams in First Attempt Easily

CompTIA Project+ Certification Practice Test Questions, CompTIA Project+ Exam Practice Test Questions

Want to prepare by using CompTIA Project+ certification exam practice test questions efficiently. 100% actual CompTIA Project+ practice test questions and answers, study guide and training course from Exam-Labs provide a complete solution to pass. CompTIA Project+ exam practice test questions and answers in VCE Format make it convenient to experience the actual test before you take the real exam. Pass with CompTIA Project+ certification practice test questions and answers with Exam-Labs VCE files.

All About Projects

2. Working with programs

As a project manager, many of your projects may exist within a program. So you need to understand what a programmer is and how that affects your project management approach. Program management is where we have multiple related projects that work together to achieve benefits that the projects may not realize if they were managed independently. Overseeing this program, you have programmer managers who then manage the individual projects. Within that program, you have project managers. There is a PMI certification for programmer management. It's the Pumps. So this is really something that PMI has embraced. And you may encounter this on your exam—this idea of programmer managers becoming project managers and then the idea of a Pumps. You probably won't see that on your exam, but you need to be familiar with programmer managers for your exam. Let's take a look here at the relationship among portfolio management, programmer management, project management, and organizational project management. Basically, what's happening here is that projects are the smallest elements. That's where the work gets done. So what we're looking at here with portfolios, remember, is kind of an umbrella over everything in the project. And then programmers can be a collection of projects, and then individual projects are where the work gets done. Each of those has to fit into the strategic goals. And each of those is about maximizing the return on investment. So it's really looking at the value of the project. Now, projects, programs, and portfolios. Recall that a portfolio is like this big umbrella of all the different projects. And so within the portfolio, you could have a programmer with several little projects, and you could have another programmer with several little projects, or you could have a bunch of little projects within that portfolio. So programmers are collections of projects. A portfolio can be a collection of programmers and projects. So think of the portfolio as the big umbrella for the company; we only have so much money to invest, and we are going to invest in programmers and projects. Now, each has to have management and oversight of the scope of any changes they have to plan. There's reporting to management. The programmer managers and project managers are responsible for the success. And there's an ongoing monitoring and controlling effort, as you'll see throughout this course. Let's look a little bit more at the organizational portfolio concept. So the organizational portfolio concept is often made up by a portfolio management board or a steering committee for the company. And what happens at the beginning of the year or the fiscal year is that this board says, well, we have, let's say, $10 million to invest in programmers and projects this year. That's our portfolio. It's kind of a budget for one year. So this group begins to identify projects that really have to be done. Like their top priorities, they have projects that have to be done. And so they have set aside money for each one of those projects. Then they say, "You know what, we also have this programmer where a lot of little projects could take place." And so that comes out of the organizational portfolio. It's even possible to have a sub-program where maybe we're going to develop an entire office park, and then each building within that office park would be a program. So you can see they have projects within a program, and even projects within a sub program. Not to get bogged down on that right now, but the idea is that the organizational portfolio is kind of the parent for all of these different programmers and projects. Now, in a really large, complex organization, the portfolio could say, all right, this is the portfolio, $10 million for the entire company, but we're going to have a $4 million investment over here. And so rather than manage that for the whole organization, we will set up a sub-portfolio just for it. And so that sub-portfolio all deals with it, and the rest of the stuff deals with the manufacturing side of the business, so they can divide it up however they want; nothing to get too excited about. It's just a way of showing that all of these things are part of the portfolio, the suite of initiatives that are not part of the day-to-day operations.

3. Working with a project management office

In many organizations, the project manager has to work with a PMO, a project management office, and sometimes the PMO has a project chief or a chief project officer that the PMS will report to. So let's take a look at this concept of project management offices. The primary goal of a PMO is to support project managers and help them do their job. So they really are a support mechanism where they'll share resources across the PMO. A lot of times, those resources come in the form of forms or templates, software, or standardized procedures so that everyone knows what to expect when there's a project in the organization. Now the PMO might provide some training or coaching, but they'll also want to look to see that each project is following the rules of the PMO. So you might have a project audit where they're going to come in and look at your forms, templates, and projects to make certain they're adhering to the organizational standard. Now the PMO is responsible for developing and managing these processes. So they have to provide expectations for rules for you to follow. Then they have to provide some training and directions on those rules. The PMO might also facilitate communications across all the projects. So if you're in a matrix environment, that's really important when you're sharing resources among several projects. There are some different PMO types. These PMO types provide the standards for project management for an entire organization. Let me just be really clear on that. If we have a very large company, you could have a PMO for the entire company or each line of business, sales, marketing, finance, It, each line of business or department could have its own PMO. So the standards for project management and the It might be different than the standards for project management in sales. So it kind of depends on how the organization is structured. So a lot of times we'll see just this concept of an organization, but don't get caught up on that. It could be the entire company or just one department. Now the three types of PMO that you may encounter are supportive, which is the primary type where it's more of a consulting effort and they provide templates, training, and coaching. Then you have controlling, which usually occurs where there's a lot of government regulation, like in a banking environment or a hospital environment, where projects have to operate within a specific framework and use very specific forms and templates. And it's all about governance. A lot of times, the reason why is because there are government regulations for that industry. So you think about construction or health care. Those are two really good examples of compliance. And then you have a directive where the PMO directly manages the project. The PMO owns it and controls the project lifecycle. So, while this appears to be the PMO's boss, if you're the project manager, you're a part of the PMO in a directive structure, and all projects flow through the PMO.

4. Exploring a project life cycle

Building the project lifecycle is something that happens as you begin to talk about planning the project's work. The project lifecycle is really unique to the type of work that you're doing. And so we have two different lifecycles you're going to learn about. We have the project lifecycle and the project management lifecycle. And here's a real clear way to keep these clear in your mind: The project lifecycle is unique to the work that you're doing. The project management lifecycle is universal for all projects. So let's talk more about the project lifecycle. The project lifecycle is unique to each project and lasts for the entire duration of the project. Now, in the project lifecycle, typically you move through phases. So, if you consider construction versus it, So, in construction, you might start with the concept of building the house, then the design, and finally the actual drawings. Maybe you put it up for bid, and then you get into the construction phase where you have the foundation and the framing and so on. As a result, the phases are crucial in determining the project lifecycle. Now, project phases: to really nail down what a phase is, we're talking about a set of work that results in key deliverables. So oftentimes your phases will have pretty clear names like the foundation phase, the framing phase, and so on. At the end of each phase, you typically create a milestone. Milestones are timeless events. A milestone has no time limit. It's like a marker that shows how far you've come or how far you have to go. And typically, at the end of the phase, you have a milestone. Now, as the project lifecycle moves forward, we have to talk about time and influence. So on our x axis, we have the project timeline. That's the duration of the project. And on the y axis, we have the cost and the degree of influence. So the degree of influence I'm talking about here is stakeholder influence. Very early in our timeline, stakeholders have a lot of influence. So you show them a drawing of the house you want to build for your stakeholder, and they say no, I don't like it, or yes, I do. And it's very easy for you to redraw to create that work. Again, so early in the project, stakeholder influence is high because they're the people that are setting the requirements for what you're going to create. Now, as we move deeper and deeper into the project, and as we move into the project timeline, notice that stakeholder influence begins to diminish. And then if they change, if they change at month six, a year long project, they change requirements. Well, it's going to be very expensive to incorporate those changes because you may have to undo work that you've already done. So the cost of change gets higher the further along you get in the project timeline. Now, the risk is also highest at the beginning of the project. The reason why I say that is the odds of project being successful, the probability of success, it will increase the closer that we get to the end of the project. So project risk is high for the overall project to succeed, and it diminishes as we move closer and closer to the end of the project. So that's time and influence. Early on in the project, we have a lot of uncertainty. Late in the project, our uncertainty begins to diminish because we're certain we will finish the project. Now, sometimes people will talk about the product lifecycle, and the product lifecycle describes the thing that you're creating. A great example of a product lifecycle is a piece of software. So you have different versions of software. Well, each version has a product lifecycle. The last product phase is its retirement. So don't get mixed up between product and project product. You're talking about that thing. A project creates those things. Remember, the project lifecycle is really about you’re moving something, you're adding something, you’re changing something, or you're deleting. And sometimes we might call that MADD: move, add, change, delete. Now, within the project lifecycle, there are different ways to describe our phase relationships. Sometimes we have a sequential relationship, like in construction, where you're going to demo and then the foundation and the framing, and then all the way through to the house. the end product here. So it's sequential. It's a very logical approach. Other times we may have overlapping relationships, and you can have this in construction as well. Here's a great example of overlapping phases. You can see on one part of the stadium that they have the bleachers already installed, but over on the other part, they're not quite done yet. You can even see that the field isn't done yet, and they're putting up the rafters for that retractable roof. So they're overlapping phases because they can happen in tandem. And then there are special circumstances where you have an iterative relationship. So sometimes, like in chemistry or manufacturing, you have iterations of phases. Most projects are sequential in nature. Predictive life cycles are also known as "plan-driven," where the plan drives the project. In other words, we know exactly where the project is going to go. If you're a software developer, you may be familiar with the waterfall approach, where each phase trickles down to the end of the project so you know exactly where you're going to go. Now, in the predictive life cycle, it predicts what's going to happen in each phase. Changes to the scope are tightly controlled upfront. We plan the entire project. Everyone is in agreement as to what the requirements are and what the end result will be. So we have a clear vision of what the end of the project may be, and that's a predictive iterative process. And incremental life cycles, though, are where we have those special conditions, where we have iterations of phases. Now, sometimes in project management, you might be using Scrum or Extreme Programming, where we have iterations to create deliverables, where we plan and we work. We plan and we work. The scope for the whole project is at a high level, but for each phase or iteration, we have a very detailed scope. Changes to the project scope are expected because we're discovering them as we move through the project. And so that's known as an iterative or incremental life cycle. And then we have adaptive life cycles that are change-driven, where the work we do in this current phase allows us to respond to the next phase. So with agile project management and rapid iterations of the project work, you might have a backlog of requirements. And again, changes to the project scope are expected. and that's an adaptive life cycle. You.

5. Reviewing the project management life cycle

The project management lifecycle is universal for all projects. Regardless of whether you're in IT, manufacturing, or healthcare, you'll have the same project management lifecycle cycle. The project management lifecycle is really made up of project management processes. So what is a process? A process is where you have a set of interrelated actions that will create a prespecified result. So for example, in project management we have a project management process of planned quality. As a result, the quality plan will be the quality management plan as well as the process improvement plan. We have another process that's developed the project team, and the goal is to have a more cohesive and educated project team. So the project management processes are the activities that the project manager directs. There are five groups of processes, and within those five groups, there are 47 project management processes. Each process, as you'll see throughout this course, has a set of inputs, tools, techniques, and outputs. And so that is a project management process. In order to be successful in your project management lifecycle, you need to use the appropriate processes. So you go to the process that's most appropriate for what you're experiencing in the project, and then you'll use a defined and documented approach. So you're organized, and you keep track of what you're doing and what you're going to do in your project management. You'll comply with stakeholder requirements. So this means that you're interacting with and engaging stakeholders. And then you want to balance time, cost, scope, quality, and risk. five very important knowledge areas. Now, the project management processes can be applied in any industry. But do you have to use every procedure? Probably not. Now I even emphasise it here and say You should not use every procedure. You want to apply the most appropriate processes. It's possible that in a very large project you would use every project management process, but you don't have to. I mean, there are 47 of them. Also, the depth of execution for each process needs to be defined, and what that means on smaller projects is that you usually don't have to go to the same level of execution that you will on larger projects. So where do these project management processes exist? Well, these are the five process groups that the 47 processes live within. initiating, planning, executing, monitoring and controlling, and closing. All of these processes will be demonstrated throughout the course.

6. Comparing products and projects

There is a difference between the product and the project. The product is the end result of project management. It's the thing—the deliverable—that we are creating for our project customer. The product has the characteristics, the features, and the functions—the tangible deliverables—of what we're creating for our customer. The project is the activity of creating the product. So there's a real difference here between creating a product and creating a project. When we create a project, we're talking about setting up the project and all of the planning, executing, and controlling, and ultimately the closing. So there's a real difference here. It's important to understand the difference because this could affect how you answer exam questions. The product has a life cycle, so the life of the product describes how long it exists in the world. A great example of the life of a product is a software version. So, let's take Microsoft Word version five from a long time ago. Well, that version lived in the marketplace for so long, and then it was superseded or replaced by version six. So the life of the product describes how long that product sticks around. Now, sometimes in the product, we talk about sunsetting the product and saying that it's going to retire. When a product is going to be replaced by a newer version, it's retired. The project, though, will retire, end, or close when we have created the product, when we've done all of the deliverables and all the activities to create those things that constitute the product the project lifecycle creates. So we're thinking about moving, adding, adding, changing, and deleting. Those are project activities. So pay attention to this for your exam. But like I said, the majority of your test questions will deal with project life, not product life.

7. Introducing the project management processes

As a project manager, you should be familiar with the project management process. A process deals with the activities that bring about a project's predefined result. And there are 47 of these activities, 47 of these processes, that we'll cover in this lecture. First off, we're going to look at initiating. Now as we move through this, in the upper left-hand corner of each one of these slides, you'll see these numbers three, three, four, and so on. That is the Pin box reference point. If you want to go to the Pin box, the body of project management knowledge, the reference point, you'll go to section three dot three, or three dot four. In fact, you'll see those reference points throughout this entire course. So in this first one with initiating, there are only two processes in the initiating group, which are to develop the project charter and identify stakeholders. That's it. In planning, we have 24 processes. So a lot of activities are in the planning stages. I like to say that projects fail at the beginning, not at the end, and usually it's because of poor planning. Now, the 24 processes and planning weave developed the project management plan, plan scope management, collect requirements, define the scope, create the work, breakdown, structure, plan schedule management, define activities. Now, I'll talk about all of these processes through the remainder of the course. This is just a quick intro to these processes. So let's continue on with planning. Now the process continued, we have sequence activities, estimate activity resources, estimate activity durations, develop schedule, plan cost management, estimate cost and determined budget. And then we have planned quality management, planned human resource management, planned communications, planned risk management, identified risk, and performed qualitative and quantitative analysis. And then the last three: plan risk responses; plan procurement; plan management; plan stakeholder management. So a ton of processes are here in planning, and in the executing process group, we have eight processes: direct and manage the project, work quality assurance, acquire the project team, develop the project team, manage the project team, manage communications, conduct procurement, and manage stakeholder engagement. So only eight executions. Now in the monitoring and controlling process group, we have eleven processes to monitor and control the project work: integrated, change control, validate scope, control scope, and control schedule. Then we have cost control, communications control, risk control, procurement control, and stakeholder engagement. So those are the eleven processes for monitoring and controlling. Finally, in closing, just two processes remain: close the project or phase and close procurement.

8. How organizations are structured

Did you know that the structure of your organisation can influence how you manage a project? It's actually a really important principle that you need to understand for your CAPM examination. So let's dive in and take a look at these different organisational structures. The organisational structure really describes the influence that the structure has on the project management approach. So when we talk about organisational structure, we're also including the culture of the structure, how the people within that organisation communicate with one another and with different departments, and then the overall structure of the organization. First off, the organisational culture, or culture in an organization, describes its values, its business model, and the policies, methods, and processes that it uses to get work done. And then, what about the view of authority? So do we see management as a joke or are they really providing some good leadership? And then overall, we're talking about the work ethic and the hours that the people within the company contribute. So organisational culture definitely affects how you manage the project. Organizational structures affect the power of the project manager, the decisionmaking abilities, and the communication demands of who needs to know what information. It affects the project team and how you'll manage the team. And then it also affects stakeholder management, how you'll keep stakeholders involved and on board, and how you'll manage their expectations of the project. Organizational structures and powers can be divided into five different types of structures.First off, we have to project. Now, "projectiles" means that the entire project team comes together, and they are only on one project for the duration of that project. That's all that they do. They don't do anything else but work on this one project. And the project manager is in charge of that project team. So that's really the ideal environment for a project manager. Then we have a strong matrix, a balance matrix, and a weak matrix. The matrix means that the organisation allows project team members to come from all these different departments and work on several different projects at one time. So you can imagine, we have Bob over here at Itand Bob is working on six different projects at once. Now we also have on one of those projects,we have Bob from It and we have Susanfrom sales, and we have Pam from marketing, andwe have Jeff from Manufacturing and so on. So the project team has people from all over the company on this team.Now, strong, balanced, and weak—those adjectives describe the authority level of the project manager. So in a strong matrix, the project manager has a lot of authority over the project team. In a weak matrix, the PM doesn't have a whole lot of authority at all, and the authority will reside with the functional managers. Now, a balance matrix means that the functional manager and the project manager share authority. Now, while that's nice in concept, the execution of it can be pretty difficult. So, if you have a strong balance, we'll know those for your exam, because we'll determine who makes project decisions based on which structure you're in. And then the last one we have is a functional structure. In a functional structure, the functional manager has very little authority over the project team. The project team all work for the same department. So an IT project would only consist of people from the IT department, and the functional manager would really be in charge. Sometimes in a functional structure, the project manager is called a project coordinator or an expediter because they really aren't managing the individuals and are instead following the orders of the functional manager. So you need to be familiar with those for your CAPM exam. Another way of looking at the organisational structures in detail is to break out the different types of authority. So in this first column here, we have the PM's authority, the resource availability, who's in charge of the budget, the PM's role, and then if there's any admin staff for the project. So as we go across this, we're going to start at the bottom with functional and work our way up to project size. So in a functional structure you can see thePM has very little authority whereas in a projectilethe PM will have high to almost total authority. Now, in a functional structure, resource availability is pretty limited because people have day-to-day work that they still have to do in a functional environment; a week's worth of matrix is limited because they have day-to-day work and they're still reporting back to that functional manager. And then you can see, as we go to the right all the way to project eyes, that it's high—almost total. Now, the budget is under control for the rest of the week. Functional managers control the budget. As you move towards Project I, the project manager gets more authority. Because even the project manager in a functional environment has day-to-day work to do, the percentage of time that a PM will spend on a project in a functional environment is now part time. However, once we achieve a balance between strong and projecting eyes, their role becomes full-time. Now, admin staff in a functional in aweek and a balance, it's part time. Here, administrative staff refers to the person who acts as a PM assistant or keeps minutes of meetings and communications, among other things. As you move to a strong matrix and projectiles, that individual's role in the project becomes more full-time. So, for your exam, you need to be topically familiar with these five structures. So you're going to be presented with exam questions where they'll mention these different structures, and then that will affect how you answer the decision and the questions.

9. Meeting the stakeholders

Stakeholders are the people and the groups of people that are affected by your project, and they can affect the success of the project. So it's really, really important to understand who the stakeholders are in your project. So who are the stakeholders? Well, they're the people in the organisations that are affected by your project, and they're the people that are involved in your project and can affect it—your project team, your customers, your vendors—in this can affect the project.Now, oftentimes in our exams, we want to think about how the project affects those people. If we have a project where we are replacing all of the laptops and all of the computers in our organization, and we have to do that during working hours, that will definitely affect the stakeholders. And some people may see this as a positive thing, while others may see that new laptop or at least the experience of having you come and replace the laptop as a negative thing in their day. Some stakeholders may say, "No, you can only do this on Thursday between the hours of two and five," so they can exert some influence over the project. So stakeholders affect your decisions. One of the biggest decisions that stakeholdershave on the project are the stakeholderswho help build the scope. So if we're going to build a house for these people, and those people could say we want a four-bedroom home with four bathrooms and a kitchen, and so on, because they are exerting their influence and because they're paying for the project, So, those are stakeholders. Now, there are four types of stakeholders that you'll encounter. Positive stakeholders are enthusiastic about the project and want it to succeed; negative stakeholders are dissatisfied with the project's progress and would have assumed it did not take place. And then you have neutral stakeholders—people who are not really for or against the project but are involved. A great example of a neutral stakeholder is in construction. The city has to come out and inspect what you're building. So they're a stakeholder; they can affect your project, but they're neutral. They don't care if your project makes money or not; they're neutral to the project. And then we have all these question marks here. What's that mean? Well, these are stakeholders that are mysterious ora mystery or hidden to the project. This is something that haunts a lot of project managers. Pun intended. The mystery stakeholders are those stakeholders that were overlooked early in the project. And then you're late in the project and you bump up against them, and they say, "What are you guys doing?" This is not what we had talked about with their boss, or you never came to us and discussed this project, and it's certainly going to affect what we have going on over here. And so you overlook those stakeholders early in the project, and then now you have to recoup that mistake. So these mystery stakeholders sometimes justcalled hidden stakeholders, the accidental stakeholdersor the overlook, was the accidentof identifying these stakeholders. So there's something you don't want to happen in your project. So how do you identify stakeholders? So you don't have any unintentional, hidden, or mysterious stakeholders? Well, first, you start with the obvious. Who are the people in the groups that are affected by the project? So you have to ask questions. And one of the best ways of identifying stakeholders is to ask stakeholders: "Is there anyone else that should be involved in this project that we have not yet identified?" Is there anyone else that can influence the project? So that's a great way of identifying stakeholders. The goal is to identify stakeholders as early as possible because you want them involved, you want their buy-in, and you want to respect the stakeholder and how your project may affect them. This leads to what we'll talk about in a later session on stakeholder management strategy. How will you best manage the stakeholders? And so part of that would be to classify stakeholders by their interest in the project, their level of influence over the project, and then to what extent they will be involved in the project. So those are all the methods you can use to identify project stakeholders. And this is a new section, a new chapter in the Pinball Guide, Fifth Edition, on stakeholder management. So you can bet you're going to see this on your exam. So pay attention to this idea of stakeholder management strategy and to this initiating process of identifying project stakeholders. So what do you do once you've identified the stakeholders? Well, you create a stakeholder registry or a stakeholder register. What this is is a document; it's just a database of all the stakeholders in your project. So who are they, and how do you get a hold of them? And then you give an assessment of the stakeholders. So are they a vendor? Are they a Project Team member? Are they a negative? Are they neutral? Are they positive? So it's just a way of knowing who's who in the project. And then you can also do some classification here. Are they part of the project team? Are they external to the organization? Are they inspectors, or whatever the case may be? You can sort of group those. Now, this isn't necessarily a document you share with everyone because this information can be sensitive, just like the stakeholder management strategy. So a lot of times, you guard the stakeholder register so that you don't allow everybody to see what's in this document.

10. What's in a project charter?

One of the most important documents in project management is the project charter. The project charter is a document that first authorises the project to exist in the organisation and then, secondly, authorises the project manager to act on behalf of the project sponsor. Now the project sponsor is a new term. This is the person who obviously signs the charter, but it is also the person with enough authority in the organisation to grant the PM authority over the project's resources. So you need someone to sign the charter that usually has executive or organisational power; maybe within one department, it would be the director of that department, but it's someone that has the authority that allows the project to exist and allows the project manager to have authority over the project team. So in the process of developing the project charter from the PO, this is someone who is external to the project. The project manager does not sign the project charter; it's someone with the appropriate power. Now, sometimes the charger is issued by our portfolio steering committee. So remember we talked about that earlier? We had portfolios of programmes and projects. The portfolio steering committee is usually made up of individuals such as directors, vice presidents, or even the company's CEOs who direct the project, direct the organisation to begin, and can give the PM authority. Now when we look at developing the project charter, we're looking at the process. This is one of our initiating processes, and whenever we have a process, we have inputs. The things you must do, the process, tools, and techniques, how you will carry out this process, and finally the results. Now I call these ETOs "ito." So if I ever say that, just now I'm talking about inputs, tools, techniques, and outputs. Now you'll need inputs to create the charter, which is a document that describes what you're about to accomplish in the project. The business case: Why is the organisation doing the project? If you're a vendor, you may have agreements; those are contracts in order to do this project. And then two new terms for you: enterprise environmental factors and organisational process assets. Enterprise environmental factors describe the governance, the rules, and the processes of your organisation that you must follow. Organizational process assets describe things like templates, software, and support from your project management office. So you must consider enterprise environmental factors. Organizational process assets are things that have been created for you to help you do your job. So in this example, there may be a template for the project charter, and that would be an organisational process asset. An enterprise environmental factor for this case could be the project charter, which must be signed by the department head. So that could be a rule that you have to follow. Now the tools and techniques are here: expert judgment. So to write the charter, you're going to tone down some subject matter experts and facilitation techniques. Meetings, phone calls, and communicating with the person signing the charter about what the project will accomplish are all generic terms. And then our output, of course, is the project charter, the document that gives you the authority as the PM and authorises the project to exist in the organization. I've talked about expert judgement and facilitation techniques. Expert judgment. So we're talking about subject matter experts, like consultants. It could be the people within your organization. It could be stakeholders or industry groups with whom you will consult on the project. Or if you have a project management office, a PMO, they may guide you in the creation of the project charter. Now, facilitation techniques—I said they're just meetings and conversations— Really. It's more than that. We're talking about brainstorming and conflict resolution, because we're probably going to have some competing objectives for what the project accomplishes, and meeting management; all of those meetings don't want to go on forever and ever. Now, as you are developing the project charter, the actual process, and doing the work here, you have requirements for satisfaction. How do I know when the project is done? You have approval requirements. Who signs off on the charter? Who is the project manager and what authority level do they have? And then of course, the project sponsor has to sign it. And then in the charter, it describes the high-level purpose of the project. Now, in developing the project charter, we also talk about the purpose of the project, the business case, and the goals. We're talking about the high-level goals of the project, the Milestone Schedule. So what are our key dates for milestones? Now, a milestone is a timeless activity that shows progress. If we were building a house, our milestones might be the foundation, the framing, the plumbing, the electrical, and so on. And then with those, we would typically have some type of high-level schedule. As an example, we could say July 15 plus or minus seven days. That would be the schedule we would have in the charter. Stakeholder influence. So what? Stakeholders have a lot of authority, a lot of interest, and a lot of influence over the project. What risk have we already identified in our project? I talked about construction. There's always a risk in construction of someone getting hurt because there are OSHA guidelines we have to follow. There may be risk in the construction of the inspectors, and we can't control when the city inspector is going to come out and look at the property. So the high-level risks here in our charter are usually the things that are very easy to identify when the project begins. And then once we get into planning, we have a process for identifying risk where we take a much more in-depth look at all of the risks throughout the project. Now, also with the development of the project charter, we have to consider the functional organizations. So, recalling a matrix structure, we have people coming from all over the company. We're working on a project where everyone is on the team for the long haul. So what about those functional organizations, and what say do they have to contribute to this project? Your charter may include a summary budget. You may have a contract if you're a vendor, because you may be doing this work for someone else. In fact, the contract could serve as your project charter because there is an offer and a consideration between the buyer and the seller. So you may have a contract in your project agreement.

11. Section wrap

Great job finishing this section on projects. You now know that a project is a short-term endeavour to create a unique product, service, condition, or result. A lot of times in projects, we say they are MADD, that is, they are moving, adding, changing, or deleting. So they do one of those activities. Now, we talked about what a project is, but we also talked about where a project lives. So remember that we had the idea of a project management office and that they are supporting the project manager through templates and forms, but also through rules and policies. And that's where we get that idea of enterprise environmental factors. And then we talked about how a project may live within a program. and a programme is a collection of projects that are working together to achieve a result. Building a skyscraper is a great example of a program. Now, we talked about two life cycles. We had the project lifecycle and the project management lifecycle. The project life cycle is unique to each project. So if you're developing an application and I am developing a new database, we might have a project, but your project lifecycle is different than mine. Just like if you were building a bridge and I were building a house, Two different types of projects, two different life cycles. Project lifecycles are typically comprised of phases, so foundation, framing, electrical, plumbing, and so on. Phases make up project life cycles. Now, the project management lifecycle is the initiating, planning, executing, controlling, and closing phases. The project management lifecycle is universal to all of our projects. Then we have a discussion about organisational structure. Remember that organisations are grouped into functions or a matrix, or we had projectiles? And depending on what type of structure you're operating in, it will determine how much authority you have as the project manager. So, great job finishing this first section. Let's keep going.

So when looking for preparing, you need CompTIA Project+ certification practice test questions and answers, study guide and complete training course to study. Open in Avanset VCE Player & study in real exam environment. However, CompTIA Project+ exam practice test questions in VCE format are updated and checked by experts so that you can download CompTIA Project+ certification exam practice test questions and answers files in VCE format.