Please login or join to subscribe to this thread
This is an organizational decision about what project variable must be taken into consideration to decide about the color (scope, time, cost). When you have the variable decided then the organization must decide about the value limit to use red, yellow or green. In our case is risk.
You could assign thresholds to your KPI's for measurement criteria. For example, if we are measuring Scope, Cost, Time, assign each a threshold for each RAG color (Red [n] to [n], Yellow [n] to [n], ....
Based on the status of the three chosen criteria, the overall status is assigned. If this is automated, it makes it more objective - just plug in the numbers.
This will add consistency and context. The thresholds can always be adjusted if need be...
Edit: Yes, Sergio is absolutely correct. Check to see if this is defined at the organizational level.
Our easiest and sensible way of identifying the statuses was this measure below,
7-10% variance either in schedule or cost is RED(we say which constraint is RED on the report, schedule budget or resources)
4-7% is Yelllow
Less than 4% is Green.
I have worked at different orgs where in others they made is so very complicated that most of it did not make sense to me. It was not worth the time in we spend in the calculation. I would rather do problem-solving(putting the project back to green) than spending a ton of time doing the calculations and reporting the statuses.
Similar to Deepa, we use
The trick is to make your yellow close enough to allow you to make corrections easily. The larger your yellow threshold, the harder it is to bring your project back on track.
Thank you for the feedback thus far. Unfortunately, I am not at a point where I can do anything quantitatively (such as a percentage tolerance). Below is what I am proposing and would like your feedback. I don't need feedback on why I need to go quantitative, but rather feedback on ideas to improve the qualitative/subjective criteria so they can be a little bit more effective:
1. An issue has surfaced and we do not believe 100% project success can be obtained due to the discovery. More than likely we will either miss the desired date, or exceed budget, or not be able to deliver the desired scope by the target date.
2. Go Live date has been missed and there is no revised date agreed upon with Business Owner
An issue has surfaced and the project goals are in jeopardy. We are triaging the issue(s) and at this time and believe we can still be successful
The project does not have any known issues at this time and is performing to plan
That's a reasonable approach, but in most complex projects you'd end up being amber most of the time - is that something your leadership team is willing to stomach? Also, based on the definition of red, the only way to get back to green is to change your baselines via integrated change control.
I agree with a Combination of "Definition of RAG status" from Samuel Vaddi and the "Back to Green" approach by Kiron Bondale.
That's exactly how I would define it without making percentage estimates.
Please login or join to reply