Three: Project Planning (Detail Level)

Process Descriptions


3.1 Conduct Detail Planning Kick-off




Conduct Project Planning (Detail Level) Kick-off formally marks the beginning of Detail Planning and facilitates the transition from Project Planning (High Level). It ensures that the project remains on track and focused on the original business need. New Project Team members are thoroughly prepared to begin work, the current project status is reviewed, and all prior deliverables are re-examined. All deliverables produced during Project Planning (High Level) are used in Project Planning (Detail).


Tasks associated with Conduct Detail Planning Kick-off


3.1.1 Orient New Project Team Members

The goal of orientation is to enhance the ability of new team members to contribute quickly and positively to the projects desired outcome. If individuals have recently joined the team, it is imperative they have adequate workspace, equipment, security access, and supplies necessary to perform their required tasks. The Project Manager (or Team Leader, if appropriate) must convey to each new team member, in a one-on-one conversation, what his/her role and responsibilities are related to the project. In order to streamline interaction among the team, new team members must also become familiar with the roles and responsibilities of all other Project Team members and Stakeholders as soon as possible, and immediately receive copies of all project materials, including any deliverables produced so far. It is usually the Project Managers responsibility to get new members of the team up to speed as quickly as possible. On large projects, however, if the team is structured with Team Leaders reporting to the Project Manager, it may be more appropriate to assign a Team Leader to mentor the new individual.

Information that would be useful to new team members includes:

Some Project Managers make use of orientation checklists to ensure that nothing is forgotten during orientation sessions. It's a good idea to retain a package containing a checklist, an orientation meeting agenda, project materials and logistical information. Then, when a new member joins the Project Team, you can just copy its contents. Remember to keep the contents of the package current.


3.1.2 Review Outputs of Project Planning (High Level) - PIP

Before formally beginning Project Planning, the Project Charter and all components of the Project Initiation Plan should be reviewed. This is a checkpoint process to recap what has been produced so far and analyze what will most likely be refined as Project Planning takes place. It is especially useful for any new members joining the team at this time. The review of materials may spark innovative ideas from new team members since they bring different and varied experiences to the project.


3.1.3 Kick Off Project Planning (Detail Level)

As was the case for Project Planning (High Level), a meeting is conducted to kick off Project Planning (Detail Level). At this meeting the Project Manager presents the main components of the Project Initiation Plan for review. Suggested items on the agenda to highlight during the Project Planning (Detail Level) kick-off include:

The goal of the kick-off meeting is to verify that all parties involved have consistent levels of understanding and acceptance of the work performed to date and to validate and clarify expectations of each team member in producing Project Planning (Detail Level) deliverables. Attendees at the meeting should include the Project Manager, Project Team, Project Sponsor and/or Project Director, and any other Stakeholders with a vested interest in the status of the project.

As in Project Planning (High Level), the Project Sponsor and/or Project Director should reinforce his/her support for the project and the value it will provide to the organization. The Project Manager should also be sure one of the Project Team members in attendance is designated as the scribe for the session, to capture pertinent project decisions, issues, and action items. Following the session, the information captured should be compiled into meeting minutes to be distributed to all attendees for review and approval. Meeting materials should be added to the project repository.

3.2 Develop Detail (Baseline) Project Plan




Remember that the Triple Constraints are Scope, Budget, and Schedule. During Project Planning (High Level), the Project Team created the Project Initiation Plan, a set of formal documents defining the project and how its desired outcome(s) will be reached. During Project Planning (Detail Level), each section of the project plan will be refined as more information becomes known about the project. The scope, budget, and schedule are not static; some of the components will continue to change throughout the life of the project.

It should be noted that detail project planning occurs in parallel with other project-specific tasks. Project Execution and Control tasks are not put on hold while the Project Team waits for the plan to be finalized. In fact, the execution of project-specific tasks usually provides additional information necessary to further elaborate the planning efforts.

The purpose of the Develop Detail Project Plan process is to use additional knowledge about the product to be produced during the course of the project, and the approach to be taken to produce the product to:

When refining the project plan, the Project Manager should create a revised version of each document while maintaining the integrity of the original documents. This will provide an audit trail as to how scope, schedule, and cost have evolved throughout the project management lifecycle.


Tasks associated with Develop Detail (Baseline) Project Plan


3.2.1 Confirm Customer Requirements

It is important to remember that refinements to the Project Scope must include discussions and interviews with the Customer and other appropriate Stakeholders. The scope document, therefore, will reflect a mutual agreement between all parties, which is more likely to ensure that agreement and buy-in are achieved.

A clearly defined Project Scope is critical to the success of a project. Without a clear definition, increased project work, rework time, and lower team productivity are almost certain to result. During Project Planning (High Level), a scope statement was written to document a basic description of the project and its deliverables (see Appendix: Project Initiation Plan.). Refining the Project Scope breaks deliverables into smaller pieces of work, allowing the scope and the existing project budget, schedule, and quality measurements to be more accurately defined. Where the initial Project Scope statement highlighted the deliverables to be produced in support of the desired project outcome, the revised Project Scope must go one step further. Using the information learned during Project Planning (High Level), and based upon input gained by communicating regularly with the Customer and other appropriate Stakeholders, the Project Team must refine the scope statement to clearly define each deliverable including exact definition of what will be produced and what will not be produced.

The nature of the specific line of business associated with the product of each project defines the specific work that must be done to refine its Project Scope. For example, for building construction projects, architectural drawings will be completed; for application software projects, detailed requirements definition and design will be completed.

Anything that may limit the options the team has to perform the work required by the project may be important to consider when refining the Project Scope. Examples of constraints are a fixed project end date or the result of a legislative decision outside the Project Teams control. Any information learned about the project during Project Planning (High Level) should have been recorded. Both formal deliverables and less formal documents such as status reports, memos, and meeting minutes will be of assistance to the Project Team in revising the scope definition.

While updating the Project Scope, the Project Manager and Customer must consider the effect the updates may have on the organization, anticipate impacts, and communicate them proactively to the user community. As in Project Initiation, selling the positive aspects of the project, the benefits of its product, and the value of changes to the scope during the entire duration of the project will facilitate acceptance down the road.

Once again, communication between the Project Manager and the Customer is crucial in creating a scope document that clearly reflects what the Customer needs and ensuring a mutual agreement between all parties. If the Project Scope is not accurately described and agreed upon, conflict and rework is almost certain to occur.


3.2.2 Decompose the Work Breakdown Structure (WBS)

The Project Initiation Plan developed during Project Planning (High Level) included a list of key deliverables and milestones. To develop the detail project plan, this must be decomposed to produce a list of deliverables that organizes and defines the total work to be accomplished in the project. Work not in the Work Breakdown Structure (WBS) is outside the scope of the project.

For each of the major deliverables in the project, the work is subdivided into smaller, more manageable components until the deliverables are defined in sufficient detail to support development of project activities (planning, executing, controlling, and closing). Constituent components of each deliverable should be described in terms of tangible, verifiable results to facilitate performance measurement. Tangible, verifiable results can include services as well as products.

Each item in the WBS is generally assigned a unique identifier; these identifiers can provide a structure for a hierarchical summation of costs and resources. A typical numbering system is exemplified by this Guidebook, where section 3 is subdivided into 3.1, 3.2, and so on; section 3.1 is subdivided into 3.1.1, 3.1.2, and so on until the decomposition has been carried as far as is needed. The items at the lowest level of the WBS are referred to as work packages. The figure below shows a sample Work Breakdown Structure.

Questions to ask to determine if each deliverable has been broken down sufficiently are:

If the answer to any of these questions is No, that particular component needs to be further broken down. This decomposition exercise assists project staff to better understand and properly document the Project Scope. It also provides information needed for Project Schedule and budget revision.

You probably will not have sufficient information to break each and every component down into excruciating detail, especially if your project spans a long period of time. How can you predict the amount of work required to produce a deliverable that is scheduled to begin two years from now? You can't.

You can, however, provide an estimate for the entire project at a high level, and should be able to provide accurate detail for the level of work required for the next 3 to 6 months. Describe the entire project to the level of detail you currently understand. Remember, as the project progresses, you will gain the information you need to break components down and provide estimates for the NEXT 3 to 6 months!


3.2.3 Determine Activity Sequencing

Once the WBS has been decomposed, the deliverables may be further subdivided into the activities or tasks that are required to produce each deliverable. In this step, the final outputs are described as activities rather than as deliverables. The WBS and the activity list are usually developed sequentially, although they may be done concurrently. In using the WBS to identify which activities are needed, the project team may identify missing deliverables, or may determine that the deliverable descriptions need to be clarified or corrected. Any such updates must be reflected in the WBS and related documents such as cost estimates.

Once the activity list is complete, the activities to produce each component can be sequenced. Activity sequencing involves identifying and documenting logical relationships between project activities. Activities must be sequenced accurately to support later development of an achievable schedule. Some activities may also have external dependencies that involve a relationship between project activities and non-project activities. For example, an activity may be dependent on delivery of materials from an external source.

Logical relationships between activities include:

  • Finish-to-start

The initiation of the work of the successor depends on the completion of the work of the predecessor (most common)

  • Finish-to-finish

The completion of the work of the successor depends on the completion of the work of the predecessor

  • Start-to-start 

The initiation of the work of the successor depends on the initiation of the work of the predecessor

  • Start-to-finish

The completion of the successor is dependent on the initiation of the predecessor (rarely used)

Dependencies may be based on a work requirement (the output of one activity is needed as the input to a successor activity), a resource availability (a particular piece of equipment is required), or an external requirement (delivery of materials is scheduled for a given date). Avoid sequencing activities based on assumed work assignments (one Team member will do both of these activities), as this will make it difficult to manage resources later in the project. The Project Manager must recognize:


3.2.4 Plan for Resources

Resource planning involves determining what physical resources (people, equipment, materials) and what quantities of each should be used and when they would be needed to perform project activities.

To effectively perform the activities required to produce project deliverables, Project Team members must have appropriate levels of skill and knowledge. It is the job of the Project Manager to evaluate the skills of team members and determine whether or not they meet the current and future needs of the project. It is important to remember that there are many kinds of skills, some technical and others soft skills, such as management, presentation, and negotiation skills. If it is determined that the team needs training, the Project Manager must include training in the Project Schedule and Project Budget. Some skills can be learned on the job, some can be learned through informal mentoring, some can be learned using computer-based courses, and others may require formal classroom training.


3.2.5 Determine Activity Duration

The Activity Duration is estimating the number of work periods that will be needed to complete each activity. Using the Project Scope revised in task 3.2.1 and the Work Breakdown Structure refined in task 3.2.2, and knowing the resources defined in task 3.2.4 will provide input for developing durations that will then be input into the schedule.

A good rule of thumb to follow is the eighty-hour rule: if the task requires more than two weeks duration to complete, it should be broken down further. This provides a solid basis for estimating level of effort, task planning, assignment of work, and measurement of performance in Project Execution and Control. Use of the eighty-hour rule not only greatly facilitates scheduling, but also lays a foundation for accurate tracking of actuals; reporting on progress is reduced to an objective, binary mode: each task (and its deliverable) is either done or not done.

On smaller projects this rule may not make sense, but you could use a rule that says a task using more than 5% or 10% of the project time should be broken down further.

On smaller projects a Project Manager works directly with Project Team members to obtain individual input on effort estimates. On larger projects with multiple components, the Project Manager most likely relies on the input of Team Leaders or individuals who are expert in the specific subject areas. In either case, the Project Manager should gain input from individuals who will actually perform the work or who have performed similar work in the past. This will not only make the effort estimates more accurate, but will help generate excitement and buy-in from the Project Team, as they will feel more a part of the process.

Estimating the time to complete an activity is directly influenced by the capabilities of the individual assigned to perform it. The skill level of each person on the team should, therefore, be considered when doing effort estimates. A good practice is to base estimates on an assumed level of skill. This will allow the Project Manager to adjust his/her estimates up or down when the actual team is in place and the exact skill levels are known. It is imperative that all assumptions used in estimates are documented.

An experienced Project Manager also takes into account absenteeism, meetings, discussions, and staff interaction. A successful schedule builds in reality factors. Specific team members may have ongoing responsibilities occupying a portion of their time, and this must be factored into the schedule. Once effort estimates have been determined for each activity, the Project Schedule must be revised to reflect them. Any revisions or refinements that were made to the Project Scope will directly affect the Project Schedule and must be reviewed and incorporated into the schedule as needed.

Activity duration must also take into account:

Management Techniques for Activity Duration Estimating:

    • Expert Judgment - Durations are often difficult to estimate due to a number of factors. Expert judgment along with historical information should be used whenever possible. Consult with past managers of similar projects to gain their perspectives on the actual time/costs to produce their projects outcomes. Solicit input from past Project Team members to gain insight into the actual time required to perform similar project tasks. If such expertise is not available, the estimates are inherently uncertain and risky.

    • Analogous estimating - Also called top down estimating, this means using the actual duration of previous, similar activity as the basis for estimating the duration of a future activity. (It is a form of expert judgment.)

    • Quantitatively based durations - The quantities to be performed for each specific work category can be used.

    • Reserve time (contingency) - Project teams may choose to incorporate addition time frame if they feel there is risk in the estimates. This can later be reduced or eliminated once more precise information is available. This should be documented along with assumptions.

Once the schedule has been revised to include tasks, effort estimates, resources, and dependencies, the Project Manager should study the schedule to determine its critical path. The critical path is the sequence of tasks in the schedule that takes the longest amount of time to complete. If any task on the critical path is delayed, the entire project will be delayed.

It is possible to have more than one critical path! In fact, every path in your Project Schedule can be a critical path if each one takes the same amount of time to complete. Having multiple critical paths is very risky the more you have, the greater the number of tasks that can potentially finish late and delay the project.

A Project Manager can determine the critical path in a Project Schedule by looking at all tasks that run in parallel and computing the total amount of estimated time to complete them. The path that takes the most time to complete is the critical path. Tasks on the critical path that are completed late will delay the project, unless the Project Manager takes proactive steps to finish subsequent critical tasks ahead of schedule. Because of the important relationship between critical tasks and the project end date, the Project Manager must always be cognizant of the critical path and understand how it is affected when changes are made to the Project Schedule.

Work with an experienced Project Manager, if you can, to learn tips and techniques for breaking work down, estimating time required to complete certain pieces of work, and refining the Project Schedule. Someone familiar with the process and the scheduling tools can save a more inexperienced Project Manager a lot of time and frustration!

If experienced Project Managers are not available, consider getting effort estimates from multiple sources, comparing results and estimating the duration based on the multiple inputs. Involving the Project Team in the planning process will not only help ensure estimates reflect reality, but will also help gain team buy-in and acceptance.

Remember - always document any and all assumptions made when deriving estimates or updating the Project Schedule. This audit trail will prove invaluable if you need to retrace your steps down the road or must explain why schedule revisions are necessary!


3.2.6 Create Budget from Estimated Costs

Based on the information now known about the project as a result of Project Planning (Detail) activities, the Project Manager recalculates the budget required to complete project activities and tasks. As with the previous work, all costs must be considered including the cost of human resources, equipment, travel, materials and supplies. In addition, the following project components must be taken into account:

Project Schedule - the schedule created during Project Planning (High Level) has been revised during Project Planning (Detail) to include more detail and greater accuracy regarding project activities, tasks, and durations. This information will be used as direct input to the refined cost budget.

Staff Acquisition the Project Manager must identify additional staffing requirements. Strategies defined in Project Planning (High Level) need to be changed accordingly. Note that if the reporting relationships among different organizations, technical disciplines, and/or individuals have changed in any way, the strategy used to acquire human resources may need to be changed. Also, if the skills required to staff the project are different from those known during Project Planning (High Level), the means by which staff members are acquired could be different. The Project Manager must update the Project Schedule to include all tasks needed to acquire Project Team members.

Resource Requirements and Costs at this point in the project, a more detailed understanding of the resources required to perform the work and their associated costs is most likely known and can be used in refining the budget.

Materials Acquisition the Project Manager must verify whether product requirements have changed since Project Planning (High Level). If changes have occurred, the product acquisition strategies need to be changed accordingly. The Project Manager must update the Project Schedule to include all tasks needed to acquire equipment, materials, and other non-human resources.

Preliminary Budget Estimate also produced during Project Planning (High Level), this spreadsheet should be the place to start to refine information pertaining to the budget. The Project Manager should add to this spreadsheet the more detailed cost estimates for the project defined in the Project Schedule, and revise the hours and cost columns based upon the revised Project Schedule, resource rates and requirements, and cost estimates. The Project Manager can use cost estimating checklists to ensure all preliminary budgeting information is known and all bases are covered.

It is also recommended that you take the time to document a preliminary disbursement schedule. This will help you and the Project Sponsor and/or Project Director understand how the total budget will be expended over the course of the project.

For historical purposes, and to enable the budget to be further refined during Project Execution and Control, the Project Manager should maintain notes on how the budget was revised.


3.2.7 Develop Implementation/Transition Plan

The Project Manager must formulate and document a plan for implementing or deploying the product of the project and for transitioning the responsibility for the outcome of the project from the Project Team to the performing Organization. The Transition Plan must include all the necessary activities to perform and procedures to follow to ensure a smooth and satisfactory hand-off. (See Appendix, CPMM Project Transition Planning Checklist.)

When planning the implementation and transition, the Project Team must consider the impact the resulting product will have on the performing Organization and Consumers. The Consumers must be prepared to use the product and the performing Organization must be prepared to support it.

The Project Manager needs to define and document a plan to implement the product, and should consider:

The Project Manager should define and document a plan to transition the ongoing support of the product to the performing Organization and should consider:

Many otherwise successful projects fail due to a lack of transition planning. Don't let this happen to you!


3.2.8 Develop Quality Plan

The Project Manager and Customer must determine if changes have occurred to the Project Scope, Customer requirements, external standards or regulations, or any other aspect of the project that will affect the quality policy established for each deliverable during Project Planning (High Level). They must ensure that quality standards still meet both Customer requirements and the projects scheduled end dates. If the standards are no longer valid, the quality policy must be changed appropriately to refine existing standards or define additional ones. The quality policy created in Project Planning (High Level) and revised in Project Planning (Detail) becomes part of the updated Quality Plan (see Appendix: Project Quality Plan).

Also during Project Planning (Detail), the Project Manager communicates with the Customer to establish and document all quality activities to be implemented during the course of the project to ensure the defined quality standards will be met. This is called quality assurance. Sometimes quality assurance for specific types of deliverables is performed by a separate Quality Assurance Department. If an organization does not have the luxury of a Quality Assurance Department, the required activities will need to be performed by designated Project Team members or Customers. Examples of quality assurance activities include:

A description of all quality activities to be implemented during the course of the project should be included in the Quality Plan.


3.2.9 Create Project Plan Baseline

A Baseline Project Plan is a project snapshot in time, taken at the conclusion of Project Planning (Detail), against which performance on the project is measured. It is one way the Project Manager can determine if the project is on track. Using an electronic tool (such as MS Project), the Baseline Project Plan (Project Schedule) is captured. Once the baseline version is approved, the Project Manager should revise it only if a change control is approved that results in a change to the schedule. The schedule and budget baseline becomes part of the Project Plan. As the project progresses, subsequent schedules may be compared to the baseline version to track project performance. This also is the start of formal scope change control as defined in Project Planning (High Level)

The Project Initiation Plan becomes the Project Plan (Detail Level) with updated version control.  

If you revise the baseline as a result of change control, be sure to save the original baseline for historical purposes.


Deliverables for Task 3.2 - Develop Detail (Baseline) Project Plan


3.3 Perform Risk Assessment




Risks require continual review and assessment throughout the project management lifecycle. The goals of risk assessment are to predict the likelihood that a risk will occur, to quantify its potential impact on the project, and to develop plans for risk management. Risks documented during Project Planning (High Level) should be reassessed during Project Planning (Detail).

Next, an approach for risk management is developed. Actions can be taken to avoid, mitigate or accept each risk, depending upon the probability of its occurrence and the magnitude of its impact on the project. If a risk event can be anticipated, there should be sufficient opportunity to weigh consequences and develop actions to minimize its negative impacts or maximize its positive ones.

The list of risks created during Project Planning (High Level) is entered into a Risk Management Worksheet (see Figure 3-8, Risk Management Worksheet) and supplemented by any additional risks identified in Project Planning (Detail). Within the worksheet, information is added to describe the risk probability, impact, and the timeframe in which impact may occur. Based on these factors, the priority level of the risk event can be derived. Last, and most important, risk management plans must specify the individuals responsible for the mitigation actions, the timing of the actions to be implemented, and the expected results of the actions.

In addition to quantifying risk probability and impact and formulating risk responses, the risk assessment process facilitates establishment of an agreement for the Project Team, Project Sponsor and/or Project Director, and Customer Representatives to collaborate in managing risks as they arise during the project.


Tasks associated with Perform Risk Assessment


3.3.1 Identify New Risks, Update Existing Risks

The Project Manager must review the list of risks initially identified in the Project Imitation Plan to determine if all risks remain applicable. As a result of Project Planning (Detail Level), the Project Manager and team members should be considerably more knowledgeable about the project and, therefore, better able to recognize and predict risk events.

Through other activities taking place in Project Planning (Detail) specific to Scope, Schedule and Cost, additional risk variables may be introduced to the project. Further refinement of the project scope may uncover areas of concern that were previously unknown. A more detailed schedule may introduce a new level of complexity and interdependencies to the project, possibly producing more risk. More accurately defined staffing requirements may call for resources with unique skills whose availability may be diminishing. These are only a few examples of how risks in a project evolve over time, with the focus shifting from one risk source to another.

The Project Manager verifies the updated list of risks with the Project Team and Project Sponsor and/or Project Director. As in Project Planning (High Level), the Project Manager must consider both internal and external risks, internal risks being those events the Project Manager can directly control (for example, staffing), and external risks, those that happen outside the direct influence of the manager (for example, legislative action).

Once again, data and experiences from previous projects may provide excellent insight into potential risk areas and ways to avoid or mitigate them. If the organization has a list of common project risks, it can be useful to ensure that the Project Manager has considered all potential risk elements in the current list. The Project Manager should update the organizations list as necessary based on the results of the current project.

Draw flowcharts or diagrams to show how elements of a project relate to one another. This can help you anticipate where potential external risk events may occur and develop responses to them.

Solicit input from experienced Project Team members and/or the Project Sponsor and/or Project Director to uncover potential areas of risk and to help you identify what types of risks the Project Sponsor and/or Project Director views as relevant. Jointly identifying and updating the risk variables for a project results in the sharing of risk awareness by all parties involved.


3.3.2 Quantify Risks

The Project Manager and Project Team members evaluate each risk in terms of the likelihood of its occurrence and the magnitude of its impact. Both criteria should be quantified by using: high, medium, or low. These measurements are used as input into the Risk Management Worksheet for further analysis when determining how the risk threatens the project.

There are a number of tools available to quantify risks. The Risk Management Worksheet presented here has been selected for its simplicity and ease of use. More sophisticated tools may be necessary for large-scale high-risk projects.

A factor to be considered when quantifying risks is stakeholder risk tolerance, the threshold to which the organization will assume risk, which is dependent on its attitude toward and motivation for the project. For example, an organization may view a 15% chance of a project overrun as acceptable since the cost benefit for the organization to do the project far outweighs this factor. The Project Managers understanding of the organizations strategic direction and the motivation of the Project Sponsor and/or Project Director and the Customer will help determine the level of risk tolerance for the project.


3.3.3 Update Risk Management Plan

The Project Manager evaluates the results of the previous task to determine an appropriate response for each risk: avoidance, mitigation or acceptance. Each case will require a decision by the Project Team. The Project Manager is then responsible for communicating the steps necessary to manage the risk and following up with team members to ensure those steps are taken.

Management Techniques for Risk Response planning can include four types of responses:

    • Avoidance - Changing the plan to eliminate the risk or condition.

    • Transference - Shift the consequence of a risk to a third party together with ownership of the response. (shifts, but does not eliminate the risk)

    • Mitigation - seeks to reduce the probability and/or consequences of an adverse risk even to an acceptable threshold. Early action is taken to reduce the probability of occurring.

    • Acceptance - Deal with the risk and identify a suitable strategy.

Identifying the risk is good, but planning a wise course of action around it is infinitely better.

Be aware that by addressing one risk, you may be introducing another. For example: you identified a risk that your cost estimates may be off by as much as 15%. Your mitigation plan is to request a 20% increase in funds to cover the increased cost. You may have introduced a new risk, because a red flag may be raised, inviting an audit.

Since each risk may have more than one impact, the Risk Management Plan must describe the actions to be taken to avoid, mitigate or accept each risk impact, including contingency plans. It should also specify the individuals responsible for the mitigation actions or contingency plan execution. Most attention should be directed to those risks most likely to occur, with the greatest impact on the outcome of the project. On the other hand, a conscious decision can also be made by the Project Team to accept or ignore certain risks. These decisions must be documented as part of the Risk Management Plan for subsequent re-evaluations.

Some commonly employed risk mitigation strategies may include:

The frequency with which the Risk Management Plan will be monitored, reviewed and maintained, and the method of communicating progress of risk mitigation actions, must be incorporated in the Project Schedule and Project Plan. At a minimum the Risk Management Worksheet should be reviewed at every status meeting, and updated with each change to the project.

At the end of this task, the Risk Management Worksheet should be complete.

When updating the Risk Management Worksheet, maintain the original. Each revision should be kept to provide an audit trail demonstrating how the risks evolved throughout the project management lifecycle.


Deliverables for Task 3.3 - Perform Risk Assessment


3.4 Refine Management Plans




Most of Management Planning was done during the Project Planning (High Level) and they are documented in the Project Initiation Plan. Now that Project Planning (Detail Level) is underway these plans should be refined and updated as new information is known. Refining the Management Plans includes development of all required management processes and plans for project implementation. All new or updated (refined) management plans are compiled and included in the Project Plan.


Tasks associated with Refine Management Plans


3.4.1 Refine Management Plans defined in the PIP

The Change Control Process and Issues Management and Escalation Process as defined in the PIP must be reviewed and updated as needed. Refine Change Control Process

Every aspect of the project defined during Project Planning (High Level) and Project Planning (Detail Level) has the potential to change. In fact, change should be expected to occur throughout the project; but if an effective change control process is refined and agreed upon during Project Planning (Detail), any change should be able to be handled without negative effect on the project outcome. You should start by reviewing the change process defined in the Project Initiation Plan

Changes to a Project Scope document must be made using a defined change control process. This process was originally defined in the Project Initiation Plan. Formal change control should begin as soon as an agreed detail baseline plan is approved. This process should include a description of the means by which scope will be managed and how changes to scope will be handled. Any refinement to this plan becomes part of the Project Plan. It is vital to document a clear description of how to determine when there is a change in scope to facilitate change control during Project Execution and Control. Documenting how to determine what constitutes change is a difficult process, but one that is critical to the change control management process.

Project change is not defined simply as a change to the scope, budget or end date. Change should be defined as ANY adjustment to ANY aspect of the Project Baseline Plan or to ANY already approved deliverable(s). This includes anything formally documented in the Project Charter, Project Initiation Plan and subsequent Project Plan, or any deliverable produced during the course of the project.

The Project Manager and Customer Decision Maker must agree on the change control process, which then must be formalized, documented, and updated in the Project Plan. Items that must be defined are:

Should you advise your Project Sponsor and/or Project Director to set up a change budget set aside a pot of money (10 to 20% of the project total) for unforeseen eventualities? Let's see. Does your Project Sponsor and/or Project Director enjoy going to the well time and time again to ask for additional funds? Do you enjoy writing justifications and groveling repeatedly? Enough said.
 Refine Issue Management and Escalation Process

Issue management involves capturing, reporting, escalating, tracking, and resolving problems that occur as a project progresses. A process must be in place to manage issues, since they can potentially result in the need for change control and can become major problems if not addressed. At this stage of the project the Issues Management processes should be reviewed as they were defined in the Project Planning (High Level) Project Initiation Plan, and refined and agreed upon between the Project Manager and Project Sponsor and/or Project Director . This process should be updated in the Project Plan and communicated to the team:



3.4.2 Refine Communications Plan

A preliminary Communications Plan was developed for inclusion in the Project Initiation Plan during Project Planning (High Level), and describes how communications will occur (see Appendix: CPMM Communications Plan). As a project progresses, certain events may occur to alter the way information is accessed or change communication requirements. For example, a department may move to a new building, allowing users access to email for the first time. Or a change in personnel may dictate a change in the frequency of communications. During Project Planning (Detail) and subsequent work, the Project Manager should review the Communications Plan with the Project Team to be sure it is still viable. If it is determined that any portion of the plan is no longer applicable, the Project Manager must develop appropriate revisions to the plan.

Also, at this point in the project, sufficient information is most likely known to allow the Project Manager to describe in further detail what the distribution structure will look like. Part of the Communications Plan describes how communications will be managed. Depending on the project, communications management may be very informal or highly sophisticated. When deciding how to manage communications on a project, a Project Manager solicits information from the Project Team and Stakeholders and together they decide:


Sometimes communications break down. To try to avoid these disconnects, you should:

  • Be as concise and clear as possible in both written and verbal messages.

  • Solicit feedback to determine if your messages have been received by the appropriate parties and interpreted correctly.

When there are problems, try to learn from them so that you can do better in the future.

Information requiring communication comes from different sources. Sometimes it is already documented in hard copy or electronic form, but sometimes it is conveyed during formal meetings, informal gatherings, or simple conversations. The Project Manager must be aware this information exists and prepared to convey it using the communications management system. Some sources of project information that may require communication include:

Conducting a status meeting regularly with your Customer is a great habit to adopt. If you plan to discuss a certain subject area during the meeting, don't be afraid to invite members of the Project Team with expertise in that area. It's also not a bad idea to invite other Stakeholders who have something constructive to contribute. Use the status report to drive the meeting discussion points (see Appendix: Project Status Report). Remember, there can never be TOO MUCH communication!


3.4.3 Define Organizational Change Management Plan

When planning the project, the Project Manager and Customer must consider the impact the resulting product will have on the performing Organization. The organization must be prepared to accept and use the product once it is implemented.

The Project Manager needs to define and document a plan to manage the changes to the organization that could occur as a result of implementing the product. This Organizational Change Management Plan becomes part of the Project Plan. Organizational change management must be explicitly planned if it is to be effective. In some large projects at Cornell, there is a specific Campus Readiness sub-team that will plan for and manage these activities.

Items to include as part of an Organizational Change Management Plan are:

In cases where implementing a project will result in a significant change to the way an organization will conduct business, the Project Manager, Campus Readiness Team Lead, Steering Committee and Project Sponsors and/or Director must be able to anticipate when and how the major impacts will occur, and plan for the specific activities that will adequately prepare the performing Organization.


Deliverables for Task 3.4 - Refine Management Plans

At the end of Project Planning (Detail), the Project Plan should contain the following:


3.5 Confirm Approval to Proceed




The purpose of this process is to formally acknowledge that planning activities have been completed and that all deliverables produced during Project Planning (Detail) have been completed, reviewed, accepted, and approved by the Project Sponsor and/or Project Director. Formal acceptance and approval also signify that the project can continue into Project Execution and Control.

The acceptance and approval process is ongoing. As changes are made during Project Planning (Detail), the Project Manager should be in constant communication with the Project Sponsor and/or Project Director. Keeping the lines of communication open will avoid a situation where a Project Sponsor and/or Project Director is surprised by a deliverable.

In addition, the Project Manager should review the interim deliverables or work products for each process with the appropriate Customer Decision-maker upon their completion and gain approval before moving on to the next process. These interim acceptances should streamline the final acceptance process.


Tasks associated with Confirm Approval to Proceed


3.5.1 Prepare Formal Acceptance Package

The deliverables from Task 3.5 need to be physically assembled into a single package that is described as the Project Plan or Project Plan (Detail Level). This contains an up-to-date version of all of the documents that fully describe the work to be done, the schedule, the estimated cost, and the management processes for the project.

At the end of Project Planning (Detail), the Project Manager and Project Sponsor and/or Project Director should review the Business Need that was developed during Project Initiation and revised during Project Planning (High Level). Because more information is now known about the project, the Business Need may need to be refined. Any refinements should be made before proceeding to Project Execution and Control.

Many of the documents will be updated during Project Execution, but a copy needs to be archived as the Baseline Project Plan for later use in reporting and for post-project analysis to improve the Project Manager's and the organization's ability to plan projects.


3.5.2 Submit Detail Project Plan for Approval

The Project Manager should schedule a meeting to discuss the Detail Project Plan and gain agreement to secure Project Execution and Control resources. Meeting attendees should always include the Project Sponsor and/or Project Director and the members of the Steering Committee whose resources will be affected. Attendees may also include other key stakeholders who are able to provide resources that will add value during Project Execution and Control.

Copies of the Project Plan (Detail Level) should be sent to all attendees in advance of the meeting. During the meeting, resources are formally secured by gaining the signatures of the appropriate performing Organization managers on the Project Deliverable Approval Form.

In addition to reviewing the Business Need all deliverables produced during Project Planning (Detail) should first be reviewed by the Project Manager to verify that Customer Decision-maker approval has been obtained. If approval is not clear and explicit, the Project Manager must pursue it again. When the review has been completed, the Project Manager should organize the deliverables into a cohesive deliverable package and prepare a formal approval form.


3.5.3 Gain Approval Signature from Project Sponsor and/or Project Director

Before gaining an approval signature, the Project Manager must review the revised Business Need with the Project Sponsor and/or Project Director. Based upon changes to the Business Need and policies within the Performing Organization, the Project Sponsor and/or Project Director must decide if a project re-approval cycle is warranted. If project re-approval is necessary, the Project Manager should ensure the appropriate Project Origination processes are followed. At this point in time, the Project Sponsor and/or Project Director may decide to terminate the project. This decision may be based upon factors outside the control of the Project Manager (that is, the organization may have new priorities that are in direct conflict with the project or increased risk may have been introduced to the project.) Or it is possible that, having done more detailed planning, the costs of doing the work are greater than initially estimated and outweigh any project benefits. Realistically, termination of a project could happen at any point during the project. The Project Manager must be comfortable and confident enough to approach the Project Sponsor and/or Project Director at any time during the course of the project if he/she feels the project has reached a point where termination is the best possible solution.

At the end of this task, the Project Manager must present the acceptance package to the Project Sponsor and/or Project Director and obtain his/her signature, indicating approval to proceed to Project Execution and Control. If the Project Sponsor and/or Project Director does not approve the package, he/she should indicate the reason for rejection. The Project Manager is then responsible for resolving issues with the deliverables and presenting the updated package to the Project Sponsor and/or Project Director.

Sometimes a Project Manager needs to gain approval of a large number of deliverables at the same time. The Project Plan is a good example, as it comprises several very important (and sometimes very complex) documents. Should the Project Sponsor and/or Project Director become overwhelmed by the number or volume of documents requiring his/her attention, the Project Manager should take steps to work with the sponsor to streamline the Acceptance Management Process (See Task 3.5.2).


Deliverables for Task 3.5 - Confirm Approval to Proceed


 Continue to next section: