Ask yourself this question: Is your dashboard designed to make your program look good or is it designed to expose your programs weaknesses and problems? If it is the former, how can you use the dashboard to help you successfully manage your program portfolio? This is my second tip in my series on creating effective dashboards to ensure program success.
Remember the Purpose of A Dashboard
The purpose of a dashboard is to provide current information that a controller can quickly use to ensure he or she is on course (and take rapid corrective action if not). It is essential to use this as a guiding principle when determining what you should measure and put on your dashboard.
The Automobile Provides a Simple, Powerful Analogy
When you search for the term “Dashboard” in Wikipedia it brings up an Automobile Dashboard. While there are many different kinds of dashboards, automobile dashboards are likely the most common ones used all of us. As such, it is great place to start a discussion of what you would like on your Program Dashboard.
Do You Want to Know When Something is Wrong?
When you are driving do you want to know when—
- You are going to fast?
- Your brakes are having problems?
- Your oil is low?
Or would you prefer everything to show us a “Green and okay” status regardless of what is really going on under the hood? Would you want it to show real measurements or would you prefer it to express an opinion?
The answers to these rhetorical questions are obvious. As such, why would you not want your Program Dashboard to provide the same service? Unfortunately, Most Dashboards show that everything is Green and okay.
Do You Want to Look Forward or Backward?
Automobile Dashboards are placed underneath the windshield for one purpose: so you can see how your car is doing while you are looking ahead to see where you are going. Your Program Dashboard should do the same: it should show look forward and tell you what problems may occur in the future—not simply report back on past cost and schedule data. Unfortunately most Dashboards simply look at the past (really serving as rear-view mirrors.)
True Forward-looking Metrics That Drive Success
Over the course of fifteen years of program management, I have repeated used six metrics over and over again on my Program Dashboards. These metrics all use objective measures (not subjective guesses) to determine Red-Yellow-Green status. They are easy to understand by all types of stakeholders from mission owners, to engineers to finance professionals. Finally—and perhaps most importantly—they are organized along a forward-looking critical path to provide “Early Alerts” of potential upcoming risks and issues (to they can be addressed before they occur).
Metric #1: Resourcing
The first thing I look at is resourcing (i.e., have you secured the resources, money and critical people and equipment you need to start and execute your project program?) If you do not have these, you will not be able to move your program or project forward. While time –and timelines already published to external stakeholders–will continue to elapse, your progress will not.
Here is how I measure Red-Yellow-Green status:
- Red. You have not secured (i.e., released) the funding for your project or program. You also have not secured critical equipment and functional leads or experts for each area of your program. Without all of this, you are “stuck in the mud.”
- Amber. You have your critical funding, equipment and leads but are not yet fully staffed (e.g., you are hiring or waiting for resources to join your project). As such, while you are able to move forward, you are not able do so at full speed.
- Green. You have all the resources you need. (See Tip 3 to understand how I can make this statement for 1,000-person programs.)
Under this model, every project starts in Red status for resources, them moves to Amber, then Green.
It amazes me how many people skip this metric. If you do not believe me look at all those budgets that allocate money for programs that are started late (or not at all). We have all seen these.
Metric #2: Scope Definition
So once you have your resources you can move forward at full speed, right? Only if you know where you are going. If you have not defined (and gained agreement by all critical stakeholders) on the scope of your project or problem (i.e., what measurable goals you will achieve, problem you will solve of capabilities you will enable) you will aimply burn money and time. (We have all seen this as well.)
As such, once you resources move from Red to Amber on Resources, you need to finalize Goals or Scope. Here is how I measure Red-Yellow-Green status.
- Red. You have yet to complete a measurable Scope document.
- Amber. You have completed a Scoping document but it is under review (either for initial review or due to a Change Request)
- Green. Your Scope is documented and approved by all critical stakeholders.
I also like to keep track of how many Change Requests I have had on the program.
Under this model, every project starts under Red status for Scope and moves to Green only when all critical parties agree on what is needed. Also, every time you go back and want to change scope, you move back to Amber. Why? Because action is required, such as estimation of cost and time impact and determination of whether this change is required for success.
Metric #3: Risk Assessment
A Process Analyst who worked for me at Amgen (Igor Mandrosov) once told me a great expression: “Unmanaged risks grow up to become issues; issues require you change your schedule and critical path.” Risk is not something you should explore at the beginning of a project; it is something you need to manage continuously from beginning to end (I have a whole course on this that I will convert to a blog series one day).
Along these lines, I ask all my project and program managers to estimate risk—both internal to and external from the program. Depending on the type of organization I am, I measure this in currency-equivalence or simple Critical-to-Quailty Six Sigma units. (Contact me if you want to know more). Here is a typical way of using this to measure Red-Yellow-Green status:
- Red. The size of outstanding Internal Risk is 90% or more of the program’s budget OR the program manager is not actively managing risk (see Tip #4 as to how to detect this)
- Amber. The size of outstanding Internal Risk is between 30% and 90% of the program’s budget
- Green. The size of outstanding Internal Risk is less than 30% of the program’s budget
I also like to report the Top 3 or Top 5 risks indicated in the programs Risk Register.
This model forces projects to continuously look at and report on risk to avoid moving into Red status. It also enables executives to focus on programs as soon as large risks are detected (not after they cause cost and schedule overruns).
Metric #4: Execution (or Performance) Assessment
When unforeseen issues emerge (usually do to errors detecting and managing risk) project managers need to begin adapting their plans in response. When issues become large enough (i.e., become Critical Issues) they require changes to the critical path (and milestones) of a project or program.
Along these lines I ask project and program manages to track all issues in an Issues Log. I use the following way to translate this into Red-Yellow-Green Status to detect programs that need intervention before requiring major schedule changes:
- Red. You have re-baselined the schedule three or more times or have five or more outstanding critical issues. (When these numbers reach nine it is time to consider killing the project program. I also automatically mark programs that cannot show me an Issue Log with Red Execution Status.)
- Amber. You have re-baselined the schedule once or have three to five outstanding critical issues.
- Green. You are adhering to your original schedule and less than three outstanding critical issues.
Notice the heavy adoption of Six Sigma Critical-to-Quality measures here. I also require project and program managers to track a count of open Issues (critical and non-critical) in a log or register (and often report the Top 3 or Top 5 on the Program Dashboard.)
This model forces continuous exposure and resolution of issues. This enables you to detect problems earlier (and to drive better risk management), before you miss a major cost or time milestone
Metric #5: Schedule Status
Now we are finally at a (traditional) rearward-looking dashboard metric. This metric is measured using the classic PMBOK definition of Red-Yellow-Green Schedule Status:
- Red. You have missed (or it is no longer possible) to meet your final scheduled milestone
- Amber. You have missed you last milestone (or are late on your current one) but are still able to meet your final scheduled milestone
- Green. You are on time for both your last and current milestones and can still meet your final scheduled milestone
Notice that this allows projects and programs to slip to Amber but return to Green after demonstrated success. (Most Dashboards move quickly from Amber to Red.)
However, if you are using your Dashboard correctly, you should have detected and resolved problems before you reached the point of missing actual milestones. This is critical having a project or program that is considered a success.
Metric #6: Budget Status
This, too, is a (traditional) rearward-looking dashboard metric. It is measured using the classic definition of Red-Yellow-Green Schedule Status (as defined by your Finance department):
- Red. The program is (or is projected to be) over budget by Y% (I typically see 15%
- Amber. The program is (or is projected to be) over budget by between X% and Y% (I typically see 5% and 15%)
- Green. The program is (or is projected to be) less than X% over budget (again typically 5%)
Notice how this measure directly includes input from your Finance stakeholder. Notice also that it is separate cost from time.
The Big Differences in These Metrics
The model uses a series of metrics that require you to prove you are not Red (vs. the other way around). They also are designed to “Go Amber or Red” early to enable you to take proactive steps to prevent schedule and cost overruns. This enables to provide a true Dashboard (not a Rearview Mirror).