I am a project manager within a PMO and am in the process of calculating earned value. While I understand the methodology and the data I am recieving is solid, I am curious about what expereinces others have had in translating this into an executive dashboard that senior management can a) understand and b) want to use. I have the standard curves but when it comes to "red light vs/ green light etc" there doesn't seem to be a standard approach/methodology to use (i.e. if project A is 1 % ahead of schedule = green light etc)
Does anyone have any information or links to exsiting docs that could help?
Thanks in advance Saving Changes...
In General:
Green = On-time, on-budget, and the client is happy with the quality and scope. There is allowance for being slightly behind (in my opinion) if the issue is contained only in one area (e.g. CPI is .9) yet everything else is okay and you have plenty of time to catch up.
Yellow = The project is partially in trouble (either late, over-budget, etc.) and can be recovered with moderate effort
Red = The project is in serious trouble and it is unlikely that the projet can be recovered
For large projects, you'll want to show green, yellow, and red color codes for sub-categories (e.g. Budget, Scope, Quality, Schedule) ... and then have those categorise roll up into one big dashboard.
So, if say scope, quality, and schedule are green on your project and your CPI is .9 (cost = yellow), I'd show the project as Green .... if scope is short (yellow) and your CPI (is .7 (budget is yellow/red), I'd show the total status as yellow.
What I have done is to always define the meanings for dashboard that I've done AND include a Legend in the back that describes the meaning behind green, yellow, and red.
When you are initially rolling out your dashboards, get the buy-off on the meaning.
Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Hi Fraser, excellent post and the reply by Marcus is very good too. Dashboards are very useful tools. As Marcus stated, as you roll-out and use your dashboard it is helpful to get buy-in and sign-off as to the various meanings of the dashboard elements. One approach is to ask your executive what level of information is comprehendable, useful, and actionable. Toward that aim, the dashboard need not be overly complex or detailed, unless desired or requested and can be whatever format or tool most appropriate for your organization; from PowerPoint, to Excel, and of course to PPM application dashboards. And even when you do have a sophisticated PPM application with dashboarding, you may have business and organization considerations that your executive would like to see incorporated into the dashboard that may be independent and outside of your PPM application dashboard. Let the dashboard serve the user's need. Keeping the needs of that user in mind is half of the solution. Cheers. -- Mark Perry, VP of Customer Care, BOT International Saving Changes...
For US government project that must report their status to OMB using EVM, if SPI or CPI are greater than +/- 10% (<.9 or >1.1), then a corrective action plan is required for each leg of the WBS.
But, is .9 red or yellow? Can't say. What I do suggest is that you only ever use RYG stoplight reporting with clearly defined thresholds. Objective, not subjective.
Creating Reports and Dashboards-
Assumption: When a metric is applied to data, it creates information. If a metric has not been applied then it is a table of data (data dump), possibly filtered, but just a table.
Assumption: A "Report" contains information, analyzed to define the condition of the project at the time of the data collection.
When defining a report, ask yourself:
-What is the objective of the report?
-What data is needed as Input?
-What metric be applied?
-When will the data be ready as Input?
-What information will be derived by applying this metric to the data?
-What conditions/situations of the project's status could be derived by analyzing the information in the report?
-Who is the audience/receiver of the report?
Use these questions with your customer the next time they ask for a report. It will help eliminate creating misleading report information, and keep you active on real project work. Saving Changes...
I am the manager of the CPMO for a large organization and have accountability for the definition and creation of portfolio based dashboard that is reviewed by our Executive. As Mark noted, and is the nature of a CPMO, we do have several non-project initiatives listed on our dashboard. Naturally, we are now struggling with the interpretation and representation of the reported information as the dashboard is setup for project reporting. Does anyone have any guidelines or reporting standards that can be applied to operational initiatives? Saving Changes...
Andy JordanPresident| Roffensian Consulting S.A.Cherry Grove, AB, Canada
Not sure how I missed this thread - sorry for the tardy response. I could wax lyrical for several hours on this topic, but not sure that anyone wants me to :-). I have seen operational type initiatives handled a number of ways, and I think the 'right' answer depends very much on the individual organisation. My personal belief is that truly operational work has no place on a dashboard. It may fall under the control of a PMO, but trying to use project like metrics to measure it is akin to trying to put a square peg in a round hole. I would much rather see a separate set of operational metrics applied, and if that means an additional page in hte report, then so be it. However, the counter argument is that there is benefit in having a consistent look and feel to the tracking of all work, and this usually means the creation of a 'pseudo project' for this operational work - creating a project for 'maintenance 2007' for example that effectively treats the year's activities as a separate project. This will allow you to measure things like costs and resources, and you may be able to assume that the scope is fixed, but I don't find this approach very flexible for dealing with one-off situations. I would much rather see organisations identify what is important to them in terms of operational metrics and track those in an efficient manner without worrying whether it fits nicely into a project dashboard. Andy Jordan, President, Roffensian Consulting Inc., www.roffensian.com Saving Changes...
George JucanManaging Partner| Organizational Perfomance Enablers NetworkWoodbridge, Ontario, Canada
I agree with Andy, the control boundaries are specific to each organization – and I also treat them independently for each project too. The level of acceptable variation, to still consider the project “in control” (e.g. “green” status), is dependent on the organization’s ability to cope with risks and delays as well as on the particular project’s impact if not completed “on time, within budget, full scope”. For example, a project executed for an external customer on a fixed budget and still penalties for delays might be allowed a very small margin of deviation, while an internal project to enhance the organization of the shared folders might be allowed to be late with weeks (there is a repository already working, there is no significant impact if it’s reorganized next week or next month).
When I need enhanced precision I define the levels based on the complexity values for scope, time and cost areas (see http://gantthead.com/content/articles/231775.cfm). I consider Cv as the sum of complexity values for scope, time and cost, and Er from 0 to 5 as the organization’s adversity to risks (0 = risks are natural part of the process, 5 = no risks accepted). With these notations the “green/yellow” boundary is calculated as G= (+/-) Cv / (5.25*Er), while the “yellow/red” boundary is R= (+/-) Cv / (2.62*Er).
