Saturday, October 27, 2018

Cost Benefit or Benefit Cost Analysis (Basic Review)

The Cost-Benefit Analysis, which is also known as Benefit-Cost Analysis. Cost benefit analysis in itself is a vast subject.
Usually, these kinds of analyses are performed by high-level stakeholders; e.g. top management, or an organization’s board members.
They sit together and analyze which project is more profitable to them and aligned with the organization’s objective, and then pick the best project.
Once the project is chosen, they start the process of developing the project charter.
Cost benefit or benefit cost analysis is a benefit measurement method, and it is a systematic approach to calculate the cost to produce the product, service, or result and then compare it with the cost of the benefits to be received. It also provides us the current worth of future earnings and helps to compare the different projects.
Cost benefit analysis provides valuable information about:
  • Profit to be earned
  • Time value of the profit
  • Basis to compare the projects.

Profit to Be Earned

Cost benefit analysis adds all costs to be invested, and then it identifies all benefits and converts them into monetary form. Afterwards, all invested costs are subtracted from the monetary value of all benefits to get the result.
If the result is positive, then you may proceed further; otherwise, you will simply abandon the idea.
For example, let’s say you work in a large publishing house where book binding work is performed by manual operations. Therefore, you decide to propose your management to purchase a book binding machine to increase the output and improve the efficiency of the book binding department.
However, before submitting your proposal to the management, you will go for a fact-finding mission. You will list the cost of the investment and the benefits received by this investment and monetize them, such as:
  • Cost of the machines.
  • Cost of maintenance.
  • Cost of electricity used by these machines.
  • How many bindings you can perform with the machine vs how many you were performing with manual binding per day?
  • How much will manpower be reduced?
  • Cost of better quality product.
Now, you will add the cost of machines, maintenance, and electricity etc. Once you are done, you add the cost of benefits; e.g. how much extra bookbinding can be done with these machines, and cost of reduced manpower, etc.
You will then perform the cost benefit analysis. You subtract the cost of investment from the cost of benefits and show this figure to the management to convince them about your proposal.

Time Value of the Profit

In cost benefit analysis, you calculate how much money you are going to spend on it, and how much profit you will earn from this investment. Not only this, but also you have to find the current value of the profit that you will earn after a certain period of time because inflation erodes the value of money. Profit earned after several years will not have the same value as today. Therefore, an inflation factor must be taken into the consideration while doing the calculation.
For example, let us say if the inflation rate is 5% yearly then the thing you buy today for 100 USD, you will be able to get the same thing after one year for 105 USD.

Calculating the Current Worth

Let’s say that you are going to invest 100,000 USD on a project, and after one year you earn a 10,000 USD profit.
Then, considering a yearly inflation of 5%, what will be the current value of this money?
Formula to find the Current Value is
FV = CV(1+r/100)^n
FV = Future Value
CV = Current Value
r = Inflation
n = time period.
FV = 10,000 USD
r = 5
n =1
Putting all these values in the formula,
10,000 = CV(1+0.05)^1
CV = 10000/1.05
CV = 9,523.80
Therefore, the current value of your profit is 9,523.80 USD

Basis to Compare the Projects

If you have multiple projects and you have to select any one project, then you can perform cost benefit analysis on all projects and compare the profit in its current value. You will choose the project which will give you the highest profit.
Cost Benefit analysis helps especially when the projects are very costly and the duration is very long. In this case, on first look, the profit may appear to be high; however, applying the cost benefit analysis can bring a shocking result.
Cost benefit analysis helps you to decide which project should be selected from all the available options.


  • Cost benefit analysis compares the cost invested to the benefits.
  • It also compares the future earnings with today’s dollar value.
  • It helps in selecting the most profitable project.
  • Usually, top management is involved in cost benefit analysis.
  • Cost benefit analysis is performed before the project charter is developed.

Quality Management - Defect Repair vs Corrective Action vs Preventive Action

Corrective action, preventive action, and defect repair are the most commonly used key elements in the quality management system. You must understand these terms in order to have a better command over the quality management processes in the PMBOK Guide.
Defect repair is an easy concept—repair the defects. However, the difference between corrective action and preventive action is so thin that many people get confused while trying to differentiate them.
In corrective action, you try to take action to correct the non-conformance event that happened in the past. Whereas, in preventive action, you take action to avoid or mitigate any potential non-conformance event that may occur in the future.
Defect Repair

Defect repair is a process of repairing the defective part or replacing it, as needed. For example, let us say you are manufacturing some component. Suddenly, you see that a component is in bad shape or has any kind of discrepancy or non-conformity. You will physically inspect the material and you will see if this defect can be corrected. If this defect can be corrected, you will correct it. And if this defect cannot be corrected, then you will simply replace it.
Defect repair is also known as the correction and is performed when the product does not meet the quality requirements.

Corrective Action

Corrective action is a future response to the defect repair process or the correction, so that the cause of error or non-conformity will not occur again. For example, let us say that during the inspection you find some defective component, and you corrected the defective component. Now, you don’t want this defect to happen again. Therefore, you will look into the root cause of the problem, find a solution, and apply it to your operations so that the defects do not occur again.
In other words, you can say that the corrective actions are the steps taken to correct the root problem and stop the recurrence of deviation.
Corrective action is a reactive process and it is performed to bring the deviation under control.

Preventive Action

Preventive action is an action that is taken to avoid any anticipated future defects that may appear in the component. For example, let us say that you are going to start the production of some component. Before starting the production process, you think that some defects may appear on the component. Therefore, you review your processes and procedures and make some changes (if needed) so that the cause of anticipated defects could be prevented.
Preventive action is a proactive process.
Please note that there is a distinct difference between corrective action and preventive action. In corrective action, a problem has occurred and you try to make sure that this problem should not recur.
On the other hand, in preventive action, a problem has not yet occurred. You simply take measures so that any identified problems should not occur.
In other words, you can say that the preventive action is a process of identification of the most likely cause of any potential non-conformity in order to prevent it from initially occurring. Preventive actions are performed to ensure that there should not be any deviation from the baselines.

Scope Creep and Gold Plating

Let us say that you are managing a project and some extra functions are added to the product, either knowingly or unknowingly, and these changes are not stated in the scope statement.
This is a bad practice and it is known as either scope creep or gold plating. Scope creep and gold plating both bring changes in the final product; however, the mechanism of these changes is different in each case.
Scope creep refers to the uncontrolled changes in scope due to either interference of the customer or due to a misunderstanding of the scope by the project team or the project manager. On the other hand, gold plating refers to intentionally adding the extra features or functions to the product which were not included in the product’s scope.
Scope Creep
Scope creep is also known as requirement creep, which refers to the uncontrolled changes in the project’s or product’s scope.
Scope creep happens in the project for following reasons:
  • Interference from the client.
  • An incomplete scope statement.
  • A poor change control system.
  • Miss-communication among the team members.
  • Reasons external to organizations; e.g. market conditions, regulatory requirements, or technological advancements.
Scope creep is considered bad for the project health and it must be avoided in all cases. Here, you make some changes without any proper review, which may create many problems in later stages. And then you will have to implement many other changes just to cover up the changes made in earlier stages.
However, please bear in mind that if the scope is changed and the schedule and budget are also changed to reflect the change in scope, it cannot be called scope creep. Scope creep occurs when the scope of product is changed and the project budget and schedule remain unchanged.
Consequences of scope creep may include a delayed schedule and cost overrun. If you do not control the scope creep, then you may have problems with successfully completing your project, or in severe cases it may be terminated.
Suppose you are building a 100-foot wall for the client, and client comes to the team and asks them to increase the length of wall by one foot. Team members think there is a lot of material lying around on the site, and it will make no difference to them to build just one foot of the wall; therefore, they go ahead and add the extra length to the wall.

How to Avoid the Scope Creep

Scope creep is something that can be avoided. You can avoid scope creep by following below given guidelines.
  • Never allow changes without proper review and approval.
  • Establish a communication channel between client and you. Don’t let them talk directly to your project team members.
  • Prepare a solid and complete scope statement.
  • Establish a robust change control system.
  • Establish and encourage good communication among the team members.
  • Keep proper checks on the project’s progress.
If you follow the above guidelines, I believe that you will avoid many problems dealing with scope creep.

Gold Plating

Gold plating means intentionally adding extra features or functions to the products which were not included in the scope statement.
Usually gold plating is performed by either the project team or the project manager with no additional cost to the client. Gold plating is done with good intentions and may be appreciated by the clients. However, there are many cases where it is not liked and the gold plating backfires because you are adding some features to the product which were not demanded by the client. This might be considered as an unauthorized change in the scope and the client can refuse to accept the product.
Gold plating is very common in software programming and is done by team members to show their abilities, or by the project manager to make the client happy.
Following are a few causes of gold plating:
  • A team member may add extra functions to prove his abilities to the project manager.
  • Project manager may add extra functions to earn credit from the client or the top management.
  • Sometimes it is performed to divert the attention of the client from the defects in the product.
Although, gold plating sounds good to everyone, it is bad for the project team and the project manager in the long run. Gold plating increases the input cost (though, in many cases it does not appear to be high), increases the risk, and the expectation of the customer is elevated. If you do another project for the same customer, he would again expect you to deliver a product with extra features. And if you do not do so he will be dissatisfied.
Let us say that you are building a software program for the client. Your programmer comes to you and says he can add some extra features to the program with almost no effort which will increase the functionality of the product, and the client will like it. You also agree with him, and allow him to add this extra functionality.

How to Avoid Gold Plating

Avoiding gold plating is easier than avoiding scope creep. Below are a few guidelines to help you avoid gold plating:
  • You should never allow team member to add any extra function or features to the product without approval.
  • As a project manager, you should also avoid it.
  • You must establish proper communication lines within the project team.
As a project manager, it is your job to keep monitoring the activities of the project and stop unwanted actions which may lead your project into problems such as scope creep and gold plating.

Assumptions and Constraints in Project Management

We always make assumptions and are bound by constraints, and we always deal with them in our daily life. For example, suppose you plan to go shopping at a big mall, which is far away from your home. It will take one hour to reach there by car.You made the assumption that you will leave your home around 6:00 PM and reach there by 7:00 PM. After that, you can enjoy shopping.
This was your assumption. What about the constraints?
At first glance, you can think of two constraints. The first constraint is the amount of money to be spent on shopping. If you have $500 in your hand, you cannot spend more than this amount. This is your first constraint. The second constraint can be the mall’s closing time. If the mall closes at 10:30 PM, you cannot continue your shopping after this time. You have to wrap up everything before this time.
Likewise, projects also have assumptions and constraints. It is necessary for you to understand them if you want to complete your project successfully. A successful project manager always keeps an eye on his project’s assumptions and constraints and understands them thoroughly.
The assumptions and constraints can be identified and documented throughout the project’s life cycle. These parameters play an important role during the planning process. Your risk management plan is heavily dependent on assumptions. If you failed to properly analyze them, it may affect your project’s outcome.
The assumptions and constraints are an important aspect of your project. Although they are not managed like the requirements or risks, a proper documentation of them helps protect you from many potential issues.
You can find your project’s assumptions and constraints in the project scope statement.
An assumption is a belief of what you assume to be true in the future. You make assumptions based on your knowledge, experience or the information available on hand. These are anticipated events or circumstances that are expected to occur during your project’s life cycle.
Assumptions are supposed to be true but do not necessarily end up being true. Sometimes they may turn out to be false, which can affect your project significantly. They add risks to the project because they may or may not be true.
Suppose in our shopping example, you assumed that it would take one hour for you to reach the destination. What will happen if, due to traffic, you don’t reach the mall on time?
Your assumption is false and your plan for shopping is endangered.
This can also happen to your project.
For example, you have made the assumption that some particular equipment will be made available to you whenever you need it. However, when the time comes, the equipment is not available.
Now you are in a difficult situation.
Assumptions play an important role in developing the risk management plan. Therefore, as a project manager you must collect and identify as many as assumptions you can. It will assist you in developing a sound risk management plan.
The following are a few examples of assumptions:
  • You will get all resources required by you.
  • During the rainy season, cheap labor will be available.
  • All important stakeholders will come to the next meeting.


Constraints are limitations imposed on the project, such as the limitation of cost, schedule, or resources, and you have to work within the boundaries restricted by these constraints. All projects have constraints, which are defined and identified at the beginning of the project.
The PMBOK Guide recognizes six project constraints: scope, quality, schedule, budget, resource, and risk. Out of these six, scope, schedule, and budget are collectively known as the triple constraints.
A constraint can be of two types:
  1. Business Constraints
  2. Technical Constraints

Business Constraints

Business constraints depend on the state of your organization; for example, time, budget, resource, etc.

Technical Constraints

Technical constraints limit your design choice. For example, let’s say you’re constructing a pipeline, and according to the design your pipeline should be able to withstand a certain amount of pressure. This pressure limit is your technical constraint.
So now you know that every project has constraints; therefore, you must identify all your project constraints (such as any milestone, scope, budget, schedule, availability of resources, etc.), and develop your plan accordingly.
Constraints are outside of your control. They are imposed upon you by your client, organization, or by any government regulations.
There is an interesting fact about the constraints: If the constraints become false or are no longer valid, it is more likely that your project will benefit from it.
The following are a few examples of constraints:
  • You must complete 25% of the work within the first 30 days.
  • You have to work with the given resources.
  • You will be given only two site engineers.


As you can see how important the assumptions and constraints are for your project. An assumption is anything you think to be true but there is no guarantee, and a constraint is a limitation on you and your project. Assumptions and constraints can be anything; they might be related to human resources, budget, time or any kind of functionally.
Assumptions need to be analyzed and constraints need to be identified.
As a project manager, you must analyze how assumptions and constraints affect your project and what will happen if any assumption fails or any constraint gets resolved or turns out to be false. If you handle your project constraints and assumptions appropriately, it will help you deliver your project on time while meeting stakeholders’ expectations.

Validation Versus Verification

Validation and verification are two terms which are understood to be synonyms to each other; however, they are not.


Validation is about building the right thing. Validation process determines if you have built the correct product for the customers and whether it meets all of their needs and requirements. Validation process checks whether the product specification is fulfilling the customers’ needs or not.
Validation is a subjective process used to assess how well the product is fulfilling or will fulfill the customer requirements. Modeling, simulation, and the user evaluation are few examples of the validation process.
For example, let us say that you are developing a cell phone for your customers. You conducted the market research, collected the number of features to be included in the cell phone, and then you started the production of it.
However, when the cell phone is launched in the market, it did not get the expected response from the customers, and eventually, it failed.
Here, you would say that the product could not be validated because it failed to meet the customers’ requirement and needs.


Verification is about building something correctly. Verification process determines if you are building the product in the correct way as described in procedure manuals and all quality assurance and quality control activities are being performed as they are supposed to be.
Verification process checks that the product is being developed with all specifications are properly applied, or in other words, you can say that the verification process sees whether the product is meeting all documented specifications or not.
Verification is an objective process where product specifications and all quality requirements are documented well enough so that they could be measured and analyzed.
For example, let us say that you are developing a cell phone to be launched in the market. You conducted the market research and then collected the number of functionalities to be included in the cell phone. After collecting the requirements, you design the procedures to be used to build the product and specify the quality requirements for it.
Now the production process has been started. To make sure that everything is going according to plan, you will perform the inspection activities to the process.
Afterwards, you would say that the product has been verified and is being developed as you planned for it.
Let us summarize these terms once again:


  • It is about the evaluating the process and product in development.
  • It is performed to build a product in right way.
  • Document reviews and inspection are examples of the verification process activities.


  • It is the process of seeing whether the product satisfies the customers’ needs or not.
  • It is performed to the build the right product.
  • Validation activities include testing of the product itself.
It is quite possible that the product passes the verification process but fails in validation. You can see it in the example provided in this blog post. The company developed a cell phone for the market that passes through a well-designed and well-defined manufacturing process. However, when the company launches the product in the market, it could not get succeed to get enough customers and ultimately failed.

Validated Deliverables Versus Accepted Deliverables

Validated Deliverable

As per the PMBOK Guide, the results of the execution quality control process are validated deliverable. Validated deliverable tell you that the deliverable has been checked for completeness and correctness; i.e. deliverable are validated.
Validated deliverable are an output of the perform quality control process and they are input to the verify scope process.

Accepted Deliverable

Clearly, these are the deliverable which are accepted by the client or the customer. As per the PMBOK guide, accepted deliverable are the deliverable that meet the acceptance criteria and are approved by the customer or client.
Accepted deliverable are the output of the “verify scope” process.
Deliverable are accepted when they have passed the validation process; i.e. once the deliverable are thoroughly checked for completeness and correctness, then it will go to the customer for his or her acceptance.

Control Quality versus Validate Scope

The verification process comes before the validation process. In the verification process, you inspect the deliverable for its completeness and correctness. Here you will check that the product is built the correct way. Verification is an internal process performed by quality control staff (i.e. Application Service Owner Team Member) to make sure that the product meets all stated requirements, specifications and complies with regulations.
Verification is about building the product correctly.
The validation process comes after the verification process, and it checks if the product meets customers’ and other stakeholders’ needs or not. Here you will analyze whether the product performs its intended use as it was envisaged. The validation process does not involve the project management team. Most of the time, this process involves the project manager, customers, and other stakeholders.
Validation is about building the right product.
Suppose you plan to build a new demanding product. You design and develop it. Before launching the product you check that whether it was developed as per the design or not and if it is developed the right way or not. If the answers to these questions are yes, this means you have verified the product.
Now, you have launched the product to the market. Your product has gotten good responses from customers, and good sales were generated as you have expected.
This means that the product is validated because it has satisfied its users’ needs and expectations.
Now let’s discuss the control quality and validate scope process in detail.
The control quality and validate scope processes may seem to be the same, because both processes involve the inspection and review of deliverable; however, they are not the same. The purposes of these two processes are different, and both processes are performed in a different manner.

Control Quality

The control quality process is performed internally to ensure that deliverable are defect free, complete, and fulfill all stated requirements. Quality control activities are undertaken by the quality control people during the project execution.
According to the PMBOK Guide 6th edition, “Control Quality is the process of monitoring and recording results of executing the quality management activities in order to assess performance and ensure the project outputs are complete, correct, and meet customer expectations.”
This means that in the control quality process, you will see the specifications of deliverable and tally them with the designed specifications. If you find any deviation from the design specifications, you will recommend a corrective action.
In the control quality process, you inspect the deliverable for its correctness and whether it meets all its quality requirements specified in the contract.
Suppose you obtain a contract to build 200 km road. You start working on it, and appoint a quality control engineer to monitor the quality of work. This quality control engineer will be available all the time on-site. He will check the quality of deliverable at each stage; e.g. the quality of raw materials, level of the road, slope on turn, alignment of the footpaths, etc.
The above example shows quality control activities.

Validate Scope

The validate scope process is performed by the project manager with the client after the deliverable or the product is completed. The purpose of this process is to ensure that the client accepts the product formally.
According to the PMBOK Guide, 6th edition, “Validate Scope is the process of formalizing acceptance of the completed project deliverable.”
In the quality control process you verify the deliverable, and once the quality control department passes the deliverable, you validate it with the client.
Let’s continue with the example given for the control quality process.
You have completed 50 km out of 200 km of the road. You invite the client to come and inspect the completed part of the road so that they can formally accept it, and you get the payment.
The client comes and sees if all of his requirements have been met or not. The client will check whether the width of the road is correct, the footpath is properly aligned, and whether the length of the road is correct or not. After inspecting these parameters, the client may also check the strength of the road.
Once the client is satisfied, he signs the acceptance letter, the road is formally accepted, and you get paid for the completed part of the work.
This process is called the validate scope.
Please note, it is not necessary that the validate scope process be performed at the end of the project. This process can be performed before the project ends; moreover, this can also happen with the control quality process, as we can see in the above given example.
In the example, although the client has validated the scope and accepted the 50 km of road, you are still working to build the rest of the road.

Similarities between Control Quality and Validate Scope

The following are a few similarities between the control quality and validate scope processes:
  • Both processes belong to the monitor and control process group.
  • Both processes involve inspection and review of deliverable.
The similarities end here. Now let’s see the differences between these two processes.

Differences between Control Quality and Validate Scope

The following are a few differences between the control quality and validate scope processes:
  • Control quality is performed internally by the project manager with the quality management team, while validate scope is performed by the client with the project manager.
  • Control quality checks whether the product is produced in the right way, and validate scope is concerned with producing the right product.
  • The control quality process is performed to ensure that product is ready to be delivered while validate scope process gets the formal acceptance from the client after delivering the product.
  • Control quality is usually performed during the project execution, and validate scope is performed at the end of the phase or project.
  • The objective of the control quality process is to make sure the product is defect free, and fulfills all its requirements. On the other hand, the purpose of the validate scope process is to get formal acceptance of the product from the client.


For many people, control quality and validate scope are the same; however, they are quite different. Although they involve the inspection of deliverable, their purpose is different. The control quality process helps you build the correct product in the first place, and the validate scope process helps you get the formal acceptance from the client that he has accepted the deliverable or the product. These two processes complement each other and help deliver a good quality product.
As a project manager, you must understand the difference between these two processes and manage them accordingly for your project to conclude successfully.

Risk Management - Monte Carlo simulation

If you are involved in risk management, you need to be aware of the Monte Carlo simulation. The Monte Carlo simulation is a quantitative risk analysis technique which is used to identify the risk level of completing the project.

Monte Carlo Simulation

The Monte Carlo simulation was invented by an atomic nuclear scientist named Stanislaw Ulam in 1940, and it was named Monte Carlo after the town in Monaco which is famous for its casinos.
This is a mathematical technique that allows you to account for risks in your decision-making process. With the help of this technique, you can determine the impact of the identified risks by running simulations many times, and identify a range of possible outcomes in different scenarios.
You can use the Monte Carlo simulation to analyze the impact of risks on forecasting models such as cost, schedule estimate, etc. You need this technique here because in these types of decisions, some degree of uncertainty exists. If you don’t use this technique, your outcome will not be sound and the results of your decision may surprise you at a later stage.
This technique gives you a range of possible outcomes and the probabilities that will occur for any choice of action.
For example, let’s discuss the use of the Monte Carlo simulation in determining the project schedule.
To perform the Monte Carlo simulation to determine the schedule, you must have duration estimates for each activity.
Let’s say that you have three activities with the following estimates (in months):
table-1-monte-carlo-simulationFrom the above table you can deduce that according to the PERT estimate, these three activities will be finished in 17.5 months.
However, in the best case, it will be finished in 16 months, and in the worst case it will be finished in 21 months.
Now, if we run the Monte Carlo simulation for these tasks five hundred times, it will show us results such as:
table 3 for monte-carlo-simulation
From the above table you can see that there is a:
  • 2% chance of completing the project in 16 months
  • 8% chance of completing the project in 17 months
  • 55% chance of completing the project in 18 months
  • 70% chance of completing the project in 19 months
  • 95% chance of completing the project in 20 months
  • 100% chance of completing the project in 21 months
So, as you can see, this program provides you with a more in-depth analysis of your data which helps you make a better informed decision.

Limitations of the Monte Carlo Simulation

The Monte Carlo simulation has its own set of limitations. Some of these limitations are as follows:
  • To run the Monte Carlo simulation, you input three estimates for an activity. If you show some bias in determining the estimates, your result will not give you a correct analysis. Therefore, the results depend on the quality of your estimates.
  • The Monte Carlo simulation shows you the probabilities of completing the tasks. It is not the actual time taken to complete the task.
  • The Monte Carlo simulation technique cannot be applied to a single task or activity; you need to have all activities, and the risk assessment completed for each activity.
  • You will need to buy an add-on or a software program to run the Monte Carlo simulation.

Benefits of the Monte Carlo Simulation

The Monte Carlo simulation method has many benefits in project management, such as:
  • It helps you evaluate the risk of the project.
  • It helps you predict chances of failure, and schedule and cost overrun.
  • It converts risks into numbers to assess the risk impact on the project objective.
  • It helps you build a realistic budget and schedule.
  • It helps you gain management support for risk management.
  • It helps you in decision making with the support of objective data.
  • It helps you to find out the chances of achieving your project milestones or intermediate goals.


The Monte Carlo simulation is a very important tool and technique in the quantitative risk analysis process which helps you make decisions based on an objective data. Although this technique is not used frequently in low and low-medium sized projects, if used it increases the chances of achieving project success within approved baselines.

Risk Management - Contingency Plan vs Fallback Plan

Contingency and fallback plans are developed to manage identified risks. Since both plans are used to manage risks, you may wonder which plan you will use if any risk occurs.
A risk can be one of two types: identified risk, unidentified risk.
Identified risks can be further divided into many categories, such as: primary risk, secondary risk, residual risk, etc. Now you may think that if any of these risks occur, which plan will you use to contain the risk?
This complicates the situation.
You have two kinds of reserves to manage the reserve: contingency reserve and management reserve. Now the question comes to mind: which reserve will you use to implement the contingency plan and fallback plan?
This again complicates the situation.
Contingency Plan
Contingency is an event that may or may not occur. Therefore, you can say that the contingency plan is a plan that deals with events that may or may not occur.
In project management, a contingency plan is a part of the project management plan. It describes every action that you will take if the risk is about to happen or has happened.
Please note: this plan is developed to manage identified risks.
Let’s look at a real-world example of a contingency plan.

A real-world example

You are working on a construction project and there is a risk that rain may fall during your project execution, which will damage your consumables lying out in the open.
Therefore, you make a plan that says if there is an indication of rainfall, all consumables will be covered with a plastic sheet. You further add that after the rain stops, you will bring a blower/vacuum pump to clean and dry the wet consumables.
This is the contingency plan for this risk event.
If you examine these definitions, you will find that these are not different, just phrased differently:
  • Contingency plans are the plans describing the specific actions that will be taken if an opportunity or a threat occurs.
  • Contingency response strategy will be executed if there is a sufficient warning sign (risk trigger).

Fallback Plan

A fallback plan is implemented when the contingency plan fails or is not fully effective. In other words, you can say that the fallback plan is generally made for residual risks. It is a backup plan for the contingency plan.
The fallback plan is also a part of the project management plan and defines the cases where actions have to be taken.
Let’s look at a real-world example.

A real-world example

Let’s reconsider the above given example once again.
Suppose the rain continued to fall for a very long time, longer than you anticipated, which causes the consumables to be not usable any more.
In this case, you will implement your fallback plan. Your fallback plan says that if the rain continues to fall for a very long time, causing consumables to be damaged, you will reorder consumables from a pre-identified supplier, and start the work.
Before I go any further, let me share with you another example from my own experience.
For my blog, I always keep an updated copy of all posts and comments on my computer, so in case my blog gets hacked, I can restore my blog from this backup.
Now, suppose what would happen if my site got hacked, and at the same time my computer also crashed; how would I restore my blog?
This is where my fallback plan comes into play. To save myself from such disaster, I always send updated copies of my blog posts and comments to two separate email accounts from different email providers.
Now, if my blog is hacked and even my computer crashes, I can restore my blog from my backup saved in my email accounts.

The difference between Contingency Plan and Fallback Plan

There is no difference between the contingency plan and fallback plan. In fact, the fallback plan compliments the contingency plan and it only comes into use when the contingency plan fails.

Similarities between Contingency Plan and Fallback Plan

There are many similarities between these two plans, such as:
  • Both are used to manage identified risks.
  • To manage the contingency plan and fallback plan, a contingency reserve is used.


Contingency and fallback plans are the backbones of your risk management plan which help you manage the identified risks. If any identified risk occurs you will implement the contingency plan. However, if the contingency plan seems to be ineffective or has failed, you will implement the fallback plan.

Sunday, October 21, 2018

Business Case 101

A business case is something that you will work on very early in the project life cycle. It is a component of a project charter.

A business case has three components; the business need, the reasons to select the project, and the business value for completing the project.
Did you catch that business value? The business value is a portion of the business case. The value cannot stand alone, but the case is not complete without the business value!
The business need is what is happening in the organization, which facilitated the request for a project. For example, you might receive a request from HR that their current hiring process is very manual making it take roughly two months to hire a candidate. Thus, the business need is to improve the HR hiring process.
Next you need to explain why the project should be selected. In this portion, using our example above, you should explain that your organization is currently experiencing significant growth, and without a new hiring process positions cannot be filled in a timely manner. If the organization continues to use the current-manual HR process they stand to lose $100,000 on lost manufacturing because positions won’t be filled.
Finally, the business value explains what benefits the organization will receive if the project is completed. A business value can be different at each organization. For example, one might value financials while others might value recognition. In this example, you could explain the business value is an increase in hiring 5 employees a month which will increase revenue by $75,000.
Ultimately, the business case if very important in justifying why a project is important. Within that justification the business value is a very influential part of why the project should be selected. Therefore you cannot have a business case without a good business value, making these two concepts inseparable.

PMP Business Case: What’s Next

I keep talking about a good business case for the project to be selected. Well who is making this selection? that is a great question.
Most organizations have a process for HOW a project is selected. Although a project manager is not typically a part of this process it is important for you to understand that these process exist, for the PMP exam if nothing else.
Typically an organization will review all business cases for proposed projects during routine meetings. In theses selection meetings the group, usually made up of business leaders, will choose projects to complete based on cost-benefit analyses.
We won’t get into the specifics of a project selection process, other than ensuring you understand there is a process.
If you haven’t noticed yet, EVERYTHING within a good project management model has a process. There should be planning and systems put in place to ensure that a project can be successful, even as early as the initiation of an idea!

Project Charter and Its Benefits You Need to Know About

A Project Charter is the most important document on a project and the most underrated one.
A project without a Project Charter is a ship without a port of destination
The secret of a Project Charter is simple. It is a cornerstone of project success. No more no less. It is the start and the end point of a project. If you never thought a project charter is necessary, I urge you to look through the benefits and advantages it gives.
A lot of project managers think that Project Charter is something from the corporate and bureaucratic world; that it is a long and complicated document; that efforts spend on it are not worth the benefits.
A Project Charter should be short. A person should be able to read it within a few minutes. Otherwise, no one will read it. I would suggest no more than five pages long. Though, it may look like authorization of a project is the primary goal of a Project Charter. In fact, it is the least important aspect. It is a formality.

1. Background of a Project (Project Description)

The first section of a Project Charter usually explains who needs this project and why. What problems it solves. Justification of the project and it’s general goal.
You may object that it doesn’t really matter from the project management point of view.
But here is the truth:
The background will profoundly impact attitude of stakeholders to the project.
Do not assume that everyone will do their best just because you ask.
Critical, engaging, and highly visible projects will draw stakeholders’ attention much more than an ordinary maintenance project.
What’s more:
The same applies to your top management.
They will have little interest in your problems.
Therefore, you will have to plan and work accordingly. Expecting delays in communications, approvals, resources, and support.
On the other hand, all project results, services or products are created for people.
At least to some extent.
It is quite easy to dehumanize your work and fall under cognitive scope limitation. As defined by Josh Kaufman:
“Cognitive Scope Limitation is the way the human mind tends to simplify reality when it becomes too overwhelming for the mind.”
Background of a project provides a connection to the human value that your project is meant to create.
This link helps to overcome the limitation and personalize problems. Therefore, make decisions and solutions that help people.

2. Objectives (Goals) in Project Charter

How can you tell whether a project is successful?
Finishing it within constraints of scope, time and budget is not enough!
A project should achieve its goal. A concrete and measurable goal.
Otherwise, is 4% improvement good enough? What about 10%?
Unless you have a specific goal, you can not prove that you have finished the project successfully.
Moreover, you can’t plan and predict effectively and efficiently.
Let’s take the Law of Diminishing Returns for example:
This law states that after a certain point adding more resources will not produce the proportional increase in results. In pursuit of the best possible outcome, you may sink a lot of money and resources.
So, unless you can measure against your goals, you can’t tell how successful your project currently is. And when do you need to stop?
It is not always black or white. Acceptable results for a reasonable price is also a success.
That is not all!

3. Aligned Understanding of the Project

Most of the resources and books on project management state that Project Charter is created by a project manager.
Or issued by a sponsor.
These statements are usually misinterpreted. As if it is done solely.
You can create Project Charter on your own.
In this case, you lose the main advantage that this document can provide.
Instead, invite all key stakeholders to a Project Charter session.
By facilitating this meeting, you can achieve mutual understanding for the project goals, discover expectations on deliverables, and discuss main risks, assumptions, and constraints.
In the end, you will have a shared vision for the project. This vision will be stated in the Project Charter and signed by the sponsor.
A good basis for a project start, don’t you think?
It is ultimately important:
Quite often organizations ignore the importance of a Project Charter and do not require it.
But it doesn’t mean that you should deprive yourself of the overall advantage at the start of the project.

Project Charter Definition

PMBOK® Guide gives us the following definition:
“A Document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with authority to apply organizational resources to project activities.”
From this definition, it looks like a Project Charter is a crucial document.
A single project can start without it.
Well, in large organizations it does work this way. You do need the authorization to allocate and use some serious money and resources.
Develop Project Charter Data Flow Diagram
Develop Project Charter data flow as described by PMBOK® Guide
On small and medium projects and in less formal environment things are entirely different.
In some cases, it is even not in the best interests of a client to explicitly mark the start of a project. You will be billed from that moment. Therefore, no one sees the benefits of spending time and effort to create a Charter.
Therefore, a project manager becomes the most interested person in it.

6 Benefits of a Project Charter

As I mentioned above, there are benefits and advantages of just having a Project Charter.
However, it also has a formal purpose.
Project Charter helps to recognize your authority.
Imagine a situation.
Your manager assigns you to a project. No Project Charter was created.
The only information he provides is that the project is already up and running.
No time to waste, you need to get there and do the work.
The first-priority task is to place an order to buy equipment 12000$ worth.
You analyze requirements, investigate available solutions, draft the procurement documents.
When you get to procurement manager, he only asks: “Who are you? And why do you think you can spend that money?”.
At this moment, you should realize that you have only one argument:
Your manager asked you to do that! But formally, unless he is the sponsor, he is not authorized to use the project’s money.
And the project officially doesn’t exist for the rest of the organization. At least, you can not prove that.
It is a bit of a bureaucratic exaggeration at first glance. On small projects and in small organizations such problem might not even exist.
At least, unless everything goes well.
However, what if you will work for a large company or your customer (sponsor) is from the formal corporate world?
You should expect that they will be solemn about the Project Charter.
To avoid unnecessary problems, you need to know the benefits of having a charter.
Here are key aspects where it helps you:
1. It recognizes the project existence.
Project Charter is the tool that helps an organization to control allocated resources.
It offers an ability to ensure that efforts and money are spent to achieve specific goals. These goals are aligned with organization’s strategy and are justified in financial or any other aspect.
When you are working on a project for an external party, a contract is a preferred way to establish your agreements.
However, in this case, you will still need to create a Project Charter. It will be an internal agreement with your organization. This project charter will ensure that your project will fulfill the contract obligations.
2. It clearly defines project start.
Quite often projects creep from pre-sale or initial feasibility assessment right into the project planning phase.
And you continue your work without clear goals and boundaries. As you will see below the contents of a Project Charter will help you to avoid poor decision making and the waste of resources and time.
You will be working towards the agreed goal within defined constraints, assumptions and expectations.
3. It sets the change management foundation.
As I said before, Project Charter states the project objective.
After it is signed off, you will be spending efforts and allocated resources to reach that goal.
Changes are inevitable, and Project Charter will help you to control them.
You will be able to check and ensure that every change request is aligned with a project objective. If not, it must be rejected.
What’s more:
It can give you valid reasons to justify canceling the project.
Sometimes it is better to restart the project with explicitly redefined objectives.
Workflow from Project Charter to Work Breakdown Structure
Workflow from Project Charter to Work Breakdown Structure
4. It sets mutual understanding of the project boundaries.
For example, you need to improve a system.
Be that software, logistics or marketing one. You can spend a fortune and a lot of time, but still, there will always be some place for improvement.
But will the improvement be worth it?
By providing project justification and setting specific requirements and goals, Project Charter sets boundaries. It ensures that each dollar is well spent.
5. It states the assigned project manager and his level of authority.
I firmly believe that there should be only one responsible person for the project.
Also, I think there should be only one person on a project that can make hard decisions. That is why the name of this person should be on a Project Charter.
On the other hand, to mitigate critical risks, there should be an upper limit of authority.
Beyond that limit, a project manager should make sanity checks and get approvals from the sponsor.
6. It gives permission to project manager to use allocated resources.
Within stated boundaries and limits of authority, a project manager can do his best to achieve project objectives.
No one should interfere with his project management activities.
Take my advice.
Even if a Project Charter is not required by your organization or by your customer, find time to create it, explain its benefits and get agreement on its contents.
It will pay you back many times more.
Here why:
When you searched the Internet for “project charter example,” you probably found a lot of relevant results.
The vast number of available samples, templates, and examples points to only one fact.
There is no universal project charter example!
Save your time and nerves. Learn the concepts and create your own project charter template.
A long time ago I tried to take the shortcut.
I found a template.
Following the predefined structure, I filled out the suggested sections.
I even gave it a second thought and added some extras on my own.
However, I had a feeling like “why worry? Someone smart enough created this template. It should just work.”
Should I even say that it was a waste of time?
I will guide you through the generic project charter example.
However, only to help you to understand the concept.

Contents of A Project Charter

Project Title and Short Name
First of all, you need an official name for the project. It is the way to differentiate your project among other projects in your organization.
It is also useful to think of a short name. An abbreviation that you will use in project management software and different systems.
Project Description
What this project is all about. It is a simple description of the project background. It will help you to connect with the business case and to understand requirements more clearly.
Assigned Project Manager
That is the only place that formally states that you are the one who makes decisions on the project. Project manager role brings a lot of responsibility. So at least, ensure that your authority is recognized.
Project Manager’s authority
Nevertheless, your authority has limits. Here you need to clarify whether you can determine, manage, and make changes to the budget, scope, schedule or request team members, etc.
In most cases, there will be a limit where you will have to get approval from the sponsor.
Business case
What is the justification for the project? Is it a financial, a legal, or a market matter? Why it was decided to do it.
Business case stated in Project Charter has exceptional importance.
During the execution phase, any change to the project should be checked against the business case. If the change is not aligned with it, it is automatically rejected in most cases.
Preassigned resources
At this moment, you don’t have a team yet. But someone has to help you to decide what needs to be done.
Who will be able to handle the tasks?
So you will have some preassigned resources beforehand. Their names and availability are stated here.
Key stakeholders are stated here. It is a list of people or group of people who can influence your project or will be influenced by your project.
Known Requirements
High-level requirements as they are known as of now. Keep in mind that you can refer to other documents here. No need to put full text in Project Charter.
Description of Products/Service/Result or Deliverables
It will be a list of deliverables and description of the end result, service or product your project should produce.
It may include project documentation such as Work Breakdown Structure, Risk Register, Budget, etc. Also, it can be intermediate results for product development
Factors that, for planning purposes are considered to be true, real or certain without proof or demonstration.
Applicable restrictions or limitations, either internal or external to a project that will affect the performance of the project.
Project Objectives
It is crucial. You can fulfill or implement requirements in many different ways. However, the project was started to achieve a particular goal.
While your final product, service or result may be functional and usable, it might not be able to achieve the project objectives.
Objectives here should be concrete and measurable. Meeting these objectives will mean you finished the project successfully.
Project Approval Requirements
This section should state what items of the project should be approved and by whom. It is common for sponsors to approve WBS, schedule and budget baselines, risks, etc.
Project Risks
Risks are uncertain events or conditions that, if they occur, have a positive or negative effect on a project performance. This section contains only high-level risk. They will be later elaborated during risk management processes.
Signatures of project sponsors
All in all project sponsor should sign the Project Charter.

How to Develop Project Charter

  1. Check who is responsible for creating a charter. Is it mandatory?
  2. Check if there is a template in your organization. If not, create one.
  3. Talk to Sponsor, Client, Customer and key stakeholders. Collect information about the business case, high-level requirements, constraints, assumptions, risks.
  4. Understand the project objective and how it is aligned with the business case.
  5. Try to identify real expectations from the project.
  6. Make the first draft.
  7. Consult with subject matter experts, review historical data, look for similar projects.
  8. Update the draft.
  9. Meet with preassigned team members and get their input.
  10. Update the draft.
  11. Plan a meeting with key stakeholders.
  12. Present the draft, collect the feedback.
  13. Update the draft and finalize the Project Charter.
  14. Get the sign-off.