BLUE the PMP Exam Made Easy Your 24-Hour
Short Description
BLUE the PMP Exam...
Description
The PMP Exam Made Easy Your 24-Hour Study Guide to Passing, 2013 Edition by Ron Ponce and Christopher Scordo SSI Logic © 2013 (337 pages) Citation ISBN:9780982576885 Containing expert tips for exam success, this all-in-one study guide offers top-notch tips, tools and techniques to help you prepare for and pass the PMP exam, while making it easy for you to focus on just the information you need to succeed.
Table of Contents The PMP Exam Made Easy—Your 24-Hour Study Guide to Passing Accessed 1 days ago A Brief Introduction to this Guide A Concise Overview of the PMP Exam PMI Code of Ethics and Professional Conduct The Project Management Framework The Project Life Cycle & Organization All About Project Management Processes Deep Dive into Project Integration Management Deep Dive into Project Scope Management Deep Dive into Project Time Management Deep Dive into Project Cost Management Deep Dive into Project Quality Management Deep Dive into Project Human Resource Management Deep Dive into Project Communications Management Deep Dive into Project Risk Management Deep Dive into Project Procurement Management Deep Dive into Project Stakeholder Management A Review of Critical PMP Exam Formulas Quick Guide to Important PMP Exam Acronyms Quick Study Checklist for the PMP Exam Helpful Hints for Taking the PMP Exam More Exam Taking Tips List of Figures List of Tables List of Cheat Sheets
A Brief Introduction to this Guide Overview Congratulations on deciding to take and pass the PMP® exam! This guide will walk you through the process to apply for the exam and, most importantly, what you will need to know in order to pass the exam. You will find numerous references in this study guide to the Project Management Body of Knowledge, or PMBOK Guide. These terms are interchangeable. At the time of this writing, the PMBOK® Guide – Fifth Edition is the most recent version and is the standard upon which the PMP exam is based from 31st of July, 2013. It is expected that the PMBOK Guide - Fifth Edition will remain the standard text upon which the exam is based until 2017. Important Note
The page references indicated in this book refer to the PMBOK Guide - Fifth Edition.
Why Take the PMP Exam? Today more than ever, organizations are looking at more than just a person's experience. They want to know that you are well versed in the best project management fundamentals and standards. Those standards are set by the Project Management Institute (PMI). The PMI provides several certifications around project and program management, but the flagship is the Project Management Professional or PMP® certification. The PMP® certification shows that you are part of an elite group of professionals that have been trained and credentialed in project management best practices recognized worldwide.
A Concise Overview of the PMP Exam Qualification to Take the Exam To take the PMP® exam, one needs to meet the requirements as stated by the Project Management Institute. The current requirements are described in the table below: Category General Education
Project Management Education
Project Management Experience
Experience
One
4-Year Degree 35 contract hours (bachelor's degree within the last or equivalent) eight years
4,500 hours
Three years within the last eight years
Two
Secondary Degree 35 contract hours (high school within the last diploma or eight years equivalent)
7,500 hours
Five years within the last eight years
The qualifications show that you have not only been provided the proper education about project management but that you have the practical experience needed to apply the knowledge properly.
Application You need to first go to the PMI.org site in order to begin the application process. There are two ways that you can apply for the PMP certification:
Online By mail
The recommendation is that you complete the application online at the PMI.org website. The processing and notification process is much faster than sending the application through the mail. You can print a copy of the application in order to help you capture your thoughts and experiences before you enter it online. It will be a time saver for you. The PMI does occasionally audit the information that is presented in applications in order to ensure that all the requisites are in order. You want to make sure that you are honest about the information that is being presented. If your application is audited your approval will be delayed until the audit is completed. Up to 10% of PMI applications are audited.
Cost At the time of this publishing, the exam fee for the electronic exam is $405 for PMI members in good standing and $555 for non-PMI members. The current costs can always be found at the PMI.org website.
Quick Overview of PMP Exam Details
The PMP® exam includes 200 multiple-choice questions. Each question will have four answer choices. You must complete the exam in four hours. Twenty-five of the 200 questions are "pretest (unscored) questions" which the PMI uses to validate the questions for inclusion in future exams. You will not be able to distinguish the "pretest questions" from the questions that will count toward your score. These pretest questions will appear randomly throughout the exam and will not be included in your score for the exam. Your score will then be calculated based on the response to the remaining 175 questions. Try to answer every question, since unanswered questions are considered wrong answers. The passing score for the exam is based on psychometric analysis and varies with exam difficulty. Although it is hard to determine an absolute
passing point, it would be safe to say that having 75% of the questions correctly answered will have a high probability of passing the exam. The current exam is centered on the material covered within the Fifth Edition of the Project Management Body of Knowledge also known as the PMBOK Guide. While the PMBOK Guide represents the standard for the industry, the exam is not a test on how much you memorized from the guide. The exam may also include questions related to topics and concepts that are not directly covered in the PMBOK Guide.
The Exam The exam covers the following five key Process Groups: 1. 2. 3. 4. 5.
Initiating Planning Executing Monitoring & Controlling Closing
In addition to these five Process Groups, the exam will take into consideration the ten Knowledge Areas as outlined in the PMBOK Guide. The ten Knowledge Areas include:
Integration Management Scope Management Time Management Cost Management Quality Management Human Resource Management Communications Management Risk Management Procurement Management Stakeholder Management
The table below breaks out by each process group the percentage of scored questions on the PMP exam: Open table as spreadsheet
Project Management Process Group Percent of Questions Project Initiating
13%
Project Planning
24%
Project Executing
30%
Project Monitoring & Controlling
25% 8%
Project Closing
The Project Management Institute does make changes periodically to the exam, the application process, and the qualifications. You should always make sure to get the latest information directly from the PMI at their website www.pmi.org.
Be Ready for the Exam As we mentioned previously, the PMP exam does not just cover the content of the PMBOK Guide. Although it tests your knowledge of how to apply the content of the guide, it is not a test that measures how much of the guide you have been able to memorize. There are parts of the exam where memorization will be important and come in very handy. Those areas will be clearly called out for you. In addition to a thorough knowledge of the PMBOK Guide, the exam also factors in how a project manager uses that knowledge when managing projects. While your project management experience may differ from that outlined by the PMI, it is important to keep the recommendations of the PMBOK Guide in mind when answering the questions rather than basing your answer only on your real world experience. You will find that many of the questions are situational or based on specific scenarios. This type of question is designed to see whether you can apply the information provided and determine which of the selections "is the best answer". These types of questions allow for confusion, because in some instances they contain information that has nothing to do with determining the answer. The sole reason the information is provided is to confuse you and lead you away from the best answer. The best answer also could signify that you were presented with two valid choices, but only one is the best selection for the specific situation described in the question. Read carefully! Don't confuse yourself by assuming you know what is being asked. Take the time to make sure you know exactly what is being asked, and review each answer choice in its entirety. We tend to read the first and second and then skim the third and fourth. That would be a huge mistake, because all you need to do is not read, or misread, a single word that can make the difference between choosing the correct or the incorrect selection. The first tip for the exam is this: Review and study the PMBOK Guide – Fifth Edition. This first step is the key, since most of the questions on the exam reside within the guide. For many people, the terms and definitions that are provided within the guide are new or at least different from what they have experienced in the real world. That is why reading the guide and becoming familiar with what is being presented is so important even before going forward with this guide.
PMI Code of Ethics and Professional Conduct Overview The Code of Ethics and Professional Conduct (the Code) get to the core of who we are as a profession. We are project professionals with the objective of doing the best we can for our projects and our teams. The terms and concepts in the Code are in many cases intuitive, but for some they may be a change from the norm. In August 2011, the PMI incorporated the concept and terms from this section into the body of the questions within the PMP exam. Before that, there was a 6th category of test questions that focused on this section. With the change, I wanted to bring the code front and center so that it is the first area we cover. It is important to realize that the Code touches all aspects of a project. As you look at the test, you will see questions that are related to the Code in each of the five Process Groups. As you read the important aspects of the Code, remember them as we move forward in each section of the guide.
Vision and Purpose
Describes the expectations that we have of ourselves and our fellow project managers in the global project management community. Articulates the ideals to which we aspire as the behaviors that are mandatory in the many roles we play. Instills confidence in the project management profession and helps an individual become the best project manager they can be. Assists us in making wise decisions when faced with difficult situations that challenge our integrity or place us in a position of compromise.
Persons to Whom the Code Applies
All PMI Members Non-members of PMI who fall into one of the following categories: o Who hold a PMI certification o Who apply to commence a PMI certification process o Who serve PMI in a voluntary capacity
Aspiration and Mandatory Conduct
Aspirational standards describe the conduct that we strive to uphold. o This is not easily measured o It is an expectation that the standards are upheld o They are not optional Mandatory standards establish firm requirements o Must adhere to the standards or face disciplinary action
Structure of the Code
Divided into sections that contain standards of conduct that are aligned with four values
Values that Support this Code
Responsibility Respect Fairness Honesty
Responsibility Description
Is our duty to take ownership for the decisions we make or fail to make, the actions we take or fail to take, and the resulting consequences.
Responsibility - Aspirational Standards
We make decisions and take actions based on the best interests of society, public safety, and the environment. We accept only those assignments that are consistent with our background, experience, skills, and qualifications. We do what we say we will do. We take ownership for our work and our team by o Making corrections promptly o Communicating errors to appropriate body We protect proprietary or confidential information that has been entrusted to us. We uphold this Code and hold each other accountable to it.
Responsibility - Mandatory Standards
We inform ourselves and uphold the policies, rules, regulations and laws that govern our professional work and volunteer activities. We report unethical or illegal conduct to appropriate management and, if necessary, to those affected by the conduct. We bring violations of this Code to the attention of the appropriate body for resolution. We only file ethics complaints when they are substantiated by facts. We pursue disciplinary action against an individual who retaliates against a person raising ethics concerns.
Comments
Specifically, we do not engage in any illegal behavior, including but not limited to: theft, fraud, corruption, embezzlement, or bribery. Further, we do not take or abuse the property of others, including intellectual property, nor do we engage in slander or libel. In focus groups conducted with practitioners around the globe, these types of illegal behaviors were mentioned as being problematic.
Respect Description
Our duty to show a high regard for ourselves, others, and the resources entrusted to us. Resources entrusted to us may include people, money, reputation, the safety of others, and natural or environmental resources.
Respect - Aspirational Standards
We inform ourselves about the norms and customs of others and avoid engaging in behaviors they might consider disrespectful. We listen to others' points of view, seeking to understand them. We approach directly those persons with whom we have a conflict or disagreement. We conduct ourselves in a professional manner, even when it is not reciprocated.
Respect - Mandatory Standards
We negotiate in good faith. We do not exercise the power of our expertise or position to influence the decisions or actions of others in order to benefit personally at their expense. We do not act in an abusive manner toward others. We respect the property rights of others.
Fairness Description
To make decisions and act impartially and objectively. Our conduct must be free from competing self-interest, prejudice, and favoritism.
Fairness - Aspirational Standards
We demonstrate transparency in our decision-making process. We constantly reexamine our impartiality and objectivity, taking corrective action as appropriate. o One of the biggest problems practitioners report is not recognizing when we have conflicted loyalties and recognizing when we are inadvertently placing ourselves or others in a conflict-of-interest situation. We as practitioners must proactively search for potential conflicts and help each other by highlighting each other's potential conflicts of interest and insisting that they be resolved. We provide equal access to information to those who are authorized to have that information. We make opportunities equally available to qualified candidates.
Fairness - Mandatory Standards
We proactively and fully disclose any real or potential conflicts of interest to the appropriate stakeholders. When we realize that we have a real or potential conflict of interest, we refrain from engaging in the decision-making process or otherwise attempting to influence outcomes, unless or until: we have made full disclosure to the affected stakeholders; we have an approved mitigation plan; and we have obtained the consent of the stakeholders to proceed. We do not hire or fire, reward or punish, or award or deny contracts based on personal considerations, including but not limited to, favoritism, nepotism, or bribery. We do not discriminate against others based on, but not limited to, gender, race, age, religion, disability, nationality, or sexual orientation. We apply the rules of the organization (employer, Project Management Institute, or other group) without favoritism or prejudice.
Honesty Description
Duty to understand the truth and act in a truthful manner both in our communications and in our conduct.
Honesty - Aspirational Standards
We earnestly seek to understand the truth. We are truthful in our communications and in our conduct. We provide accurate information in a timely manner. We make commitments and promises, implied or explicit, in good faith. We strive to create an environment in which others feel safe to tell the truth.
Honesty - Mandatory Standards
We neither engage in nor condone behavior that is designed to deceive others, including but not limited to, making misleading or false statements, stating half-truths, providing information out of context or withholding information that, if known, would render our statements as misleading or incomplete. We do not engage in dishonest behavior with the intention of personal gain or at the expense of another.
The Project Management Framework What is a Project? (Page 3) You may think this is a trick question. Everyone knows this or they shouldn't be thinking about taking the exam. While that may be true, what is critical is that you know the right answer. So the correct way to answer the question is this:
A project is a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates a definite beginning and end.
The key here is the word temporary. While the deliverables of a project may be lasting, the project activities involved in creating those deliverables, whether they be a product, a service, or a result, have a clear beginning and ending. For the exam, it will be critical to think of a project as being large in scale. The reason is that larger projects are more likely to provide the opportunity to cover all five Process Groups and all ten Knowledge Areas, whereas a smaller project may not require the need to deal with them all.
What is Project Management? (Page 5) Project management involves managing the activities required in order to meet the project objectives. This includes application of specific knowledge, skills, tools and techniques. There is systematic process that ties the activities of a project together in order for them to be accomplished successfully during the lifecycle of the project. The PMBOK Guide tells us that project management is accomplished through the appropriate application and integration of 47 logically grouped project management processes compromising the 5 Process Groups. Although project management is part science with its logic of step-by-step progression, it is also an art. It is an art, because you are dealing with people that need to execute those logical steps. Anytime you deal with people, their own opinions may overpower the logical steps necessary for successful completion of the project and its deliverables. As the project manager, you may feel more like a baby sitter in these situations, but we'll touch on that more in the upcoming pages.
Relationship between: Portfolio Management, Program Management, and Project Management In most cases, project management is leveraged to serve a broader purpose or set of objectives. A single project can be part of a group of projects that are within a program or portfolio of projects. Organizational structures and strategies are formed in order to support program and portfolio management. It is important for the exam to understand this strong relationship as well as the differences between each.
Portfolio Management (Page 9) Projects or programs may be combined into a portfolio in order to facilitate more effective management of those projects and help the organization achieve specific business goals. Portfolio management focuses on ensuring that projects and programs are reviewed to prioritize items like resource allocation in order to keep them aligned to organizational strategies. It is important to note that the collection of projects or programs within the portfolio may not be directly related or interdependent in any way. Depending on the organization, there is the flexibility to construct the portfolio in the best way to support the organizational objectives. Portfolio management helps to centralize the management of all the projects within the portfolio. There is a consistency in dealing with prioritization, authorization, and controlling of the projects.
Program Management (Page 9) Individual related projects may be combined into a larger program. This allows management in a coordinated manner and provides a level of control that would not be available by managing them on an individual basis‥ This coordination may provide decreased risk, economies of scale, and improved management that could not be achieved if the project were managed individually. Program management, unlike
Portfolio Management, focuses on making sure there are ties or interdependencies between each of the projects within the program related to having a common outcome or collective capability.
Projects and Strategic Planning (Page 10) Each organization is out to accomplish a set of objectives as part of a strategic plan or vision that ensures continued growth and success. At least that is the hope, otherwise that organization won't be around for very long. Projects play a critical role in the execution of that strategic plan. The strategic objectives can center on some of the following topics
Business opportunities Customer requests Legal / Regulatory Market trends
The projects that are created in order to achieve the objectives of the strategic plan can then be placed in programs or portfolios in order to gain the greatest economies of scale to ensure their successful execution. The strategic plan provides the guidelines on how the project is assigned to a program or portfolio, the prioritization of the resources that get assigned, and so much more. The key is recognizing the connection between the individual project, and the benefits that project's success can add to the organization.
Project Management Office (Page 10) The Project Management Office (PMO) is a centralized organizational entity that provides coordinated management of the projects that are under its control. The projects under the PMO may or may not be related. Each organization has the flexibility to define how the PMO will function in order to best meet its needs. The typical responsibilities of the PMO can range from
Terminating projects Managing the interdependencies between projects Providing resources Monitoring compliance with organizational processes Providing templates and define standards Centralizing communication about the projects under its control Being a member of the change control board Being a stakeholder Prioritizing projects
Project Management and Operations Management (Page 12) Operations management focuses on the requirements needed for ongoing execution of activities after the project is complete. These activities in many cases are more repetitive in nature unlike a project with a definitive beginning and end. There is a tight tie between a project and with operations during varying points such as:
Close out phase The development of a new product or enhancing an existing one Lessons learned
These points in time are examples of when information is transferred between the project team that creates and the operations team that manages the ongoing requirements. The communication during these transfer points is critical to ensure that the necessary information is passed between the two groups to mitigate any ongoing issues.
Role of Project Manager (Page 16) In order to achieve the project objectives, the performing organization assigns a project manager. The project manager's responsibilities are unique when compared with other roles in the organization such as a functional manager or operations manager. Many of the tools and techniques for managing projects are specific to project management. Effective project management requires that the project manager possess the following characteristics:
Knowledge Performance Personal
As a project manager you need to have knowledge about project management and how best to apply that knowledge to successfully deliver the project. At the end of the day, project managers are judged on how well they and their team were able to meet the objectives of the project. As a project manager, your performance is based on your ability to take your knowledge about project management and apply it to successfully deliver on the objectives of the project at hand. It also involves how successfully you deal with the project team and stakeholder as well as your own behavior during the project. Challenges abound with any project and your ability to get through them personally as well as a team are also data points where your performance is judged. Your leadership abilities, the effectiveness of how you manage a project, the attitude that you have, day in and day out, provide measurements of your personal performance.
Enterprise Environmental Factors (Page 29) This may be one of those terms that make you go, "What?" As you read the list of items included in the guide or listed below, you begin to get a better idea of what this term means. Most organizations that have been executing projects have a history. They may have developed a way projects should be executed. The PMBOK Guide calls these items "enterprise environmental factors." They are inputs to the Develop Project Charter and many other processes as we will see in more detail. While they can have a positive influence on the project outcome by helping you as a project manager not have to reinvent the wheel for each project, they can also be a constraint to your project. Although the standards in place may not be appropriate for your project, you still need to adhere to them. They include but are not limited to:
Organizational culture, structure, and process Government or industry standards Infrastructure o Facilities o Capital equipment Existing human recourses o Skills o Disciplines o Knowledge Personal administration o Staffing o Retention guidelines Company work authorization systems Marketplace conditions Stakeholder tolerances Political climate Organizational established communication channels Project Management information systems o Automated tools (scheduling software, configuration management system, etc.)
Organizational Process Assets (pg. 27) Enterprise Environmental Factors have a counterpart called Organizational Process Assets. This term is a lot clearer about what it means. Project managers in most cases deal with existing processes, procedures, and historical information that is available to them when managing their projects. These assets help the project benefit from past organizational experience. The following are some examples of organizational process assets:
Processes, Procedures, and Policies –
o
Over time, organizations develop processes, procedures, and policies as they mature based on past projects. These items have been tested and considered to be best practices for project managers to follow. o They include items like: Standards or guidelines Templates Processes Procedures Policies Corporate Knowledge Base – o Organizations have information such as historical records and lessons learned from previous projects. The organization sees the value of this information and then invests to centralize that data into an indexed corporate knowledge base that is available to all. Hint – In the real world, an organization may or may not have such a knowledge base. For the exam you can assume that a database will be available to all project managers unless stated otherwise. o The items stored in the knowledge base may include but are not limited to: Measurement data points – Metrics that have been captured to evaluate projects, products, processes Project files Plans Financial data Risk registers Diagrams Issues and defect management databases Configuration management Baseline & Versions Historical Information – o Historical information (or data) is a record of past projects. It is used to plan and manage future projects, thereby improving the process of project management. Historical information can include: Activities Lessons Learned WBS Benchmarks Reports Risks Estimates Resources needed Project management plans Correspondence Lessons Learned o Project initiating involves looking up past lessons learned for use on the current project.
The Project Life Cycle & Organization When we look at projects and how they are managed, we need to consider that they take place in a much broader landscape. Each project is one piece in an overall puzzle for any organization. As a project manager, the success of your project may depend to some extent on your understanding of your project's context in that full puzzle. This chapter describes the importance of understanding the basic structure of a project. You will also know the importance of the relationship between a Project Life Cycle and a Product Lifecycle, as well as project work and ongoing operational work. Finally, we will focus on the importance of stakeholders and the influence they have, as well as the effect an organizational structure can have on a project.
Project Life Cycle – Overview A life cycle is a progression through different stages of development. We can apply that general definition to both a project as well as a product as we will soon see. PMBOK Guide Definition – Page 38
A project life cycle is the series of phases that a project passes through from its initiation to its closure. The phases are generally sequential, and their names and numbers are determined by the management and control needs of the organization or organizations involved in the project, the nature of the project itself, and its area of application. In order to successfully manage a project you need to have not only the structure of the project lifecycle but also partner that with a methodology of how that will be done.
Characteristics of the Project Life Cycle (Page 38) Regardless of the size or complexity of a project, there are four basic characteristics of a Project Life Cycle including:
Start Planning – Organizing Executing – Carry out the work Closing out
The fact that these characteristics are common in all project life cycles makes it simpler to communicate the project status with all project team members and stakeholders. You are able to quickly provide a status without having to go too deeply into the details, especially when those details will not be meaningful to the audience. The types of information you can use a life cycle to help graphically display would be:
Cost and Staffing levels –
o
showing how they grow at the start, and how they drop rapidly as the project comes to a close Risk & Stakeholder influence o Both are highest at the start of a project, decreasing over the life cycle of the project Cost of change o Being able to show that it is best to make changes early in a project since the cost is low compared to the end where the cost can be very high.
Product vs. Project Life Cycle Relationship The product life cycle consists of generally sequential, non-overlapping product phases determined by the manufacturing and control need of the organization. The life cycle lasts from the conception of a new product to its withdrawal from the market place. During that life cycle a product will require many different projects from the initial one to give it life to those that are done as it declines.
Project Life Cycle Chart
There is a tight relationship between the product life cycle and the project life cycle. From a product perspective, given that there can be numerous projects created to support the product, the organization may decide that it is best to manage the project collectively in order to gain the most efficiency possible. PMBOK Guide Definition – Page 41
Project Phases are divisions within a project where extra control is needed to effectively manage the completion of a major deliverable. In many cases you will see that phases in a project are completed in a sequential pattern, but there can also be overlap. This will depend in part on the type of methodology the organization has chosen to manage projects. Phases allow a project to be broken down into logical chunks to make it easier to plan and manage. Project phases also help with mitigating the complexity or size of a project, thus making the larger project less overwhelming to a project manager. In the end, each phase has a beginning and an end. This gives all phases similar characteristics. Finally, it is possible to have just one phase. Don't be surprised if you are presented with a single phase for a project. It may
be that it is a simple and straight forward project so it only needs a single phase. Exam Hint
A project phase is not a Project Management Process Group
Project Governance Across the Life Cycle Project governance provides a comprehensive, consistent method of controlling the project and ensuring its success. Governance is important for all projects. Each organization, as part of it Organizational Process Assets, has a philosophy of how programs, portfolios and individual projects should be controlled. The phase structure allows a project manager to have stronger controls within each phase and thus over the entire project.
Phase to Phase Relationships (Page 42) When involved with large and complex projects consisting of multiple phases, arranging the phases sequentially is not always the best approach because there could be constraints with respect to the timeline. As a result, the best approach may be to have the phases overlapping or concurrent. There are two basic types of phase-tophase relationships:
Sequential Relationship o Phase can only start once the previous phase is complete. Overlapping Relationship o Phase will start prior to the completion of the previous phase.
Phase-to-Phase Relationships and Project Life Cycles The phase to phase relationship between the project phases heavily depend upon the selected project life cycle for the project. Three basic types of project life cycles that influence the phase to phase relationship of a project are:
Predictive Life Cycles (page 44) o These are also known as fully plan-driven life cycles. o The project scope, time and cost requirements, and other project plans are developed early in the project life cycle. o Project phases are usually sequential in such project life cycles. o Rolling wave planning, where project plans are progressively elaborated as the project progresses and more and more project information becomes available, may be used in such life cycles. Iterative and Incremental Life Cycles (page 45) o Project phases are intentionally repeated as the project team's understanding of the product increases. o The product is iteratively and incrementally developed during these repeated cycles.
o
Such life cycles are preferred for projects where changes to the project's scope and objectives are expected during the life cycle. Adaptive Life Cycles (page 46) o Adaptive life cycles are also known as change-driven or agile methods. o Such life cycles are preferred for complex projects where changes to the project are expected to be very frequent and highly likely and stakeholder involvement is very critical for the success of the project. o The overall scope of the project is broken down into a set of requirements. During every iteration, the project team will select a subset of the requirements to be developed. o Adaptive methods are ideally suited for rapidly changing environments.
Projects vs. Operational Work Many times we don't think about how to categorize work because it is just work. We just need to do it. That said, many organizations find that there are two main buckets that work can fall into. They are project or operational work. Operational work is made up of ongoing and repetitive tasks of a product or service that need to be executed in order to sustain that product or service. That is in contrast to the project work that is temporary and has a definitive beginning and end.
Project Stakeholders (Page 30) Stakeholders are persons or organizations (e.g., customers, sponsors, the performing organization, or the public), who are actively involved in the project or whose interests may be positively or negatively affected by the project performance or completion of the project. For the exam, stakeholders have varying levels of responsibility and authority when participating on a project, and these can change over the course of the project life cycle. Stakeholders may include individuals or groups that you had not really thought about before as having a role or being impacted. The bottom line is that a stakeholder can be anyone or anything. Here are some examples:
Customer User Sponsor PMO Functional Managers Business Partners Project Team Members Project Manager Operations Manager
Stakeholders also have varying levels of influence. Remember that the influence can be both positive as well as negative toward your project. It will be important to determine which stakeholders are behind you and which ones will be possible
obstacles. As a project manager, a major responsibility will be to manage these stakeholders and their expectations. This is not an easy task, as each will have their own opinions and requests.
Organizational Influences on Project Management (Page 20) As a project manager, it is hard enough to take the requirements of any project and successfully deliver them even without any outside influences. In addition to the project requirements, there are always outside influences that a project manager must be aware of in order to deliver any project successfully. Every organization will have a different culture, structure, and style, and each of these areas may have an influence on the success or failure of a project. In addition, an organization's project management maturity will have a major impact on success or failure as well.
Organizational Cultures and Styles (Page 20) Organizational culture is one of the Enterprise Environmental Factors. As a project manager, you need to know and understand the culture in detail. It is important to understand areas like:
Shared vision Organizational values & beliefs Work ethic & hours Policies Procedures
In addition to the above items, an organization's authority structure is a key area the project manager needs to understand
Organizational Structures (Page 21) One of the major influences on any project is how an organization is organized structurally. The structure will dictate who the project manager goes to for resources, how communications will be distributed, and much more. Exam Hint
When you see questions on the exam regarding organizational structure, be sure you know which structure the question is related to. The right answer will depend on it.
Organizational structures have a direct correlation to the extent of the project manager's level of authority. This is an important concept to understand. Remember that we are taking an exam focused on project management, so it is critical to have that focus.
Here are the three types of organizations: Functional (Page 22) This is the most common form of organization. The organization is grouped by areas of specialization within different functional areas (i.e., Sales, Marketing, and Technology). In a functional organization each individual has one immediate superior. Projects generally occur within a single department. If information or project work is needed from another department, the request is sent from the head of the department to the head of the other department. Projectized (Page 25) In a projectized organization, the entire company is organized by projects. The project manager has control of projects. Personnel are assigned and report to a project manager. Team members do not have a department they belong to; they have projects. Once they finish one project, they move on to the next project. Matrix (Page 23) A matrix organization attempts to maximize the strengths of both the functional and projectized structures. In this structure, when team members are assigned to a project, they will typically report to the project manager for project work and to their functional manager for their organizational duties. In a strong matrix organization, power will rest with the project manager. Remember that the exam is focusing on project management, so it should not be a surprise that the project manager will be positioned front and center. In a weak matrix organization, the power rests with the functional manager. In the balance matrix organization, the power is split between the project manager and the functional manager. Now that we have seen the three different structures, you need to think of how these structures will impact your ability as a project manager. The following shows how to determine the impact of the organizational structure:
Who has the power in each type of organization? Is it the project manager or functional manager? What are the advantages of each type of organization? What are the disadvantages of each type of organization?
The following recaps the three different structures: Open table as spreadsheet
Matrix
Project Manager's Authority Resource Availability
Functional Weak Matrix
Balanced Matrix
Little or None
Low
High to Low to Moderate Almost Moderate to High Total
Little or None
Low
High to Low to Moderate Almost Moderate to High Total
Strong Matrix
Projectized
Who Controls the Functional Functional Mixed Project Budget Manager Manager
Project Manager
Project Manager
Project Manager's Role
Part-time
Part-time
Full-time
Full-time
Full-time
Project Management Administrative Staff
Part-time
Part-time
Part-time Full-time
Full-time
All About Project Management Processes We need to start from the beginning with a definition for a process. PMBOK Guide Definition – Page.47
A process is a set of interrelated actions and activities performed to create a prespecified product, result, or service. As a project manager, processes help to provide structure to managing a project. The processes encompass the tools, techniques, inputs, and outputs as described in the Knowledge Areas of the PMBOK Guide. The focus of this section is solely on the process of managing a project. It will describe in detail what should be done, when it should be done, and it summarizes the information that is critical for the exam. According to the PMBOK Guide in order for a project to be successful, the project team must:
Select appropriate processes required to meet the project objectives, Use a defined approach that can be adopted to meet requirements, Comply with requirements to meet stakeholders needs and expectations, and Balance the competing demands of scope, time, cost, quality, resources, and risk to produce the specified product, service, or result.
Project processes performed by the project team will typically fall into one of two major categories:
Project Management Processes. These processes help to ensure the project moves through its lifecycle in an effective manner. Product-Oriented Processes. These processes are necessary to define and create the project's product.
Project Management Process Groups (Page 49) Project management processes are grouped into five different categories which are officially known as the Project Management Process Groups. Each of the five Process Groups contains individual processes associated with that group. There are a total of 47 project management processes that comprise the five Project Management Process Groups and the Project Management Knowledge Areas. Exam Hint
This chapter is one of the most important to know and fully understand for the exam. Within the PMBOK Guide, page 61 is key. The table on this page shows the relationship between each process and its associated Knowledge Area and Process Group. I recommend that you "Memorize" this page or know it very, very well. In many cases, the majority of the exam questions you will see will be related in some way to having knowledge about the Process Groups and Knowledge Areas.
The following are the five Project Management Process Groups:
Initiating Process Group o The processes in this group: Define a new project or new phase of an existing project Provide the authorization to start the project or phase Planning Process Group o The processes in this group: Establish and define the scope of the project Refine the project objectives Define the course of action Executing Process Group o The processes in this group: Ensure that the work defined for the project and noted in the project plan are performed and completed to satisfy the project objectives. Monitoring and Controlling Process Group o The processes in this group: Track Review Regulate progress and performance Identify areas where change is required Initiate the approved change Closing Process Group o The processes in this group:
Finalize all the activities across all the Process Groups to formally close a project or phase.
How Do These Processes Work Together?
The diagram shows how the project management process groups fit together. The first step, Initiating, must be completed for the project to be approved. During this stage there is normally a rough high-level plan that is used to provide duration and impact in order to help with the selection process. Once the project is approved it moves on to the next step. Detailed planning of the project takes place in the Planning process. Details related to how the project will be executed and monitored and controlled are finalized. The project then moves into Executing. This is when the work is performed according to the processes and procedures detailed in the project management plan. While the work is being done, the results are fed into Monitoring and Controlling to make sure the project is tracking according to the baseline plan. If there are variances that require changes, the changes are fed into a change control process to determine if the change should be approved. If approved, the change will then be fed back into planning. Ultimately when the work is done (or the project is terminated), the project moves into the closing process group.
Common Project Management Process Interaction Within the PMBOK Guide, you will see the presentation of the Process Groups and Knowledge Area as distinct entities. In practice, they are interdependent and overlap over the life cycle of a project. The Process Groups and their associated processes provide a guide to the project manager to determine how to apply the knowledge and skills within them for their project. While there are many ways one can manage a
project to a successful completion, as a project manager, you need to determine how to best leverage these elements for your unique project. The application of the Process Groups is an iterative process as shown within the diagram, and in many cases many processes are repeated during the project. We will soon see that each process creates outputs. In most cases, those outputs are inputs to new processes.
Initiating Process Group (Page 54) The Initiating Process Group formally starts by defining a new project or project phase through obtaining the necessary authorization to begin the project or phase. In many organizations, there is a formal project selection process with established selection criteria. Once a project is selected, a project charter is created and authorized. Initiating a project also involves the identification of stakeholders so their needs can be incorporated into the project. During the Initiating Process Group, large projects may be divided into separate phases. In that case, the initiating processes are enacted during each phase to validate the decisions made during the original Develop Project Charter and Identify Stakeholders processes. This helps keep the project focused on the original objectives.
Planning Process Group (Page 55) It is the Planning Process Group that goes through the project in detail by determining the total scope of the effort, defining and refining the objectives, and developing the course of action required to achieve the stated objectives. The planning processes organize the work through the development of the project management plan and project documents that will be used to carry out actual work. It is during the planning process that you begin to see the likelihood of success of the project in achieving its stated objectives. It is during the execution of the processes within this group that the project team may discover opportunities to save on resources, time, and costs based on the high-level plan and assumptions made during the initiating process. Project planning addresses all the appropriate project management processes and knowledge areas. This means that the project manager and the project team will determine what processes in the PMBOK Guide are appropriate in order to avoid needless activities that are not relevant to the current project. The results of Project Planning are the project plan and supporting project documents that will be used to manage the project. A key point to remember is that planning is iterative. There are constant changes and adjustments that take place and need to be accounted for by the project manager and the team. The plan and supporting documents are the best way to detail, execute, and track those changes. Exam Hint
In the real world and for the exam, you want to follow the processes in the planning group and attempt to complete each one as fully as possible. For the exam, the project planning process involves everyone. The project plan and documents are compiled by the project manager with input from stakeholders. Don't forget that you have Enterprise
Environmental Factors and Organizational Process Assets. These contain items such as historical records from previous projects, company policies, and other similar information that may also be utilized in planning the project. At this point, since everything is in hand, the project manager may think they are finished planning. If such is the case, they have failed to recognize one very important aspect of project management: Risk. It is critical to consider risk identification, analysis, and response planning into the planning process. Once the risk is in hand, you then need to go back to finalize all the components of the project management plan and documents. The risk management process may uncover necessary changes that could impact the plan and project resources, including the final cost and any impact on schedule or resource allocation. This approach to planning is the most efficient way to proceed. I am sure each of you has experience where people don't understand the importance that planning has for a project. They are of the mindset that is in line with "Fire Ready Aim". They see action as being the primary driver, and they are not concerned with how the action happens. You would not be reading this guide nor wanting to pass the PMP if you had that mindset. As a project manager, you will need to help influence others to see the importance planning has to the success of the project. There is also a sense of balance that must be achieved in that the amount of time spent in the planning process group should be appropriate to the needs of the project. Projects in which the schedule requires a high level of confidence will require more planning time to reduce the possibility of schedule variance to the minimum level.
Executing Process Group (Page 56) The Executing Process Group is where all the work is done. Officially it is made up of processes that complete the work defined in the project management plan to meet the project objectives. The focus is now on managing people, following processes, and distributing information, all in accordance with the project management plan and project documents. During the project execution, the project results may require planning changes and updates. These updates can include changes in resource availability, activity durations, and unidentified risks. These changes or variances to the project management plan may result in change requests being created, which if approved, would require updating the project management plan and documents. Exam Hint
For the exam, you must assume proper project planning was done before the project work began. You need to get your mind around the critical difference planning makes and assume the project has been properly planned as you answer the questions. It is surprising how few project managers create a realistic plan or get it officially approved. In the real world, and in the world of the exam, that would be a huge mistake. A project manager should be spending time preventing problems, so he or she does not have to spend time solving them. Meetings are an activity
Exam Hint
that can consume a great deal of the project team's available time. Many project managers do not realize that proper planning can decrease the number of meetings they need, making meetings only a minor activity. You don't want to meet for meeting sake nor do you want to waste the time of a meeting on simple status updates when that can be captured in other more efficient ways. It is in this section that you need to be able to identify what you are not doing, or what you are doing wrong in the real world and leave those practices at the door. You will be penalized in the exam if you follow your poor real world practices. You want to keep the words "work to the project management plan," "be proactive," "manage," and "guide," in mind as a way to summarize executing activities while you take the exam. This frame of mind will ensure you have your PMI hat on when taking the exam.
Monitoring and Controlling Process Group (Page 57) The Monitoring and Controlling Process Group comprises processes that focus on measuring the performance of the project to the project management plan and approving change requests, including any recommended corrective and preventive actions and defect repair. The key benefit of this set of processes is that the project performance is tracked and measured in a consistent way to identify any variances from the project management plan. The monitoring gives management and the project team insight into the status and health of the project, and more importantly where added attention may be required. Note: Exam Hint
You have a project management plan that is realistic and complete. You have plans already in place for how and where you will measure time, cost, and scope performance against the performance measurement baseline. You are accountable for meeting the performance measurement baseline. You also measure against the metrics you have determined for the project and included in the project management plan to see how the project is performing. You can act to correct any variances that warrant action. Any deviation from the plan should be made up, rather than requesting a change to the project to accommodate them. Submitting a change request should be the very last resort and only used if there is no other way to make up the deviation.
Closing Process Group (Page 57) The Closing Process Group consists of the processes needed to finalize all activities in order to formally complete the project, phase, or contractual obligations. This is one of the most ignored parts of the project management process because many project managers incorrectly believe that the project is complete when the final product scope is done. The project is completed only when the closure is completed.
The closing processes will include administrative activities such as collecting and finalizing all the paperwork needed to complete the project, and technical work to validate that the product of the project is acceptable. It will also include any work needed to transfer the completed project to those who will use it and return all resources back to the performing organization and /or the customer. In many real world situations, projects never really end; they just seem to fade away. Sometimes the project manager goes on to another project, sometimes the project's priority decreases, or sometimes the work on the project just stops. In any situation, ignoring the closing processes is a real mistake, as the work to be done during closure is extremely important to the performing organization and to the customer.
Project Management Knowledge Areas (Page 60) The PMBOK Guide documents 47 processes in the above mentioned five process groups. These 47 processes are further grouped into ten separate Knowledge Areas or project management fields/areas of specialization. The ten project management knowledge areas are:
Project Integration Management Project Scope Management Project Time Management Project Cost Management Project Quality Management Project Human Resource Management Project Communications Management Project Risk Management Project Procurement Management Project Stakeholder Management
These ten knowledge areas are managed in most projects. However, depending upon the complexity and the need of a project, the project manager can decided which project management processes from these ten knowledge areas must be applied on the project. Exam Hint Within the PMBOK Guide, page 61 is key. The table on this page shows the relationship between each process and its associated Knowledge Area and Process Group. I recommend that you "Memorize" this page or know it very, very well. In many cases, the majority of the exam questions you will see will be related in some way to having knowledge about the Process Groups and Knowledge Areas.
Deep Dive into Project Integration Management Project Integration Management – (Page 63) The project manager's main role is to pull all the pieces of a project together into a cohesive whole. Integration Management has characteristics of unification, consolidation, and integrative actions that help to manage a project successfully between the team and the stakeholders. PMBOK Guide Definition – Page 63
Project Integration Management includes the processes and activities need to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Management Process Groups. Many people have trouble with this knowledge area on the exam because they do not currently perform integration management on their project in the real world, or they don't think about integration management from a large project perspective. The project manager is responsible for integration – putting all the pieces of the project puzzle together into one cohesive whole that gets the project done faster, cheaper, and with fewer resources, while meeting the project objectives. Think about integration as balancing all the processes in the knowledge areas with each other. These project management processes do not happen independently. In order to add a new resource to a project, it may require cost and schedule changes. In dealing with each situation that comes up on a project, the project manager is integrating the processes of project management. Given that integration management incorporates all the different groups and knowledge areas it is a difficult area of the exam. Always remember that the project management processes are iterative. Any process can be revisited as required Open table as spreadsheet
The Integration Management Process Done During Develop Project Charter
Initiating Process Group
Develop Project Management Plan
Planning Process Group
Direct and Manage Project Work
Executing Process Group
Monitor and Control Project Work
Monitoring and Controlling Process Group
Perform Integrated Change Control
Monitoring and Controlling Process Group
Close Project or Phase
Closing Process Group
Develop Project Charter The first part of integration management is creating a project charter. A project charter establishes a partnership between the performing organization and the requesting organization (or customer, in the case of external projects). The approved project charter formally initiates the project. PMBOK Guide Definition – Page 66
Develop Project Charter is the process of developing a document that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. Don't underestimate the value of the project charter. The project charter is such an important document that a project can't be started without one. This is not always a best practice in the real world. If the project charter is your target for the project and serves as a definition of how success will be measured, then without a project charter, the project and project manager can't be successful. Exam Hint
You need to know the following about a Project Charter for the exam:
Guide Hint
The project charter formally recognizes/authorizes the existence of the project, or establishes the project. It gives the project manager authority to spend money and commit corporate resources. The project charter provides the high-level requirements for the project. It links the project to the ongoing work of the organization.
There will be inputs, tools and techniques, and outputs for the processes as we go forward. The guide will highlight and provide additional details on some of the terms as we move forward through the upcoming chapters. The additional details will help to explain the term and its use.
Inputs
Project Statement of Work (page 68) The project statement of work or SOW is a description of the product or services that are to be delivered by the project. The SOW can be used for both internal project as well as external projects. The SOW typically references the following:
Business need o The following are examples of areas that may influence the business need Market demand Technological advances Regulations Legal requirements Product scope description
o
Documents the characteristics of the product and the relationship to the ongoing services and the tie in to the business need. Strategic plan o Documents the organization's strategic objectives. As a project manager, it is important to make sure that your project is in line with those objectives.
Business Case (page 69) The business case documents all the information to help determine if a project is worth the organization's investment in time and resources. A key component within the business case is a financial analysis with a quantifiable justification for the project. The following items are drivers to create a business case:
Market demand Organizational Need Customer request Technological advance Legal requirement Ecological impact Social need
Agreements, memorandums of understanding (MOUs), service level agreements (SLAs), letters of agreement and letters of intent are all forms of legal documents establishing a contractual engagement between two parties Agreements Enterprise Environmental Factors Organizational Process Assets Do not confuse organizational process assets and enterprise environmental factors as internal and external project factors. Enterprise environmental factors can be internal to the performing organization, e.g., existing human resources and project management information system Tools and Techniques Guide Hint The Tools and Techniques are meant to be a practical application of
how the process is derived and leveraged for the good of the project. Whenever the PMBOK Guide mentions "Expert Judgment", do not assume it is referring to an executive decision being taken by the project manager. Expert judgment is usually obtained from the subject matter experts and this may include the project manager Expert Judgment (page 71) Expert judgment is used a great deal, and is based on the expertise from an individual or groups that have special knowledge or training.
The following are some examples of sources of expert judgment: o Stakeholders o Consultants o Subject matter experts
Facilitation Techniques (page 71) Facilitation techniques are used by project managers collect and define the high level requirements from the project stakeholders. At this stage, facilitation techniques play a key role since the stakeholder influence and project risk is high.
The following are examples of some facilitation techniques: o Brainstorming o Conflict resolution o Problem solving o Meeting management
Outputs
Project Charter (page 71) The project charter is the document that describes the business need, the customer need, and the new product, service, or result the project is intended to satisfy. There is a generic sample below just to show what a Project Charter might include: Project Title and Description
Detail out at a high-level what the project is all about and what it is trying to accomplish.
Project Manager Assigned and Authority Level
Formally communicate the project manager for the effort. Provide details on the authority and decision making capabilities when it comes to budget, schedule, staffing, etc.
Business Case
Detail why the project is being done. Specify the financial or other justification for the project. Outline high-level objectives that are going to be used to track success for the project.
Resources Assigned
Provide the details on the size of the team and justification. Outline the names of known resources assigned.
Stakeholders
Detail the names and roles of each of the stakeholders affected by the project.
Product Description/ Deliverables
Detail the high-level description of the product to be delivered. Highlight the key deliverables needed and their timing in order to meet business objectives.
Measureable Project Objectives
Define the project objectives and their tie in to the business objectives. Define measurable metrics to support and track the project objectives.
Approval Requirements
Detail the specific requirements that need to be met in order for the project to be approved by all the stakeholders.
High-Level Project Risks
Determine the known key risks that could impact the project as well as any plans to mitigate them.
Develop Project Management Plan (Page 72) PMBOK Guide Definition – Page 72
Develop Project Management Plan is the process of defining, preparing, and coordinating all subsidiary plans and integrating them into a comprehensive project management plan. Project managers must plan before they act. Management plans are the strategy for managing the project and the processes in each knowledge area. The concept of management plans is very important to understand. These plans are created for each project management knowledge area. You need to think ahead and document how you will plan this particular project based on the needs of the project, how you will manage the project, and how you will control it. This effort to think through the project in advance should cover all aspects of the project management process. A management plan is a necessity and unique to each project in order to address its particular needs. The creation of management plans is an integral part of the project manager's job. To reiterate to make sure we are all on the same page, a management plan covers how you will:
Define Plan Execute
Monitor & Control Close Exam Hint
Here is a trick to understanding the topic of management plans for the exam. Know that management plans look forward in time, and that there are management plans for each knowledge area: o o o o o o o o o
Scope Schedule Cost Quality Human Resources Communications Risk Procurement Management Stakeholder Management
There are also the following management plans:
Change Management Plan Configuration Management Plan Requirements Management Plan Process Management Plan
Inputs
Project Charter "Outputs from Other Processes" is an input to the Develop Project Management Plan process. This refers to the subsidiary project management plans developed during planning processes across each knowledge area Outputs from Other Processes (page 74)
These are the management plans from the other planning processes described above
Enterprise Environmental Factors that can influence, include but are not limited to:
Governmental and/or industry standards Project management information systems Organizational structure and culture Infrastructure Personnel administration
Organizational Process Assets (OPA) that can influence, include but are not limited to:
Standardized guidelines Project management plan template Change control procedures Past project files Historical information and lessons learned Configuration management knowledge base
Tools and Techniques
Expert Judgment
Make sure you are taking the unique aspects of your project into consideration including the project needs, resources and skills required, documentation and configuration, and much more.
Facilitation Skills Outputs
Project Management Plan
Integrates and consolidates all subsidiary management plans & baselines.
Project management plans can be either summary level or detailed, depending on the level of information that you and the project team have available to you at the time. Baselines Baselines are established when the project plan has been approved. Once the baseline is established, the key management plans as noted below can only be changed via a change request and approval through Perform Integrated Change Control process.
Schedule Cost Scope
The project manager must be able to clearly, completely, and realistically define the scope, schedule, and cost budget to derive baselines. The project performance and the performance of the project manager will be measured against those baselines. The project manager needs to be aware of any deviations from the baselines while the work is being done. If a deviation is discovered, the project manager needs to see if adjustments can be made to keep the project on track while dealing with the problem. If the adjustment is not sufficient to correct the variance, a formal change request to the baseline might be necessary.
Direct and Manage Project Work(Page 79) This is the integration part of the executing process group. In Direct and Manage Project Work, the project manager integrates all the executing processes into one coordinated effort to accomplish the project management plan and product deliverables. In addition, it involves requesting changes and completing the work accompanying approved change requests. Exam Hint
Please note the confusing terms. If the exam talks about Direct and Manage Project Work, it is NOT talking about the entire executing process group. Instead, it is just talking about the integration piece of executing.
The PMBOK Guide does not say too much about the Direct and Mange Project Work process, but this and the Monitor and Control Project Work process make up the majority of the project work. You want to make sure you remember that the Direct and Manage Project Work process involves managing people, doing the work, and implementing approved changes. The following are examples of possible Direct and Manage Project Work activities:
Perform activities designed to accomplish the project requirements Create the project deliverables Staff, train, and manage team members Obtain, manage, and use resources assigned to the project, including materials, tools, equipment Implement the planned methods and standards Establish and manage the internal and external project communication channels Generate project data Issue change requests and implement approved changes Manage risks and risk responses Manage procurement Collect and document lessons learned
During the executing of any project there are going to be changes that materialize throughout the lifecycle of the project. The only time that changes can be executed is when they have been approved. There are different types of approved changes to be aware of for the exam. Always remember that a corrective action fixes some of project work to bring it back in alignment the project management plan. On the other hand, a preventive action ensures that a mistake will not happen or be repeated in the future
Corrective Action o A corrective action is any action taken to bring project performance in line with the project management plan.
o
Any corrective actions that would change the project management plan, baselines, policies or procedures, charter, contract, or scope of work require formal change requests, to be reviewed and approved or rejected as part of the Perform Integrated Change Control process. Preventative action o Preventive action deals with anticipated or possible deviations from the performance measurement baseline. o A preventive action ensures the future project performance is in line with the project management plan. Defect repair o This is when quality issues or defects have been identified and need to be corrected in order for them to meet the defined requirement standards.
Each type has a different impact on a project and each plays an important role in the project success. Inputs
Project Management Plan Approved Change Requests (page 82)
The Integrated Change Control Process will facilitate which changes are approved and which are not. The approved changes can then be assessed in terms of the impact they will have on the project.
Enterprise Environmental Factors
Enterprise environmental factors which can influence Direct and Manage Project Work can include, but are not limited to: o Organizational and customer culture and structure o Infrastructure o Personnel administration o Risk tolerance of stakeholders o Project management information systems if available
Organizational Process Assets
Organizational process assets that may influence the Direct and Manage Project Execution can include, but are not limited to: o Work instructions and guidelines o Requirements defining communications media, record retention an security o Defect management procedures o Database of process measurements o Prior project files o Historical records regarding defect management
Tools and Techniques
Expert Judgment
Expert judgment may be available from various areas in the organization. Some of these areas include but are not limited to: o Other organizational units o Internal and external consultants o Stakeholders including sponsors and customers o Technical and professional associations
Project Management Information System (PMIS) (page 84)
This is considered to be part of the Enterprise Environmental Factors. It is an automated tool such as a configuration management system, scheduling software, or other online tool that may be used to help the project execution be more efficient.
Meetings
Project activities and issues are discussed during meetings. Key objectives of a typical meeting are: o Information exchange o Brainstorming, option analysis, design review o Decision making
Outputs
Deliverables (page 84)
We generally have a good idea of what a deliverable means, but it is important to make sure there is no doubt, especially for the exam. First the final deliverable needs to be approved. A deliverable is a verifiable result that can come in the form of a product or service.
Work Performance Data
This can take many forms. As project managers, we capture project data in status reports, budget reports, and progress per the plan.
Change Requests
Corrective action Preventative action Defect repair Updates o This is an added component to the above three that we covered previously. Every project's approved changes need to be incorporated into the controlled documentation created by the project. These updates are made to the control documents to ensure they are kept up to date.
Project Management Plan Updates The following are examples of the different management plans that would be updated during the life cycle of the project to reflect the progress in each area:
Scope management plan Requirements management plan Schedule management plan Cost management plan Quality management plan Human resource plan Communication management plan Risk management plan Procurement management plan Stakeholder management plan Project baseline
Project Document Updates The different types of project documents that can be updated include but are not limited to:
Requirements documents Project logs (issue, assumptions, etc) Risk register Stakeholder register
Monitor and Control Project Work (Page 86) Monitoring and controlling project work is a control function that is done from project initiating through project closing. When you think of a large project, it makes sense that the project manager would need to monitor and control how the processes are going, because he or she would not typically be personally involved in performing all the project functions. The results of Monitor and Control Project Work are change requests, work performance reports, as well as updates to the project management plan and documents. PMBOK Guide Definition – Page 86
Monitor and Control Project Work is the process of tracking, reviewing, and reporting the progress to meet the performance objectives defined in the project management plan. Monitor and Control Project Work is an integration function because the project manager must balance the demands of the different knowledge areas to control the project. This process also involves monitoring any other performance measures that the project manager has created for the project and distributing that information to stakeholders as needed.
Exam Hint
Keep in mind that a project must be controlled. If the exam asks what you should do if a work activity on the project takes longer than estimated, the answer is to take corrective action to make up for the schedule variance. Such action always keeps the project on or close to schedule and allows the project manager to feel comfortable that the scope will be completed according to the budget and schedule agreed to. This is the value of controlling the project.
The Monitor and Control Project Work Process is Concerned with:
Comparing actual project performance against project plan Assessing work performance to determine if corrective or preventive actions are required Identifying new risks and monitoring existing risks to make sure the risks are identified Maintaining accurate and timely information concerning the project's products and associated documentation Providing the information necessary for status reports, progress measurements, and forecasting Providing forecasts to update current cost and schedule information Monitoring implementation of approved changes
Inputs
Project Management Plan Schedule Forecasts (page 89) Schedule forecasts are obtained after analyzing the project progress against the schedule baseline. Earned Value Management Techniques (EVM) are used to measure the schedule performance. We will discuss these techniques in detail later in the guide. Cost Forecasts The cost forecasts are obtained after analyzing the project's spending against the cost performance baseline. Earned Value Measurements such as Earned Value (EV), Cost Variance (CV), Estimate to Complete (ETC), and Cost Performance Index (CPI) are some of the measures used to predict future costs. We will discuss these topics in a greater detail later in the guide. Validated Changes Approved change request, that result from the Perform Integrated Change Control process and implemented during the Direct and Manage Project Work process, require validation to ensure that the change was appropriately implemented. Work Performance Information
The work performance information is obtained by analyzing the work performance data collected from various controlling processes. The project management team transforms the work performance data into work performance information. The work performance information helps the project management team take well informed decisions. Enterprise Environmental Factors Enterprise Environmental Factors that can influence this process include, but are not limited to:
Governmental or industry standards Company work authorization system Stakeholder risk tolerance Project Management Information systems
Organizational Process Assets Organizational Process Assets that can influence the process include, but are not limited to:
Organization communication requirements Financial controls procedures Issue and defect management procedures Risk control procedures Process measurement database Lessons learned database
Tools and Techniques
Expert Judgment
The project team may rely on expert judgment to interpret the information provided by the process.
You should remember the names of the analytical techniques mentioned as the tools and techniques of the Monitor and Control Project Work process. While these tools and techniques may not explicitly be mentioned in the PMBOK Guide, it is valuable to familiarize yourself with them via external sources (online search, etc) Analytical Techniques The project management team can utilize various analytical techniques to forecast potential outcomes on possible variations or environment factors and their interrelationships. Some of the examples of such techniques are:
Regression analysis Grouping methods Root cause analysis Simulations
Trend analysis Earned value management Variance analysis
Project Management Information System
Meetings Outputs
Change Requests
Corrective action Preventative action Defect repair
Work performance reports are not the same as work performance information. The work performance report is a physical or electronic representation of the work performance information. The work performance information is the processed form of the work performance data Work Performance Reports Work performance reports are the physical or electronic representation of work performance information obtained by transforming the work performance data. These reports play a critical role in providing key project information to the project stakeholders and enable them to take well-informed decisions. Project Management Plan Update examples include, but are not limited to:
Schedule management plan Cost management plan Quality management plan Scope baseline Schedule baseline Cost performance baseline
Project Document Update examples include, but are not limited to:
Forecasts Performance reports Issue log
Perform Integrated Change Control (Page 94) During the executing, and monitoring and controlling processes, changes may be requested that affect any part of the project. These changes are accepted or rejected and handled in the Perform Integrated Change Control process. A key aspect of integrated change control is looking at the impact the change may have on each of the knowledge areas and the resulting impact a scope change may have on quality, risk, time, costs, human resource, etc. PMBOK Guide Definition – Page 94
Perform Integrated Change Control is the process of reviewing all change requests, approving changes and managing changes to the deliverables, organizational process assets, project documents, and the project management plan; and communicating their disposition. Exam Hint
Integrated change control is an important topic to know. Nearly 10% of the questions on the exam can touch on this one topic from different angles.
As we have said, every project has changes. Integrated Change Control process starts with a review of those changes. In order to evaluate the impact of change, it is necessary to have:
A realistic project management plan to measure against A complete product scope and project scope
In the event that Integrated Change Control is a new concept to you or one that your organization does not follow, the following is a generic look from a high-level as well as detailed level on the steps you need to take from start to finish of the process:
High-level Process for Making Changes
Evaluate the impact o Evaluate the impact of the change to the project o Consider the project constraints against the change Create options o This can include cutting other activities, crashing, fast tracking, etc., as described in Time Management. Get the change request approved internally Get customer buy-in
Now that you know the high-level process, let's take a look at the more detailed process for making changes.
Detailed Process for Making Changes
Prevent/Remove the root cause of changes o The project manager should not just focus on managing changes, but proactively eliminate the need for changes. Identify change o Changes can come from the project manager, as a result of measuring against the project performance measures, or from the sponsor, the team, management, the customer, or other stakeholders. o The project manager should actively be looking for changes from all the different sources, because discovering a change early will decrease the impact of the change. Assess the impact of the change o If it is a scope change, how will it affect the rest of the scope of the project? If it is a time change, how will it affect the rest of the schedule for the project? Create a change request o Changes can be made to the product scope, contract, charter, or a host of other areas of the project. The process of making a change should follow the change management plan. Perform integrated change control o Assess the change o Look for options Options include actions to decrease threats further; increase opportunities; or compress the schedule. Change is approved or rejected Update the status of the change in the change control system Adjust the project management plan, documents, and baselines if approved. Manage stakeholders' expectations by communicating the change to the stakeholders affected by the change Manage the project to the revised project management plan and project documents.
Changes can have both a positive as well as negative effects on a project. Depending on the timing of the change, the later in the project life cycle the higher the probability is for the change to be more expensive and disrupt the project. Generally the project manager should do their best to prevent the root cause of the need for changes or do their best to mitigate the impact. In order to help you as a project manager you want to make sure you to do the following:
Work to obtain final requirements as soon as possible Spend enough time in risk management to comprehensively identify the project's risks Come up with time and costs reserves Have a process in place to control changes Follow the process to control changes Have a process and templates in place for creating change requests Have clear roles and responsibilities for approving changes Reevaluate the business case if the number of changes becomes excessive
Consider terminating a project that has excessive changes and starting a new project with a more complete set of requirements Allow only approved changes to be added to the project baselines Update the project documents accordingly.
Change in any project can produce an administrative nightmare in terms of being able to keep up with the documentation necessary in order to keep it in sync with the changes. In many organizations there are more formal tools in place such as a Configuration Management System.
A Configuration Management System with integrated change control offers an effective and efficient method for managing change within a project. Project wide application of the configuration management system including change control processes, accomplishes three main objectives: o Establishes a method for consistently identifying and requesting changes to established baselines while assessing the value of effectiveness of those changes o Provides opportunities for validating and improving the project by evaluating the impact of each change o Provides a communication mechanism the project management team can use to communicate approved and rejected changes to the stakeholders Configuration Management activities included in Integrated Change Control process are as follows: o Configuration identification o Configuration status accounting o Configuration verification and audit
Inputs
Project Management Plan Work Performance Reports Change Requests Enterprise Environmental Factors Organizational Process Assets that can influence this process include, but are not limited to:
Change control procedures Procedures for approving and issues change authorizations Process measurement database Project files Configuration management knowledge base
Tools and Techniques
Expert Judgment
Stakeholders may be asked to provide expertise and/or sit on the change control board.
Meetings
If a change control board is created, its responsibility will include meeting to review the change requests to either approve or reject them.
Change Control Board (Page 96) Depending on the project manager's level of authority, their role might be to facilitate decisions about some changes, rather than actually make the decisions. For these reasons, many projects have change control boards. The board is responsible for reviewing and analyzing change requests. It then approves or rejects the changes. The board may include the project manager, customer, experts, the sponsor, and others. Exam Hint
For the exam, assume that all projects have change control boards.
Change Control Tools Various manual and automated tools can be used during this process in order to facilitate the configuration and change management. Such tools handle change requests and track the subsequent decisions and implementation. Outputs
Approved Change Requests Change Log Project Management Plan Updates Project Document Updates
Close Project or Phase (Page 100) Many high-level concepts of closing have already been touched on in the Project Management Process. What remains is to realize that this process finalizes all activities across all process groups to formally close out the project or project phase. It is critical to get formal acceptance of the project, issuing a final report that shows that you have been successful, issuing the final lessons learned, and archiving all the project records.
Exam Hint
Be sure to remember for the exam that as project manager you always close out a project, no matter the circumstances under which it stops, is terminated, or is completed. Here is a quick reminder of the closing activities:
Confirm work is done to requirements Complete procurement closure Gain formal acceptance of the product Complete final performance reporting Index and archive records Update lessons learned knowledge base Hand off completed product Release resources
Inputs
Project Management Plan Accepted Deliverables Organizational Process Assets that can influence this process include, but are not limited to:
Project or phase closure guidelines or requirements Historical information and lessons learned knowledge base
Tools and Techniques
Expert Judgment Analytical Techniques Meetings Outputs
Final Product, Service, or Result Transition
This refers to the transitions from the project to the ongoing servicing of the product or service once the project is approved and completed.
Organization Process Assets that can influence this process include, but are not limited to:
Project files Project or phase closure documents Historical information
With the completed project, all the materials and documents that were created during the life cycle of the project need to be gathered and officially stored. This way other
project managers and project teams can leverage this information to help them with their projects.
Other Key Concepts Project Selection
There are various ways to select which project to initiate from among the many possible choices. The projects that were considered before a particular project was chosen, as well as the process used to select the project, may have some influence how the project is planned and managed. Know the following two categories of project selection methods and their subsets for the exam: 1. Benefit measurement method (Comparative Approach) a. Peer Review b. Scoring Models c. Economic models – more details below 2. Constrained optimization methods (Mathematical approach) a. Linear programming b. Integer programming c. Dynamic programming d. Multi-objective programming Economic Models from Project Selection
The following are economic models for selecting a project:
Present Value Net Present Value Internal Rate of Return Payback Period Benefit- cost ration
Present Value
Historically, Present Value has only been mentioned once or twice on the exam. You will not have to calculate it, nor know the formula. You will just need to understand the concept behind it. Present value means the value today of future cash flow and is defined by the formula: PV = FV (1+r)n Open table as spreadsheet
FV = future value R = interest rate N = number of time periods
Watch out! PV also stands for planned value (described in the Cost Management section). You want to avoid confusing these terms. Net Present Value (NPV)
You will not have to calculate NPV for the exam. You will need to know that it is the present value of the total benefits (income or revenue) minus the costs over many time periods. NPV is useful because it allows for a comparison of many projects to select the best project to initiate. Generally, if the NPV is positive, the investment is a good choice unless an even better investment opportunity exists. The project with the greatest NPV is selected. Internal Rate of Return (IRR)
IRR does get confusing when you give it a formal definition such as: The rate (as in interest rate) at which the project inflows (revenues) and project outflows (costs) are equal. Calculating IRR is complex and requires the aid of a computer. You will not have to perform and IRR calculations on the exam. You will need to understand the definition and be able to answer questions related to the following: Payback Period
This term refers to the number of time periods it takes to recover you investment in the project before you can start accumulating profits. Benefit Cost Ratio
This term is one of many that is not in the PMBOK Guide, but may be on the exam. Benefit cost ratio relates to costing projects and determining what work should be done. This ratio compares the benefits to the costs of different options.
A benefit costs ratio of greater than 1 means the benefits are greater than the costs. A benefit cost ratio of less than 1 means the costs are greater than the benefits. A benefit cost ratio of 1 means the costs and the benefits are the same. Benefit cost ratios can be expressed as decimals or ratios.
Additional Accounting Terms: Economic Value Added (EVA)
In terms of project selection, this concept is concerned with whether the project returns to the company more value that it costs. (Note that this is a different concept than earned value analysis, which can also have the acronym of EVA. Earned value, discussed in the Cost Management section, is frequently mentioned on the exam, whereas economic value added should rarely appear in questions or choices.) For the exam, simply remember that economic value added is the amount of added value the project produces for the company's shareholders above the costs of financing the project. Opportunity Costs
This term refers to the opportunity lost by selecting one project over another. Sunk Costs
Sunk costs are expended costs. Be aware that accounting standards say that sunk costs should not be considered when deciding whether to continue with a troubled project. Law of Diminishing Returns
The law states that after a certain point, adding more input (e.g., resources) will not produce a proportional increase in productivity. Working Capital
This term refers to current assets minus current liabilities for an organization, or the amount of money the company has available to invest, including investment in projects. Depreciation
Large assets purchased by a company lose value over time. Accounting standards call this depreciation. Several methods are used to account for depreciation. 1. Straight Line Depreciation – the same amount of depreciation is taken each year. 2. Accelerated Depreciation – For many years, the exam has not asked detailed questions about this topic. For the exam you need to know the following: a. There are two forms of accelerated depreciation. You do not have to understand what these two forms mean or do any calculations.
i. Double Declining Balance ii. Sum of Years Digits b. Accelerated depreciation depreciates faster than straight line. Project Integration Management Cheat Sheet
Open table as spreadsheet
Process Develop Project Charter
Develop Manage ment Plan
Direct & Manage Project Work
Monitor &
Descripti Group Input Tools & Output on Technique Formal Initiatin Project Expert Project authoriza g SOW judgment Charter tion of Business Facilitati the case on project or Agreeme techniqu phase nts es EEF OPA Documen Plannin t actions g to define, prepare, integrate, and coordinat e subsidiar y plans into the PMP
Execute Executi the work ng defined in the project managem ent plan to achieve requirem ents in scope statement .
Monitor and
Controll ing
Project charter Outputs from other processes EEF OPA
Project managem ent plan Approved changed requests EEF OPA
Project managem
Expert judgment Facilitati on techniqu es
Project managem ent plan
Expert judgment PMIS Meetings
Deliverab les Work performan ce data Change requests Updates – project plan; docs
Expert judgment
Change requests
Process
Descripti Group on
Control Work
control the processes to meet the performa nce objective s.
Input
Reviewin Controll g change ing requests, approvin g change requests and controllin g changes.
Finalize Closing Close Project all or Phase activities to formally close the project or phase.
Perform Integrate d Change Control
Tools & Technique ent plan Schedule forecasts Cost forecasts Validated changes Work performa nce informati on EEF OPA
Project managem ent plan Work performa nce reports Change requests EEF OPA
Project managem ent plan Accepted deliverabl es OPA
Output
Analytic al techniqu es PMIS Meetings
Work performan ce reports Updates: project managem ent plan; document s
Expert judgment Meetings
Approved change requests Change log Updates: project plan; document s
Expert judgment Analytic al techniqu es Meetings
Final product/se rvice Updates: OPA
Deep Dive into Project Scope Management Project scope is the work that is required to be completed. Always remember; scope = work PMBOK Guide Definition – Page 105
Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Exam Hint
How the PMBOK Guide outlines the best practice for scope management and how you manage it in the real world might be different. There are a lot of acceptable ways to manage scope. For the exam, you want to be in the mindset of what the PMBOK Guide describes as the scope management process, which is:
Make sure all requirements support the business need of the project as described in the charter. Sort through and balance the needs of the stakeholders to determine product scope and project scope. Create a WBS (Work Breakdown Structure) to break the scope down to small, more manageable pieces. Validate that the scope of work planned is actually being done. Measure scope performance, and adjust as needed.
The following are the more formal scope management processes: Open table as spreadsheet
The Scope Management Process Done During Plan Scope Management Planning Process Group Collect Requirements
Planning Process Group
Define Scope
Planning Process Group
Create WBS
Planning Process Group
Validate Scope
Monitoring and Controlling Process Group
Control Scope
Monitoring and Controlling Process Group
Key Terms to be familiar with: Product Scope (Page 105)
Product scope are the features and functions that define the product or service Product scope may be supplied as a result of a previous project to determine requirements, or it may be created as part of the project. Project Scope (Page 105)
This is the work the project will do to deliver the product scope or product of the project. The work includes the planning, coordination, and management activities (such as meetings and reports) that ensure the product scope is achieved. Scope management involves managing both product scope and project scope.
Plan Scope Management PMBOK Guide Definition – Page 107
Plan Scope Management is the process of creating a scope management plan that documents how the project scope will be defined, validated, and controlled. The scope management plan is a component of the project management plan. It contains specifics about how the project scope will be defined, developed, monitored, controlled and validated. The completion of project scope is measured against the scope management plan. The scope management plan must be well integrated with other knowledge area management plans to ensure the successful delivery of the product scope. Exam Hint
Scope creep refers to uncontrolled changes to the project scope during a project. The first step to prevent scope creep is the definition of a wellstructured project scope management plan.
Inputs
Project Management Plan The approved subsidiary plans of the project management plan are used to create the scope management plan. Please note that neither the scope management plan nor the other management plans are developed in isolation. These processes are iterative in nature and the Develop Project Management plan from the Integration Management Knowledge Area coordinates this effort. Project Charter The project charter provides the initial inputs to this process. The high level project and product scope are documented in the project charter. This can serve as the primarily input to this project during the first few iterations when none of the other knowledge area management plan have been developed.
Enterprise Environmental Factors The enterprise environmental factors that can influence the development of the scope management plan include, but are not limited to:
Organization's culture Infrastructure Personnel administration Marketplace conditions
Organizational Process Assets The organizational process assets that influence the Plan Scope Management process include, but are not limited to:
Organizational policies and procedures Historical information and lessons learned knowledge base
Tools and Techniques
Expert Judgment Meetings Outputs
Always remember that the scope management plan doesn't contain the project scope. The scope management plan is a project plan that tells how scope will be identified, managed and controlled Scope Management Plan The scope management plan is a subsidiary plan of the overall project management plan. It is the major input to the Develop Project Management Plan process. Typical components of a scope management plan include:
Project scope statement development procedures Work Breakdown Structure (WBS) development procedures WBS maintenance and approval methods Formal project deliverables acceptance methods and criteria Scope change control procedures
Requirements Management Plan The requirements management plan is also a component of the project management plan and supports the project scope management plan. It documents how the project requirements will be collected, analyzed, documented, and managed. Typical components of a requirements management plan include:
Project requirements collection procedures
Procedures regarding requirements activities planning, tracking and reporting Configuration management activities Requirements prioritization process Requirements traceability structure
Collect Requirements (Page 110) The Collect Requirements process looks for all requirements as defined by the stakeholders that are necessary to meet the project objectives. Work should not be included in a project just because someone wants it. Instead, the requirements should relate to solving problems or achieving objectives. The high-level project and product requirements should have already been defined in the project charter, giving you and your project a leg up. The Collect Requirements process involves gathering more specific input on those requirements from all stakeholders. This process is critical to project success, as missed requirements could mean significant changes and conflict throughout the remainder of the project and could possibly result in project failure. The first step in collecting requirements to is to know who the stakeholders are. This is not an easy task since large project may contain a vast number of possible stakeholders. As a project manager, collecting requirements from such a large number of stakeholder may require using more than just one method, because missing a needed requirement can be expensive and may result in other problems later. The techniques described next can help in this process. The project manager needs to choose the techniques that are most appropriate for the project and the stakeholders they have identified. Many of these techniques can also be used in the risk management process to identify risks. Inputs
Scope Management Plan Requirements Management Plan Stakeholder Management Plan
This provides stakeholder communication requirements and the level of stakeholder engagement. This helps in assessing the level of stakeholder participation in requirements activities.
Project Charter Stakeholder Register This is used to identify and track the stakeholder information that is collected. There are many tools and techniques associated with the Collect Requirements process. The PMBOK Guide does not discuss these tools and techniques in great
detail. While these tools and techniques may not explicitly be mentioned in the PMBOK Guide, it is valuable to familiarize yourself with them via external sources (online search, etc.) Tools and Techniques
Interviews
This technique may also be called "expert interviewing" on the exam. The team or project manager interviews project stakeholders to identify their requirements for a specific element of the product or project work, or for the overall project. These interviews can take place between individuals or in group settings. Interviews can also be conducted via email, phone calls, letter, or other methods.
Facilitated Workshops
Facilitated workshops bring together stakeholders with different perspectives to talk about the product and ultimately arrive at consensus regarding the requirements. A key benefit with all the players in the room is that issue resolution can be done more quickly than through other techniques.
Group Creativity Techniques
Brainstorming o Use to generate and collect multiple ideas related to the requirements. Nominal Group Technique o This technique is usually, but not always, done during the same meeting as brainstorming. The meeting participants rank the most useful ideas generated during the brainstorming session. The Delphi Technique o With this technique, a request for information is sent to experts who participate anonymously, their responses are complied, and the results are sent back to them for further review until consensus is reached. Idea/Mind Mapping o A mind map is a diagram of ideas or notes to help generate, classify, or record information. It looks like several trees radiating out of a central core word. Colors, pictures, and notations can be used to make the diagram more readable. Affinity Diagram o In this technique, the ideas generated from any other requirements gathering techniques are sorted into groups by similarities. Each group of requirements is then given a title. This sorting makes it easier to see additional scope (or risks) that have not been identified.
Group Decision Making Techniques Soliciting input on requirements from all stakeholders may result in too many or conflicting requirements. These need to be reviewed, analyzed, accepted or rejected,
and prioritized before recording them in project documents. There are different ways to make decisions in a group setting such as:
Unanimity Majority Plurality Dictatorship
Questionnaire and Surveys
Questionnaires or surveys are typically used for large groups. These tools present questions for the respondents that can help identify their requirements.
Observations
This technique involves job shadowing, allowing an opportunity to watch a potential user of the product at work, and through hands on experience, identify requirements.
Prototypes
A prototype is a model of the proposed product. In this technique, the prototype is presented to stakeholders for feedback. The prototype may be updated multiple times to incorporate the feedback until the requirements have been solidified for the product.
Benchmarking Benchmarking helps the requirements collection and definition process by analyzing comparable organizations to identify best practices, new ideas, and standards for performance measurements. Context Diagrams These diagrams visually display the product scope by showing business systems and their interactions. They show the inputs and outputs of these business systems and their sources. Document Analysis Analyzing existing documentation elicit requirements. There are a wide range of documents that may be reviewed and analyzed including:
Business plans Marketing literature Agreements Request for proposals Process flows Logical data models Business rules
Software documentation Use cases Problem/issue logs Policies and procedures Laws, codes or ordinances etc.
Outputs
Requirements Documentation After the requirements have been collected and finalized, they are documented. This documentation helps to make sure the requirements are clear and unambiguous. You will have a lot of requirements that could easily be misunderstood. Therefore, one of the important aspects is to make sure the stakeholders are in agreement with the requirements. Components of requirements documentation can include, but is not limited to:
Business need or opportunity Business and project objectives for traceability Functional requirements describing business processes Non-functional requirements Quality requirements Acceptance criteria Impacts to other entities Requirements assumptions and constraints
Requirements Traceability Matrix There are many instances of a requirement being lost in the details, and the customer receiving one thing when they expected another. The requirements traceability matrix helps track requirements over the life of the project to ensure they are accomplished. The matrix usually takes the form of a table containing information such as the source of each requirement and its status. The concept is similar to risk or issue management, making sure there is an owner who is accountable for managing and controlling the work. The following are possible data points that requirements can be traced against:
Business needs, opportunities, goals, objectives Project objectives Scope/WBS deliverables Product design Product development Test strategy and test scenarios High-level requirements to more detailed
Define Scope (Page 120) The Define Scope process is primarily concerned with what is and is not included in the project and its deliverables. This process uses the scope management plan, requirements documentation created in the Collect Requirements process, the project charter, the organizational process assets, and any information about the project risks, assumptions, and constraints to define the project and product scope. It is imperative to remember that planning is iterative. When the requirements have been determined, the project manager follows the project management process to determine the schedule and budget. If the budget and/or schedule do not meet with the sponsor's approval, the project manager needs to balance the requirements against all other constraints. The iteration process involves coming up with options for meeting the scope, time, or cost objectives of the project and presenting those options to management for a decision. The result is a realistic schedule and budget that can achieve the project's scope. Exam Hint
The Define Scope process is important on the exam for the following reasons:
Project managers complain about unrealistic schedule and do not realize the unrealistic schedules are their fault because they have not followed the iterations process described previously. Project managers spend a large portion of their time, while the work is being done, looking for options to adjust the project and still meet the project schedule and budget. Therefore, all the tools used in planning to come up with a realistic schedule and budget, such as negotiating scope and fast tracking, are also major activities while the work is being done.
Inputs
Scope management plan Project Charter Requirements Documentation Organizational Process Assets that can influence this process include, but are not limited to:
Policies, procedures and templates Project files from previous projects Lessons learned
Tools and Techniques
Expert Judgment Product Analysis
The purpose of product analysis is to analyze the objectives and description of the product stated by the customer or sponsor and turn them into tangible deliverables. The analysis may include a detailed breakdown of the product, systems analysis, requirements analysis, and more.
Alternatives Generation
Important to be able to generate ideas on different approaches to completing the requirements.
Facilitated Workshops Outputs
Project Scope Statement (page 123) The primary result, or output, of the Define Scope process is the project scope statement. PMBOK Guide Definition – Page 123
The project scope statement is the description of the project scope, major deliverables, assumptions, and constraints. The project scope statement documents the entire scope, including project and product scope. It describes, in detail, the project's deliverables and the work required to create those deliverables. The creation of the project scope statement can take a lot of time and involve the expert judgment of many stakeholders and even experts from outside the organization. While defining requirements and defining scope, the project manager will identify areas where people want scope but it was not approved to be included in the project. The project manager should also clarify areas where the work could easily be misunderstood. It is a waste of project time and money to create scope that is not needed or approved, yet it is easy for this to occur. The project manager should also consider different approaches to performing the work and incorporating the needs of stakeholders into the project. The project scope statement, along with the WBS and WBS dictionary, comprise the scope baseline, which is part of the project management plan. The scope statement may reference the following other documents:
Product scope description Product acceptance criteria Project deliverables Project exclusions
Project constraints Project assumptions
Project document updates can include, but are not limited to:
Stakeholder register Requirements documentation Requirements traceability matrix
The Create WBS process is the process that defines the scope of the project. The scope baseline is the output of this process
Create WBS Although the WBS may look like a corporate organizational chart, it is not. It is a cornerstone to building a realistic project plan. PMBOK Guide Definition – Page 125
Create WBS is the process of subdividing project deliverables and project work into smaller, more manageable components. This is a top-down effort to decompose the deliverables, and the work required to produce them, into smaller pieces called work packages. Note that generally each work package consists of nouns – things, rather than actions. The work package can then be scheduled, estimated, monitored and controlled. A WBS is deliverable-oriented. This does not mean that only customer deliverables are included in the WBS. The complete scope of the project, including product scope, project scope, and project management efforts, are included. The total scope of the project is included in the WBS. Watch out for the word "task." In the real world, it means one thing, but for the exam that level of detailed information is called "activity." Understand that there are a few rules that would be good to know for creating a WBS, especially for those that don't have a great deal of experience with WBS. There is more than one way to create a WBS, and two WBS documents for the same project, each created by a different person, will look different. That's acceptable, provided they comply with the following rules.
The WBS is created with the help of the team. The first level is completed before the project is broken down further. Each level of the WBS is a smaller piece of the level above. The entire project is included in each of the highest levels of the WBSs. Eventually some levels will be broken down further than others. The WBS includes only deliverables that are really needed. Deliverables not in the WBS are not part of the project.
Work packages are reached when they include deliverables that:
Can be realistically and confidently estimated Can be completed quickly Can be completed without interruption (without the need for more information) May be outsourced or contracted out
The work packages in the WBS are divided further into scheduled activities, or activities for short, with the help of the WBS dictionary. Note that dividing the work package into activities is part of the time management process of Define Activities. Exam Hint
There can be many references to the WBS on the exam. In short, remember the following. A WBS:
Is a graphical picture of the hierarchy of the project Identifies all the deliverables to be completed – if it is not in the WBS, it is not part of the project Is the foundation upon which the project is built Is VERY important Should exist for every project Forces you to think through all aspects of the project Can be reused for other projects Does NOT show dependencies
Inputs
Scope management plan Project scope statement Requirements documentation Enterprise environmental factors that can influence this process include industry-specific WBS standards. Organizational process assets that can influence this process include, but are not limited to:
Policies, procedures and templates Project files from previous projects Lessons learned
Tools & Techniques
Decomposition (page 128) Decomposition is the exercise of subdividing the project deliverables into smaller, more manageable components on the way to getting to the work package level.
The following activities are involved in decomposition: o Identifying and analyzing o Organizing the WBS o Decomposing WBS o Validating that decomposition has gone to the appropriate level WBS structure creation o There are several forms that the structure of the WBS can take such as: Use the phases of the project as a guide for first level of WBS Use the major deliverables as the guide for first level Use subprojects that are independent and complete packages of work that could be outsourced if needed.
Expert Judgment Outputs
Scope baseline The scope baseline is the approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary.
Project scope statement WBS WBS dictionary (page 132) The WBS dictionary provides a description of the work to be done for each WBS work package and helps make sure the resulting work matches what is needed. It can be used as part of the work authorization system to inform team members of when their work package is going to start, schedule milestones, and other information. The WBS dictionary helps the project by putting boundaries on what is included in the work package. Information in the WBS dictionary may include: o o o o o o o o o o
Code of account identifier Description of work Assumptions and constraints Responsible organization Schedule milestones Associated schedule activities Resources required Cost estimates Quality requirements Acceptance criteria
o o
Technical references Agreement information
Project Documents Updates Requirements documentation might get updated during this process. The Validate Scope process should be performed for every project deliverable, or a group of deliverables, being presented to the customer or sponsor
Validate Scope The Validate Scope process is very time intensive because the project team will be dealing with the clients. PMBOK Guide Definition – Page 133
Validate Scope is the process of formalizing acceptance of the completed project deliverables. During this process you are reviewing the deliverables with the client to ensure that they are completed to their satisfaction. Another aspect of the Validate Scope process is it can be done at the end of each project phase in the project life cycle (to verify the phase deliverables along the way) and during the monitoring and controlling process group in the project management process. You can validate scope with the customer multiple times in one project. The last area that we'll cover here is how Validate Scope relates to Control Quality. Although Control Quality is generally done first (to make sure that work meets the quality requirements before meeting with the customer), the two processes are very similar in that both involve checking for the correctness of work. The difference is the focus of the effort and who is doing the checking. In Control Quality, the quality control department checks to see if the quality requirements specified for the deliverables are met and makes sure the work is correct. In Validate Scope, the customer checks and either accepts or rejects the deliverables. Inputs
Project Management Plan
Project scope statement WBS WBS Dictionary
Requirements documentation Requirements traceability matrix Verified deliverables
Work performance data Tools and Techniques
Inspection (Page 135)
This includes validation activities involving measuring, examining, and verifying that the deliverables are completed to the specification of the requirements. The inspections can take on different forms such as: o Audits o Product reviews o Walkthroughs
Group decision-making techniques Outputs
Accepted Deliverables (page 135)
This must include a formal signoff. The formal documentation is then used in the Close Project or Phase process.
Change Requests Work Performance Information Project Document Updates
Control Scope The Control Scope process involves measuring project and product scope performance and managing scope baseline changes. This control ensures that any approved changes are accounted for and managed into the scope successfully. It also ensures that any recommendations for change go through the formal Perform Integrated Change Control process. As a project manager, in order to control scope, you need to: 1. Have work completed with a clear definition of what the scope on the project is, which is captured in the project scope baselines from the project management plan. 2. Be aware of the original requirements recorded in the requirements documentation and the requirements traceability matrix. 3. Measure scope performance against the scope baseline to see the magnitude of any variances (variance analysis) and decide if corrective action or preventative action is required. 4. Determine if any updates to the scope baseline, other parts of the project management plan, or the project documents are needed, and what changes should be requested. 5. Look for the impact of scope changes on all aspects of the project (through the Perform Integrated Change Control process). The Control Scope process is an extremely proactive process for the project manager. It will involve thinking about where changes to scope are coming from on the project, and what can be done to prevent or remove the need for any more changes from that source going forward. The project manager's job is to control the project in accordance with the project management plan and to meet all the baselines. Therefore, the project manager should not be easily swayed or influenced and let others add scope or change scope without following the approved change management process. Inputs
Project Management Plan – contains information from the following:
Scope baseline Scope management plan Change management plan Configuration management plan Requirements management plan
Requirements Documentation Requirements Traceability Matrix Work Performance Data
Organization Process Assets Tools and Techniques
Variance Analysis (page 139)
As project manager you will be capturing project performance measurements. If variance exists, it is important to recognize its cause, and to determine at what point corrective or preventive action is necessary for the success of the project.
Outputs
Work Performance Information Change Requests Project Management Plan Updates
Scope baseline updates Other business updates
Project Documents Updates
Requirements documentation Requirements traceability matrix
Organizational Process Assets Updates Project Scope Management Cheat Sheet
Open table as spreadsheet
Process
Descript Gro Input ion up
Plan Scope Managem ent
Develop Plan a scope manage ment plan
Collect Defining Plan Requirem and
Tools & Technique Project manageme nt plan Charter EEF OPA
Scope manageme
Expert Judgment Meetings
Output
Focus groups
Scope manageme nt plan Requireme nts manageme nt plan
Requireme nts
Process
Descript Gro Input ion up
ents
documen ting stakehold ers' needs to ensure project objective s are met.
Tools & Technique nt plan Requireme nts manageme nt plan Stakehold er manageme nt plan Charter Stakehold er register
Define Scope
Create WBS
Developi Plan ng detailed descripti on of the project and product as a basis for future decisions .
Subdivid Plan ing major deliverab les into smaller compone nts
Scope manageme nt plan Charter Requireme nts doc OPA
Scope manageme nt plan Scope statement Requireme nts doc EEF OPA
Interviews Facilitated workshops Group creativity techniques Group decisionmaking techniques Questionna ires & Surveys Observatio ns Prototypes Benchmark ing Context diagrams Document analysis
Output
Expert judgment Alternative s Generation Product analysis Facilitated workshops
Decomposi tion Expert judgment
documenta tion Requireme nts traceabilit y matrix
Scope statement Updates: docs
Scope baseline Updates: docs
Process
Descript Gro Input ion up
Validate Scope
Formal Cont acceptan rol ce of the complete d project deliverab les.
Control Scope
Monitori Cont ng status rol of the project and product scope and managin g changes to scope baseline.
Tools & Technique Project mgmt plan Requireme nts docs Requireme nts traceabilit y matrix Verified deliverabl es Work performan ce data
Project mgmt plan Requireme nts docs Requireme nts traceabilit y matrix Work performan ce data OPA
Inspection Group decisionmaking techniques
Output
Variance analysis
Accepted deliverabl es Change requests Work performan ce informatio n Updates: docs
Work performan ce informatio n Change requests Updates: OPA; docs; plan
Deep Dive into Project Time Management Overview Project Time Management includes seven processes. These processes are required to manage the timely completion of the project. On simpler and smaller projects, most of the planning processes (defining activities, sequencing activities, estimating activity resources, estimating activity durations, and developing schedule) can be viewed as a single process. Make sure you realize there is no such thing as true project management software. The software is only as good as the data that is provided to it. You can't follow the software; as a project manager you need to lead it. You need to make it conform to your needs, because the software does not always conform to proper project management methods. The following should help you understand how each part of time management fits into the project management process: Open table as spreadsheet
Time Management Process Done During Plan Schedule Management Planning Process Group Define activities
Planning Process Group
Sequence Activities
Planning Process Group
Estimate Activity Resources Planning Process Group Estimate Activity Durations Planning Process Group Develop Schedule
Planning Process Group
Control Schedule
Monitoring and Controlling Process Group
The Plan Schedule Management process produces the project's schedule management plan. It does not contain the project's schedule. It only describes how the project's schedule will be developed, managed and controlled
Plan Schedule Management PMBOK Guide Definition – Page 145
Plan Schedule Management is the process of establishing the policies, procedures, and documentation for planning, developing, managing, and controlling the project schedule. The only output of this process is the schedule management plan. The schedule management plan is a component of the project management plan. It can be detailed or broadly framed, based on the needs of the project.
Inputs
Project Management Plan Project Charter Enterprise Environmental Factors
Organizational culture and structure Resource availability and skills Project management software Published commercial information Organizational work authorization systems
Organizational Process Assets
Monitoring and reporting tools Historical information Schedule control tools Schedule control policies and procedures Templates Project closure guidelines Change control procedures Risk control procedures
Tools and Techniques
Expert Judgment Analytical Techniques
Scheduling tools and techniques Estimating techniques Rolling wave planning Alternative analysis
Meetings Outputs
Schedule Management Plan (Page 148) Project time management processes and their associated tools and techniques are documented in the schedule management plan. The schedule management plan will help make the schedule estimating process faster by providing guidelines on how estimates should be stated. During monitoring and controlling, the schedule management plan can help determine if a variance is over the allowable threshold and therefore must be acted upon. The schedule management plan can also help determine the types of reports required on the project relating to schedule.
The schedule management plan includes:
The scheduling methodology and scheduling software to be used on the project Procedures to establish the schedule baseline; Identification of the performance measures that will be used on the project, to identify variances early Planning how schedule variances will be managed Identification of schedule change control procedures
A schedule management plan requires that progress be measured along the way by the project manager. The project manager is playing an active role in gathering the data. Measures of performance are determined in advance so the project manager can plan to capture the necessary data. The schedule management plan can be formal or informal, but again it is part of the project management plan. The Define Activities process decomposes the work packages into project activities. However, care must be taken such that activities are decomposed up to a level that they do not complicate the project schedule and eliminate the room for creativity for the project team
Define Activities This process involves taking the work packages created in the WBS and breaking them down further (decomposing) in order to reach the activity level, which is a level small enough to estimate, schedule, monitor, and manage. PMBOK Guide Definition – Page 149
Define Activities is the process of identifying and documenting the specific actions to be performed to produce the project deliverables. In order to define the activities, the project manager must know the key inputs. This requires the schedule management plan, the scope baseline (scope statement, WBS, WBS dictionary), and the project team. Involving the project team helps define activities completely and accurately and therefore makes the estimates more accurate. When completed, the Define Activities process will result in an activity list and the details of the activities being completed. It will also result in the determination of milestones to be used on the project. Inputs
Schedule management plan Scope Baseline Enterprise Environmental Factors
Organizational Process Assets Tools and Techniques
Decomposition Rolling Wave Planning (page 152)
This is a form of progressive elaboration where the activities that need to be completed in the near term are planned in detailed, while those activities targeted for the future are planned at a higher level.
Expert Judgment Outputs
Activity List (page 152)
This is a comprehensive list of all the activities required on the project. The detail of the information on the list can vary so long as there is sufficient detail so that the team understands what needs to be completed.
Activity Attributes (page 153)
The attributes allows for additional data points to be added to the description of the activity. The data points evolve over time as more information is known. Examples include: o Activity ID o WBS ID o Activity name o Predecessor o Successor
Milestone Lists (page 153)
The list identifies all the milestones and can also provide additional information in terms of the milestone being required by a contract term, if it is optional, or if it is mandatory.
Milestones
Milestones are significant events within the project schedule. They are not work activities. If a checkpoint or milestone in the schedule arrives and all the planed work has been completed, it indicates that the project may be progressing as planned.
Sequence Activities The next process involves taking the activities and milestones and starting to sequence them into how the work will be performed. PMBOK Guide Definition – Page 153
Sequence Activities is the process of identifying and documenting relationships among the project activities. It is important to remember that every activity, except for the first and last, are connected in the project schedule. There are many ways to show the connection by using software or manually. A manual best practice is to use a network diagram (also referred to as a project schedule network diagram), which can look like the following picture. Example of a Network Diagram
Methods to Draw Network Diagrams
In the past, the Precedence Diagramming Method (PDM), the Arrow Diagramming Method, and the Graphic Evaluation and Review Technique (GERT) method were commonly used to draw network diagrams. Today most network diagrams are creating using PDM. Inputs
Schedule management plan Activity Lists Activity Attributes Milestone List Project Scope Statement Enterprise environmental factors Organizational Process Assets
Tools and Techniques
Precedence Diagramming Method (PDM) (page 156) PDM is a method that is used in Critical Path Methodology (CPM). In this method, nodes (or boxes) are used to represent activities, and arrows show activity dependencies and relationships as follows:
The start-to-finish relationship confuses many PMP candidates and should be thoroughly understood prior to entering the exam. While this relationship may not explicitly be detailed in the PMBOK Guide, it is valuable to familiarize yourself with it via external sources (online search, etc.) PDM can have four types of logical relationships between activities:
Finish-to-start (FS) – An activity must finish before the successor can start. o Example: You must finish digging a hole before you can start the next activity of planting a tree. o The most commonly used of the types Start-to-start (SS) – An activity must start before the successor can start. o Example: You must start designing and wait for two weeks lag in order to have enough of the design completed to start coding. Finish-to-finish (FF) – An activity must finish before the successor can finish. o Example: You must finish testing before you can finish documentation. Start-to-finish (SF) – An activity must start before the successor can finish o Rarely used.
Dependency Determination (page 157) The sequence of activities is determined based on the following dependencies. Mandatory and external dependencies may not be removed. During fast-tracking, the internal and discretionary dependencies are usually considered and removed. This increases the project risk as a tradeoff
Mandatory Dependency o The dependency is inherent in the nature of the work being done or required by the contract. o The project team will determine if the dependency is mandatory during sequencing. o This is also referred to as "hard logic" Discretionary Dependency o This dependency is determined by the project team during the sequencing of activities.
o
Discretionary dependencies can be changed if needed, while the other types of dependencies cannot easily be changed. o Discretionary dependencies are important when analyzing how to shorten the project to decrease the project duration (fast track the project). o Also referred to as Preferred logic, Preferential logic, or Soft logic External Dependency o This dependency is based on the needs or desires of a party outside the project. o The project team will determine which dependencies are external during the sequencing of activities. Internal Dependency o This dependency is generally under the project team's control. The project team determines which dependencies are internal during the sequence activities process.
Leads and Lags (page 158)
Leads o o
A lead may be added to start an activity before the predecessor activity is completed. For example, coding might be able to start five days before the design is finished.
Lags o o
A lag is a delay or waiting time between activities. For example, needing to wait three days after design before coding can begin.
Outputs
Project Schedule Network Diagrams (page 159)
Standard network diagrams are schematic displays of the project's schedule activities and the logical dependencies among them. These can be produced manually or via software.
Project Document Updates
Activity lists Activity attributes Milestone list Risk register
Exam Hint
The next two management processes (Estimate Activity Resources and Estimate Activity Durations) involve estimating. The following are important points to understand about estimating for the exam:
Estimating should be based on a WBS to improve accuracy. Estimating should be done by the person doing the work whenever possible to improve accuracy.
Historical information from past projects (part organizational process assets) is a key to improving estimates. The schedule baseline (as well as the cost and scope baselines) should be kept and not changed except for approved project changes. The project schedule should be managed in the schedule baseline for the project. Changes are approved in integrated change control. Estimates are more accurate if smaller size work components are estimated. A project manager should never just accept constraints from management, but should instead analyze the needs of the project, come up with his or her own estimates, and reconcile any differences to produce realistic objectives. A project manager may periodically recalculate the estimate to complete (ETC) for the project in order to make sure there is adequate time (and funds, etc.) available for the project. Plans should be revised during completion of the work as necessary with approved changes. Padding is not acceptable project management practice. The project manager must meet any agreed upon estimates. Estimates must be reviewed when they are received to see if they are reasonable and to check for padding and risks. Estimates must be kept realistic through the life of the project by re-estimating and reviewing them periodically. Estimates can be decreased by reducing or eliminating the risks. The project manager has a professional responsibility to provide estimates that are as accurate as feasible and to maintain the integrity of those estimates throughout the life of the project.
Estimate Activity Resources Once the activities are sequenced, the type and quantity of needed resources is determined. Remember that resources include equipment and materials, as well as people. Resources must be planned and coordinated in order to avoid common problems such as lack of resources and resources being taken away from the project. PMBOK Guide Definition – Page 160
Estimate Activity Resources is the process of estimating the type and quantities of material, human resources, equipment, or supplies required to perform each activity.
Inputs
Schedule Management Plan Activity List Activity Attributes Resource Calendars (page 163)
The calendar provides information regarding availability of resources. It will also provide how long the resource will be available. Additional information around experience and skill level may also be incorporated into the calendar.
Risk Register Activity Cost Estimates The activity cost estimates are obtained during the Estimate Costs process of the Cost Management Knowledge Area. The cost of resources may impact the resource selection. Enterprise Environmental Factors Organizational Process Assets Tools and Techniques
Expert Judgment Alternative Analysis Published Estimating data (page 164)
Data that is published from an outside vendor. Data that includes production rates and unit costs for materials and equipment
Bottom-up Estimating Project Management Software Outputs
Activity Resource Requirements (page 165)
Details the types and quantities of resources required to support the project.
Resource Breakdown Structure (page 165)
This is a graphical representation using a hierarchical structure of the identified project resources. The resources can be categorized or shown by skill level, grade level, or other category.
Project Document Updates can include, but are not limited to:
Activity lists Activity attributes Resource calendars
Estimate Activity Durations In order to estimate well, you will need to know activity resource requirements, resource calendars, project scope, resource breakdown structure, organizational process assets (historical data and lessons learned about activity durations, past project calendars, and the defined scheduling methodology), and enterprise environmental factors (company culture and existing systems that the project will have to deal with or can make use of, such as estimating software and productivity metrics). Other inputs that guide this process include the schedule management plan, activity list, activity attributes and risk register. Keep in mind that the time estimates and any other information gathered during estimating will be an input to the risk management process. PMBOK Guide Definition – Page 165
Estimate Activity Durations is the process of estimating the number of work periods needed to complete individual activities with estimated resources. Sometimes in the real world, you hear the concept of padding a schedule. Padding is a sign of unprofessional project management. A "pad" is an extra time or cost added to an estimate because the estimator does not have enough information. In the cases where the estimator has many unknowns, the need for a pad should be addressed through the risk management process, and the uncertainties should be turned into identifiable opportunities and threats (risks). Uncertainties should not remain hidden; instead they need to be identified and addressed openly with the project manager. Successful estimators have a WBS that they and their team created. They also have a description for each work package (the WBS dictionary). They may even have helped create the activity list from the work packages, and they may know there will be time reserves on the project. With that information, they should not need to pad estimates, since they have all the needed information and no reason to guess.
Inputs
Schedule management plan Activity List Activity Attributes Activity Resource Requirements Resource Calendars Project Scope Statement
Assumptions Constraints
Risk Register
This is described in a greater detail in the Risk Management knowledge area. The risk register provides the list of project risks and their corresponding planned responses. Considering project risks during the activity duration estimated provides more reliable estimates.
Resource Breakdown Structure Enterprise Environmental Factors Organizational Process Assets Tools and Techniques
How Is Estimating Done? Activities can be estimated using the following techniques: Single-Point Estimate (SPE)
When estimating time using a single-point estimate, the estimator submits one estimate per activity. The time estimate can be made based on expert judgment, by looking at historical information, or even by just guessing.
Single-point estimates per activity can have the following negative effects on the project:
It can force people into padding their estimates. It hides important information about risks and uncertainties from the project manager, which is needed to better plan and control the project.
It creates a schedule that no one believes in, thus losing buy-in to the project management process. It has the estimators working against the project manager to protect themselves, rather than with the project manager to help all involved in the project.
The role of the project manager in estimating is to:
Provide the team with enough information to properly estimate each activity. Let the team know how refined their estimating must be. Complete a sanity check of the estimates. Prevent padding. Formulate a reserve Make certain any assumptions made during estimating are recorded for later review and possible input into Risk Management.
Single-point estimates should be used for projects that are smaller and not complex in nature. If single-point estimates are used, it is critical that the project manager provides the estimator with as much information as possible or the estimate will likely be unreliable. This information should include the WBS, the WBS dictionary, and the activity list, Expert Judgment Although the PMBOK Guide does not mention it, Analogous Estimating is also referred to as "Top-Down Estimating". Analogous Estimating (Page 169) Analogous estimating can be done for a project or an activity. Analogous estimating uses data points such as duration, budget, size, and complexity from past projects as the basis for estimating. It is used to estimate project duration when there is limited data. It is an inexpensive method to use, but it is not a very accurate one. Heuristics
A heuristic means a rule of thumb. An example of a heuristic is the 80/20 rule. This rule applied to quality, suggests that 80 percent of quality problems are caused by 20 percent of the potential sources of problems.
Parametric Estimating (Page 170) Parametric estimating calculates projected time for an activity based on historical records from previous projects and other information. The result is an activity estimate based on measures like time per line of code, time per linear meter, or time per installation. This technique can produce a higher level of accuracy depending on the quality of the data points used in the calculations. Always remember that both the PERT average and Simple Average are two approaches for Three-point Estimating. Most people associate only the PERT average with a Three-point Estimate
Three-Point Estimating –(Page 170)
In creating estimates, remember that things do not always go according to plan. Analyzing what could go right and what could go wrong can help estimators determine an expected range for each activity. This technique tries to factor in the uncertainty and risk inherent in any project. With three-point technique, estimators give an estimate for each activity: o Optimistic (O), Best case scenario o Pessimistic (P), and Worst case scenario o Most likely (M)
Exam Hint
For the exam, you MUST memorize these formulas and know that they can be used for both time and cost estimates.
Expected Activity Duration = (P + 4M+ O) / 6 Activity Standard Deviation = P-O/6 Activity Variance = [P-O/6]2
Knowing the ranges of individual activity duration estimates is not enough to manage a project successfully, because you need to understand how these ranges affect the overall project duration estimate in order to effectively address variations on your project. Finding the range for the overall project duration estimate is not as simple as finding the range for an individual activity estimate. You start by:
Finding the expected project duration o This is the sum of the PERT estimates (EADs or Expected Activity Durations) for each activity on the critical path. You then find the standard deviation for the project o You can't simply add the standard deviations for each activity on the critical path o You must calculate the variance for each critical path activity, add those variances, and then take the square root of the sum of the activity variance. The project duration estimate range is the expected project duration (the sum of the EADs) plus or minus the project standard deviation (the square root of the sum of the activity variance).
Exam Hint
For the exam, you need to be able to do simple calculations using the formulas, have general understanding that estimates of time (or cost) should be in a range, and know the concept of three-point time (or cost) estimates per activity. You could also see a PERT total project duration used in questions without requiring calculation. The exam addresses standard deviation and variance in many different ways (Schedule, Risk, etc.). Make sure you have a general understanding of these concepts, which you will, based on these sessions.
Group Decision-Making Techniques Reserve Analysis (page 171) It is important for you to connect estimating to risk management, as estimating will help determine risks, and completing the risk management process will reduce the range of time and cost estimates and make them more accurate. Successful project management involves having a reserve to accommodate the risks that remain in the project after the completion of risk management activities. Outputs
Activity Duration Estimates Project Document Updates Exam Hint
You will frequently see a single-point estimate per activity used on the exam. This method is not always best, but it is an easier way to improve your understanding of finding critical paths and drawing network diagrams. Using single-point estimates also allows for quick calculations and proof that you understand those concepts.
Develop Schedule Once a network diagram and estimates are completed, it is time to put the information into a schedule. The difference between a time estimate and a schedule is that the schedule is calendar based. PMBOK Guide Definition – Page 172
Develop Schedule is the process of analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule model. During schedule creation, the project manager may need to review the duration estimates and resource estimates. Many times a scheduling tool will be used to capture the data points needed for a project schedule, such as the activities, durations, and resources. Exam Hint
It is critical that any project schedule be realistic and that it is created with the full input from the entire project team.
Inputs
Schedule management plan Activity List Activity Attributes
Project Schedule Network Diagrams Activity Resource Requirements Resource Calendars Activity Duration Estimates Project Scope Statement Risk Register Project Staff Assignments Resource Breakdown Structure Enterprise Environmental Factors Organizational Process Assets Tools and Techniques
Schedule Network Analysis (page 176)
This is a technique that employs various analytical techniques to calculate the early and late start and finish dates for the uncompleted portion of the project activities. The different techniques are: o Critical path method o Critical chain method o Resource optimization techniques o Modeling techniques o Schedule compression
Practice the forward pass and the backward pass on a schedule network and make yourself comfortable with it. Many people struggle with this and incorrectly compute the early and late start and finish dates Critical Path Method (page 176) The critical path method includes determining the longest path in the network diagram (the critical path), the earliest and latest an activity can start, and the earliest and latest it can be completed. A critical path is characterized by zero float on the critical path. Become very comfortable with the Critical Chain Method. While it may not explicitly be mentioned in the PMBOK Guide, it is valuable to familiarize yourself with examples via external sources (online search, etc).
Critical Chain Method (page 178) This is a technique that will alter the project schedule to account for limited resources. This is also known as resource-constrained critical path. This technique will add duration buffers that are non-work schedule activities to manage uncertainty. Resource Optimization Techniques (page 179)
Resource leveling: The schedule first needs to be analyzed by the critical path method. In situations where required resources are only available at certain times, or when it's necessary to keep resource usage at a constant level, a project manager may use resource leveling. The technique can also be used where resources have been over allocated on a project. Resource leveling often alters the project's critical path and delays the project's completion date. Resource smoothing: This technique adjusts the activities in a schedule model such that the resource requirements on the project do not exceed a defined limit. In resource smoothing, the project's critical path in not changed and the completion date is not delayed.
The Monte Carlo simulation technique is not discussed in the PMBOK Guide in great detail but is a critical exam concept. While this technique may not explicitly be mentioned in the PMBOK Guide, it is valuable to familiarize yourself with it via external sources (online search, etc.) Modeling Techniques (page 180)
What If Scenario Analysis In creating a finalized, realistic schedule, it is helpful to ask "What if a particular thing changed on the project? What would happen?" The assumptions for each activity can change, and therefore the activity durations can also change.
Simulation This method of estimating uses computer software to simulate the outcome of a project, making use of the three-point estimates (optimistic, pessimistic, and most likely) for each activity and the network diagram. The simulation can tell you: o o o o
The probability of completing the project on any specific day The probability of completing the project for any specific cost The probability of any activity actually being on the critical path The overall project risk
Monte Carlo analysis, a simulation technique, is a way of putting together the details of a three point estimate into a project estimate that is more accurate than other methods, because it simulates the actual details of the project and takes into account probability.
Leads and Lags Schedule compression (page 181) One of the most common problems projects have is an unrealistic timeframe. This can occur during project planning when the customer requires a completion date that cannot be met, or during project executing when the project manager needs to bring the project back in line with the schedule baseline or to adjust the project for changes. This method of schedule network analysis is done during project planning to see if the desired completion date can be met and what can be changed to make that date. It is also done during integrated change control to look at the schedule impact of the changes to time, scope, risk, resources, and customer satisfaction. The objective is to try to compress the schedule without changing project scope.
Crashing o This technique involves making cost and schedule trade-offs to determine how to compress the schedule the most for the least incremental cost while maintaining project scope. In crashing or fast tracking, it is best to see all potential choices and then select the choice or choices that have the least negative impact on the project. If you have negative project float, (the estimated completion date is after the desired date), you would analyze what could be done about the negative float by compressing the schedule. For the exam, remember that you need to identify all the possible options and, if given a choice between crashing or fast tracking options, select the choice or combination of choices with the least negative impact on the project. Fast tracking o This technique involves doing critical path activities in parallel that were originally planned in series. Fast tracking often results in rework, usually increases risk, and requires more attention to communication.
Network Diagram Showing the Effect of Fast Tracking
Scheduling Tool Outputs
Schedule Baseline (page 181) A schedule baseline is the approved version of the schedule model. Once approved, the schedule baseline can only be changed through the Integrated Change Control process. The schedule baseline is used to manage the project and the schedule that the project team's performance is measured against. Meeting the schedule baseline is one of the measures of project success.
Project Schedule (page 182) A project schedule includes key data points such as a planned start date and a planned end date for each activity. The project schedule can be presented in different formats such as:
Milestone charts o These are similar to bar charts, but they only show major events. Remember that milestones have no duration. They are simply the completion of activities. Milestones may include "requirements are complete" or "design is finished" and are part of the inputs to the Sequence Activities process. Milestone charts are good tools for reporting project status to management and the customer. Bar charts o Bar charts are not project management plans. Bar charts do not help organize the project as effectively as a WBS and a network diagram can. They are completed after the WBS and the network diagram in the project management process. Project schedule network diagrams
Schedule Data (page 184) The schedule data for the project model is the collection of information for describing and controlling the project schedule. This typically include:
Resource requirements Alternative schedules Scheduling for contingency reserves
Project Calendars (page 184) The project calendar identifies the working times of the project. This includes the working days and shifts that are available for scheduling the project activities. Project management
Schedule baseline Schedule management plan
Project document updates can include, but are not limited to:
Activity resource requirements Activity attributes Calendars Risk register
Control Schedule A major component of Control Schedule is knowing the current status of the project. The effort goes beyond measuring, because it looks at taking corrective and preventative action over and over again during the life of the project. Schedule control also means looking for things that are causing changes and influencing them to change. So, if there is one person or one piece of work causing a lot of changes, the project manager must do something about it. If the project can no longer meet the agreed-to completion date (the schedule baseline), the project manager might recommend the termination of the project before any more company time is wasted. You have to think of it as someone protecting the hard work of the stakeholders in planning to make sure what was planned occurs as close to the plan as possible. The following are some additional activities involved in controlling the schedule:
Re-estimate the remaining components of the project partway through the project Conduct performance reviews by formally analyzing how the project is doing Adjust future parts of the project to deal with delays, rather than asking for time extension Measure variances against the planned schedule, and determine if those variances warrant attention Level resources to distribute work more evenly among the resources Continue to play "What if?" with the project schedule to better optimize it Adjust metrics that are not giving the project manager the information needed to properly manage the project Adjust progress reports and reporting Utilize the change control process Identify the need for change requests, including recommended preventive actions
Inputs
Project Management Plan Project Schedule Work Performance Data Project Calendars Schedule Data Organizational Process Assets
Tools and Techniques
Performance reviews (page 188) The reviews provide a way to measure, compare, and analyze the schedule performance. The reviews help determine schedule variance as well as what type of corrective action may be needed to address the variance. Project Management Software Resource Optimization Techniques Modeling Techniques Leads and Lags Schedule Compression Scheduling Tool Outputs
Work Performance Information Schedule Forecasts Change Requests Project Management Plan Updates can include, but are not limited to:
Schedule baseline Schedule management plan Cost baseline
Project Document Updates can include, but are not limited to:
Schedule data Project schedule Risk register
Organizational Process Assets Updates
Causes of variances Corrective actions chosen and reasons Lessons learned
Project Time Management Cheat Sheet
Open table as spreadsheet
Process
Descripti Grou Input on p
Plan Schedule Managem ent
Develop a Plan schedule managem ent plan
Activity Plan Define Activities list Milestone list
Sequence Identify Plan Activities and document the logical relationsh ips and dependen cies
Estimate Activity Resource s
Estimatin Plan g the type and quantities of resources required
Tools & Technique Proj. Mgt. Plan Charter EEF OPA
Schedul e mgt. plan Scope baseline EEF OPA
Schedul e mgt. plan Activity list Activity attribute s Milesto ne list Scope stateme nt EEF OPA
Schedul e mgt. plan Activity list Activity attribute s Resourc e calendar s
Output
Expert judgment Analytical techniques Meetings
Schedule manageme nt plan
Decomposit ion Rolling wave planning Expert judgment
Activity list Activity attributes Milestone list
Precedence diagrammin g methods Dependency determinatio n Leads & lags
Expert judgment Alternatives analysis Published estimating data Bottom-up estimating PM software
Network diagrams Updates: docs
Activity resource requireme nts RBS Updates: docs
Process
Descripti Grou Input on p
Estimate Estimate Plan Activity # of work Durations periods per activity
Develop Analyze Plan Schedule sequences , durations, resources and constraint s to document
Tools & Technique
Output
Resourc e calendar s Risk register Activity cost estimate s EEF OPA Schedul e mgt. plan Activity list Activity attribute s Resourc e require ments Resourc e calendar s Scope stateme nt Risk register RBS EEF OPA
Schedul e mgt. plan Activity list Activity attribute s Networ
Expert judgment Analogous estimating Parametric estimating 3-point estimating Group decision making techniques Reserve analysis
Schedule network analysis Critical path method Critical chain method Resource
Activity duration estimates Updates: docs
Schedule baseline Project Schedule Schedule data Project calendars Updates:
Process
Descripti Grou Input on p project schedule
Control Controllin Contr Schedule g changes ol
Tools & Technique k diagram s Activity resource require ments Resourc e calendar s Activity duration estimate s Scope stateme nt Risk register Project staff assignm ents RBS EEF OPA Project mgmt plan Project schedul e Work perf data Project calendar s Schedul e data OPA
optimization Modeling techniques Leads and lags Schedule compression Scheduling tool
Output
Proj. mgt. plan Updates: docs
Performanc e reviews Project managemen t software Resource optimization Modeling techniques Leads and lags Schedule compression Scheduling tool
Work perf informatio n Schedule forecasts Change requests Updates: docs; plan; OPA
Deep Dive into Project Cost Management Overview Cost Management is all about the planning, estimating, budgeting, and controlling costs related to the project in order to keep the project within the approved budget. As with the other Knowledge Areas, the processes within Cost Management interact and are interdependent. The processes are completed at least once and may be completed multiple times in phased projects. Open table as spreadsheet Cost Management Process Done During Plan Cost Management
Planning Process Group
Estimate Costs
Planning Process Group
Determine Budget
Planning Process Group
Control Costs
Monitoring and Controlling Process Group
Plan Cost Management The Plan Cost Management process produces a cost management plan for the project. The cost management plan is part of project management plan, and the project manager and project team need to spend the time required to determine the cost of the project. This is a concept that many project managers miss. PMBOK Guide Definition – Page 195
Plan Cost Management is the process that establishes the policies, procedures, and documentation for planning, managing, expending, and controlling project costs. The sole benefit of this process is to develop guidelines and direction on how the project costs should be managed and controlled during the project life cycle. Inputs:
Project Management Plan
Scope baseline Schedule baseline
Project Charter Enterprise Environmental Factors
Organizational culture and structure Market conditions Currency exchange rates Published commercial information Project management information system
Organizational Process Assets
Financial control procedures Historical information Financial databases Cost estimating and budgeting policies and procedures
Tools & Techniques:
Expert Judgment Analytical Techniques
Strategic options identification and selection Financing options analysis Financial techniques: payback period, return on investment, internal rate of return, discounted cash flows, net present value
Meetings Outputs:
Cost Management Plan (page 198) Like other management plans, the cost management plan can be formal or informal. It is part of project management plan, and the project manager and project team need to spend the time required to determine the cost of the project The cost management plan includes:
Level of accuracy o Define the level of rounding that is acceptable to monitor project data Units of measure Organizational procedures links o These are links that tie into the existing organizational infrastructure, such as the accounting system, to assist with cost management. Control thresholds o Defined data points to assist with determining variances in performance measurement. Rules of performance measurement
o
Define WBS and points at which measurement of control accounts are performed o Establish the Earned Value Measurement techniques o Specify the Earned Value Measurement computation equations Reporting formats Process descriptions
Estimate Costs The Estimate Cost process is where the estimates for each activity are made. This process does not combine all the estimates into one time-phased spending plan or the cost budget. That happens in the next process, Determine Budget. PMBOK Guide Definition – Page 200
Estimate Costs is the process of developing an approximation of the monetary resources needed to complete project activities. This process takes into account the best information available at the time. Given the iterative nature of a project, we know that information may change and so the potential is there to update the estimates as well. As a project manager, you will need to refine and keep current cost estimates based on the latest information at hand. In most cases, the communication of the estimates is generally expressed in some unit of currency or unit of time such as hours. Types of Cost There are several ways to look at costs when creating an estimate. Historically, the exam has only asked about three questions regarding types of cost. The following information should help you answer such questions. A cost can be either variable or fixed:
Variable Costs – These costs change with the amount of production or the amount of work. o Examples include the cost of material, supplies, and wages. Fixed Costs – These costs do not change as production changes. o Examples include the costs of set-up, rental, etc.
A cost can be either direct or indirect:
Direct Costs – These costs are directly attributable to the work on the project. o Examples are team travel, team wages, recognition, and costs of material used on the project. Indirect Costs – Indirect costs are overhead items or costs incurred for the benefit of more than one project. o Examples include taxes, fringe benefits, and janitorial services.
Inputs
Cost Management Plan Human Resource Management Plan (page 202) The human resource management plan is discussed in detail in the Project Human Resource Management knowledge area. The human resource management plan provides information regarding staffing attributes, hourly rates, and related rewards and recognition. These costs must be considered during the Estimates Costs process. Scope Baseline (page 202) In order to estimate, you need to know the detail of what you are estimating, what is out of scope, and what constraints might have been placed on the project. These can be found by looking at all the components of the scope baseline:
Scope statement Work breakdown structure WBS dictionary
Project Schedule (page 203) This is one of the key inputs to cost management, as it contains the activities, the type and quantity of resources needed to complete the work, and when the work will occur. Keep in mind that you need a schedule before you can come up with a budget. Risk register Enterprise Environmental Factors
Market Conditions Published commercial information
Organizational Process Assets
Cost estimating policies Cost estimating templates Historical information Lessons learned
Tools and Techniques
Expert Judgment Analogous estimating is the weakest estimating technique. However, at times, this is the only available option for the project team due to time and cost constraints Analogous Estimating
Parametric Estimating Bottom-up Estimating Three Point Estimating
Most likely Optimistic Pessimistic
Reserve Analysis (page 206) It is a good project management practice to accommodate the cost and time risk in a project estimate through the use of reserves. In risk analysis, you identify which activities on your project have significant risks and determine how much time and money to set aside to deal with the risks if they happen. Cost of Quality (page 206) The costs of work added to the project to accommodate quality planning should be added to the project estimate. Project Management Software Vendor Bid Analysis (page 207) This is where project work may be awarded to a vendor under a competitive process. This will require the project team to factor in the additional costs the vendor selection process may incur. Group Decision-Making Techniques Outputs
Activity cost estimates Basis of Estimates (page 208) The more information that is known about the costs and how they were derived, the easier those costs are to justify. The following are some of the supporting detail that may be included in the estimate:
Documentation of the basis of the estimate Documentation of all assumptions made Documentation of any known constraints Indication of the range of possible estimates Indication of the confidence level of the final estimate
Project Document Updates Additional Estimate Concepts: Accuracy of Estimates As a project manager, it is important to set the right expectation around estimates. Estimates made in the early part of the project will be less accurate than those made later in the project. Because of this, it is best to communicate estimates early in the project as a range. As the project progresses, these estimates can become more refined. The Rough Order of Magnitude (ROM) estimate, as defined by the current PMBOK Guide (5th Edition), is in the range of -25% to +75%. The older PMBOK Guide (4th Edition) defined it to be in the range of -50% to +50%. For the exam, remember the correct ROM is in the range of -25% to +75% range Exam Hint
These ranges do show up on the exam. Make sure to MEMORIZE the following:
Rough Order of Magnitude (ROM) Estimate o This type of estimate is usually made early during the project. o A typical range from ROM estimate is from -25% to +75% from the actual, but this range can vary depending on how much is known about the project when creating the estimates. Budget Estimate o This type of estimate is usually made during the planning phase and is in the range of -10% to +25% from the actual. Definitive Estimate o Later during the project, the estimate will become more refined. Some project managers use the range of +/- 10% from actual, while others use -5% to +10% from actual.
Determine Budget In this part of cost management, the cost of the project needs to be calculated in order to determine the amount of funds the organization needs to set aside or have available for the project. The result of this calculation is called the budget or the authorized cost baseline. Meeting the cost baseline will be a measure of project success, so the budget should be in a form the project manager can use while the work is being done to control costs and therefore make sure the overall project is controlled. Exam Hint
A project estimate cannot be completed without risk management activities and the inclusion of reserves. Make sure you note this for the exam, especially if you do not do this in the real world.
Two types of reserves to be aware of are:
Contingency Reserves o Address the cost impacts of the risks remaining during risk response planning. Management Reserves o Are any extra funds to be set aside to cover unforeseen risks or change to the project
These reserves make up the difference between the cost baseline and the cost budget. The cost baseline contains the contingency reserves. It represents the funds authorized for the project manager to manage and control. The cost budget is the cost baseline plus the management reserves. Remember, an unrealistic budget is the project manager's fault, given that it was built off an unrealistic schedule. Inputs
Cost Management Plan Scope Baseline
Scope statement WBS WBS dictionary
Activity Cost Estimates Basis of Estimates Project Schedule Resource Calendars Risk Register Agreements(page 211) It is important to review any contractual costs and factor them into the overall project costs. Organizational Process Assets Tools and Techniques
Cost Aggregation (page 211) This is the roll up of project costs. To create a budget, activity costs are rolled up to work package costs. Work package costs are then rolled up to control account costs and finally into project costs.
Reserve Analysis Expert Judgment
Consultants Stakeholders (including customers) Professional and technical associations
Historical relationships (page 212) These are the historical data points that are used in parametric or analogous estimates. It is important to call those relationships out to determine the potential accuracy of the estimate based on the data. Funding Limit Reconciliation Outputs
Always remember: Cost baseline = work package estimate (project estimate) + contingency reserves. On the other hand, the total project budget = cost baseline + management reserves Cost Baseline (page 212) This is an authorized budget at completion (BAC). It is time-phased and used to measure, monitor, and control overall cost performance on the project. When plotted graphically over time, the project budget takes the form of an S-curve. On the other hand, the funding requirements take the shape of a ladder Project Funding Requirements Project Document Updates can include, but are not limited to:
Risk register Cost estimates Project schedule
Control Costs You and the team have worked hard to create a realistic budget. Now, as project manager, you need to make sure that the budget is tracked and met. PMBOK Guide Definition – Page 215
Control Costs is the process of monitoring the status of the project to update the project costs and managing changes to the cost baseline. With resources entering actual cost data, be it hours and expenses, the project manager spends a great deal of their time analyzing the data to determine the amount of the budget that has been consumed and the quantity of work that still remains to be done. They key to being a successful project manager who can control costs is to be able to keep a tight grip on the performance baseline data and the changes to those baselines. When you think of project cost, you should think about the following factors. According to the PMBOK Guide, these factors may include: (page 216):
Influencing the factors that create changes to the authorized cost baseline Ensuring that all change requests are acted on in timely manner Managing the actual changes when and as they occur Ensuring that expenditures do not exceed the authorized funding, both by period and in total for the project Monitoring cost performance to isolate and understand variances from the approved cost baseline Monitoring work performance against funds expended Preventing unapproved changes from being included in the reported cost or resource usage Informing appropriate stakeholders of all approved changes and associated costs Acting to bring expected costs overruns within acceptable limits
Inputs
Project Management Plan
Cost baseline Cost management plan
Project Funding Requirements Work Performance Data Organizational Process Assets
Tools and Techniques
Earned Value Management (page 217) Yes, earned value is on the exam. Many of you get worried when you hear or see earned value, and I realize that is it because for many the concept is not typically used in the real world. We need to begin with a clear definition so we are all starting from the same point. It is best to start from the high-level and then go into the detail. PMBOK Guide Definition – pg. 217
Earned value management (EVM) is a commonly used method of performance measurement for projects. It integrates the scope baseline with the cost baseline, along with the schedule baseline, to form the performance baseline, which helps the project management team assess and measure project performance and progress. Results from an earned value analysis indicate potential deviation of the project from the scope, schedule, and cost baselines (the performance measurement baseline). Many project managers manage their project performance by comparing planned to actual results. With this method, you could easily be on time but overspend according to your plan. Using earned value measurement is better, because it integrates cost, time, and the work done (or scope) and can be used to forecast future performance and project completion dates and costs. Earned value will lead to budget forecasts, change requests, and other items that will need to be communicated. Since the results of earned value measurement should be a major part of project reporting, you will also see earned value mentioned in Communications Management. Cost Management Terminology and Acronyms Acronym Term
Interpretations
PV
Planned Value
As of today, what is the estimated value of the work planned to be done?
EV
Earned Value
As of today, what is the estimated value of the work actually accomplished?
AC
Actual Cost (total cost)
As of today, what is the actual cost incurred for the work accomplished?
BAC
Budget at Completion How much did we BUDGET for the TOTAL (the budget) project effort?
EAC
Estimate at Completion
ETC
Estimate to Complete From this point on, how much more do we expect it to cost to finish?
VAC
Variance at Completion
What do we currently expect the TOTAL project to cost (a forecast)?
As of today, how much over or under budget do we expect to be at the end of the project?
Planned value: (page 218)
The authorized budget assigned to the work to be accomplished for the project. It is sometimes referred to as the Performance Measurement Baseline (PMB). The total planned value for the project is also known as Budget At Completion (BAC).
Earned value (page 218)
Earned value represents the value of the work performed expressed in terms of approved budget assigned to that work.
Actual costs
These are the cost that have been incurred and reported for the work that has been performed.
Positive values for Schedule Variance (SV) and Cost Variance (CV) are good project health indicators Schedule variance Open table as spreadsheet
Concept
Formula
Schedule Variance (SV)
SV = EV PV
Provides schedule performance of the project. Helps determine if the project work is proceeding as planned.
Result Interpretation
Negative = behind schedule = bad Positive = ahead of schedule = good
Cost variance Open table as spreadsheet
Concept
Formula Result Interpretation CV = EV Negative = over Cost Variance (CV) AC budget = bad Positive = under Provides cost performance of the budget = good project. Helps determine if the project is proceeding as planned.
Schedule performance index Open table as spreadsheet
Concept
Formula Result Interpretation SPI = EV 1 = good. We are Schedule Performance Index (SPI) / PV progressing at the originally planned rate. Measure of schedule efficiency >1 = good. We are on a project. Ratio of earned progressing at a faster value to planned value. rate than originally Used to determine if a project is planned. behind, on, or ahead of 1 = good. We are getting >$1 for every $1 spent. Funds are used better than planned. $1 for every $1 spent. Funds are used better than planned.
View more...
Comments