My Kindle book, “Project Management for the Real World”, is now available at
If you like this blog, you will benefit from reading this book.
Welcome!
The Project Management Institute (PMI) encourages its members to advance the profession. One of the ways to do this is by helping others increase their project management skills. The target audiences for this blog are professional PM’s early in their careers as well as those who manage projects but are not PM’s by title or trade. I will be posting every week or so, offering practical tips and tools on the full range of project management topics. I hope you will find this useful and help you advance your career.
The Project Health Scorecard Part 4 – Value
Here is the suggested guidance for the status of the Project Value Health:
Your Value Health is Green if ALL of these things are true:
- The business objectives are stated in the project charter
- The business objectives are measurable
- The value in the business case will still be achieved
- There are no compromises from the original scope and schedule that affects the value of the solution.
Your Value Health is Yellow if ANY of these are true:
- The business objectives stated in the project charter may not be achieved
- There are compromises (e.g. a smaller testing window) from the original scope and schedule that somewhat affect the value of the solution.
Your Value Health is Red if ALL of these are true:
- The business objectives stated in the project charter cannot be achieved
- There are compromises (e.g. a smaller testing window) from the original scope and schedule that have a major affect on the value of the solution.
Note: Much more detail on the Project Health Scorecard can be found in my Kindle book “Project Management For The Real World”, available at
The Project Health Scorecard Part 3 – Scope Health
Here is the suggested guidance for the status of the Project Scope Health:
Your Scope Health is Green if all of these are true:
- You have an approved Project Charter
- Scope is defined in the Charter
- There is a defined scope change request process
Your Scope Health is Yellow if all of these are true:
- You have an approved Project Charter
- Scope is defined but there are significant change requests pending Executive Sponsor review and approval
Your Scope Health is Red if one of these is true:
- Scope is not defined
- Scope is defined and there is no approved scope change process
- The defined Scope change process is not being followed.
Note: Much more detail on the Project Health Scorecard can be found in my Kindle book “Project Management For The Real World”, available at
The Project Health Scorecard Part 2 – Budget Health
Here is the suggested guidance for the status of the Project Budget Health:
Your Budget Health is Green if all of these are true:
- You have an approved budget
- It is actively managed
- The current forecast is within the approved budget
Your Budget Health is Yellow if all of these are true:
- You have an approved budget
- The current forecast is greater than the approved budget but corrective action is defined and likely to resolve the problem.
Your Budget Health is Red if either of these are true:
- You don’t have a budget
- You have a budget and the forecast is greater than the current budgeted amount and corrective action is not possible
Your budget health can turn back to Green if you obtain approval for a new budget. The new budget becomes your new baseline from which you will measure budget health.
Note: Much more detail on the Project Health Scorecard can be found in my Kindle book “Project Management For The Real World”, available at
The Project Health Scorecard Part 1 – Project Schedule Health
Here is the suggested guidance for the status of the Project Schedule Health:
Your Schedule Health is Green if:
- You have a schedule and…
- It is actively managed and…
- The forecast matches the published completion date
Your Schedule Health is Yellow if:
- It is early in the project and you don’t have a schedule but are working towards one, or…
- You have a schedule and the forecast has a greater “live date” than the current published date but corrective action is defined and probable, or…
- The schedule is not being actively managed.
Your Schedule Health is Red if:
- You don’t have a schedule, or…
- You have one but the published live date cannot be met.
- Note: Red can turn back to Green when a new schedule is approved and base-lined.
Note: Much more detail on the Project Health Scorecard can be found in my Kindle book “Project Management For The Real World”, available at
The Project Health Scorecard: Overview
Some years ago, a company I worked for invested in improving our Project Management practices. They engaged with IBM professional services for 6 months to guide and mentor the in-house Project Managers. The first thing the IBM consultants did was establish a baseline that would be used to measure success at the end of the engagement. This baseline was “The Project Health Scorecard” (aka “PHS”). The PHS was measured at the beginning and end of the engagement as evidence of progress in our project management practices. I am a big fan of this concept and now use it on my project dashboard for all of my projects.
The PHS is an “early warning system” for potential project trouble. In that sense it is a child of Risk Management. Because of its condense and concise nature, it is appropriate for use in Project dashboards as well Project Portfolio dashboards, where you can see the health of all active projects at once. I typically update the PHS weekly in the regular project status meetings.
The PHS contains six key measures of project management best practices. Each measure is given a status value of “green”, “yellow” or “red”. I will present each of these measures along with the guidance for status values in an upcoming six part series as follows:
- Part 1: Schedule
- Part 2: Budget
- Part 3: Scope
- Part 4: Value
- Part 5: Resources
- Part 6: Risk
Note: Much more detail on creating the Project Health Scorecard and other Project Management topics can be found in my Kindle book “Project Management For The Real World”, available at
Risk Management Deeper Dive Part 7 – Risk Monitoring
In this final part of “Risk Management Deeper Dive” I will briefly discuss “Risk Monitoring”. Monitoring your risks involves the following:
- Conducting regular meetings (as outlined in the Project Management Plan) where the risks and risk plans are reviewed. I recommend every week or every other week depending on the levels of risk exposure.
- The Risk Owners, the Project Sponsor(s) and the Project Manager(s), at a minimum, should be present at the meetings.
- In the meetings you should review the risks in order of risk exposure, with the highest exposure risks addressed first. In case your meeting time is limited, this ensures the most important risks are discussed.
- The risk probabilities and impacts are reviewed and changed as needed.
- The risk triggers are reviewed to ensure reliable monitors are in place. Any triggers tied to a near-term upcoming date are reviewed in detail.
- Risk mitigation plans are reviewed to confirm the plans are being executed.
- Risk contingency plans are reviewed to verify the plans are still valid.
- Close any risks that are no longer valid.
- New risks are raised and discussed. You can continue to use the Risk Hierarchy chart to help identify new risks.
After each meeting, the updated risk plan should be posted to the project repository. Open high-exposure risks should be highlighted in the project status report.
Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at
https://www.amazon.com/author/lettera
Risk Management Deeper Dive Part 6 – Risk Ownership
A Risk Owner must be assigned to each risk. The Risk Owner for each specific risk is responsible for identifying and executing all parts of the Risk Management Plan related to that risk. It is the Project Manager’s responsibility to regularly review the risk with the Risk Owner and update the plan with new information. The Project Manager should also make suggestions and act as a “sounding board” to assist the Risk Owner.
Here are some questions to ask the Risk Owner:
- Probability/Impact/Exposure – Have the mitigation plans reduced the probability and or impact? Have other conditions changed that have raised or lowered the probability and or impact?
- Trigger – Has the Risk Owner assigned someone to monitor the risk trigger? Is the method of monitoring adequate? Will the risk be detected in time to react?
- Mitigation Plans – Are these plans still adequate? Has the Risk Owner started execution of some or all of these plans? Are there additional plans that can be added?
- Contingency Plans – Are these plans still adequate? Are there additional plans that can be added?
It is important that the Risk Owner understands their role. Some may assume the Project Manager is taking care of it for them. Make sure the roles and responsibilities are clear to all parties.
Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at
Risk Management Deeper Dive Part 5 – Contingency Plans
In the prior post I discussed risk mitigation strategies, which can reduce the potential impact of risks that haven’t occurred yet. In contrast, risk contingency plans are meant to deal with risks after they have occurred. It is sometimes amusingly referred to as “Plan B” (and “C”, “D”, etc if necessary). Contingency plans answer the question “What will we do if …”.
It can be much easier to create contingency plans in advance because you are not under the stress of the risk having already occurred and you have more time to brainstorm the potential plans. Anticipating risks and having well vetted contingency plans keeps you in control of the project and minimizes “crisis mode”.
Here are a few examples:
- If there is a risk of testing taking longer than planned, you can have a list of additional testing resources identified to join the effort if testing falls behind.
- If there is a risk of inclement weather disrupting outdoor activities, you can have indoor activities lined up to keep the project moving.
- If there is a risk of a key resource leaving the project, you can have a consultant resource procured in advance to step in if needed.
As with all elements of Risk Management, conditions may change over time, so the contingency plans should be revisited on a regular basis to ensure they are still viable.
Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at
Risk Management Deeper Dive Part 4 – Risk Mitigation Strategies
With your risks identified, prioritized and monitored, it is now time to develop strategies for managing the risks. The first type of strategy is “Risk Mitigation”. These are actions you can take before a risk occurs that can reduce the exposure to the risk. You should brainstorm these strategies with the members of the project team you identified in the Risk Management section of your “Project Management Plan” (refer to prior posts on this topic).
There are four mitigation strategies you can employ:
- Risk avoidance – this is the most expensive of the risk options. You can spend money or resources to eliminate the risk. An example would be if you have a lesser skilled resource assigned to a task, which raises a risks of on-time completion and/or deliverable quality, you can spend more money for a resource skilled enough to eliminate those risks.
- Risk limitation – this is the most common strategy. You take some action to reduce the probability and/or impact of the risk. One example would be if you are concerned about server downtime or performance during peak loads, you can implement redundancy and load-balancing to mitigate this risk.
- Risk transference – involves handing off the risk to another (willing) party. Examples are buying insurance, or outsourcing services.
- Risk acceptance – if the cost of mitigating the risk outweigh the cost of the risk itself, you may choose to just accept the risk with no mitigation actions. This strategy is typically employed for risks with low probability and/or low impact.
Documenting your mitigation strategies puts you in control of the project. You can manage your risks or they will surely manage you.
Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at
Risk Management Deeper Dive Part 3 – Risk Triggers
In this series Part 1, I addressed Risk Identification. In Part 2, I addressed Risk Probability, Impact and Exposure. In this entry I will discuss the concept of the “Risk Trigger”.
An important aspect of Risk Management is knowing and detecting that the risk has occurred. This is know as a “Risk Trigger”. In some cases it may be obvious. An example of this would be a risk such as “If the project team loses key resource “A”, then the task estimates assigned to “A” will need to be extended which may impact key milestone commitments”. In most cases the PM will know when they have lost a key resource. However, in the case of very large project teams, the key resource may be embedded deep in the project hierarchy, hiding the loss unless there is a communication plan to notify the PM
Your risk triggers must define the method you will use to monitor the risk. For example, if there is a possible change to a government regulation that will impact your project, you can engage your Legal team to monitor the status of this regulation on a regular basis and report any changes directly to the PM.
Here is another example: if there is a risk your server capacity is insufficient to meet peak demand, you might direct your technical team to establish monitors for CPU and disk usage and raise a flag if they are approaching the safe limits.
The lesson here is don’t assume you will just know when a risk has occurred. Define Risk Triggers (even the obvious ones) for all of your risks.
Now that you know your risks, exposures, and when they occur, the next step is to manage them with mitigation and contingency plans. I will tackle these topics in the upcoming posts.
Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at
