Green in the System, Red on the Ground

Why Does Updating Projects Become a Task Completed the Night Before the Steering Committee Meeting?

In many of the organizations I have worked with, the biggest problem was neither the lack of a project management system nor the absence of methodology or standards. The most recurring problem was simpler yet far more critical: updating data in the system and writing these updates in an accurate manner that reflects reality.

The scene is familiar to anyone who has worked in a Project Management Office. As the steering committee meeting approaches, reminder messages start pouring in. The project manager opens the system to update completion percentages that have remained stagnant for weeks, typing generic statements about "work in progress" without clarity on tasks or challenges. Then, they enter the meeting with the project marked green, only for surprises to emerge weeks later.

The project did not stumble suddenly; it was struggling on the ground all along, and green only in the system.

Why Are Updates Delayed?

The first reason lies within the teams themselves. The experience of team members varies, making knowledge transfer and experience sharing between them difficult.

With employee turnover and frequent personnel changes, good practices do not last long. Every new employee starts from scratch, making it difficult for the organization to maintain a clear and stable practice over extended periods due to varying levels of general and domain-specific practical expertise.

The second reason is workload pressure. When project volume and burden increase, updating status becomes the lowest priority.

The project manager and team cannot update data continuously, so they postpone it until right before the meeting—often to the very last minute to ensure it captures all details. However, in such cases, many learned lessons or resolved challenges are often left unmentioned in the update.

The third reason is rarely stated clearly, which is the project manager admitting: "I have reached my maximum workload capacity" in work or within a project—or sometimes across multiple projects simultaneously. Many project managers handle several massive initiatives at once and never reach the point of admitting they have reached their limit. They do not say: I am struggling, I cannot update reports, I have no time to develop myself. When this goes unsaid, drained energy translates into delayed updates and incomplete data.

What Gets Lost Along the Way?

When an update is reduced to just a "completion percentage", we focus on the number and forget what is explained by "real risks and challenges"—current challenges delaying work today or in the future, future risks that might hit the schedule a month from now if action is not taken today considering mitigation mechanisms to reduce impact on project flow, and even past challenges that explain how the project reached its current state.

An update that lacks this information gives an incomplete picture, even if its numbers are correct. Executive management does not make decisions based solely on percentages, but rather on understanding what is happening and what might happen.

From My Experience: "The Project Will Turn Red"

In most systems, project status uses three colors: Green means on track, within an acceptable deviation margin of 3% to 5% depending on the organization. Amber/Orange means off track with some challenges requiring a mechanism to restore it to an acceptable state. Red means troubled, requiring immediate intervention and a review of existing challenges and issues.

I took over an amber project and communicated its actual status to everyone. After taking over, it started drifting toward red, so I did not wait to surprise anyone at the committee meeting.

I stated clearly: The project will turn red, but it will return to amber and then to green, and here is the action plan to bring it back.

The plan implied real pressure on the timeline and working on multiple tracks simultaneously. We executed multiple activities in parallel—a decision with its own risks requiring close monitoring—but it accelerated the project's return to track without submitting a change request or baseline modification.

The lesson I learned: an early declared red status is not a failure; rather, it provides insight into the resolution mechanism. The real failure is hidden red status, because it will eventually surface regardless of how long one conceals it. Honesty in status updates did not weaken my position before management; instead, it gave me the space and support to correct the course.

Who Are You Writing the Update For?

An update is a message, and a message is useless if it reaches the wrong person. Before every update, a project manager must ask: Is the person being contacted truly capable of executing the required action according to project needs? Do they have the authority and mechanism to help me?

Many project managers get stuck for weeks with people who lack both authority and capability to resolve issues. They wait for a reply that will never come, while the project pays the price.

Here comes the role of escalation. Escalation is neither a complaint nor an accusation against anyone; it is a legitimate management tool. In many cases, a project needs it to regain its rhythm, improve performance, and bring its indicators back on a healthy track. What matters is doing it at the right time, to the right level, and with accurate information.

What Should We Do?

Because this problem recurs in almost every organization, it is not enough to demand that teams "update". We need a clear mechanism, explained with examples, answering four questions: what to write, where to document it, when to update it, and who receives it.

Examples here are more important than explanation. Notice the difference between two updates for the exact same status:

Superficial Update: Work on Phase Two was carried out, current completion rate is 60%.

Realistic Update: Completion rate is 60% compared to 70% planned. Reason for delay: pending approval of requirements from the beneficiary department. Expected impact: two-week delay on delivery date if not approved before the end of the month, as of October 31st...

Required Action: Department Manager intervention to approve requirements, or escalation according to approved governance by October 31st at the latest....

The first merely fills a field in the system; the second provides the decision-maker with what they need to act.

When teams change, the mechanism and examples remain, so the organization does not start from scratch with every new employee.

Conclusion

Updating is not filling out a system before a meeting. It is an honest message sent to the decision-maker while they still have the capability to act.

A project flagged red early can be saved. However, a project that remains green in the system until the last moment often lingers in the system for years, lacking both the mechanism and the capacity to admit that it will not succeed or complete according to requirements.