Saturday, October 20, 2018

Project Plan vs Project Management Plan

Project Plan

In some organizations, this plan is also referred to as a work plan.
Simply put, you can say that the project plan is a formal approved document used to broadly guide the project, and facilitate communication among the stakeholders. The project plan takes its objective from the project charter and the scope statement.
The project plan speaks in general, for example:
  • Why is the project undertaken?
  • What value will it add to the organization?
  • What will the output or deliverables of the project be?
  • Who will be involved in the project?
  • What is the deadline?
  • What are the milestones?
  • What is the scope, budget and schedule?
  • What technology is going to be used to accomplish the task?

Project Management Plan

The project management plan is a formal approved document that guides you precisely on how you are going to proceed.
For example:
  • How will the project work be carried out?
  • How will the scope be managed?
  • How will you monitor and control the various project activities?
  • How will you deliver the product and close the project?
A project management plan is composed of many subsidiary plans, for example, scope management plan, cost management plan, risk management plan, procurement management plan, etc.
The project management plan is a meta-plan of the project plan. It is the actual plan which is followed by the project management team to successfully complete the project.

The Difference Between the Project Plan and Project Management Plan

There are many differences between the project plan and project management plan. Some of them are as follows:
  • The project plan describes the plan broadly with less attention to detail. It deals with high level planning. On the other hand, the project management plan is described with every possible detail.
  • The project plan deals with the “what” part of the project, and the project management plan deals with “how” part of the project.
  • The project plan is a visionary document; it defines the vision. The project management plan is executed to achieve the vision.
  • The project plan gives you the vision to complete the project successfully, while the project management plan defines and develops the system to be used to complete the project successfully.
  • For larger projects, the project plan and project management plan are different, but for smaller projects, they can be merged.

Quality Control vs Quality Assurance

Quality assurance is the process of managing quality. Quality control is used to verify the correctness and quality of the product.

What is Quality?

The most important and accepted definition of quality is given by Mr. Philip B. Crosby which says quality is “Conformance to requirements.”
According to ISO 8402:1996 (Quality Management and Quality Assurance Vocabulary standard), “Quality is the totality of features and characteristics of a product or service that bears on its ability to satisfy stated or implied needs.”
According to ISO 9000:2000 (Set of International Quality Standards and Guidelines for Quality Management Systems), “Quality is the degree to which a set of inherent (existing) characteristics fulfills requirements.”
Simply put you can say that ‘quality is about meeting the customers’ requirements and the deliverable being fit for use.
If a product meets or exceeds customers’ requirements you can say that the product is of high quality. However, if it is not meeting its stated requirements the product is of low quality.
Keep in mind that, regardless of the grade, the quality should be high. In any case, the quality cannot be compromised.

Quality Assurance

We have discussed the term quality which simply means “fitness to use and conform to requirements.”
What is meant by “assurance?”
Put more simply, it is a surety or trust. This is an act of giving confidence that you can believe in.
You can say that quality assurance assures the quality of the product. This process ensures that the output of the process is defect free and conforms to all stated requirements.
Quality assurance is a process based approach whose prime objective is to prevent defects in deliverable in the planning stage to avoid rework, which costs a lot.
Quality assurance is a proactive process. It emphasizes planning, documenting, and finalizing the guidelines that will be necessary to assure the quality. This process starts at the very beginning of the project to understand the product’s requirements and expectations.
Once all requirements and expectations are identified, a plan is developed to meet these requirements and expectations.

Tools Used in the Quality Assurance Process

There are three tools used in quality management: quality audit, process analysis, quality management, and control tools.
In quality audit, a team of external experts come and review the process and procedures. If they find any discrepancies, they will suggest corrective action. They may also suggest an improvement in the process.
Quality audit is a great tool to ensure that the best practice and approved procedures are being followed.
In process analysis, you analyze the process to find any improvements, discover the root cause of any problem that occurred, and identify any non-value added activities.
Quality management and control tools include various diagrammatic techniques which help you find ideas, help you make decisions, and prioritize issues.
Some examples of quality management and control tools are affinity diagram, tree diagram, network diagram, etc.

Quality Control

Quality assurance is a process based approach; on the other hand, quality control is a product based approach. Quality control is concerned with the operational activities and techniques that are used to fulfill the quality requirements.
Quality control functions start once the project work has begun. It is a reactive approach and helps you find defects in deliverable's.
The objective of the quality control process is to make sure that the deliverable's are defect free and acceptable as per the quality requirements. If the deliverable has a defect, you will take any suitable corrective action.
Simply put, the quality control process has two objectives: to find any defects in the product and correct them, and validate the deliverable.
Quality assurance and quality control are dependent on each other. The quality control process receives input from the quality assurance process, and in turn, gives its feedback to the quality assurance process so that the quality assurance can validate the operational process.
For example, if the project team finds a defect during the project execution, they will correct it and the feedback will be sent to the quality assurance team. The quality assurance people will investigate the cause of this defect and they will take corrective and/or preventive action in the process so this defect will never happen again in the future.
Once the process is updated, the quality control people will follow the process defined by the quality assurance team so the defect does not recur.
The quality assurance process takes input from the quality control process, and the quality control process takes input from the quality assurance process.

Tools Used in the Quality Control Process

Generally, you use three techniques for the quality control process. These techniques are inspection, statistical sampling, and seven basic tools of quality.
In inspection, you physically examine the deliverable for any defects and to see if it matches the requirements.
In statistical sampling, you select a random number of items from a batch and inspect them for any defects and conformance.
Seven basic tools of quality are scatter diagramcontrol chart, histogram, checklist, Pareto diagram, cause and effect analysis, and flow chart. These tools help you find defects and conformance of the product.

The Difference Between Quality Assurance and Quality Control

  • Quality assurance focuses on defect prevention and quality control focuses on defect identification.
  • In quality assurance, you check if the plan was efficient to avoid any anticipated defect. In quality control, you try to find defects and correct them while making the product.
  • Quality assurance is a proactive process while quality control is a reactive process.
  • Quality assurance is a process based approach while quality control is a product based approach.
  • Quality assurance involves processes managing quality, and quality control is used to verify the quality of the product.
  • Quality audit is an example of quality assurance. Inspection and testing are examples of the quality control process.

 The Benefits of Quality Assurance and Quality Control

The following are a few benefits of these processes:
  • They provide you with a high-quality output.
  • They eliminate waste.
  • They increase the efficiency of operations.
  • They provide customer satisfaction, which affects your brand and helps you grow your business.
  • Less rework and after-sale support is required. This will help you save a lot of money.
  • They encourage a high level of confidence and a motivated team.
    Quality assurance and quality control are closely related and their objective is also the same, i.e. to deliver a defect-free product.
Both processes are an integral part of a quality management plan and complement each other. Failing to apply either of them will result in a failure of quality management on the project.

Summary

Quality assurance and quality control processes are intended to make a product defect-free and ensure it conforms to requirements. The purpose of both processes is the same, however, the approach is different. Quality assurance is a process based approach. Quality control is a product based approach. Quality assurance designs a process so that the product coming from this process is defect free, while quality control checks the product when you are producing it so no defected product reaches the market.
These processes have important roles in the success of your project. Their effectiveness can only be achieved they are well understood by the organization and the team performing the job.

Small guide to Project Risk Management

Risk management is a process of identifying risk, planning responses to those risks, and monitoring them throughout the project life cycle.
On the other hand, a risk management plan is a document which documents the detailed plan to identify risks, analyze the risks, developing responses, and how to manage the responses. It describes how the risk management activities will be carried out in the project.
Steps in a risk management plan are as follows:
  • Plan Risk Management
  • Identify Risks
  • Analyze Risks
  • Planning the Responses
  • Monitor and Control the Risks

Plan Risk Management

In the plan risk management process, you define how you’re going to conduct the various risk management activities.
You define how you’re going to identify the risks, and once they are identified, how they will be categorized, analyzed, etc.
In this process, you will lay down the formula which will determine the criteria to identify which risks are high, medium or low.

Identify Risks

In this process, you start collecting risks by using the techniques defined in your risk management plan. Some techniques extensively used in the process of identifying risk are as follows:
  • Documents review
  • Information Gathering Techniques; e.g. Brainstorming, Delphi, etc.
  • Interview
  • Other techniques
Documents review involves a review of historical records of old projects, and lessons learned etc. Review of these documents provides you with many risks.
Information gathering techniques such as brainstorming and Delphi give you the chance to interact with various stakeholders to collect the risks.
In brainstorming sessions, you ask experts to list as many risks as they can.
The Delphi technique is a fantastic technique to receive responses from the experts who do not feel comfortable in expressing their opinion publicly.
In Delphi technique, you circulate a questionnaire to experts anonymously and ask for their responses. Once you get the responses, you compile them and send the responses again to the experts for their review. You repeat this procedure until you get your job done.
Interview usually happens one to one. In the interview technique, you approach some very busy and important stakeholders with one of your team members. You ask some pre-selected questions during your conversation. The team member records all these conversations.
You might use some other techniques defined in your risk management plan to gather some more risks.

Analyze the Risks

Once all risks are identified and noted in the risk register, you will start analyzing them. You will analyse them using qualitatively and/or quantitatively risks analysis process, as set in the risk management plan.
The qualitative risk analysis process is performed on almost all projects, while the quantitative risk analysis process is optional. The quantitative risk analysis process is most likely to perform on complex, critical, and important projects.
In the qualitative risk analysis process, you determine the probability and impact of each risk, and then you prioritize the risks.
After completing the qualitative risk analysis review, you move on to the quantitative risk analysis review.
In the quantitative risk analysis process, you numerically analyze the risks and their effect on the project objective.
Expected Monetary Value Method (e.g. Decision Tree Method) is a widely-used method for the Quantitative Risk Analysis Process. Here you numerically calculate the Expected Monetary Value (EMV) of each choice, and then select the best option.
Expected Monetary Value Analysis helps you determine the contingency reserve.
Monte Carlo simulation is another technique in the quantitative risk analysis process that gives you the probabilities of completing the project in different scenarios.
Monte Carlo simulation can be performed with either cost risk analysis or with schedule risk analysis, or with any other project objective.
Monte Carlo simulation gives you a graphical representation of the project objective vs its chance of being completed. For example, if you run the Monte Carlo simulation for schedule risk analysis, it may give you the information that there is an 80% chance your project will be completed within 24 months, and a 90% chance that your project will be completed within 26 months.
Expected Monetary Value method helps you calculate the contingency reserve, which you can use when any identified risk occurs. However, there is another kind of reserve, known as management reserve, usually set by the management as some percentage of the project cost; e.g. 5% of the total cost of the project.
This management reserve will be utilized when an unidentified risk occurs. You cannot use this fund on your own, you will have to take management approval to use this fund.
Planning Risk Responses
You have identified and analyzed risks, now you have to make a plan to manage these risks. This process is called Plan Risk Responses.
Risks can be divided into two categories: positive risks and negative risks. Positive risks are known as opportunities, and negative risks are known as threats.
The main objective of risk response planning is to lessen or avoid the probability of happening negative risks or their effects, and increase the chance of positive risks happening or their impact.
Strategies for dealing with negative risks are different than the strategies used for positive risks.
Strategies used to deal with negative risks are as follows:
  • Mitigate: In mitigation, you try to reduce the chance of the risk occurring, or its impact.
  • Avoid: In avoid risk response strategy, you take measures to completely eliminate the threat or its effect. For example, changing the project management plan.
  • Transfer: Here, you transfer the risk to a third party; e.g. insurance.
  • Escalate: Here, you transfer the responsibility to manage the risk to higher management.
  • Accept: Here, you acknowledge the risk and document it, but do not take any action to mitigate it or its effect.
As for positive risks, you can use any of the below given strategies:
  • Enhance: Here, you only try to increase the chance of happening of an opportunity or its impact.
  • Exploit: In this strategy, not only do you try to increase the probability of risks, but you also do everything to make sure that opportunity is realized.
  • Share: If you are not capable of realizing the opportunity on your own, or due to some other reason, you cannot go alone, you ask someone to join you to share the opportunity.
  • Escalate: Here, you transfer the responsibility to manage the risk to higher management.
  • Accept: Here, you acknowledge the opportunity and document it, but do not take any action to realize it.
Accept and escalate risk response strategies can be used with both type of risks; i.e. positive risk and negative risks.
Once you determine the strategy for each risk, you will update it in the risk register.

Monitor and Control Risks

You have identified risks, analyzed them, and made a plan to manage them. Now that your project has started, you have to keep looking for these risks and control them when they occur.
During this process, you will continuously watch for risk occurrences and manage them as per the plan, and record the outcome into the risk register.

Summary

The risk management plan is a subsidiary plan of the project management plan. To develop a sound risk management plan, your first step should be to collect as many risks as possible. You can do that with various information team  gathering techniques. The next important thing is to note that the Quantitative Risk Analysis process is not required for all projects. It is needed when the project is large and complex.

Contingency vs Management Reserve

During the risk management planning process, you first identify and qualify the risk. The next step is to calculate the contingency and management reserve.
These reserves provide you with a cushion against known and unknown risks. Without contingency and management reserves, you cannot estimate your project cost and budget. These reserves are an inseparable part of your budget and help you manage risks.
Since both reserves serve the same purpose, managing risks, many professionals assume they are the same.
Some also think that they are just a percentage of the project cost because in many small to medium-sized organizations project managers take a percentage of the project cost for all kinds of risks, often because of a lack of resources or the simplicity of the project.
Keep in mind that contingency reserve and management reserve are not the same. They are different, calculated with different techniques, and serve different purposes.
Contingency Reserve
You manage identified risks, or “known-unknown” (known = identified, unknown = risks), with the Contingency Reserve. This reserve can be measured in either cost or time.
Contingency reserve is not a random reserve; it is an estimated reserve based on various risk management techniques.
This reserve is controlled by the project manager. The project manager has full authority to use it whenever any identified risk occurs. They can also delegate this authority to the risk owner, who, in turn, will use this reserve at the time of the risk occurrence. The risk owner can update the project manager at later stages.

How to Calculate the Contingency Reserve

There are various techniques to calculate the contingency reserve. Some of them include:
  • Percentage of the Project’s Cost
  • Expected Monetary Value
  • Decision Tree Analysis
  • Monte Carlo Simulation
Percentage of the Project’s Cost
Many small and medium-sized organizations use this technique. You can also use this technique when the project is small and not complex. This can help you save money and resources.
In this technique, you take a percentage of the cost of the project and calculate the contingency reserve. Usually, this percentage lies between 3% and 10% and is largely based on the perceived risk of the project.

Expected Monetary Value

Expected monetary value is a statistical technique used to quantify the risks, which helps you calculate the contingency reserve. This technique is used in medium to high-cost projects where you have enough resources and cannot risk the failure of the project because the stakes are high.
To find the expected monetary value, you calculate the probability and impact of each event. Once you calculate this data, you multiply probability and impact together to generate the EMV of each risk.
Expected Monetary Value (EMV) = Probability * Impact
Once you have calculated the EMV of all identified risks you add them together.
Please note that you should calculate the EMV of all risks, regardless of whether they are positive or negative.
Example
Let us say you have four risks with probabilities and impacts as follows:
contingency reserve management reserve expected monetary value
From the above table, you could argue that you may need 4,500 USD to manage all the negative risks, but this would not be correct.
Not all possible risks are going to happen. Some of them may happen and some may not. All risks will add their EMV to the pool. The risks that do occur will use the money from the pool, but the risks that do not occur will not use money from the pool. Their unrealized risk will help cover the cost of those risks that did occur.
In the above case you may need to add 1,100 USD to your budget to cover all identified risks.
The expected monetary value concept works well when you have a lot of risks, because the more risks you identify, the better the spread of the reserve will be among all risks. If you have identified fewer risks, you will not get enough spread and your reserve may dry up too soon.
The expected monetary value technique has a few drawbacks, including:
  • In the calculation, you assume that all risks are independent, though in reality this is many times not the case.
  • If the number of risks is small, the spread will be less and the reserve may be insufficient.
  • There is a chance of avoiding positive risks, which may lead to you a false result.

Decision Tree Analysis

Decision tree analysis is a quantitative risk analysis technique. This technique helps you select the best choice from many available options. This is a graphical technical which looks like a tree. Hence, it is known as decision tree analysis.
In a decision tree calculation, you determine multiple choices and the probability of each occurring as well as the impact. You will also need to find the expected monetary value of each event and select the best choice.
Example:
contingency reserve management reserve decision tree.png
Calculate the expected monetary value of the best choice.
In the given example, you have three choices: Choice A, Choice B, and Choice C.
As you can see from the figure, all three choices are representing opportunities. Therefore, you will find the expected monetary value of three events and go with the most favorable. Normally you are trying to get the maximum profit.
Okay, let us find out the EMV of all three events.
In the diagram, you have been given the probability of one event. The probability of the other event is not given. To find the other, you will have to subtract the percentage of the first event from 100%.
This is because the sum of all possible choices for one event is 100%.
EMV of Choice A = 0.25*200 + 0.75*350
= 50 + 262.5
= 312.50 USD
EMV of Choice B = 0.45*300 + 0.55*400
= 135 + 220
= 355 USD
EMV of Choice C = 0.2*450 + 0.8*200
= 90 + 160
= 250 USD
You can see that the EMV of Choice B is the highest, so you should choose that one.
Keep in mind that if all risks are negative, you select the least negative option. This is because you want to spend the least on managing the risks.

Monte Carlo Simulation

This technique was invented by an atomic nuclear scientist named Stanislaw Ulam in 1940. It was named Monte Carlo after the city in Monaco which is famous for its casinos.
This technique gives you a range of possible outcomes and the probabilities for any choice of action.
For example, we will discuss the use of the Monte Carlo simulation in analyzing a project schedule. To perform the Monte Carlo simulation to determine the schedule, you must have duration estimates for each activity.
You have three activities with the following estimates (in months):
pert
According to the PERT estimate, these three activities will be finished in 18.3 months.
In the best case, it will be finished in 15 months, and in the worst case it may take 23 months.
Now, if we run the Monte Carlo simulation for these tasks five hundred times, it will show us results like this:
contingency reserve management reserve monte carlo 2.png.jpg
(The above information is for illustration purposes only, and is not taken from an actual Monte Carlo simulation test result.)
After reviewing the results of the above Monte Carlo simulation, you can determine there is a 2% chance of completing the project in 16 months, or a 70% chance of completing the project in 19 months, or a 95% chance of completing the project in 20 months, etc.
Likewise, you can run the Monte Carlo Simulation for the budget.
For example, you can generate data like: adding 20,000 USD to the project cost produces a 70% chance that you can complete the project within the budget. If you add 40,000 USD to the project cost, there is a 95% chance that you can complete the project within the budget, etc.
So, you can see that with the use of this technique you can get valuable information which will help you make better informed decisions.
As you move forward, the situation becomes clearer and you can review this contingency reserve again. If needed, this reserve can be reduced or eliminated.
Contingency reserve is used to manage known risks including residual risks. Keep in mind that a fall back plan also uses the contingency reserve, as this is the plan used for identified risks.

Management Reserve

Management reserve is the cost or time reserve that is used to manage the unidentified risks or “unknown-unknown” (unknown = unidentified, unknown = risks).
Management reserve is not a part of the cost baseline, and the project manager needs management’s permission to use this reserve.
Management reserve is not an estimated reserve. It is a figure which is defined according to the organization’s policy.
For some organizations it is 5% of the total project cost or duration of the project, and for others it may be as high 10%. Usually, the management reserve is estimated based on the uncertainty of the project.
For example, if you are doing a project in which your organization has expertise, the management reserve will be less. In this case there will be less uncertainty. However, if you’re doing a new kind of project where your organization has less, or no, expertise, the management reserve will be high, because in this case the uncertainty will be more.
Management reserve is not controlled by the project manager; it is managed by the management of an organization. Whenever any unidentified risk occurs, the project manager should receive approval from management to use this reserve.
Many organizations try to avoid using this kind of reserve. The opinion is that if the project manager has to come to them every time to get approval, then why keep it separate? The thinking is that the project manager can come any time they need extra money, so there is no need for any management reserve.

Project Budget

You must understand the relationship between contingency reserve, management reserve, and the project budget. These are important concepts. Without these reserves, you cannot estimate the cost baseline and project budget.
Let us discuss it in detail.

Cost Estimate

The cost estimate is the cost of all work packages and is “rolled up” to the top level. This is the total cost of your project.

Cost Baseline

When you add the contingency reserve to the cost estimate, you get the cost baseline.
Cost Baseline = Cost Estimate + Contingency Reserve
Note that the project’s performance will be measured against the cost baseline.
If you add the management reserve to the cost baseline, you will get the project budget.
Project Budget = Cost Baseline + Management Reserve

When You Cannot Use the Management Reserve

Management reserve and contingency reserve are different reserves and serve different purposes. You should be able to differentiate between the situations and use the correct type of reserve.
Below are a few cases where you should not use the management reserve.

When You Are Over Budget

If you are over budget, estimate the new budget and try to get it approved. When you are over budget, you should never use the management reserve to compensate for cost overrun.
The management reserve is for unidentified risks, not to cover cost overrun.

While Using Schedule Compression Techniques

You have two schedule compression techniques: fast tracking and crashing.
Usually, in fast tracking you may encounter some risks. The first step is to identify those risks, prepare a response plan, and update the contingency reserve, though you may need to get it approved.
You can also revisit your management reserve for a review.
The situation will become familiar after following all these steps. For identified risks you will use the contingency reserve and for unidentified risks you will use the management reserve.
However, in crashing you are authorized to use extra resources. After you complete the planning for crashing you must revisit your plan for any new risk.

Gold Plating

Gold plating should be avoided and you should not use the management reserve for it. Gold plating increases the risk and changes the scope.

Fall Back Plan

I have mentioned it earlier and am reminding you again about this point. I often receive emails from my visitors asking why we cannot use the management reserve for the fall back plan.
By definition, the management reserve is used for unknown risks.
A fall back plan is not a plan for unknown risks, it is a plan for known risks when the primary risk response plan fails. Therefore, you will use the contingency reserve for this plan, not the management reserve.

The Difference between Contingency Reserve and Management Reserve

The following are a few differences between contingency reserve and management reserve:
  • Contingency reserve is used to manage identified risks, while management reserve is used to manage unidentified risks.
  • Contingency reserve is an estimated figure. Management reserve is a percentage of the cost or duration of the project.
  • The project manager has authority over the contingency reserve. For management reserve, they need management’s permission.
  • Contingency reserve is a part of the performance measurement baseline while management reserve is not.

Summary

To successfully complete your project, you will have to manage all risks proactively. If you fail to do so, your project may not be able to be completed successfully. Try to identify as many risks as you can and calculate the contingency and management reserve. Once you get approval, the next job is to use them wisely in your project.
Do not spend these reserves on gold plating, crashing or any other technique. Avoid gold plating and request a budget revision for crashing. Many times, project managers try to use contingency or management reserves for gold plating and crashing. They do so to avoid going to the management for more funds. This is a poor practice and you should refrain from doing it.

Managing risk and contingency

Many people think contingency is a cost management concern, they forget that its actually the integration point between cost and risk, and time and risk since contingency should also apply to the schedule.
Microsoft Excel and Sharepoint type tools are terrific for logging, assigning responsibility, ratings and capturing response plans. They can play a key part in ensuring issues and risks are managed. But what about the response plans, especially those you will do now or soon?
Many people think response plans are only activated once risks are realised, but that’s not risk management that’s issue management. There are things that can be done right now to either reduce the likelihood and/or the impact of the risk. The things you intend to do after the risk is realised are called contingency plans.
A classic mistake people make is to think that you only need one response plan for each risk. Wrong! With many risks, you plan to do various things to reduce the likelihood and various things to reduce the impact, plus have one or more contingency plans.
Example: Ocean racing and man overboard
Man overboard is an obvious risk with yacht racing. IF you fall overboard THEN you face a real prospect of death or severe exposure. As a skipper, you ensure:
  • Training and procedures to avoid falling overboard (to reduce likelihood)
  • Wearing of tethers, especially at night and in rough weather (to reduce likelihood)
  • Wearing of life jackets and protective clothing (to reduce impact)
  • Carrying of emergency beacons (to reduce impact)
  • Training in man overboard recovery procedures (contingency plans)
As you can see, there are multiple response plans, real cost to people up front and a residual risk, since there will always be a man overboard risk.
So who funds the response plans? Are they expected to already be included in schedules and budgets or is there a separate risk budget and time allowance? Is there a hidden funding allowance or an expectation of overrun? Is there no allowance made?
Terminology is a problem, with some organisations referring to a risk budget, some to contingency, some to management reserve. This is further complicated if vendors are involved. Policies differ: some organisations consider a 10% overrun in budget is acceptable, for example 10% contingency factored in to funding.
Regardless of what it is called, consider:
  • Time, effort and hence cost to fund risk response plans you will do now or soon.
  • Time, effort and hence cost to fund contingency plans you might do in the future if risks are realised—tricky as probability is a factor here.
  • Cost allowance to fund impact on the project and/or business of risks in the future if risks are realised—tricky as probability is a factor here.
  • Time, effort and hence cost to fund anticipated but as yet unknown risks.
  • Time, effort and hence cost to fund anticipated but as yet unknown scope changes.
Some of the above will be included in the project budget, others will be outside of the project budget but may well be included in funding requests.
Is contingency owned by the vendor, the project team or the sponsor? This depends to some extent on who owns the risk. Maturity also comes into it, with fear of making visible contingency plus misunderstanding of forecasting versus budgeting being common.
So how much is enough? In construction, we used to talk 10%. In IT, depending on what you believe, studies we have seen indicate 30% or higher is more realistic. All we really know for sure is that 0% is definitely the wrong answer.

Lessons Learned and Project Performance

If PMO and Project Team is going to learn from projects, it must therefore take a proactive and collective approach to gathering – and acting – on ‘lessons learned’. There is a range of collective approaches from software to suggestion boxes, but I find getting the team together and discussing the project is the most effective way.
This approach encourages positive team relationships and fosters a culture of trust and improvement,whilst also learning the technical lessons. However, it also presents a number of challenges. 
Trying to actively learn from project experiences can often fail at the first hurdle – culture. If it’s not part of your organisational culture to improve, you will have a hard time convincing your colleagues and management to invest the time and effort to a collective ‘Lessons Learned’ approach.  
Next step at which ‘Lessons Learned’ processes stumble is commitment. If you capture but then don’t apply the ‘Lessons Learned’, people see it as an exercise in futility, or, that what they’ve produced is undervalued.
The third challenge is complacency – after a number of iterations things are going so well that it seems redundant to keep doing them.

The four cardinal sins of the ‘Lessons Learned’ workshop


#1 Don’t let it become another ineffectual meeting

Make sure this is the best meeting you have ever run! That way people will feel positive about the time they invest. Spend time planning your purpose and objectives and create an agenda that makes the best use of everyone’s time. Make sure you have someone responsible for facilitating or chairing the meeting. 
Without a strong process and facilitation it’s likely to turn into another talk-fest. If you think this will happen, it’s probably better to do nothing at all and wait until you’re confident in the process, rather than running another ineffective meeting that makes it harder again, to gain time commitments in the future.  

#2 Avoid the blame game, finger pointing and being too subjective

Often people’s reputations are on the line when we start looking at success and failure on projects. If you have challenging egos or relationships on the project, managing group dynamics can be especially challenging.   
Setting some ground rules and good preparation can help, but it’s also worthwhile having a think beforehand about how you might handle particular people or behaviours in the room. You may also consider having someone external to the project chair the meeting, so they can be a neutral party and more objective. 

#3 Make sure you have a process to ensure action

The most important question in planning any workshop is “what do you plan to do afterwards?”  This helps design workshop outcomes and a follow-up process that maps workshop goals with business goals. 
Running a ‘Lessons Learned’ workshop has intrinsic value on its own – through the reflective discussion that ensues. Understandably though, the most value comes from actually using the lessons to improve in the future. 
If your project management process doesn’t allow resources to do this, how is it going to happen? If you are responsible for organising a ‘Lessons Learned’ workshop, ask yourself upfront “what do we want to do with the learnings, and how will we ensure action?”  
Make sure you discuss with your organising team the approach you will use to carry through actions, and if there are any organisational mechanisms you can tap into. This may involve tabling the actions in a regular project control group, giving individuals accountability and integrating it into KPIs and role descriptions. 

#4 If you want culture change – don’t make them optional

If you are going to start integrating ‘Lessons Learned’ workshops regularly, you should establish very clear expectations in your organisation or project around these workshops, and your commitment to them. 
Particularly about why they are important, but also when to do them, and ensure you match the process to the scale and phase of the project. Some of the considerations include what type and detail of process you will use at the start of, during and at the end of projects.     
Did we say start? Yes, even running a brief meeting at the start of a project to ask, “What did we learn from our previous projects and experiences?” can be invaluable.
By being clear on when you run them, you avoid an ad-hoc or optional approach.  The reason being, it’s hard for busy people to commit to something that’s considered as ‘optional’ when they have plenty of other deadlines to meet.  If you or your organisation wants to be a market leader, this must change. 

Lean, Six Sigma and Project Management Together as one (Marriage made in heaven)

Lean is a way of reviewing processes to eliminate non-value adding activities.  Six Sigma reduces the variability in the process to provide a better quality outcome.  First you take out the non-value adding tasks.  You’re left with the things you have to do, but probably still an inefficient process.  Then you use Six Sigma to improve the efficiency.  The end process is now faster, cheaper, better quality and with reduced risk.  Every time you do something, there’s an opportunity to make it wrong;  If you do less, there’s less opportunity to make it wrong.
Process improvement on projects have certain pitfalls – and they are pretty much the same as other types of project.  You’ll come unstuck if you:
  • Don’t have a committed team or sponsor
  • Have a target of arbitrary headcount reduction.
  • Have poor input from the wrong people.
  • Spend too much time doing analysis and not enough time delivering change.
  • Send out mixed messages and have a poor communications plan.
  • Expect there to be a silver bullet which will solve all your problems.
  • Don’t plan.



While there are a number of boxes focused on the delivery of each methodology, the process that selected which group got which project consisted of three primary decision questions.
  1. “Does Project pass the risk assessment?” – All organizations, no matter their projects delivery structure, should have an established approach for the review of the risk associated for each proposed project. The review here is not to be confused with Business Risk Management, where the risks to the organization at large are identified, assessed and managed, but rather, should focus on the risks for the project itself. Issues like the level of project sponsor engagement, has the process owner been named, the complexity of the project scope and projects ability to meet the schedule and budget are issues that should be highlighted in this activity. If there are too many concerns, then it is prudent to send the project back to the requesting party for some additional preparation before it is acted upon by the organization.
  2. “Is the solution already known” – While this may seem like a simple question, it is often the hardest question for the business to handle. The reason for the difficulty is the subjectivity of the requested response. It is often the case, especially in an organization where Lean Six Sigma is in its infancy, where business leaders feel they know the right solution, but have done little if any analysis around the core problem. Many times this means the proposed solution will not address the true root causes, thus limiting or eliminating the potential for success. As an organization matures in the understanding and use of Lean Six Sigma, these types of discussions become less frequent, as leadership begin to recognize the value of executing a Lean Six Sigma style projects. However, the temptation to race to a solution will always be present, even in the most well developed LSS Programs. After all it is generally human nature to value action over analysis, but as the legendary UCLA coach John Wooden said “If you don’t have time to do it right, when will you have time to do it over?”
  3. “Does project require multiple business groups or IS/IT resources?” - For those projects that are assigned to the left side of the chart, there is a further question to answer. It seeks to identify the complexity of the project, by understanding how many business groups will be involved in the effort or if there are IT/IS development requirements. This question reduces the PMO’s project queue by giving business units the chance to execute projects internally and not be constrained by often limited PMO resources. It is advisable to keep track of the department specific efforts for enterprise visibility purposes and to assist in holding baseline standards for business based project management processes. This approach will lower project cycle times for the smaller and medium sizes efforts in the business. The project filter can also include a project benefit/cost parameter to determine the needs for PMO involvement.
There will undoubtedly be unique decision criteria within every business as they begin to decide how the ‘Project’ (Lean Six Sigma and PMO) world pieces together. The challenge of finding the right fit for each project opportunity will always be there, but can be greatly aided with the use of a decision process flow as discussed above. A final piece of advice on this issues, the simpler the better. The less you can ask the business to decipher the Lean Six Sigma vs. PMO riddle, the more they can focus on finding the best opportunities to assign their resources to.