What is a project?
Published: Last Edited:
Disclaimer: This essay has been submitted by a student. This is not an example of the work written by our professional essay writers. You can view samples of our professional work here.
Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UK Essays.
A project can be defined as a temporary endeavor that is undertaken to create a unique result, which can be a product or a service. There are some terms in this definition, which have to be defined themselves. The main ones are temporary and unique result.
The term temporary means that every project must has a definite beginning and a definite end. The end would be reached when the project's objectives have all been achieved, or it becomes clear for us that the project objectives cannot or will not be met, or the former need for the project no longer exists. All of these result in the termination of project. Temporary does not necessarily mean short in duration; many projects can last for several years. In every case, however, the duration of a project is finite. Projects are not ongoing efforts.
In addition, temporary does not generally apply to the product, service or result created by the project. Most projects are undertaken to create a lasting outcome. For example, a project to erect a national monument will create a result expected to last centuries. Projects also may often have intended and unintended social, economic and environmental impacts that far outlast the projects themselves.
The temporary nature of projects may apply to other aspects of the endeavor as well:
The opportunity or market window is usually temporary-some projects have a limited time frame in which to produce their product or service.
The project team, as a working unit, seldom outlives the project-a team created for the sole purpose of performing the project will perform that project, and then the team is disbanded and the team members reassigned when the project ends.
Unique Products, Services, Or Results
A project creates unique deliverables, which are products, services, or results. Projects can create:
- A product or artifact that is produced, is quantifiable, and can be either an end item in itself or a component item
- A capability to perform a service, such as business functions supporting production or distribution
- A result, such as outcomes or documents. For example, a research project develops knowledge that can be used to determine whether or not a trend is present or a new process will benefit society.
Uniqueness is an important characteristic of project deliverables. For example, many thousands of office buildings have been developed, but each individual facility is unique-different owner, different design, different location, different contractors, and so on. The presence of repetitive elements does not change the fundamental uniqueness of the project work.
Progressive elaboration is a characteristic of projects that accompanies the concepts of temporary and unique. Progressive elaboration means developing in steps, and continuing by increments. For example, the project scope will be broadly described early in the project and made more explicit and detailed as the project team develops a better and more complete understanding of the objectives and deliverables. Progressive elaboration should not be confused with scope creep.
Progressive elaboration of a project's specifications needs to be carefully coordinated with proper project scope definition, particularly if the project is performed under contract. When properly defined, the scope of the project-the work to be done-should be controlled as the project and product specifications are progressively elaborated.
Projects And Strategic Planning
Projects are a means of organizing activities that cannot be addressed within the organization's normal operational limits. Projects are, therefore, often utilized as a means of achieving an organization's strategic plan, whether the project team is employed by the organization or is a contracted service provider.
Projects are typically authorized as a result of one or more of the following strategic considerations:
- A market demand (e.g., an oil company authorizes a project to build a new refinery in response to chronic gasoline shortages)
- An organizational need (e.g., a training company authorizes a project to create a new course in order to increase its revenues)
- A customer request (e.g., an electric utility authorizes a project to build a new substation to serve a new industrial park)
- A technological advance (e.g., a software firm authorizes a new project to develop a new generation of video games after the introduction of new game- playing equipment by electronics firms)
- A legal requirement (e.g., a paint manufacturer authorizes a project to establish guidelines for the handling of a new toxic material).
What Is Project Management?
Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements. Project management is accomplished through the application and integration of the project management processes of initiating, planning, executing, monitoring and controlling, and closing. The project manager is the person responsible for accomplishing the project objectives.
Managing a project includes:
- Identifying requirements
- Establishing clear and achievable objectives
- Balancing the competing demands for quality, scope, time and cost
- Adapting the specifications, plans, and approach to the different concerns and expectations of the various stakeholders.
Project managers often talk of a 'triple constraint'-project scope, time and cost-in managing competing project requirements. Project quality is affected by balancing these three factors. High quality projects deliver the required product, service or result within scope, on time, and within budget. The relationship among these factors is such that if any one of the three factors changes, at least one other factor is likely to be affected. Project managers also manage projects in response to uncertainty. Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on at least one project objective.
It is important to note that many of the processes within project management are iterative because of the existence of, and necessity for, progressive elaboration in a project throughout the project's life cycle. That is, as a project management team learns more about a project, the team can then manage to a greater level of detail.
The term 'project management' is sometimes used to describe an organizational or managerial approach to the management of projects and some ongoing operations, which can be redefined as projects, that is also referred to as 'management by projects.' There has been a tendency in recent years to manage more activities in more application areas using project management. More organizations are using 'management by project.' This is not to say that all operations can or should be organized into projects. The adoption of 'management by project' is also related to the adoption of an organizational culture that is close to the project management. Although, an understanding of project management is critical to an organization that is using 'management by projects,' a detailed discussion of the approach itself is outside the scope of this standard.
The Project Management Knowledge Areas
The Project Management Knowledge Areas, organizes the 44 project management processes from the Project Management Process Groups into nine Knowledge Areas, as described below.
Project Integration Management: describes the processes and activities that integrate the various elements of project management, which are identified, defined, combined, unified and coordinated within the Project Management Process Groups. It consists of the Develop Project Charter, Develop Preliminary Project Scope Statement, Develop Project Management Plan, Direct and Manage Project Execution, Monitor and Control Project Work, Integrated Change Control, and Close Project project management processes.
Project Scope Management: describes the processes involved in ascertaining that the project includes all the work required, and only the work required, to complete the project successfully. It consists of the Scope Planning, Scope Definition, Create WBS, Scope Verification, and Scope Control project management processes.
Project Time Management: describes the processes concerning the timely completion of the project. It consists of the Activity Definition, Activity Sequencing, Activity Resource Estimating, Activity Duration Estimating, Schedule Development, and Schedule Control project management processes.
Project Cost Management: describes the processes involved in planning, estimating, budgeting, and controlling costs so that the project is completed within the approved budget. It consists of the Cost Estimating, Cost Budgeting, and Cost Control project management processes.
Project Quality Management: describes the processes involved in assuring that the project will satisfy the objectives for which it was undertaken. It consists of the Quality Planning, Perform Quality Assurance, and Perform Quality Control project management processes.
Project Human Resource Management: describes the processes that organize and manage the project team. It consists of the Human Resource Planning, Acquire Project Team, Develop Project Team, and Manage Project Team project management processes.
Project Communications Management: describes the processes concerning the timely and appropriate generation, collection, dissemination, storage and ultimate disposition of project information. It consists of the Communications Planning, Information Distribution, Performance Reporting, and Manage Stakeholders project management processes.
Project Risk Management: describes the processes concerned with conducting risk management on a project. It consists of the Risk Management Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, and Risk Monitoring and Control project management processes.
Project Procurement Management: describes the processes that purchase or acquire products, services or results, as well as contract management processes. It consists of the Plan Purchases and Acquisitions, Plan Contracting, Request Seller Responses, Select Sellers, Contract Administration, and Contract Closure project management processes.
Figure 1-1. Overview of Project Management Knowledge Areas and Project Management Processes
The Project Life Cycle
Project managers or the organization can divide projects into phases to provide better management control with appropriate links to the ongoing operations of the performing organization. Collectively, these phases are known as the project life cycle. Many organizations identify a specific set of life cycles for use on all of their projects.
Characteristics Of The Project Life Cycle
The project life cycle defines the phases that connect the beginning of a project to its end. For example, when an organization identifies an opportunity to which it would like to respond, it will often authorize a feasibility study to decide whether it should undertake the project. The project life cycle definition can help the project manager clarify whether to treat the feasibility study as the first project phase or as a separate, stand-alone project. Where the outcome of such a preliminary effort is not clearly identifiable, it is best to treat such efforts as a separate project. The phases of a project life cycle are not the same as the Project Management Process Groups.
The transition from one phase to another within a projects life cycle generally involves, and is usually defined by, some form of technical transfer or handoff. Deliverables from one phase are usually reviewed for completeness and accuracy and approved before work starts on the next phase. However, it is not uncommon for a phase to begin prior to the approval of the previous phases deliverables, when the risks involved are deemed acceptable. This practice of overlapping phases, normally done in sequence, is an example of the application of the schedule compression technique called fast tracking.
There is no single best way to define an ideal project life cycle. Some organizations have established policies that standardize all projects with a single life cycle, while others allow the project management team to choose the most appropriate life cycle for the teams project. Further, industry common practices will often lead to the use of a preferred life cycle within that industry.
Project life cycles generally define:
- What technical work to do in each phase (for example, in which phase should the architects work be performed?)
- When the deliverables are to be generated in each phase and how each deliverable is reviewed, verified, and validated
- Who is involved in each phase (for example, concurrent engineering requires that the implementers be involved with requirements and design)
- How to control and approve each phase.
Project life cycle descriptions can be very general or very detailed. Highly detailed descriptions of life cycles can include forms, charts, and checklists to provide structure and control.
Most project life cycles share a number of common characteristics:
- Phases are generally sequential and are usually defined by some form of technical information transfer or technical component handoff.
- Cost and staffing levels are low at the start, peak during the intermediate phases, and drop rapidly as the project draws to a conclusion.
- The level of uncertainty is highest and, hence, risk of failing to achieve the objectives is greatest at the start of the project. The certainty of completion generally gets progressively better as the project continues.
- The ability of the stakeholders to influence the final characteristics of the projects product and the final cost of the project is highest at the start, and gets progressively lower as the project continues. A major contributor to this phenomenon is that the cost of changes and correcting errors generally increases as the project continues.
Although many project life cycles have similar phase names with similar deliverables, few life cycles are identical. Some can have four or five phases, but others may have nine or more. Single application areas are known to have significant variations. One organizations software development life cycle can have a single design phase, while another can have separate phases for architectural and detailed design. Subprojects can also have distinct project life cycles. For example, an architectural firm hired to design a new office building is first involved in the owners definition phase while doing the design, and in the owners implementation phase while supporting the construction effort. The architects design project, however, will have its own series of phases from conceptual development, through definition and implementation, to closure. The architect can even treat designing the facility and supporting the construction as separate projects, each with its own set of phases.
Characteristics Of Project Phases
The completion and approval of one or more deliverables characterizes a project phase. A deliverable is a measurable, verifiable work product such as a specification, feasibility study report, detailed design document, or working prototype. Some deliverables can correspond to the project management process, whereas others are the end products or components of the end products for which the project was conceived. The deliverables, and hence the phases, are part of a generally sequential process designed to ensure proper control of the project and to attain the desired product or service, which is the objective of the project.
In any specific project, for reasons of size, complexity, level of risk, and cash flow constraints, phases can be further subdivided into subphases. Each subphase is aligned with one or more specific deliverables for monitoring and control. The majority of these subphase deliverables are related to the primary phase deliverable, and the phases typically take their names from these phase deliverables: requirements, design, build, test, startup, turnover, and others, as appropriate.
A project phase is generally concluded with a review of the work accomplished and the deliverables to determine acceptance, whether extra work is still required, or whether the phase should be considered closed. A management review is often held to reach a decision to start the activities of the next phase without closing the current phase, for example, when the project manager chooses fast tracking as the course of action. Another example is when an information technology company chooses an iterative life cycle where more than one phase of the project might progress simultaneously. Requirements for a module can be gathered and analyzed before the module is designed and constructed. While analysis of a module is being done, the requirements gathering for another module could also start in parallel.
Similarly, a phase can be closed without the decision to initiate any other phases. For example, the project is completed or the risk is deemed too great for the project to be allowed to continue.
Formal phase completion does not include authorizing the subsequent phase. For effective control, each phase is formally initiated to produce a phase-dependent output of the Initiating Process Group, specifying what is allowed and expected for that phase, as shown in Figure 2-3. A phase-end review can be held with the explicit goals of obtaining authorization to close the current phase and to initiate the subsequent one. Sometimes both authorizations can be gained at one review. Phase-end reviews are also called phase exits, phase gates, or kill points.
Project Management Processes
The project management processes are presented as discrete elements with well- defined interfaces. However, in practice they overlap and interact in ways that are not completely detailed here. Most experienced project management practitioners recognize there is more than one way to manage a project. The specifics for a project are defined as objectives that must be accomplished based on complexity, risk, size, time frame, project teams experience, access to resources, amount of historical information, the organizations project management maturity, and industry and application area. The required Process Groups and their constituent processes are guides to apply appropriate project management knowledge and skills during the project. In addition, the application of the project management processes to a project is iterative and many processes are repeated and revised during the project. The project manager and the project team are responsible for determining what processes from the Process Groups will be employed, by whom, and the degree of rigor that will be applied to the execution of those processes to achieve the desired project objective.
An underlying concept for the interaction among the project management processes is the plan-do-check-act cycle. This cycle is linked by results the result from one part of the cycle becomes the input to another. See Figure 3-1.
The integrative nature of the Process Groups is more complex than the basic plan-do-check-act cycle (see Figure 3-2). However, the enhanced cycle can be applied to the interrelationships within and among the Process Groups. The Planning Process Group corresponds to the plan component of the plan-do-check-act cycle. The Executing Process Group corresponds to the do component and the Monitoring and Controlling Process Group corresponds to the check and act components. In addition, since management of a project is a finite effort, the Initiating Process Group starts these cycles and the Closing Process Group ends them. The integrative nature of project management requires the Monitoring and Controlling Process Group interaction with every aspect of the other Process Groups.
Project Management Process Groups Mapped to the Plan-Do-Check-Act Cycle
Project Management Process Groups
There are five dependent Project Management Process Groups which are required for any project. These five Process Groups are performed in the same sequence on every project and are independent of application areas or industry focus. Individual Process Groups and constituent processes are often iterated prior to completing the project. Constituent processes can also have interactions both within a Process Group, and among all Process Groups.
- Process Groups
- Processes within the Process Groups
- Organizational Process Assets and Enterprise Environmental Factors, which are shown as inputs to and outputs from the Process Groups, and external to the processes
- Arrows or line arrows indicate data or process flow among or within the Process Groups.
The process flow diagram, which is shown in Figure 3-4, provides an overall summary of the basic flow and interactions that happen among the Process Groups. An individual process may define and constrain the use of inputs to produce outputs for that Process Group. Each Process Group includes the constituent project management processes which are linked by the respective inputs and outputs; so the result or outcome of one process becomes the input to another. It is important to mention that The Process Groups are not project phases. All Process Group processes are normally repeated for each phase or subproject.
The Process Groups are:
- Initiating Process Group: Defines and also authorizes the project, or a project phase.
- Planning Process Group: Defines and refines the objectives and plans the course of action that is required to attain the objectives and scope that the project has to address.
- Executing Process Group: Integrates resources (like people) to carry out the project management plan for the project.
- Monitoring and Controlling Process Group: Regularly measures and monitors progress to identify the variances from the project management plan to take the corrective when it is necessary to meet project objectives.
- Closing Process Group. Formalizes acceptance of the result (product or service) and brings the project (or a project phase) to an orderly end.
Initiating Process Group
The initiation processes determine the scope and nature of the project. If this stage is not done well, probably the project will not be successful in meeting its defined needs. The key project controls that are needed here are an understanding of the business environment, and also making sure that all of the necessary controls are incorporated. The failures have to be reported and a recommendation should be made for fixing them.
The initiation stage should include a plan that covers the following areas:
- Analysis of the business requirements in measurable goals
- Review of the current operations
- Financial analysis of the costs and benefits containing a budget
- Stakeholder analysis and support personnel for the ongoing project
- Project charter containing costs, tasks, deliverables, and schedule
Planning Process Group
Following the initiation stage, the project is planned to a suitable level of detail. The main aim is to plan time, cost and resources sufficiently to estimate the work needed and to effectively manage the risk during project execution. Like the Initiation processes, a failure to adequately plan greatly decreases the project's chance of successfully accomplishing the goals.
Project planning is generally consisted of the following:
- Finding out how to plan
- developing the scope statement;
- selecting the planning team;
- identifying the deliverables and creating the WBS;
- identifying the activities that are needed to complete the deliverables and networking the activities in their coherent sequence;
- estimating the resources required for the activities;
- estimating time and cost for activities;
- developing the schedule;
- developing the budget;
- risk planning;
- Getting the formal approval to begin work.
For new product development projects, conceptual design of the operation of the final product may be performed simultaneous with the project planning activities, and can help to inform the planning team during identification of deliverables and planning activities.
Executing Process Group
Executing is consisted of the processes which are used to complete the work defined in the project management plan to gain the project's requirements. Execution process contains coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are then produced as outputs from the processes performed as is defined in the project management plan.
Monitoring And Controlling Process Group
Monitoring and controlling mainly consists of the processes that are performed for observation of project execution. Therefore, the potential problems can be easily identified in a timely manner and needed corrective action can be taken, to control the execution of the project. The key benefit is that project performance is observed on a regular basis to identify variances from the project management plan.
Monitoring and Controlling process group includes:
- Measuring the current project activities;
- Monitoring the project variables (cost, effort, scope, etc.) with a look at the project management plan and the project performance baseline;
- Identifying needed corrective actions to address topics and risks properly;
- Influencing the factors that could circumvent structured change control so only approved changes are accepted and implemented
In multi-phase projects, the monitoring and controlling process may also provide feedback between project phases for implementing corrective or preventive actions to bring the project in compliance with the project management plan.
Project Maintenance is an ongoing process. Therefore, it includes:
- Ongoing support of end users
- Correcting errors
- Updating the software over time
Monitoring And Controlling Cycle
Over the trend of any construction project, the work scope might change. Change is an expected and normal part of the construction process. Change can be the result of necessary design modifications, differing site conditions, contractor-requested changes, material availability, value engineering and affects from third parties. Beyond executing the change in the field, the change needs to be documented to show what is actually constructed. This is referred to as Change Management.
When changes are implemented to the project, the feasibility of the project has to be re-checked. It is important not to lose sight of the initial goals and targets of the projects. When the changes are collected, the forecasted result may not explain the original proposed investment in the project.
Closing Process Group
Closing includes the formal acceptance of the project and the ending thence. Managerial activities include the archiving of the files and documenting everything.
This phase mainly consists of:
- Project close: Finalizing all activities across process groups to formally close the project
- Contract closure: Completing and settling each contract (including the resolution of any open items) and closing each contract applicable to the project or project phase
Overview Of Project Risk Management
Project Risk Management includes the processes concerned with conducting risk management planning, identification, analysis, responses, and monitoring and control on a project; most of these processes are updated throughout the project. The objectives of Project Risk Management are to increase the probability and impact of positive events, and decrease the probability and impact of events adverse to the project. Figure 11-1 provides an overview of the Project Risk Management processes, and Figure 11-2 provides a process flow diagram of those processes and their inputs, outputs, and other related Knowledge Area processes. The Project Risk Management processes include the following:
1. Risk Management Planning: deciding how to approach, plan, and execute the risk management activities for a project.
2. Risk Identification: determining which risks might affect the project and documenting their characteristics.
3. Qualitative Risk Analysis: prioritizing risks for subsequent further analysis or action by assessing and combining their probability of occurrence and impact.
4. Quantitative Risk Analysis: numerically analyzing the effect on overall project objectives of identified risks.
5. Risk Response Planning: developing options and actions to enhance opportunities, and to reduce threats to project objectives.
6. Risk Monitoring and Control: tracking identified risks, monitoring residual risks, identifying new risks, executing risk response plans, and evaluating their effectiveness throughout the project life cycle.
These processes interact with each other and with the processes in the other Knowledge Areas as well. Each process can involve effort from one or more persons or groups of persons based on the needs of the project. Each process occurs at least once in every project and occurs in one or more project phases, if the project is divided into phases. Although the processes are presented here as discrete elements with well-defined interfaces, in practice they may overlap and interact in ways not detailed here. Process interactions are discussed in detail in Chapter 3.
Project risk is an uncertain event or condition that, if it occurs, has a positive or a negative effect on at least one project objective, such as time, cost, scope, or quality (i.e., where the project time objective is to deliver in accordance with the agreed-upon schedule; where the project cost objective is to deliver within the agreed-upon cost; etc.). A risk may have one or more causes and, if it occurs, one or more impacts. For example, a cause may be requiring an environmental permit to do work, or having limited personnel assigned to design the project. The risk event is that the permitting agency may take longer than planned to issue a permit, or the design personnel available and assigned may not be adequate for the activity. If either of these uncertain events occurs, there may be an impact on the project cost, schedule, or performance. Risk conditions could include aspects of the project's or organization's environment that may contribute to project risk, such as poor project management practices, lack of integrated management systems, concurrent multiple projects, or dependency on external participants who cannot be controlled.
Project risk has its origins in the uncertainty that is present in all projects. Known risks are those that have been identified and analyzed, and it may be possible to plan for those risks using the processes described in this chapter. Unknown risks cannot be managed proactively, and a prudent response by the project team can be to allocate general contingency against such risks, as well as against any known risks for which it may not be cost-effective or possible to develop a proactive response.
Organizations perceive risk as it relates to threats to project success, or to opportunities to enhance chances of project success. Risks that are threats to the project may be accepted if the risk is in balance with the reward that may be gained by taking the risk. For example, adopting a fast track schedule (Section 18.104.22.168) that may be overrun is a risk taken to achieve an earlier completion date. Risks that are opportunities, such as work acceleration that may be gained by assigning additional staff, may be pursued to benefit the project's objectives.
Persons and, by extension, organizations have attitudes toward risk that affect both the accuracy of the perception of risk and the way they respond. Attitudes about risk should be made explicit wherever possible. A consistent approach to risk that meets the organization's requirements should be developed for each project, and communication about risk and its handling should be open and honest. Risk responses reflect an organization's perceived balance between risk-taking and risk- avoidance.
To be successful, the organization should be committed to addressing the management of risk proactively and consistently throughout the project.
Risk Management Planning
Careful and explicit planning enhances the possibility of success of the five other risk management processes. Risk Management Planning is the process of deciding how to approach and conduct the risk management activities for a project. Planning of risk management processes is important 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, to provide sufficient resources and time for risk management activities, and to establish an agreed-upon basis for evaluating risks. The Risk Management Planning process should be completed early during project planning, since it is crucial to successfully performing the other processes described in this chapter.
Risk Identification determines which risks might affect the project and documents their characteristics. Participants in risk identification activities can include the following, where appropriate: project manager, project team members, risk management team (if assigned), subject matter experts from outside the project team, customers, end users, other project managers, stakeholders, and risk management experts. While these personnel are often key participants for risk identification, all project personnel should be encouraged to identify risks.
Risk Identification is an iterative process because new risks may become known as the project progresses through its life cycle. The frequency of iteration and who participates in each cycle will vary from case to case. The project team should be involved in the process so that they can develop and maintain a sense of ownership of, and responsibility for, the risks and associated risk response actions. Stakeholders outside the project team may provide additional objective information. The Risk Identification process usually leads to the Qualitative Risk Analysis process. Alternatively, it can lead directly to the Quantitative Risk Analysis process when conducted by an experienced risk manager. On some occasions, simply the identification of a risk may suggest its response, and these should be recorded for further analysis and implementation in the Risk Response Planning process.
Qualitative Risk Analysis
Qualitative Risk Analysis includes methods for prioritizing the identified risks for further action, such as Quantitative Risk Analysis or Risk Response Planning. Organizations can improve the project's performance effectively by focusing on high-priority risks. Qualitative Risk Analysis assesses the priority of identified risks using their probability of occurring, the corresponding impact on project objectives if the risks do occur, as well as other factors such as the time frame and risk tolerance of the project constraints of cost, schedule, scope, and quality.
Definitions of the levels of probability and impact, and expert interviewing, can help to correct biases that are often present in the data used in this process. The time criticality of risk-related actions may magnify the importance of a risk. An evaluation of the quality of the available information on project risks also helps understand the assessment of the risk's importance to the project.
Qualitative Risk Analysis is usually a rapid and cost-effective means of establishing priorities for Risk Response Planning, and lays the foundation for Quantitative Risk Analysis, if this is required. Qualitative Risk Analysis should be revisited during the project's life cycle to stay current with changes in the project risks. Qualitative Risk Analysis requires outputs of the Risk Management Planning and Risk Identification processes. This process can lead into Quantitative Risk Analysis or directly into Risk Response Planning.
Quantitative Risk Analysis
Quantitative Risk Analysis is performed on risks that have been prioritized by the Qualitative Risk Analysis process as potentially and substantially impacting the project's competing demands. The Quantitative Risk Analysis process analyzes the effect of those risk events and assigns a numerical rating to those risks. It also presents a quantitative approach to making decisions in the presence of uncertainty. This process uses techniques such as Monte Carlo simulation and decision tree analysis to:
- Quantify the possible outcomes for the project and their probabilities
- Assess the probability of achieving specific project objectives
- Identify risks requiring the most attention by quantifying their relative contribution to overall project risk
- Identify realistic and achievable cost, schedule, or scope targets, given the project risks
- Determine the best project management decision when some conditions or outcomes are uncertain.
Quantitative Risk Analysis generally follows the Qualitative Risk Analysis process, although experienced risk managers sometimes perform it directly after Risk Identification. In some cases, Quantitative Risk Analysis may not be required to develop effective risk responses. Availability of time and budget, and the need for qualitative or quantitative statements about risk and impacts, will determine which method(s) to use on any particular project. Quantitative Risk Analysis should be repeated after Risk Response Planning, as well as part of Risk Monitoring and Control, to determine if the overall project risk has been satisfactorily decreased. Trends can indicate the need for more or less risk management action. It is an input to the Risk Response Planning process.
Risk Response Planning
Risk Response Planning is the process of developing options, and determining actions to enhance opportunities and reduce threats to the project's objectives. It follows the Qualitative Risk Analysis and Quantitative Risk Analysis processes. It includes the identification and assignment of one or more persons (the 'risk response owner') to take responsibility for each agreed-to and funded risk response. Risk Response Planning addresses the risks by their priority, inserting resources and activities into the budget, schedule, and project management plan, as needed.
Planned risk responses must be appropriate to the significance of the risk, cost effective in meeting the challenge, timely, 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.
The Risk Response Planning section presents commonly used approaches to planning responses to the risks. Risks include threats and opportunities that can affect project success, and responses are discussed for each.
Risk Monitoring And Control
Planned risk responses that are included in the project management plan are executed during the life cycle of the project, but the project work should be continuously monitored for new and changing risks.
Risk Monitoring and Control is the process of identifying, analyzing, and planning for newly arising risks, keeping track of the identified risks and those on the watchlist, reanalyzing existing risks, monitoring trigger conditions for contingency plans, monitoring residual risks, and reviewing the execution of risk responses while evaluating their effectiveness. The Risk Monitoring and Control process applies techniques, such as variance and trend analysis, which require the use of performance data generated during project execution. Risk Monitoring and Control, as well as the other risk management processes, is an ongoing process for the life of the project. Other purposes of Risk Monitoring and Control are to determine if:
- Project assumptions are still valid
- Risk, as assessed, has changed from its prior state, with analysis of trends
- Proper risk management policies and procedures are being followed
- Contingency reserves of cost or schedule should be modified in line with the risks of the project.
Risk Monitoring and Control can involve choosing alternative strategies, executing a contingency or fallback plan, taking corrective action, and modifying the project management plan. The risk response owner reports periodically to the project manager on the effectiveness of the plan, any unanticipated effects, and any mid-course correction needed to handle the risk appropriately. Risk Monitoring and Control also includes updating the organizational process assets, including project lessons-learned databases and risk management templates for the benefit of future projects.
Cite This Essay
To export a reference to this article please select a referencing stye below: