A former colleague of mine, Rob Young, recently lamented the lack of rigor in governance by new project managers. This is especially evident in red / amber / green (RAG) summaries in status reports, where a failing project can still be reported as green. “Clearly, there needs to be a common understanding of the status metric that is being reported against and the rationale for moving between statuses.”
Rob is absolutely correct: You can’t manage what you don’t measure, and you can’t effectively communicate your measurements if there are no well-understood units of measure. And as Glen Alleman regularly insists, the dimensions measured and units of measurement need to be meaningful to the decision-makers and applicable to their problem domain.
Selecting Project Dimensions for RAG Measurement
While I am an advocate of using RAG status indicators to direct attention to specific areas, such as schedule, budget, quality, staffing, and so on, I believe that reporting an overall project status or risk status using RAG is “governance for dummies.” These are complex topics deserving of a short narrative description that invites inquiry into the details. More on that below.
Prior to the project kickoff, select dimensions that are both relevant to the project and meaningful to your stakeholders, and create a scope statement for each one. Schedule and quality are always relevant, and unless you have an unusual situation, so is budget. Projects with a dependence on shared resources should include staffing. You may also need dimensions for software development, change management and communication, data record conversion, and so on. Then describe how you intend to measure that aspect of your project, as you move from one phase to another. For example, your projected budget should be broken down by month, or whatever shorter time period is meaningful. With that assumption, consider this description:
Budget: Cumulative non-BAU spending to date matches cumulative projected spending in the approved project budget, with approved changes. Capital budget expenditures tracked separately from those to be treated as operating expenses.
- Green: Cumulative capital spending not more than 3% over budget and operating expenses not more than 5% over budget and no anticipated events are expected to change this state
- Amber: Cumulative capital spending more than 3% over budget or operating expenses more than 5% over budget, or an anticipated event is expected to put the project over these limits
- Red: Cumulative capital spending more than 5% over budget or operating expenses more than 10% over budget, or an anticipated event is expected to put the project over these limits
This definition is both precise and verifiable throughout the project life cycle. Other dimensions, such as quality, are more complex and may need different definitions in different project phases.
Trends and Transitions
Once you’ve reported an amber or red status, you have their attention. But when you transition from amber in one reporting period to red in a subsequent period, or red back to amber, you are indicating more than just a status—you are describing a change of state.
- Green to Amber: An issue has been identified that is driving the project over budget, and corrective action is being taken. If the underlying issue has not been identified or no mitigation is possible, report as Red
- Amber to Red: The underlying issue that drove the project over budget has not been corrected and executive management attention is required
- Amber to Green or Red to Amber: The underlying issue that drove the project over budget has been corrected and the overage recovered, or the adjusted budget has been approved
- Red to Green: Not an acceptable transition in a single period
I’ve seen some status reports that use arrows to identify trends. For example, an up arrow indicates trending toward green, down represents trending red, and an arrow pointing to the right indicates a steady state. Trend reporting can be useful, if accurate, but if you report an upward trend from amber in one period and then red in the next, you are going to face some well-deserved hard questions. If you decide to report trends, be sure your stakeholders understand what you want them to do with the information—a down arrow may not mean “all hands on deck.”
Dimensions Where RAG Isn’t Appropriate
As I mentioned earlier, overall status and risk are not RAG-appropriate. Smart stakeholders and sponsors don’t get bogged down in the details, but they want the ability to identify, investigate, and act on a specific, troublesome weed. Facilitate this with your narrative descriptions. If a risk has morphed into an issue or has been overtaken by events and is no longer a concern, say as much. If the schedule has slipped due to resource conflicts with another project or with business as usual, be specific. One team’s solution can easily become another team’s issue. It may be that the conflicting demand really has a higher priority, but let the sponsor and stakeholders make the decision, explicitly.
I’ve also learned to like using “++” and “–“ to flag changes in scope. For example:
- — Interface to FloximateKersplunk moved to Phase 2, per Nixard Richon
- ++ Additional testing of GL interface approved and funded by CFO
Also, as Rob points out, “Especially on T&M projects there should of course be no reason not to report spend (in hours and dollars), and estimate to complete.” If you are managing a project with multiple vendors, it may be useful to break out their costs separately, in a detail section. If one vendor is way over budget, while the others are on target, don’t just report amber.
Actionable Information in Digestible Form
The people who are reading your status reports can handle mixed metaphors, so aim for clarity and accuracy rather than mind-numbing consistency. Deliver actionable information and recommend actions. You can be concise and clear, if you seek to communicate rather than just fill out some weekly form.
Consider the ultimate in status reporters: those folks who forecast the weather. They start with current temperature, humidity, precipitation, and so on, and then talk about their projections. You quickly learn whether you need an umbrella or sun block, and when you need a sweater, because they don’t just give you the numbers—they help you reach conclusions. Watch, and learn.
For more brilliant insights, check out Dave’s blog: The Practicing IT Project Manager