Article Overview
Project managers require the ability to predict, or at least they are frequently asking team members to predict. Project Status reports generally have a summary where three colors are used to convey the status of the project: Red, Yellow and Green. But how can you be sure any articulation of the situation is accurate? Read the article to find out.
Table of Contents:
Project managers require the ability to predict, or at least they are frequently asking team members to predict. How do we know what our team tells us, is representative of the project circumstances? How can we be sure any articulation of the situation is accurate? The project manager must be able to discern the truth about the project status. Are we in trouble? Are we subject to certain, previously unidentified risks?
Can we expect to be within the projected schedule and cost targets? How do we know?
I was once in a meeting, I was not the project manager but the manager of the test department, the project managers were giving reports to the managers. The project manager was reporting the status of the projects on the company template. The Embedded development manager was there also, Martin, we worked closely together as our two departments had many works product exchanges. This company had a template for reporting on the project that used green, yellow, or red circles to present the state of that project attribute (for example schedule). The project manager presented on a project and all of the attributes were presented as green, and Martin and I looked at each other knowingly. We knew the specifications were late, the software late, the estimated delivery date would be after the desired delivery date. Green, yellow and red circles tell us little.
Project Status reports generally have a summary where three colors are used to convey the status of the project. Red, Yellow, and Green. This seems very simple: Red – serious trouble; Yellow – some risk; Green – everything is good. But if a PM is not clear and has not written out how these colors are used for the particular project, there will be issues.
Once while developing the bi-weekly status report I was asking team members their status. We as a team would develop the colors to apply to each area. One team member stated “Green is a relative color. Which shade of green would you like?” There are various statuses in each color.
A team member gives you an estimate of what they must do to accomplish the tasks. They use experience, and perhaps historical records to generate estimates. These estimates will be fodder for our cost, and duration quotes for the project. These estimates support, or refute the business necessity for the project, and are used as a baseline for the project execution. We will compare the actual rate of accomplishment with our project, and adjust one or more of the following:
- the way we work
- our estimates based on actual rates of accomplishment (historical record)
- alter the scope (tasks and objective)
The comparison of work completed to the original estimate helps when defining the current project status and the ability to interpret the status in a color.
There are folks out there that believe we should not estimate the effort. Now, I can agree that there are times when estimates may not be necessary. However, making a rule that would suggest we should never estimate, that is where I am out. For projects that we intend to do, we are not spending great amounts of company money or resources, as our colleague Glen Alleman, says, de minimis projects. Little at stake, not much effort, no great loss, no great investment. I have worked on these types of projects, there is a time and a place where this works. The question becomes how does one know the project status?
How do we know what is happening? How do we know where we are on the path to success? Early during the project plan developing stage, Metrics and Key Performance Indicators (KPIs) should have been developed or company-specific metrics & KPIs should have been included.
Here is a sampling of possible KPIs:
- Productivity (throughput, units / time)
- Customer Satisfaction
- Earned Value
- Cost Variance
- Schedule Variance
- Issues – resolved/unresolved
- Labor Costs per Month
- Return on Investment
There are notions that metrics are used against the team and team members. This is certainly true. We can use metrics to shame and bully the team members. We may admonish the team members for not meeting their commitments.
Metrics drive behavior, including self-preservation and manipulation to meet benefits to the individual or team. People who are awarded bonuses, for example for performance or new customer acquisition, these things will be prioritized, to include behavior that we do not want. Consider this story:
In the early 1900’s, the French were in Hanoi intending to alter the city to reflect the expectation of French nationals. One part of the program of this effort was to reduce the population of rats as a hygiene improvement, reducing the reducing the spread of disease. To prove the removal of the rats, the tails of the removed rats were used as verification the rats were disposed of. There was a reward for each rat tail removed.
Initially, a lot of tails were handed in, which supposedly reflected a lot of rat deaths. However, the French government soon discovered that Vietnamese vigilantes only cut off the tails and let the still-living rats go, so they could continue to breed and generate profits! They even tried to raise rats for the bounty, by smuggling rats into the city and also through rat farming.1
Definitely not a Green for the project or is it. City leaders were looking for rat tails and that is what they got. But the rats continued to breed, the disease continued to spread, and the city had lots of tail-less rats.
Have you ever gone to your team member, and asked them the status of the actions they undertake on behalf of the project? Then you hear something like “I am ½ complete”, conveniently at the ½ way point of the effort. Then we get to the end of the time defined for the effort and find that the item is about 30% complete. Do we believe that at the ½ waypoint we truly were ½ complete given the present state? Blind trust is one thing. Secure trust is another. Ask the team member that is ½ complete to share with you the status of their deliverables. Maybe show you what's been done. Do this not confrontationally. Neither of you should use the formulae of hours spent versus hours budgeted. This is sometimes a trap.
Updating status is a chore. Updating status to accurately reflect true project status is truly tough! My ½ way complete will be different than your ½ way complete. My Green, Everything is Good, will be different than your Green. Metrics and KPIs help manage this difference. So does define what 20% complete or 60% complete looks like, include hours spent, and verify actual work complete. It is important to develop an environment expected to portray the state of the effort accurately and objectively. This applies to more than just project metrics.
Reference
1The Culture Trip: The Story Behind Hanoi's Rat Massacre of 1902 last accessed 6/28/21