So, based on previous posts, I think we are agreed that a PM's job is to continually forecast a project's schedule. And once a project agrees that it will be late, the stop light color would be Red.
Now, if a project has good reason why it went late (like scope changes), the project is able to re-baseline and thus make their color green again.
But here is my question, if a project does not have a good reason, does the stop light stay Red until the project is completed? Even if the PM does their job by forecasting a new end date and then the team stays on track towards that new end date? Are they Red because they missed the original date or are they Green because they are on track for the new date?
Said in another way, do you use Stop Lights as Report Cards or Flags to raise an issue? Thus, in my example above, the Report Card says you are Red until the project ends because you missed the original baselined date. But the Flag says, yeah, we missed the date, but we told everyone and now we are on track for the new date so make it Green.
Karl TwortSenior Project Manager| Fresh EggUnited Kingdom
Nov 21, 2019 12:42 PM
Replying to Hal Levine
...
Wow, great points everyone. Aaron asked, "what does management want?" In our organization, management is also divided, just like this discussion, which is why I came here.
Again, when a project can rebaseline (because the project doesn't resemble what it looked like when the original plan was created) then it is turned green.
The question remains, what do you do when you don't rebaseline. The PM has identified a new target for the team and everyone has been told, but in the end, management understands this project is late. Does the color stay Red so people don't forget its late, or is it turned Green to represent that the project is on track for its new (albeit late) target?
Hal,
I believe this comment "The question remains, what do you do when you don't rebaseline. The PM has identified a new target for the team and everyone has been told, but in the end, management understands this project is late." is slightly contradictory.
If you have identified and addressed a delay, the management have been advised there is a delay but a new date has been set and the team are aware, then I would see this as a new baseline - therefore GREEN.
Keith makes a good point about using status colours for specific scenario (i.e Yellow = Late with Recovery Plan).
You can implement other techniques too for overall project, using Trend status (Up Neutral Down)
In this case, your new plan could be GREEN, but the overall project 'Trend' could show a DOWN arrow. Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Nov 21, 2019 11:18 AM
Replying to Karl Twort
...
Hi Luis,
"You can and should help equate corrective measures that can be implemented to change color to green"
This is what Aaron and I are saying. It seems Sergio is saying that the status remains RED OR AMBER for the remainder of the project, irrespective of a new baseline?
Your answer above is contrary to Sergio's view and in agreement with Aaron and myself?
Or am I misinterpreting?
Dear Karl
Thanks for this comment
You help me clarify my opinion (which is just a perspective and as such is not for or against the opinion of other people participating in this reflection)
After reading what Sergio wrote, to clarify what he wrote I still agree with him
The only questions I have are:
- Whether the project manager's use of crashing to green the project is a change in scope
- How should the implementation of the risk response be handled (this may put the project back in green)
...
1 reply by Karl Twort
Nov 22, 2019 5:36 AM
Karl Twort
...
Hey Luis,
A good discussion is very healthy :) - without differing views, we never get to learn and share opinions.
Saving Changes...
Karl TwortSenior Project Manager| Fresh EggUnited Kingdom
Nov 22, 2019 5:02 AM
Replying to Luis Branco
...
Dear Karl
Thanks for this comment
You help me clarify my opinion (which is just a perspective and as such is not for or against the opinion of other people participating in this reflection)
After reading what Sergio wrote, to clarify what he wrote I still agree with him
The only questions I have are:
- Whether the project manager's use of crashing to green the project is a change in scope
- How should the implementation of the risk response be handled (this may put the project back in green)
Hey Luis,
A good discussion is very healthy :) - without differing views, we never get to learn and share opinions.
The distinction is more of a portfolio management aspect. In the end, we don't want all projects to be green. In your scenario, as long as a PM is doing their job, then all projects would be green in the end.
We define Rebaselining, not as the MSP function, but the idea that the original plan does not resemble the current project so all bets are off and a new plan is created with new dates to be held accountable to. But if a project simply goes late, while of course the PM would figure out a new target, what do you do from a Portfolio metrics standpoint? In the end, how do you show which projects were late and which ones were not?
...
2 replies by Karl Twort and Keith Novak
Nov 22, 2019 9:13 AM
Karl Twort
...
Hey Hal,
The audit of status would allow you to report on the project lifecycle. It is not the PM who sets the status to green, its an agreement as part of replanning with the Stakeholders. I am not saying the PM is never wrong or failing.
If the issue is managed and a new plan generated AND agreed, this should be tracked against the NEW dates going forward.
All metrics should be recorded from the original baselined delivery date. If you replan, that original date does not get overwritten, it remains. The new date is then tracked and for any metrics across the project, it is clear to see the original, the revised and with the 2, the delay on the project.
And this doesn't mean necessarily a PM has failed. There can be many influencing factors against a business-critical delivery that causes replanning and potentially delay.
Time, Quality, Cost. In the event of issues, usually one of these 3 will be affected.
Nov 22, 2019 12:32 PM
Keith Novak
...
Hal,
What you said about striking the new plan vs. showing things late is a very important one, but I use the term "re-baseline" in a specific way that helps with that distinction.
In my industry (aerospace), our projects have a deep value chain, and the schedule can impact supplier contracts, delivery dates, and many other schedules based of the project schedule, but that the PM doesn't directly control. Often we can make small changes to the plan without resetting the whole plan and the domino effect of downstream changes. That saves a lot of work for everyone. It also addresses the political issue of how big the problem must be before all the other stakeholders have to get involved.
Often we show the baseline plan plus the recovery plan for how we will get back to green where we are currently red or yellow. If we can't get back to green, we might have to reset the whole schedule and slide the delivery date, or at least major milestones. Hopefully we can fix the plan though, and the minor course corrections are invisible to most stakeholders.
Karl makes a great point about indicators for whether it is getting better or worse. I use up and down arrows. That is a great piece of information to include in the story. "It is yellow and getting better" vs. "It is red and getting worse", can be a very valuable piece of information when making decisions about how to react.
Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Nov 22, 2019 5:36 AM
Replying to Karl Twort
...
Hey Luis,
A good discussion is very healthy :) - without differing views, we never get to learn and share opinions.
Dear Karl
We are absolutely in tune
Thank you Saving Changes...
Karl TwortSenior Project Manager| Fresh EggUnited Kingdom
Nov 22, 2019 7:19 AM
Replying to Hal Levine
...
Hey Karl,
The distinction is more of a portfolio management aspect. In the end, we don't want all projects to be green. In your scenario, as long as a PM is doing their job, then all projects would be green in the end.
We define Rebaselining, not as the MSP function, but the idea that the original plan does not resemble the current project so all bets are off and a new plan is created with new dates to be held accountable to. But if a project simply goes late, while of course the PM would figure out a new target, what do you do from a Portfolio metrics standpoint? In the end, how do you show which projects were late and which ones were not?
Hey Hal,
The audit of status would allow you to report on the project lifecycle. It is not the PM who sets the status to green, its an agreement as part of replanning with the Stakeholders. I am not saying the PM is never wrong or failing.
If the issue is managed and a new plan generated AND agreed, this should be tracked against the NEW dates going forward.
All metrics should be recorded from the original baselined delivery date. If you replan, that original date does not get overwritten, it remains. The new date is then tracked and for any metrics across the project, it is clear to see the original, the revised and with the 2, the delay on the project.
And this doesn't mean necessarily a PM has failed. There can be many influencing factors against a business-critical delivery that causes replanning and potentially delay.
Time, Quality, Cost. In the event of issues, usually one of these 3 will be affected. Saving Changes...
The distinction is more of a portfolio management aspect. In the end, we don't want all projects to be green. In your scenario, as long as a PM is doing their job, then all projects would be green in the end.
We define Rebaselining, not as the MSP function, but the idea that the original plan does not resemble the current project so all bets are off and a new plan is created with new dates to be held accountable to. But if a project simply goes late, while of course the PM would figure out a new target, what do you do from a Portfolio metrics standpoint? In the end, how do you show which projects were late and which ones were not?
Hal,
What you said about striking the new plan vs. showing things late is a very important one, but I use the term "re-baseline" in a specific way that helps with that distinction.
In my industry (aerospace), our projects have a deep value chain, and the schedule can impact supplier contracts, delivery dates, and many other schedules based of the project schedule, but that the PM doesn't directly control. Often we can make small changes to the plan without resetting the whole plan and the domino effect of downstream changes. That saves a lot of work for everyone. It also addresses the political issue of how big the problem must be before all the other stakeholders have to get involved.
Often we show the baseline plan plus the recovery plan for how we will get back to green where we are currently red or yellow. If we can't get back to green, we might have to reset the whole schedule and slide the delivery date, or at least major milestones. Hopefully we can fix the plan though, and the minor course corrections are invisible to most stakeholders.
Karl makes a great point about indicators for whether it is getting better or worse. I use up and down arrows. That is a great piece of information to include in the story. "It is yellow and getting better" vs. "It is red and getting worse", can be a very valuable piece of information when making decisions about how to react. Saving Changes...
