Live Day: November 4, 2021, 8:30 a.m. to 6 p.m. EDT | On-Demand: November 5, 2021 – February 6, 2022 | Online Conference
Please login or join to subscribe to this thread
Hi Traffic lights can be useful for highlighting for representing the status of some project activities, phases, subsystem or work packages. They can be very dangerous because of limited options.
I did once have a manager that only wanted hear good news and insisted on traffic lights so I decided to represent schedule status the following way to represent high level schedule status with five options available.
1. Traffic lights all white and frame greyed out to represent work that is not planned to have started yet.
2. Green Light for work underway.
3. Yellow light for issues or significant risks that threaten the work being completed on time.
4. Red Light for work overdue or late
5. Traffic lights all white and frame greyed out with a big green tick across it once work is completed on time.
Sorry I know this is not specifically what you were asking but I hope it helps.
Hi - RAG status (Red, Amber, Green - as in traffic lights) - need to be defined on any dashboard - to ensure their meaning is understood.
I define baseline milestone RAG as
Red - the milestone is missed (has passed its baseline date)
Amber - the milestone may be missed - this is a cautionary indicator
Green - on target - the milestone will be met.
A Red status for milestones that are missed - represents any days in excess of the agreed baseline days - I just show a variance in terms of days beside the baseline date. I dont use any tolerance for Red - missed is missed.
If a milestone baseline date is missed - you need to establish a new forecast date - which is an unplanned / unbaselined date. To baseline the new milestone date you need to implement change control to agree the new baseline. Change control needs to assess the impact of the change - in terms of scope, resources, time, cost and quality - and the sponsor needs to agree to the change.
Amber - is hard to determine - I don't use any predefine tolerances. So if the milestone is a month away - you may know now that it will be missed so a PM will flash it Amber to indicate this - and you need to establish a new forecast date. Amber is really is an early indicator that a milestone may go Red - or an indicated that a new forecast date needs to be baselined (via change control if it is expected to be badly missed).
Green - all is well for this one - there are no tolerances - because it will be delivered on target.
You don't need to change control every milestone that is missed or delayed - but you do need to understand where a milestone is delayed - if it impacts the overall project baseline, time and cost.
Management need to understand WHY milestones are missed - so the dashboard should include KPI (Key Performance Indicator) around Resources for example. Or Dependencies. These are the main factors - reasons WHY a project can not meet its milestones.
If your management want to RAG the baseline of a project - you will need to dashboard
a) the phases of a project and
b) their associated milestones - and their status.
d) inbound and outbound dependencies.
Most project have external dependencies - and until they receive what they are dependent on from a 3rd party - the project can not progress - this is why dependencies need to be tracked - particularly external dependencies as they are not under the control of the project manager.
The overall project RAG / status can not be determined until the project plan has been baselined by the project manager. A baselined plan is an indicator that the project manager is happy he/she can commit to meeting the dates set out on the project plan / schedule to agreed time and cost and scope. A project manager who needs to agree a new baseline will do so under change control.
By the sounds of it your management need some mentoring around project management and why projects fail. There is no point in supporting a management culture that is adverse to a Red status - milestones and projects fail to deliver on time for a reason.
Its the reason that needs to be transparent - so that isssues causing project to deliver late are transparent - and can be rectified.
Otherwise you will end up with very unhappy project managers. Its up to the individual project managers to issue Flash reports showing the status of their project - and listing their RAIDs - Risks, Assumptions, Issues and Dependencies. That is the only way the tracking of baselines will have any meaning.
Tolerance should ideally be agreed and signed off by the Steering Committee up front in the Project Management Plan. This way there is a clear understanding of the rules. For software development projects we have used a negative float tolerance that is 10% of the duration before Go Live with the last week allowing zero days tolerance for slip. eg at 50 days out you have 5 days negative float allowance in your schedule. This is either a green or red light scenario.
For deviation against baseline any tasks on the Critical Path have zero tolerance and hence report red the moment they slip for other activities a rule of thumb that I use is 0-5% green, 5-10% amber, plus 10% red. This allows early identification and mitigation. A risk profile will support your reasoning for running different tolerances in different phases of the project.
Hope this helps.
In CMM organizations llike ours one the percentage of deviations(for schedule, efficiency, quality, customer leakage etc) are calculated based on past project performances. Every year these indices are updated based on various different types of projects executed in the same year. Let say If the data calculations shows that on an average schedule is missed by 3%, it is considered as capability of the organization with respect to schedule performance. Every year the PMO sets the better target for next year for delivery unit so that required improvements can be targetted.
I feel every organization should set their own deviation figures and work towards improvement every year. Iif this is done on regular basis it will increase overall capability of the organization.
I have observed that deviation of 0-5% considered as Amber, 5-10% considered as red. Every project should properly check the customer requirements before setting these parameters.
Hi Anonymous, great post and replies by all. Different PMOs naturally have different levels of deviation and the trick is to arrive at these levels by way of policy. We see many IT PMOs adopting a 10%, 10-25%, and more than 25% set of threshholds for Green (Good), Yellow (Caution), and Red (Trouble). And though you didn't mention it, we also see the re-baselining of a project as a measure that is often reported. For example, if the project has been re-baselined three times or more, this would stand out as a red flag or yellow stop light. The idea is that the project indicators for schedule and budget might be green (good) on account of a decision to re-baseline and in essence reset the measurements. But, is the project really green (or good) at that point? A project that has been re-baselined several times might not be okay even though the current stoplights of record indicate otherwise!
Please login or join to reply