Project Sponsor and/or Project Director
Project Team Members
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).
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:
All relevant project information from Project Initiation and Project Planning (High Level)
Organization charts for the Project Team and performing Organization
Information on project roles and responsibilities
General information about the Customer and performing Organization
Logistics (parking policy, work hours, building/office security requirements, user id and password, dress code, location of rest rooms, supplies, photocopier, printer, fax, refreshments, etc.)
Project procedures (team member expectations, how and when to report project time and status, sick time and vacation policy)
Orientation sessions can be held for new members to ensure that they read and understand the information presented to them.
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.
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.
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:
Introduction of new team members
Roles and responsibilities of each team member
Restating project background and objective(s)
Most recent Project Schedule and timeline
Current project status, including open issues and action items
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.
See Appendix: CPMM Detail Planning Kick-off Agenda
Project Sponsor and/or Project Director
Project Team Members
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:
Confirm the Customer Requirements and improve the definition of the Project Scope.
Break down the work to the level of detail you plan to manage the project and refine the Project Plan by more accurately defining and sequencing project activities, determining the dependencies among them, estimating their durations, and assigning resources to them. The schedule will need to be adjusted according to the approach that will be used to produce the product and the availability of resources.
Improve the understanding and definition of the processes and standards that will be used to measure quality during Project Execution and Control.
Refine the appropriate approaches for staff and product acquisition defined during Project Planning (High Level), implement the plans, and more accurately define the budget required to produce the desired outcome of the project. The project budget will be affected based upon the approach that will be used to produce the product and the availability of resources.
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.
3.2.4 Plan for Resources
3.2.8 Develop Quality Plan
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.
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:
Am I able to clearly define the component?
Am I able to clearly state what will be done to complete the work and what will NOT be done?
Am I able to estimate the time needed to complete the component?
Am I able to assign an individual or organizational unit who will be responsible for completing the work?
Am I able to assign a dollar value to the cost of completing the work?
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!
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:
The initiation of the work of the successor depends on the completion of the work of the predecessor (most common)
The completion of the work of the successor depends on the completion of the work of the predecessor
The initiation of the work of the successor depends on the initiation of the work of the predecessor
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:
Mandatory dependencies - those dependencies that are inherent to the type of work being done. They cannot and will not change, no matter how many individuals are working on a task or how many hours are allocated to a task (e.g., the frame of a building cannot be built until the foundation is in place). The Project Manager must recognize mandatory dependencies since they will dictate the way certain activities will need to be structured.
Discretionary dependencies - those dependencies that are defined by the Project Team or Customer that force the Project Manager to schedule tasks in a certain way. For example, the Project Team may be required to use an in-house best practice to complete an activity that forces other activities to be completed in a specific sequence.
External dependencies - outside the realm of the project or outside the control of the Project Manager or Customer, these dependencies may direct how portions of the project schedule must be defined. For example, a project activity may be dependent upon an outside vendor delivering a piece of equipment. This is something neither the Project Team nor the Customer can control, but it must be defined and considered.
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.
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:
Calendars - the hours and days when project work is allowed, including seasonal restrictions, holidays, labor contract restrictions, and vacation or training schedules.
Constraints - completion dates for project deliverables mandated by the Project Sponsor and/or Project Director, Customer, or other external factors, which will most often be known early in the project. Additionally, there may be financial, legal, or market-driven constraints that help dictate a projects timeline.
Elapsed Time - estimating must take into account elapsed time, for example, if concrete curing will require four days of elapsed time, it may require from two to four work periods, based on a) which day the week it begins, and b; whether or not weekend days are treated as work periods. Most automated scheduling software will handle this problem.
Management Techniques for Activity Duration Estimating:
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!
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.
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:
What needs to be done to ensure the organization will be ready to receive the product. These steps may include acquiring the necessary physical space, installing appropriate software, obtaining the appropriate building permits, etc.
How and when the Customer will test and accept the product and confirm and authorize its implementation.
The steps to be taken to ensure Consumers will be ready to use the product once it is transitioned. These steps must be coordinated with the Organizational Change Management Plan, and will include training and orientation on the use of the product. They also may include plans for training Customers or Consumers as trainers for the future. The plan must define which of the Customer(s) require training, the level of training necessary, who will provide the training, and when it will occur.
The appropriate strategy for implementing the product into the performing Organization, given the specific Consumers and Customers. For example phased in by location, phased in by specific product functionality, big bang, etc.
The Project Manager should define and document a plan to transition the ongoing support of the product to the performing Organization and should consider:
The people from both the Project Team and the performing Organization who need to be involved in the transition, and their associated roles and responsibilities. Examples include Customers, Consumers, and members of other specific support units within the Performing Organization.
The steps that should be taken to ensure that the appropriate individuals are ready to support the product once it has been implemented and is in use. This may include negotiating with various internal organizations to determine the appropriate timing of the transition of responsibility, assigning specific organizations and individuals to support the specific products, and providing necessary training.
The relationship between the implementation plan and the transition plan. The Project Team and the performing Organization must agree on the point in implementation at which the performing Organization takes responsibility for production problems, help or trouble calls, and for resolving the problems.
The performing Organizations expectations regarding any documentation that is required as part of transition.
Many otherwise successful projects fail due to a lack of transition planning. Don't let this happen to you!
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:
Collecting project documentation
Verifying business requirements
A description of all quality activities to be implemented during the course of the project should be included in the Quality Plan.
See Appendix: CPMM Quality Plan
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.
Project Plan (Detail Level) - an updated version of the Project Initiation Plan (renamed Project Plan) as each task in Project Planning (Detail Level) is completed (includes the Baseline Project Schedule), This is the document that describes in detail the project boundaries, including defining the deliverables: how they will be produced, who will produce them during the course of the project, and the means by which changes to the deliverables will be identified and managed. This is a picture in time and once approved is the baseline by which scope changes and performance will be managed. The document continues to be refined throughout the project as new information is known.
Baseline Project Schedule - a revised, definitive representation of activities, durations, dependencies, resources and milestones, to the level understood at this point in the project lifecycle. The Baseline Plan has multiple uses. It is both a task list for further planning if necessary and a structure for reporting status during Project Execution and Control. As individual tasks are completed, the project progress can be assessed. It also serves as a useful management communication tool by which results can be compared with expectations. Because it is critical to the success of the project going forward, the baseline plan must be reviewed and accepted by both the Customer and the Project Team during Project Planning (Detail). This is a picture in time and once approved is the baseline which scope changes and performance will be managed. The document continues to be refined throughout the project as new information is known.
Transition Plan - a detailed plan to move the project from development to steady state. This should identify any transition team, the time line and tasks, any training requirements, transition deliverables, documentation requirements, and production support requirements. This can be part of the Project Team Baseline Schedule or if managed by a separate team, may have its own project schedule. If separate, then the dependencies between the two plans must be maintained.
Quality Plan - the quality policy defined during Project Planning (High Level) and refined during Project Planning (Detail) becomes part of the Quality Plan. The Quality Plan will be expanded during Project Execution and Control and is included as part of the Project Plan. (See Appendix: Project Quality Plan.)
Budget - a revised, more accurate estimate of the dollars required to complete the project. It includes the cost of all required human resources, equipment, travel, and supplies, and the anticipated timing of expenditures.
Project Sponsor and/or Project Director
Project Team Members
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.
3.3.2 Quantify 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.
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.
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:
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:
Procurement - some risks can be mitigated through procurement. For example, if the project requires staff with particular skills it may be advisable to retain resources through an outside organization. Unfortunately, this may introduce other risk factors such as the resources unfamiliarity with the organization.
Performance Bond or Penalties - some organizations may opt to introduce insurance to the project in order to address some of the risk. This holds true especially for those project services being supplied by external vendors through a contract.
Resource Management - it may be beneficial to leverage a lead resource that has already worked on a project with similar characteristics by assigning that resource as a mentor to more junior team members. This will mitigate delays in the schedule due to the learning curve of more junior resources.
Use of Best Practices / Lessons Learned - some organizations already have repositories of project specific or business function best practices, which may help you to prepare for unanticipated risks. Taking advantage of other project best practices, whether they are process or tool based, will help to mitigate risk. Implementing processes that have worked successfully on other projects will save time.
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.
Risk Management Worksheet - An updated record of risk variables, impact, probability, date of impact, level of priority and risk response actions. The review and update cycle for risk assessment should be built in to the Project Plan (Detail Level).
Project Sponsor and/or Project Director
Project Team Members
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.
The Change Control Process and Issues Management and Escalation Process as defined in the PIP must be reviewed and updated as needed.
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:
Identification of the individual(s) authorized to request a change.
Identification of the person responsible for analyzing the request to understand its impact on the Triple Constraints (Project Budget, Scope, Schedule), and Quality, as well as the Customer Representative who has authority to approve the request. The Project Manager should never give the Project Team the go-ahead to begin work until a change request form has been signed by the Customer Decision-maker (see Appendix: CPMM Internal Change Order). It should be noted that the impact to the Project Schedule must take into account time spent to analyze the change request. The Project Manager should use the Change Log to track all changes and a status of each change: Proposed, Authorized, Denied, Deferred (see Appendix: CPMM Change Log).
The timeframe (number of business days) allowed for a change request to be approved or rejected by the Customer. It is important to document the fact that approval or rejection by default is not permitted, so acceptance or rejection cannot be assumed if there is no response to a submitted change request.
The process to follow if no timely decision on approval or rejection of a change request is made. The Project Manager should follow up with the person to whom it was submitted to determine why the change request has not been processed. If its identification as a change is disputed, the situation should become an open issue in the Project Managers status report. The Project Manager should attempt to negotiate a compromise, but, if there is no resolution, executive intervention may be required.
The percentage of the overall Project Budget that has been reserved for project changes. It is important to pre-determine a change budget to prevent project work from being interrupted while funds are secured to do the work.
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.
See Appendix: CPMM Change Order (Internal)
See Appendix: CPMM Request for Change Log
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:
How issues will be captured and tracked many Project Managers make use of some type of repository to ensure that issues are not lost. This repository may be either electronic or manual, depending upon the needs and size of the project. At a minimum, an issue repository must contain a description of the issue, its potential impact, the date it is recorded, its anticipated closure date, its priority, and the name of the person responsible for resolving it or getting it resolved. The due date for closure must be a specific date (that is, the date cannot be "ASAP"). The responsible party must be a specific individual, not a functional group that is, an issue should not be assigned to the IT Department). As progress occurs on the resolution of an issue, the Project Manager should update the issue repository to reflect what has occurred. An issue log (whether electronic or paper-based) should be updated regularly, possibly as often as daily depending upon the needs of the project and issue resolution progress (see Appendix: CPMM Issues Log).
How issues will be prioritized the characteristics about the issue that will determine whether its resolution will be a high, medium or low priority. Impacts to the schedule, level of effort, or cost are usually the factors that determine the priority.
How and when issues will be escalated for resolution whether they will be escalated if they are not resolved in a given period of time or when a delivery date is missed or only when the Project Budget is severely affected. Whatever the decision, details of the escalation process need to be clearly stated. It is also vital to document to whom issues will be escalated.
See Appendix: CPMM Issues Log
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:
How project information will be collected and stored, and what procedures will be followed to disseminate the information. If an electronic filing structure will be used, someone must be responsible for its setup and maintenance. Information access should be defined.
The distribution structure, specifically detailing what, how, and when information will flow to internal and Stakeholders. For Stakeholders, communication channels currently established in the organization should be used. For Stakeholders, different channels may be required for each discrete Stakeholder group. The team must decide when it should occur, what information should be communicated, and how it should be delivered. The distribution structure for Stakeholders must take into account how the particular Stakeholder group will be affected by this project.
The method by which information will be accessed if it is needed between regularly scheduled communications.
See Appendix: CPMM Communication Plan
Sometimes communications break down. To try to avoid these disconnects, you should:
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:
Steering Committee Meetings
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!
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:
People - The plan must consider how the individuals using the product will be affected by its implementation. The organization may initiate reductions or expansions in the workforce, and shift rote clerical activities to automated processing; and decision-making power may be distributed further down the chain of command. If specific job duties are being added or removed, staff reductions or increases are anticipated, or the organizational structure itself will change, the plan must identify the steps to be taken. For example, the human resources manager in the performing Organization must be involved in planning for and performing many of these change management tasks. Labor/management committees, union representatives, may all need to be included in planning for such changes, depending on the scope of the changes.
Process - The plan must consider how the product of the project will affect already existing business processes in the performing Organization. Business processes may take advantage of streamlined workflows to reduce the flow of paper, or technology advances may enable electronic communications to more quickly deliver information. Procedures will need to be redesigned to align with the change. The new procedures may effect changes in the way the performing Organization develops, documents, and trains staff, and must be addressed in the Organizational Change Management Plan.
Culture - The plan must consider how severe the projects culture shock will be. The Project Manager, Campus Readiness Team Lead, Steering Committee, and Project Sponsors and/or Director must determine how much the project will affect the performing Organizations business strategy, established norms for performance, leadership approach, management style, approach to Customers, use of power, approach to decision making, and the role of the employee. Plans might include performing an assessment of the performing Organizations readiness for change, and include development of action plans to increase the organizations readiness and ability to adapt to change through education and training.
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.
Project Plan - the revised Project Plan (see Appendix: Project Initiation Plan) which will include a detailed baseline schedule is the main deliverable of Project Planning (Detail), incorporating the revised outputs of all other Project Planning components. The document should now be thorough and accurate enough to be used as the main guide to follow during Project Execution and Control. It is important to remember that the plan will continue to be revised throughout the course of the project.
At the end of Project Planning (Detail), the Project Plan should contain the following:
Goals and Objectives
Baseline Project Schedule
WBS (Decomposed to the level the project will be managed)
Effort and Duration Estimates
Project Schedule (Detail)
Stakeholder Roles and Responsibilities
Change Control Process and Change Log
Organizational Change Management Plan
Issue Escalation and Management Process and Issues Log
Project Implementation and Transition Plan
Risk Management Worksheet
Project Sponsor and/or Project Director
Project Team Members
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.
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.
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.
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).
Project Plan (Detail) - a compilation of all components of the Project Plan packaged into a comprehensive plan for the remainder of the project.
Signed Project Deliverable Approval Form - a formal document indicating Project Sponsor and/or Project Director acceptance and approval to move to Project Execution and Control.