Seven Components to a Risk Management Plan

Seven Components to a Risk Management Plan

The Risk Management Plan describes how you will define and manage risk on the project. This document does not actually describe the risks and the responses. This document defines the process and techniques you will use to define the risks and the responses. The information in this plan includes:

  • Roles and responsibilities. This section describes the leading and supporting roles in the risk management process. The project manager typically has overall responsibility for risk management, unless the team is large enough that this role can be delegated to another team member – perhaps a specialist. Third-party risk management teams may also be able to perform more independent, unbiased risk analyses of project than those from the sponsoring project team.
  • Budgeting. Discuss your budget for risk management for the project. Since you may not know enough to request budget for risk management you can also describe the process that you will use to determine a risk management budget estimate.
  • Timing. Defines when the initial risk assessment will be performed, as well as how often the risk management process will be conducted throughout the project life cycle. Results should be developed early enough to affect decisions.
  • Scoring and interpretation. You should define risk scoring and interpretation methods appropriate for the type of the qualitative and quantitative risk analysis being performed. Methods and scoring must be determined in advance to ensure consistency.
  • Thresholds. The threshold level is how you determine which risks are important enough to act upon.  The project manager, client, and sponsor may have a different risk threshold. The acceptable threshold forms the target against which the project team will analyze risks.
  • Communication. Describe how the information on risk will be documented and communicated. This includes the risks themselves, the risk responses and the risk status.
  • Tracking and Auditing. Document how all facets of risk activities will be recorded for the benefit of the current project, future needs, and lessons learned. Also describe if and how risk processes will be audited.

Five Project Management Mistakes

Five Project Management Mistakes

Mistake #3: Not Keeping Schedule Up-to-Date

Many project managers create an initial schedule but then don’t do a good job of updating the schedule during the project. There are trouble signs that the schedule is not being updated.

  • The project manager cannot tell exactly what work is remaining to complete the project.
  • The project manager is unsure whether they will complete the project on-time.
  • The project manager does not know what the critical path of activities is.
  • Team members are not sure what they need to work on next (or even what they should be working on now).

It is a problem when the project manager does not really understand the progress made to date and how much work is remaining. When this happens, the project team is not utilized efficiently on the most critical activities.

There are a couple other common scheduling problems.

  • Infrequent updates. Sometimes the project manager updates the schedule at lengthy intervals. For instance, updating the schedule every two months on a six-month project. This is not often enough to keep control of the schedule. The schedule should be updated every week or two.
  • Managing by percent complete. All activities should have a due date. As you monitor the work, keep focused on whether the work will be completed by the due date. It is not very valuable to know that an activity is 70% completed. It is more valuable to know if the due date will be hit.
  • Assigning activities that are too long. If you assign a team member an activity that is due by the end of the week, you know if the work is on-track when the week is over. However, if you assign someone an activity that does not need to be completed for eight weeks, you have a long time to go before you know if the work is really on schedule. Keep the due dates within a reasonable timeframe. 

It is not easy to catch up a schedule once the project is started. Typically, by the time you realize you need to update the schedule, your project is already in trouble. Updating the schedule at that point only shows how much trouble you are in. The much better approach is to keep the project up-to-date, and ensure that it contains all of work necessary to complete the project. 

Be Proactive Managing a Project with Unrealistic Budget

Be Proactive Managing a Project with Unrealistic Budget

If you are a project manager dealing with what you perceive to be an unrealistic budget, the first thing you will want to do is discuss this with your sponsor to see if there are any factors that are driving the project budget. For instance, there may be budgetary restrictions. If you are a vendor, it is possible your sales people committed to a fixed price for the project. In some cases your manager or sponsor might set an arbitrary budget without much justification. It does not necessarily make your challenge any easier, but you may find that by better understanding the reason for the fixed budget, you may have an easier time getting yourself and your team members motivated to achieve it. When you have a full project management methodology you will have tools and techniques to respond to these concerns.  There are a number of responses to a project with unrealistic budgets.

  • Reduce scope. Talk to your sponsor about reducing the project scope. See if there are features and functionality that he can live without for now so that you can deliver the project within the budget specified.
  • Identify and manage the budget as a project risk. Utilizing risk management will help better manage expectations early in the project and also be a way to gather input and ideas for ways that you might be able to hit the budget.
  • Manage scope with zero tolerance. On many projects, you start with an aggressive budget and the situation gets worse because the project manager does not effectively manage scope. If you are on a project with an unrealistic budget to begin with, it is absolutely critical that you manage scope effectively and do not increase scope without an approved scope change request. Disciplined scope management will ensure that you only have to deliver what was originally promised, and that any approved changes are accompanied by a corresponding increase in budget and timeline.
  • Look for process improvement opportunities. Lastly, take an honest look at your budget and your approach for executing the project. Talk to your team, clients, and manager about any ideas they may have for executing the project at a cheaper cost. This will get everyone thinking about being part of a solution. For instance, perhaps you could buy used equipment that will still meet your needs instead of new equipment. Perhaps you can change the process for gathering requirements so that they are competed earlier. This may result in budget savings as well.

Although it appears that you are being held accountable for budgets that are not within your control, you do have control over the processes you use to manage the project. Look at all aspects of project management to see if the unrealistic budget can be achieved.

Proactively Manage Project Resources Without Authority

Proactively Manage Project Resources Without Authority

If team members are missing their deadlines you must first try to determine the cause. For example, if it is due to a lack of skills, this should be addressed through training or replacement resources. If it is because they do not fully understand the expectations you have, then you may have some changes to make as well.

Although the team members do not report to you functionally, their work on the project should still be input into their overall performance review.  You can try to hold people accountable by making sure they understand that you will be providing performance feedback into their review. This should also be reiterated and agreed to by the functional managers

From a process management side, there are project management techniques and processes that should be utilized. First of all, if the availability and performance of the team is in doubt, you should raise this early as a project risk. As part of risk management, you need to put a proactive plan in place to make sure that this risk is addressed. When people miss their deadlines and your deadline is in jeopardy, you may need to raise an issue and perform issues management. During issues management, you again look for the cause of the problem and try to resolve it.

In addition, make sure your team members are communicating proactively with you. In many cases, it is not the fact that people miss their deadlines that gets you frustrated; it is that the team member does not tell you ahead of time. If the team member communicates proactively, you can see the problem beforehand while you still some ability to help. If he just misses the date and does not communicate, then he is not managing expectations as should be done. By the same token, the project manager needs to communicate proactively as well. Communicate well with your team and make sure they understand dates and expectations. Also communicate proactively with the functional managers and make sure they know when there are resource sharing issues or people performance issues.

Matrix management involves a complex and delicate balancing act between project managers and people managers. The project manager usually has limited people management authority in these situations. Even so, it is possible to complete your projects successfully. There are many project management processes and techniques that can help. Utilize them to raise risks and issues when needed. Also, make sure you utilize the project sponsor. The sponsor can help you generate urgency and focus, and can also have an impact on the functional managers to make sure that you have the resources you need to be successful.

Schedule Estimating Threshold

Schedule Estimating Threshold

When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time though. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

A question people ask is how small the activities should be before they do not need to be broken down further. This is referred to as your “estimating threshold”. Work can be broken down into smaller activities than the estimating threshold, but normally no work would be left at a higher level. The threshold can be different based on the size of your project and how well the work is understood.

You can use the following criteria as a guide. For a typical large project (say 5000 effort hours or more) the activities should be no longer than two weeks. Medium and small projects (say 1000 effort hours or less) should have activities no larger than one week. Remember that this threshold is an upper limit. You can break the activities down further if you want.

Assigning work that is smaller than your threshold allows the work to be more manageable. Think about it. When you assign work to a team member you don’t know for sure how he is progressing until the due date (or the completion date if it comes first). (Yes, you can track progress if the work proceeds linearly – like painting a wall. But many of us work in the knowledge business (IT, Sales, Finance) and it is not easy to know exactly how the work is progressing.)

Let’s look at an example. If you assign a team member work that is due in four weeks, you are not going to know for sure whether the work is on time until the four-week deadline. The worker may tell you things are on track, but you don’t really know for sure until the due date. If the work is completed you will know you are on track. If the work is late you will know it then as well. However, four weeks (or longer) is too long to wait to know if the work is on track. A better approach is to break the four-week activity into four one-week activities. Then you will know after the first week if the work is on time or not.

If at all possible you want to try to have schedule work completed within two weeks. If you give someone work that takes four weeks or longer there is just too much time before you really know if things are on-track or not. It is much better for you if you can keep the schedule feedback loop to no more than two weeks.

Managing projects at your company? Download free tools and templates from Toolkit Cafe and make your job easier

Assumptions and Risks – Two Sides of a Coin

Assumptions and Risks – Two Sides of a Coin

Let’s take an example of a common statement that is included in many Project Definitions – that the resources needed for this project will be available when needed. What kind of a statement is this? Most people would say it is an assumption. After all, when a project starts, you always assume you will get the resources you need.

However, is it really an assumption? Can you imagine starting a project where the people and equipment were not available and there was a realistic possibility that they would not be ready when you need them – perhaps because another project needed to finish first? It is not too difficult to imagine that scenario. In that case, the same statement would definitely be a risk – not an assumption.

The same statement might be an assumption or a risk depending on the circumstances of your particular project. There is some degree of uncertainty to an assumption. If the event is negative and there is a low probability that it will happen, it can be stated as an assumption. If the event is positive and there is a high likelihood it will happen, it is also an assumption. One way to identify important assumptions is to perform a risk assessment and look at all the low-risk items. Most of these low risks are not worth mentioning, but some will have significant implications if events do not turn out as you think. These are the ones that you can document as assumptions.

There are two key characteristics of risks and assumptions. First, there must be some uncertainty to the event. If there is 100% chance of an event occurring, it is simply a fact. If there is a 0% chance of the event occurring, it is fiction. Neither are risks or assumptions.

Second, assumptions and risks are both outside the total control of the project team. If the event is within the control of the project team it is neither an assumption nor a risk. It should simply be managed to make it happen.

Review the following examples for more clarity on assumptions and risks.

Statement

Assumption, Risk or Other?

We will have strong support for this initiative from our executive sponsor. Can’t tell if it a risk or an assumption. Depending on the project, there could be a high degree of risk in this statement (risk) or very little (assumption).
We will complete requirements before we begin design work. This is part of the project approach. It is not a risk or assumption because it is within the control of the project team.
Our vendor will complete their installation by October 1 Can’t tell if it a risk or an assumption. Depending on the project, there could be a high degree of risk in this statement (risk) or very little (assumption).
We must go to the moon to get the supply of meteor fragments that this project requires. This is not a risk or assumption because there is no risk involved. It is a fiction (0% true).
It is 60 miles from one project team location to the other. This is not a risk or assumption because there is no risk involved. It is a fact (100% true). (If it were not true it would be a fiction (0% true), but it would still not be an assumption or risk statement.) 

Manage the Schedule for Small Projects

Manage the Schedule for Small Projects

All projects need a schedule. If you have a small project perhaps the schedule is a simple checklist or Excel spreadsheet. As projects get larger they need more formal scheduling templates and tools.

The processes you use to manage a schedule also vary depending on the size of the project. Large projects need a lot of schedule management rigor. Small projects can use a lighter process. The following steps can be used to mage the schedule of a small project.

  1. Review the schedule on a weekly basis.
  2. Identify activities that have been completed during the previous week and update the schedule to show they are finished.
  3. Determine whether there are activities that should be completed, but are not. Work with the individual that is assigned to the work see what is going on. Determine how much additional effort and duration are needed to complete the work and update the schedule accordingly.
  4. Evaluate the remaining work to see if the project will be completed within the original duration. You may find that even though some activities may be completing later than planned, other activities may be completing early and the overall schedule may still be okay.
  5. If your project is trending behind schedule, think of schedule management techniques you can apply to get back on schedule. Raise a schedule risk in your status report if the original deadline appears to be in jeopardy.
  6. Adjust the schedule so that it reflects the remaining work to be completed, and is as accurate as possible.

Since this is a process for a small project, it would be unusual to have major problems with the schedule. The consequences of problems on small projects are generally small as well.

Define the Objectives of Your Project

Define the Objectives of Your Project

Objectives are concrete statements that describe the things the project is trying to achieve. They are included in your Project Charter. An objective should be written in a way that it can be evaluated at the conclusion of a project to see whether it was achieved. A well-worded objective will be Specific, Measurable, Attainable / Achievable, Realistic and Time-bound (SMART). (SMART is a technique for wording the objective. An objective does not absolutely have to be SMART to be valid.)

An example of an objective statement might be to “upgrade the customer service telephone system by December 31 to achieve average client wait times of no more than two minutes“.

  • Note that the objective is specific.
  • The objective is measurable in terms of the average client wait times the new phone system is trying to achieve.
  • You can assume that the objective is achievable and realistic.
  • The objective is time-bound, and should be completed by December 31.

Objectives should infer the deliverables of the project. In the prior example, the objective refers to the upgrade of the telephone system. If you cannot determine the deliverables that are created to achieve the objective, the objective may be written at too high a level. On the other hand, if an objective describes the characteristics of the deliverables (such as speed or ability to handle a specific number of users), it is written at too low a level. Characteristics tend to be more requirements statements – not objectives.

If the project is a part of a larger program, the objectives of all the underlying projects should be in alignment with the program objectives.

Objectives are important because they show a consensus of agreement between the project manager and the project sponsor on the main purpose of the project. For example, the specific deliverables of an IT project may or may not make sense to the project sponsor. However, the objectives should be written in a way that they are understandable by all of the project stakeholders.

Objectives are also valuable since they provide alignment to organization goals and strategies. Your organization should not authorize projects that do not tie to goals and strategies

The project objectives should be defined and agreed upon before the project starts. The deliverables of the project are created based on the objectives. A facilitated meeting between all major stakeholders is a good way to create the objectives and gain a consensus on them at the same time.

Seven Steps for a Project Quality Review

Seven Steps for a Project Quality Review

In some cases, such as a government project, periodic audits may be called for as a part of the overall contract. This “outside party” could be any qualified person outside of the project manager. In some cases, your organization may have an internal project audit specialist. It is possible that the Project Director or the Project Sponsor could also perform this audit. The outside party could be an outside contractor or consultant, but they do not need to be.

The audit itself focuses on whether effective project management processes are being utilized and whether the project appears to be on-track. A project audit asks questions about the processes used to manage the project and build deliverables. The audit can follow this process:

  1. Notify the parties (Auditor) – The auditor notifies the project manager of the upcoming audit and schedules a convenient time and place. Other key stakeholders are notified of the audit as well.
  2. Prepare for the audit (Auditor) – The auditor may request certain information up-front. The auditor might also ask the project manager to be prepared to discuss certain aspects of the project. This ensures that the actual meeting time is as productive as possible.
  3. Perform initial interview (Auditor, Project Manager) – During the initial meeting, the auditor asks the appropriate questions to ensure the project is on-track. If there are any areas that are not on track, the auditor notes them as such.
  4. Perform as many other interviews as necessary (optional)(Auditor, Project Team) – On many projects, the audit might culminate in the initial meeting. If the project is large or complex, the auditor might need to perform follow-up analysis. This includes meeting with other team members and clients, and reviewing further documentation.
  5. Document the findings (Auditor) – The auditor documents the status and the processes used on this project against best practices. If the organization has standards and policies in place for managing projects, the auditor determines whether any of these are not being followed on the audited project. The auditor also makes recommendations on things that can be done to provide more effective and proactive management of the project.
  6. Review draft audit report (Auditor, Project Manager) – The auditor and the project manager meet again to go over the initial findings. This auditor describes any project management deficiencies and recommendations for changes. This review also provides an opportunity for the project manager to provide a rebuttal when necessary. The initial audit findings might be modified based on specific feedback from the project manager.
  7. Issue final report (Auditor) – The auditor issues a final report of findings and recommendations. The project manager may also issue a formal response to the audit. In the formal response, the project manager can accept points and discuss plans to implement them. The project manager may also voice his disagreement with certain audit points, and explain his reason why. In these cases, the project sponsor and the project director (manager of the project manager) will need to decide if the project manager should comply with the recommendations or not.

Manage Communication – Large Projects (Part 1 of 2)

Manage Communication – Large Projects (Part 1 of 2)

In a large project, all communication takes place in context of an overall Communication Management Plan. Status meetings and status reporting are required, just as for a medium-size project. In addition, there are many other types of proactive communication that need to be considered. This creative and proactive communication is laid out in a Communication Management Plan, which is created as follows.

Beginning of Project – Plan Communication

  1. Determine the project stakeholders. In some cases these are stakeholder groups such as a project steering committee. In other cases, there may be a single person such as the sponsor.
  2. Determine the communication needs for each stakeholder. The project manager can categorize the communication needs into three areas.
  • Mandatory. This generally includes project Status Reports, legal requirements, financial reporting, etc. This information is pushed out to the recipients.
  • Informational. This is information people want to know or that need for their jobs. This information is usually made available for people to read, but requires them to take the initiative, or pull the communication.
  • Marketing. This communication is designed to build buy-in and enthusiasm for the project and its deliverables. This type of information is pushed out to the appropriate people. You need this type of positive communication if your project requires people to change how they do their job.
  1. For each stakeholder, brainstorm how to fulfill the communication need. For each stakeholder, determine the information they need to know, how often they need an update, and the best manner to deliver the information. At this point, be creative. For instance, all stakeholders still need an updated project status. The Steering Committee may need an executive briefing to provide strategic direction every other month. The project sponsor may need a personal briefing on a monthly basis. A quarterly newsletter may need to go out to the entire client organization for informational and marketing purposes. 
  2. Determine the effort required. Estimate the effort required to create and distribute each of the identified communication options outlined in step 3. Also determine the potential benefit of the communication to the recipient and the project team.
  3. Implement mandatory communications. Regardless of the prioritization, implement any communication options that are mandatory for the project. This will definitely include project Status Reports, but there may also be government-required reports, legal reports, etc.
  4. Prioritize the other communication options. Discard the communication options that require high effort for marginal benefit. Also discard those that provide marginal benefit even though they may take little effort from the project team. Implement the communication options that provide high value and require low effort from the project team. Also evaluate those options that have high value and require a high level of effort from the project team. Some of these might make sense to implement while others may not.
  5. Add the resulting communication activities to the schedule. This will include assigning frequencies, due dates, effort hours and a responsible person(s) for each communication option implemented.