Use Expected Monetary Value (EMV)  to Create a Risk Contingency Budget

/in /by

Use Expected Monetary Value (EMV)
to Create a Risk Contingency Budget

Expected monetary value (EMV) is a risk management technique to help quantify and compare risks in many aspects of the project. One use of EMV is to make risk-based financial decisions. Another use is to help you create a risk contingency budget.

EMV relies on two basic numbers.

P – the probability that the risk will occur

I – the impact to project if the risk occurs. This can be broken down further into “Ic” for the cost impact and “Is” for the schedule impact.

The risk contingency is calculated by multiplying the probability by the impact.

Risk Contingency Budget

If you use this technique for all of your risks, you can ask for a risk contingency budget to cover the impact to your project if one or more of the risks occur. For example, let’s say that you have identified six risks to your project, as follows.

Risk

P (Risk Probability)

I (Cost Impact)

Risk Contingency

P * Ic

A

.8

$10,000

$8,000

B

.3

$30,000

$9,000

C

.5

$8,000

$4,000

D

.10

$40,000

$4,000

E

.3

$20,000

$6,000

F

.25

$10,000

$2,500

Total

 

$118,000

$33,500

Based on the identification of these six risks, the potential impact to your project is $118,000. However, you cannot ask for that level of risk contingency budget. The only reason you would need that much money is if every risk occurred at its full impact level. Remember that the objective of risk management is to minimize the impact of risks to your project. Therefore, you would expect that you will be able to successfully manage most, if not all of these risks. The risk contingency budget is calculated by multiplying the probability by the impact of each risk, and then summing the individual results.

Notice the total contingency request for this project is $33,500, which could be added to your budget as risk contingency. If risk C and F actually occurred, you would be able to tap the contingency budget for relief. However, you see that if risk D actually occurred, the risk contingency budget still might not be enough to protect you from the impact. However, Risk D only has a 10% chance of occurring, so the project team must really focus on this risk to make sure that it is managed successfully. Even if it cannot be totally managed, hopefully its impact on the project will be lessoned through proactive risk management.

Spreading the Risk

The risk contingency budget works well when there are a number of risks involved. The more risks the team identifies, the more the overall budget risk is spread out between the risks. In the case above, the fact that there are six risks helps pool enough risk contingency to accumulate a protective budget. If you have only identified one or two risks, you may not be able to spread the risk out enough to be as effective as you like. (This same “pooling” concept is applied to insurance as well. Small individual risk probabilities are pooled across thousands of entities to absorb the impact when an individual risk does occur.)

Budgeting for Unknown Risks

The EMV calculations above only reflect the known risks. If you are managing a large project, you need to continue to monitor risks on an ongoing basis. Therefore, you can also ask for additional risk contingency budget to cover risk that will probably surface later that you do not know about now. For example, you could request an additional 5% of your total budget for risk contingency to cover risks that you will encounter later. This is in addition to the risk contingency of the known risks that have already been identified.  

Here are Six Ways to Communicate Project Status

/in /by

Here are Six Ways to Communicate Project Status

Most of us still create some variation of a paper status report (free template here) to communicate progress on our project. I remember when these reports were printed on paper. An old manager of mine once asked me to review a large binder of paper status reports and tell him if there was anything interesting that he should know about. There were probably over a hundred paper reports in the binder.

Even though most organizations no longer print out status reports, the need for status updates is still here. Here are some old and new ways to report status.

  1. Status reports. Yes, what is old is also new. Many organizations still create status updates. Usually, these are reviewed online instead of printing in large binders.
  2. Email. Many organizations send the status information in-stream in an email These emails can still follow a common format so they are easy to read and digest. The information can be easier to digest if it is directly in the email instead of having to click on an attachment.
  3. Status meetings. Some organizations do not have a status report but go over the status in meetings. The Agile community does this through their daily stand-up status meetings. This can limit the status update to the people in the room, but in many projects that is acceptable.
  4. Discussions. Some organizations do not have formal status reports, but just hold formal or informal discussions with the sponsor and others with a need to know. This is very informal. Usually, if a person such as a sponsor wants an update they set up a time to talk to the project manager – may be just as a hall discussion.
  5. Tools. There are a number of tools that can help. These could be specialized status reporting and consolidation tools, or perhaps a general purpose environment like SharePoint.
  6. Phone messages. You could leave a status report voicemail. This eliminated the initial need for a paper-based report. Usually, you are also time bound to complete the report in two or three minutes – the length of a voicemail.

Remember that although there are many options for the format and technology of reporting project status, the need to communicate status. Status reporting is the way you manage expectations on a project and it is the minimum communication requirement for a project manager.

Use These Two Great Techniques to Help You  Plan Your Projects

/in /by

Use These Two Great Techniques to Help You
Plan Your Projects

Project Planning – Work on the Project Charter, Schedule and Budget Simultaneously

There is not a sequential order between chartering a project, building the schedule and estimating the total cost. That is, you do not have to completely charter the work first and then build the schedule and budget second. Some of the sections of the Project Charter (click here for free template), such as the estimates for cost and duration, and a milestone schedule, cannot be completed without starting to lay out the overall project schedule. At the same time, you cannot complete the schedule without gaining agreement on some elements in the Project Charter such as deliverables and scope. 

Defining the work, and building the schedule and budget need to be done simultaneously. The main deliverables, the Project Charter, schedule and budget, should also be developed in parallel. You will find that as you gather information about scope and deliverables, you can start laying out a high-level schedule. As you gather more information about the work, you can fill in more details on the schedule. When the deliverables, scope, assumptions and approach are complete, you should have enough information to complete a high-level schedule. You can then use the high-level schedule to estimate the necessary budget – which in turn are used to complete the Project Charter.

Make Sure Everyone Understands Project Roles and Responsibilities

For small projects, the project organization is pretty simple – maybe just the project manager and the sponsor. The person who is managing the project may be the only person actually working on the project.

However, for large projects, there may end up being an elaborate and formal organizational structure. You may have team members, an executive sponsor, a project sponsor, a customer manager, a project director, a steering committee, vendors, clients, and others involved. You do not want to get overly complex, but the more people that are involved in the project the more important it is that everyone be clear on their roles and responsibilities. For example, the last thing you want is to have someone give you direction as if he were the sponsor when really he may just be a management stakeholder.

One aspect of defining the project is to define the organization structure and the roles and responsibilities of all the major participants. The typical roles and responsibilities can be defined ahead of time for your organization and then reused as appropriate from project to project.

You Need to Collect Metrics. Here are Two Approaches.

/in /by

You Need to Collect Metrics. Here are Two Approaches.

There are two approaches for organizations looking to start collecting metrics. One is a formal, structured approach and one is an unstructured “let’s just do it” approach.

The Structured Approach

One way to get a metrics program started is to get a set of key stakeholders together and go through a planning exercise. This takes some discipline and forward thinking. The overall steps would include:

  • Identify criteria for success. First you need to define what success means to your organization. You would normally look at your business plan, strategy, vision, departmental objectives, etc. 
  • Assign potential metrics. Identify potential metrics for each of your criteria that provide an indication of whether you are achieving success. This is a brainstorming exercise so that you identify as many potential metrics as possible.
  • Look for a balance. The potential list of metrics should be placed into categories to make sure that they provide a balanced view of the organization. For instance, look for metrics that provide information in the areas such as cost, project success, quality, productivity, client satisfaction, business value, safety, etc.
  • Prioritize the balanced list of metrics. Depending on how many metrics you have identified, prioritize the list to include only those that have the least cost to collect and provide the most value to the organization. You usually want to end up with 5-8 metrics.
  • Set targets. The raw metric may be of some interest, but the measure of success comes from comparing your actual results against a predefined target.
  • Collect and analyze the information. Now the hard part – set up the processes to collect the metrics and analyze them on an ongoing basis.

The Unstructured Approach

There is another approach that can work. The basic philosophy is “just collect something, even if it’s wrong.” In this approach, some key people in the organization get together and look for information that can be easily captured that provide some indication of success in some areas. Then you start to collect and analyze. After you collect the data over time, you get a sense for whether the metrics are providing value and whether you need to find more or different ones. This approach may seem haphazard, but it gets you into the habit of collecting and analyzing metrics first and allows you to improve your metrics over time. I have seen this method work for some organizations.

Summary

Deciding to start collecting metrics is a great first step, but then you must decide how to get started on the work. Many organizations like a deliberate and thoughtful process to determine the metrics program. This can help you be more successful the first time.

The problem is that sometimes you don’t get past the planning to actually collect and analyze the data. Many organizations are not sure what information they need, so they just start to collect and analyze what is available. They then improve the collection and analysis over time. For many organizations it is better to develop good habits than to try to get things perfect the first time.

 

Do You Take Risks? Then You Understand Positive Risk.

/in /by

Do You Take Risks? Then You Understand Positive Risk.

Risks are future events or conditions that have a probability of occurring and an impact to your project. You usually always think of risks as being bad. That is classic risk management. However, is it true that all risks are bad? Let’s say your project was going to utilize a new tool or new technology. This introduces some risk since you have not used the tool before. If it is true that projects are generally more risky when you use new technology, why would you ever undertake a project with new technology? The answer is that you perceive there to be a benefit to your project. In other words, the potential impact to your project is a positive. This still meets the definition of risk.

  • There is an impact to your project. Normally risk events have a negative impact on your project. However, with positive risk there is a potential positive impact.
  • There is a probability of the event occurring. This is still the case with positive risks. In the prior example, if the benefits of moving to new technology were guaranteed, you could make the decision to move forward with 100% confidence. However, the implementation of the technology could turn out bad, in which case you might be worse off than when you started.

Positive risk is also called “opportunity risk”.

One of the key aspects of positive risk is that you put yourself in a position to take on the risks. Negative risks are potential events that can happen to you. They are the ones that you want to avoid or eliminate. Positive risks are those that you knowingly take upon yourself since you perceive there to be advantages to do so.

Generally when you are doing risk management on projects you are talking about potential negative events. In all the projects I have managed or coached, I have never seen a project manager account for positive risk. However, you can identify and manage the risk events that lead to positive outcomes. These opportunity risks can be managed the same way as negative risks except that instead of eliminating the risks, your risk plan will include activities designed to give you the best chance that the risk event will come true.  

If you look at both types of risks, you can compare the negative risks with the positive risks to understand the overall risk level of the project.

Templates, e-Books, e-Classes and More

TenStep, Inc. is a leader in the development of business methodology products and services. The TenStep Store is full of products that we have personally purchased and/or evaluated. All products in The TenStep Store come with a full 14-day money back guarantee. If you are not satisfied, notify us within 14 days for a full refund of your purchase price.

Use These Eight Elements Within Your Procurement Plan

/in /by

Use These Eight Elements Within Your Procurement Plan

There are many documents used in the procurement process. The Procurement Plan is a part of the overall Project Management Plan. The document describes how items will be procured during the project and the approach you will use to manage vendors on the project. Specific areas of the Plan include:

  • Purpose. Briefly describe the purpose of the project. This can be copied from the Charter. Some people may read this Procurement Plan without reading the Charter, so this section provides background and context to the reader.

  • Procurement Definition. Describe what will be procured, for what purpose, and under what conditions.

  • Procurement Responsibilities. Define who within your organization will participate in the procurement process and their responsibilities. This could be the buyers, the approvers, the investigators, the team members, the procurement specialists, the contract specialists, etc.

  • Decision Criteria. Define the process by which products and resources will be evaluated and selected. This could be a formal RFI, RFP, proposal evaluation process, etc. This could also be a longer or shorter process that is specific to this project.

  • Contract Type. Document types of contracts to be used and what actions need to be taken to initiate procurement. This can include fixed price, cost reimbursable, master agreements / statements of work, etc.

  • Contract Standards. Provide the contract standards that will need to be initiated and maintained for each contract. These will likely come from the Legal or Contracts group.

  • Ongoing Vendor Management. Describe steps the team will take to ensure that the vendor provides all products and/or services that were agreed upon, and how quality will be measured and maintained. This ongoing contract administration occurs throughout the project.

  • Project Procurement Plan Approval. List the individuals that need to approve this Plan. This may require a hard copy signature or some type of electronic approval.

The Procurement Plan is not required for all projects. However, if you have a large project with many procured elements, you should plan and frame the procurement approach with this Plan. 

Five Things You Need to Know About Action Items

/in /by

Five Things You Need to Know About Action Items

An action item is an ad-hoc work activity that requires follow-up execution. By their nature, action items normally cannot be planned for in advance. They arise on an as-needed basis during meetings or as a by-product of working on something else. There is no Knowledge Area in the PMBOK® Guide for managing action items, but they can be important to the smooth running of the project. They are an important aspects of time management. 

  1. An action item is assigned because there is not enough knowledge, expertise or time to resolve the item at the time it originally surfaced.
  2. Action items need to be assigned, worked on later and completed. (If they are not going to be completed, they should not be called action items. Instead, simply note that the item will not be completed.) Examples of action items include forwarding specific information to someone, arranging a meeting and providing a quick estimate on a piece of work. 
  3. Sometimes an action item is established to investigate an area where there may be a potential problem. Because of this, action items are sometimes called “issues”. However, this is not right. An issue is a problem which will have a detrimental impact on the project if left unresolved. Issues are not the same as action items.
  4. Trivial action items may be tracked and managed with a standalone Action Item Log

    . If the action item came from a meeting, you can create a section in your meeting minutes for action items. These trivial action items are usually less than two hours of effort and are scheduled to be completed by the next meeting. If you use this technique you can start each meeting with a review of the prior action items to validate that they are completed and then cross them off the list. 

  5. If the action item is non-trivial (greater than two effort hours) you should add them as activities in the project schedule. A resource and end-date are assigned as well, and the activity is then managed and tracked as any normal schedule activity. This is the better approach to follow, because it keeps the work activities in one place and allows the project manager to enforce the discipline of knowing ‘if it’s not on the schedule, it will not be worked on’. This approach also allows the project manager to see the impact of the action items on the schedule. For instance, you may have a small action item that is 4 hours of work. If you assign this action item to a person on the critical path, you will see the resulting delay to your project. This may result in you assigning the action item to someone else instead.

In many cases, action items are trivial in nature, but in other cases they can require substantial work to complete. Track non-trivial action items in your schedule. Leave the true trivial action items on the Action Item Log. Projects tend to generate lots of them and you need some method to track and close them to ensure the project work continues to run smoothly.

 

Six Reasons Companies Struggle Implementing  Project Management

/in /by

Six Reasons Companies Struggle Implementing
Project Management

There are many companies that do not have common project management processes, templates, approach and skills. One initial observation is that companies that don’t manage projects well are usually run by senior managers who never learned formal project management themselves. It is hard for them to lead culture change around project management when they don’t understand the value themselves. In fact, sometimes these managers think of project management as a tool for managing projects, rather than as a process for doing the work. When they discover a tool isn’t involved, they lose interest.

There are a number of other reasons why companies have not implemented project management processes. These include:

  • The company does not have committed sponsorship.

Some managers want to hold a training class and hope that project management sticks. They don’t have a strong commitment to the culture change required to get better at managing projects. In large companies, it could take two to three years, or longer. The sponsor needs to be committed and focused long term to make the changes successfully. 

  • The entire organization is not included.

It’s hard to be a good project manager in an organization that doesn’t value project management skills. For instance, if you take the time to create a Charter document, and your sponsor asks why you were wasting your time, you are probably not going to be very excited about the planning process on your next project. To be effective, the entire organization must be part of the project management initiative.

  • The organization does not have a lot of pain around projects.

This is very common, especially in small to medium sized organizations. In many companies, the projects are not under pressure to complete within fixed deadlines and budgets. They just need to be completed within a “reasonable” timeframe. In these companies, there is not much internal pressure to change the status quo.

  • The organization is not scaling the processes and approach.

A common criticism of methodology is that it is cumbersome, paper intensive and takes too much focus away from the work at hand.  Sometimes this is a legitimate concern, caused by not scaling the methodology to the size of your project. For instance, if you were required to develop a fifteen page Project Charter even if your project is only 200 hours, you may have been turned off. This is not usually a methodology problem as much as it is a misapplication of the methodology.

  • The project teams fight the changes.

Many people want to solve problems and do their jobs creatively, with a minimum of supervision. They fear that project management techniques will result in controls that will take the fun out of the work. Without strong sponsorship, the project teams resist the change until the pressure goes away.

  • There is a fear of the loss of control from management.

If you really want to effectively implement a project management discipline at your company, you must give a level of control and authority to the project manager. Some organizations, and middle managers especially, do not want to lose that control. They may want people to coordinate the projects, but then they want to make all the decisions and exercise all the control. Formal project management will not be possible in organizations where this fear is prevalent.

Summary

These are some common reasons why project management is not sponsored at
companies, and when it is sponsored, why it does not always stick. However, almost
every study that looks at project management shows that it is a discipline that will help
project managers deliver on time, on budget and within client expectations. All
companies should have a common project management process to maximize the chances for delivering their projects successfully.

Six “Validates” to Authorize Projects

/in /by

Portfolio 101 –
Six “Validates” to Authorize Projects

When projects get approved they should be placed on a pipeline until the organization has the capacity to staff the project. It might seem that once a project makes it through the approval process there is a commitment to start immediately. This is not the case. There is one more step that has to happen before a project can actually start – authorization.

All of the approved projects cannot start at the same time. There are usually not enough resources and business focus to work on everything al the same time. Authorization takes place when a previously approved project is actually ready to start. This is the point where the budget is actually allocated to the project, a project manager is assigned, and the work is ready to begin.  The authorize step to make sure that the project is still viable. There are a number of things that need to be validated before the project begins.

  • Validate the Business Case. The time lag between approval and when the project is ready to start may have changed the Business Case. For instance, it is possible that a competitive opportunity has come and gone.
  • Validate sponsorship. It is possible that the customer and sponsor are no longer committed to the project. This could happen with changing priorities and it could also happen with a changing of the sponsor.
  • Validate staff. You should not start a project without staff availability. It is possible that the resources that were going to work on the project are no longer available.
  • Validate budget. It is possible that budget cuts, or overruns from other projects, have resulted in a lack of funding for the project.
  • Validate detailed estimates. Once the project manager is assigned, the project planning process begins. This will result in an estimate of effort, schedule and cost at a greater level of accuracy than when the Business Case was created. It is possible that the more accurate estimates prepared at this time will result in the project no longer being viable.
  • Validate priorities. It may be that nothing has changed on a project that was approved. However, business changes during the year may have resulted in a number of new projects with high priorities. These new projects may take the funding that was originally allocated to another project.

You can now see that there are a lot of reasons why a previously approved project may no longer make sense by the time it is ready to be staffed. It is usually the case that the shorter the timeline between approval and authorization, the more likely it is that the project will in fact proceed as envisioned. Likewise, the longer the lag between the project approval and readiness to begin, the more likely it is that the project will no longer make sense. If the project no longer makes sense, then it should not be authorized.

Who Are Green Stakeholders?

/in /by

Who Are Green Stakeholders?

Recap of GreenPM:

GreenPM® integrates environmental thinking (“GreenThink”) into all of the project management processes. The point about GreenPM is not that you make every decision in favor of the one that is most environmentally friendly. The point is that you start to take the environment into account during the decision-making process. You might make most decisions the same as you do today. But there might be some decisions you would make differently.

Stakeholder Analysis

Stakeholders are specific people or groups who have a stake or an interest in the outcome of the project. Normally stakeholders are from within the company and could include internal clients, management, employees, administrators, etc. A project may also have external stakeholders, including suppliers, investors, community groups and government organizations.

The first part of stakeholder analysis is to determine the project stakeholders.

Green Stakeholders

The additional question we ask in GreenPM is whether there are any “green” stakeholders that are relevant to our project. In most cases I think the answer will be “no”. That is, most projects may not have any obvious connections with the environment or green concepts.

However, on some projects, with a little bit of thought, you might realize that there are some additional stakeholders that are interested in your project from a green perspective. Some examples of green stakeholders are.

  • Your internal Environmental Management Group. Check the mandate for this group to see the areas where they have an interest. You might be surprised that they could have an interest in many projects if the project manager and sponsor only bothered to ask the question.
  • The facilities organization. If your project touches on the facilities organization, you may well have some green implications. The facilities group is interested in recycling, waste handling, trash removal, office moves, cleaning, and much more. Of course, most projects don’t have a need to engage the facilities group. But if you do, they may very well have green policies that you will want to take into account on your project.
  • Procurement. If your project will work with vendors, make sure that the vendors meet any green requirements that have been established by the Procurement Organization.
  • The public or public agencies. If your project impacts the public, or a public agency, you may well fall under some environmental scrutiny. For instance, let’s assume your project requires a survey to gather stakeholder feedback. If the survey is only internal to your company then only your company would be interested in the format of the survey. However, if the survey goes to the public, you may get held to a higher environmental standard. For instance, you may be criticized if your survey extends to multiple pages. You might be scrutinized if you print too many physical surveys and you have many extra copies. You may be asked to use recyclable paper. These are just small examples. The point is that if your project has a public component you may get held to an even higher level of green scrutiny.

The prior examples show that you may have some stakeholders that are interested in the environmental aspects of your project. Some of them may be stakeholders anyway and you will just need to be aware of their green interests as well. However, in some cases, thinking about GreenPM will allow you to include some stakeholders that you may not have identified before.  

Save the World – Use GreenPM®.