If you take nothing away from this presentation except this one slide. You have the basic knowledge you need about project management.
The Project Management Body of Knowledge (PMBOK) is an inclusive term that describes the sum of knowledge within the profession of project management. As with other professions such as law, medicine, and accounting, the body of knowledge rests with the practitioners and academics that apply and advance it. The full project management body of knowledge includes knowledge of proven traditional practices that are widely applied, as well as knowledge of innovative and advanced practices that have seen more limited use, and includes both published and unpublished material.
Project Management is an emerging profession. This presentation provides a basic reference for anyone interested in the profession of project management.
A Guide to the Project Management Body of Knowledge (referenced as the PiMBOK) defines a project as &quot;a temporary endeavor undertaken to create a unique product or service.&quot;
Meeting or exceeding stakeholders needs and expectations invariably involves balancing competing demands among: * Competing demands for: scope, time, cost, risk and quality. * Stakeholders with differing needs and expectations. Identified requirements. Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements. Project management is accomplished through the use of the processes such as: Initiating, planning, executing, controlling and closing.
Much of the knowledge needed to manage projects is unique to project management (e.g., critical path analysis and work breakdown structures). However, the PMBOK does overlap other management disciplines. General management encompasses planning, organizing, staffing, executing and controlling the operations of an ongoing enterprise. General management also includes supporting disciplines such as law, strategic planning, logistics, and human resources management. The PMBOK overlaps or modifies general management in many areas – organizational behavior, financial forecasting, and planning techniques, to name a few. Application areas are categories of projects that have common elements significant in such projects, but are not needed or present in all projects. Application areas are usually defined in terms of: Functional departments and supporting disciplines, such as legal, production and inventory management, marketing, logistics and personnel. Technical elements, such as software development, pharmaceuticals, water and sanitation engineering, or construction engineering. Management specializations, such as government contracting, community development, or new product development. Industry groups, such as automotive, chemicals, agriculture, or financial services.
Certain types of endeavors are closely related to projects. There is often a hierarchy of strategic plans, programs, projects, and subprojects, in which a program consisting of several associated pro4ejcts will contribute to the achievement of a strategic plan. These related undertakings are described as: Programs – A program is a group of projects managed in a coordinated way to obtain benefits not available from managing them individually. Many programs also includes elements of ongoing operations. Subprojects – Projects are frequently divided into more manageable components or subprojects. Subprojects are often contracted to an external enterprise or to another functional unit in the performing organization. Project Portfolio Management – Project portfolio management refers to the selection and support of projects or program investments. These investments in projects and programs are guided by the organization’s strategic plan and available resources.
Projects and project management operate in an environment broader than that of the project itself. The management team must understand this broader context – managing the day-to-day activities of the project is necessary for success but not sufficient. The project management context consists of: Project phases and the project life cycle Characteristics of project phases Characteristics of the project life cycle Representative project life cycles Project Stakeholders Project Manager Customer Performing organization Sponsor Organizational influences Organization systems Organizational cultures and styles Organizational structure Project office Key General Management Skills Leading Communicating Negotiating Problem Solving Influencing the Organization Social-Economic Environmental Influences Standards and Regulations Internationalization Cultural influences Social-Economic-Environmental Sustainability
Project management is an integrative endeavor – an action, or failure to take action, in one area will usually affect other areas. The interactions may be straightforward and well understood, or they may be subtle and uncertain. For example, a scope change will almost always affect project cost, but it may or may not affect team morale or product quality. These interactions often require tradeoffs among project objectives-performance in one are may be enhanced only by sacrificing performance in anther. Project Processes Projects are composed of processes. A process is “a series of actions bringing about a result”. Project processes are performed by people and generally fall into one of two major categories: Project Management processes Product-oriented processes Process Groups Initiating processes Planning processes Executing processes Controlling processes Closing processes Process Interactions Within each process group, the individual processes are linked by their inputs and outputs. By focusing on these links, we can describe each process in terms of its: Inputs Tools and Techniques Outputs Customizing process interactions Mapping of project management processes
This chart reflects the mapping of the thirty-nine project management processes to the five project management process groups of initiating, planning, executing, controlling and closing and the nine project management knowledge areas. This diagram is not meant to be exclusive, but to indicate generally where the project management processes fit into both the project management process groups and the project management knowledge areas.
Project Integration Management includes the processes required to ensure that the various elements of the project are properly coordinated. It involves making tradeoffs among competing objectives and alternative to meet or exceed stakeholder needs and expectations. While all project management processes are integrative to some extent, the processes described here are primarily integrative. Project Plan Development – integrated and coordinating all project plans to create a consistent, coherent document. Project Plan Execution – carrying out the project plan by performing the activities included therein. Integrated Change Control – coordinating changes across the entire project.
Project plan development uses the outputs of the other planning processes, including strategic planning, to create a consistent, coherent document that can be used to guide both project execution and project control. This process is almost always iterated several times. For example, the initial draft may include generic resource requirements and an undated sequence of activities while the subsequent versions of the plan will include specific resources and explicit dates. The project scope of the work is an iterative process that is generally done by the project team with the use of a Work Breakdown Structure (WBS), allowing the team to capture and then decompose all of the work of the project. All of the defined work must be planned, estimated and scheduled, and authorized with the use of detailed integrated management control plans sometimes called Control Account Plans, or CAPs, in the EVM process. The sum of all the integrated management control plans will constitute the total project scope.
Project plan execution is the primary process for carrying out the project plan – the vast majority of the project’s budget will be expended in performing this process. In this process, the project manager and the project management team must coordinate and direct the various technical and organizational interfaces that exist in the project. It is the project process that is most directly affected by the project application area in that the product of the project is actually created here. Performance against the project baseline must be continuously monitored so that corrective actions can be taken based on actual performance against the project plan. Periodic forecasts of the final cost and schedule results will be made to support this analysis
Integrated change control is concerned with: Influencing the factors that create changes to ensure that changes are agreed upon Determining that a change has occurred Managing the actual changes when and as they occur The original defined project scope and the integrated performance baseline must be maintained by continuously managing changes to the baseline, either by rejecting new changes or by approving changes and incorporating them into a revised project baseline. Integrated change control requires: Maintaining the integrity of the performance measurement baselines Ensuring that changes to the product scope are reflected in the definition of the project scope Coordinating changes across knowledge areas, a proposed schedule change will often affect cost, risk, quality, and staffing
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. It is primarily concerned with defining and controlling what is or is not included in the project. Scope Initiation – authorizing the project or phase Scope Planning – developing a written scope statement as the basis for future project decisions Scope Definition – Subdividing the major project deliverables into smaller, more manageable components Scope Verification – formalizing acceptance of the project scope Scope Change Control – controlling changes to project scope
Initiation is the process of formally authorizing a new project or that an existing project should continue into its next phase. This formal initiation links the project to the ongoing work of the performing organization. In some organizations, a project is not formally initiated until after completion of a needs assessment, a feasibility study, a preliminary plan, or some other equivalent form of analysis that was itself separately initiated. Some types of projects, especially internal service projects and new product development projects, are initiated informally, and some limited amount of work is done to secure the approvals needed for formal initiation. Projects are typically authorized as a result of one or more of the following: A market demand A business need A customer request A technological advance A legal requirement A social need These stimuli may also be called problems, opportunities, or business requirements. The central theme of all of these terms is that management generally must make a decision about how to respond.
Scope planning is the process of progressively elaborating and documenting the project work that produces the product of the project. Project scope planning starts with the initial inputs of product description, the project charter, and the initial definition of constraints and assumptions. Note that the product description incorporates product requirements that reflect agreed-upon customer needs and the product design that meets the product requirements. The outputs of scope planning are the scope statement and scope management plan, with the supporting detail. The scope statement forms the basis for an agreement between the project and the project customer by identifying both the project objectives and the project deliverables. Project teams develop multiple scope statements that are appropriate for the level of project work decomposition.
Scope definition involves subdividing the major project deliverables into smaller, more manageable components to: Improve the accuracy of cost, duration and resource estimates Define a baseline for performance measurement and control Facilitate clear responsibility assignments Proper scope definition is critical to the projects success.
Scope verification is the process of obtaining formal acceptance of the project scope by the stakeholders (sponsor, client, customer, etc.). It requires reviewing deliverables and work results to ensure that all were completed correctly and satisfactorily. If the project is terminated early, the scope verification process should establish and document the leve3l and extend of completion. Scope verification differs from quality control in that it is primarily concerned with acceptance of the work results while quality control is primarily concerned with the correctness of the work results. These processes are generally performed in parallel to ensure both correctness and acceptance.
Scope change control is concerned with: Influencing the factors that create scope changes to ensure that changes are agreed upon Determining that a scope change has occurred Managing the actual change when and if they occur Scope change control must be thoroughly integrated with the other control processes.
Project time management includes the process required to ensure timely completion of the project. Activity definition – identifying the specific activities that must be performed to produce the various project deliverables Activity sequencing – identifying and documenting interactivity dependencies. Activity duration estimating – estimating the number work periods that will be needed to complete individual activities Schedule development – analyzing activity sequences, activity durations, and resource requirements to create the project schedule Schedule control – controlling changes to the project schedule These processes interact with each other and with the processes in the other knowledge areas as well. Each process may involve effort from one or more individuals or groups of individuals, based on the needs of the project. Each process generally occurs at least once in every project phase.
Risk management is the systematic process of identifying, analyzing, and responding to project risk. It includes maximizing the probability and consequences of adverse events to project objectives. These processes interact with each other and with the processes in the other knowledge areas. Each process generally occurs at least once in every project. Although processes are presented here as discrete elements with well-defined interfaces, in practice they may overlap and interact in ways not detailed here.
Risk management planning is the process of deciding how to approach and plan the risk management activities for a project. It is important to plan for the risk management process that follow to ensure that the level, type and visibility of risk management are commensurate with both the risk and importance of the project to the organization.
Risk identification involves determining which risks might affect the project and documenting their characteristic. Participating in risk identification generally include the following as possible: Project Team Risk management team Subject matter experts from other parts of the company Customers End users Other project managers Stakeholder Outside experts Risk identification is an iterative process. The first iteration may be performed by a part of the project team, or by the risk management team. The entire project team and primary stakeholders may make a second iteration. TO achieve an unbiased analysis, persons who are not involved in the project may perform the final iteration. Often simple and effective risk responses can be developed and even implemented as soon as the risk is identified.
Qualitative risk analysis is the process of assessing the impact and likelihood of identified risks. This process prioritizes risks according to their potential effect on project objectives. Qualitative risk analysis is one way to determine the importance of addressing specific risks and guiding risk responses. The time-criticality of risk-related actions may magnify the importance of a risk. AN evaluation of the quality of the available information also helps modify the assessment of the risk. Qualitative risk analysis requires that the probability and consequences of the risks be evaluated using established qualitative-analysis methods and tools. Trends in the results when qualitative analysis is repeated can indicate the need for more or less risk-management actions. Use of these tools helps correct biases that are often in a project plan. Qualitative risk analysis should be revisited during the project’s life cycle to stay current with changes in the project risks. This process can lead to further analysis in quantitative risk analysis or directly to risk response planning.
The quantitative risk analysis process aims to analyze numerically the probability of each risk and its consequences on project objectives, as well as the extent of overall project risk. This process uses techniques such as Monte Carlo simulation and decision analysis to: Determine the probability of achieving a specific project objective Quantify the risk exposure for the project, and determine the size of cost and schedule contingency reserves that may be needed Identify risks requiring the most attention by quantifying their relative contribution to project risk Identify realistic and achievable cost, schedule or scope targets Quantitative risk analysis generally follows qualitative risk analysis. It requires risk identification. The qualitative and quantitative risk analysis processes can be used separately or together. Considerations of time and budget availability and the need for qualitative or quantitative statements about risk and impacts will determine method(s) to use. Trends in the results when quantitative analysis is repeated can indicate the need for more or less risk management action.
Risk response planning is the process of developing options and determining actions to enhance opportunities and reduce threats to the project’s objectives. It includes the identification and assignment of individual or parties to take responsibility for each agreed risk response. This process ensures that identified risks are properly addressed. The effectiveness of response planning will directly determine whether risk increases or decreases for the project. Risk response planning must be appropriate to the severity of the risk, cost effective in meeting the challenge, timely to be successful, realistic within the project context. Agreed upon by all parties involved, and owned by a responsible person. Selecting the best risk response from several options is often required.
Risk monitoring and control is the process of keeping track of the identified risks, monitoring residual risks and identifying new risks, ensuring the execution of risk plans, and evaluating their effectiveness in reducing risk. Risk monitoring and control records risk metrics that are associated with implementing contingency plans. Risk Monitoring and control is an ongoing process for the life of the project. The risks change as the project matures, new risks develop or anticipated risks disappear. Good risk monitoring and control processes provide information that assists with making effective decisions in advance of the risk’s occurring. Communication to all project stakeholders is needed to assess periodically the acceptability of the level of risk on the project. The purpose of risk monitoring is to determine if: Risk responses have been implemented as planned Risk response actions are as effective as expected, or if new responses should be developed Project assumptions are still valid Risk exposure has changed from its prior state, with analysis of trends A risk trigger has occurred Proper policies and procedures are followed Risks have occurred or arisen that were not previously identified Risk control may involve choosing alternative strategies, implementing a contingency plan, taking corrective action, or replanning the project. The risk response owner should report periodically to the project manager and the risk team leader on the effectiveness of the plan, any unanticipated effects, and any mid-course correction needed to mitigate the risk.
Project Procurement Management includes the processes required to acquire goods and services, to attain project scope, from outside the performing organization. For simplicity, goods and services, whether one or many, will generally be referred to as a product.
Procurement planning is the process of identifying which project needs can be best met by procuring products or services outside the project organization and should be accomplished during the scope definition effort. It involves consideration of whether to procure, how to procure, what to procure, how much to procure and when to procure. When the project obtains products and services from outside the performing organization, the processes from solicitation planning through contract closeout would be performed once for each product or service item. The project management team may want to see support from specialists in the disciplines of contracting and procurement when needed and involves them early in the process as a member of the project team. When the project does not obtain products and services from outside the performing organization, the processes from solicitation planning through contract closeout would not be performed. Procurement planning should also include consideration of potential sellers, particularly if the buyer wishes to exercise some degree of influence or control over contracting decisions.
Solicitation planning involves preparing the documents needed to support solicitation.
Solicitation involves obtaining responses from prospective sellers on how project needs can be met. Most of the actual effort in this process is expended by the prospective sellers, normally at no to the project.
Source selection involves the receipt of bids or proposals and the application of the evaluation criteria to select a provider. Many factors aside form cost or price may need to be evaluated in the source selection decision process. Price may be the primary determinant for an off-the-shelf item, but the lowest proposal price may not be the lowest cost if the seller proves unable to deliver the product in a timely manner. Proposals are often separated into technical and commercial sections with each evaluated separately. Multiple sources may be required for critical products.
Contract administration is the process of ensuring that the seller’s performance meets contractual requirements. On larger projects with multiple product and service providers, a key aspect of contract administration is managing the interfaces among the various providers. The legal nature of the contractual relationship makes it imperative that the project team be acutely aware of the legal implications of actions taken when administering the contract.
Contract closeout is similar to administrative closure in that it involves both product verification and administrative closeout. The contract terms and conditions may prescribe specific procedures for contract closeout. Early termination of a contract is a special case of contract closeout.