Project-based delivery has a natural waterfall-y inclination. Being budget-based, a project usually ends up fixing time, scope, or both. Work progresses through phases of activity, sequenced by milestones. The developers disappear for a few months, emerging from the cave with a shiny treasure. The testers then try to smash it with a hammer. More complex projects can involve dependencies, internal or external. Those additional handoffs need management too.
Progress towards completion is measured by proxy. This is the status of the project. The traffic light (RAG) model represents status visually:
- 🟢 Green - On track to complete by expected date
- 🟠 Amber - At risk, under active management
- 🔴 Red - Not on track, escalate for resolution
Organisations with many in-flight projects aggregate RAG reports for high-level situation awareness. However, RAG reports omit vital context and dampen useful signals. They are too abstract a visualisation technique.
It is common to see RAG reports used as an indicator of project health. Red -reporting projects are then considered unhealthy, necessitating senior management intervention. Environments of low trust and low autonomy are ones of fear and blame. In that context, reporting an unhealthy project status demonstrates a failure. To avoid this perception, bad news becomes suppressed.
This suppressive effect isn't always malicious. It can arise from putting a positive spin on the situation. In my experience it requires less effort to shift from green to amber than it does amber to red. To upper management, amber is 'pay closer attention', not 'get involved'. Switching from amber to red is often a negotiation: is help necessary?
A 'greenshifting' effect occurs as statuses work their way up the chain of command. Reds become ambers, which become greens.
This is unsustainable. Reality catches up at the point of criticality. Green projects turn red without room to course-correct, with nothing to show for it. To much chagrin the project suffers delays. Heads may roll.
With a big bang release, green represents being on track to hitting the planned release date. What usually happens is that a project starts and immediately reports green. The initial plan is 'correct' in that reality has not yet invalidated or impeded it. But, as time goes on, continued reporting of green says nothing about reducing risk. Or validating assumptions. Or realising value. There is a distinct lack of transparency, risking an accumulation of issues.
The concept of being 'on track' becomes less useful as organisations embrace agility. Project-based delivery gives little breathing room for discovery or validation. Agility embraces the uncertainty.
Three principles of the Agile Manifesto come to mind:
- "Working software is the primary measure of progress"
- "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
- "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
These exist to provide focus on what matters: working product. Status is a proxy measure for progress. Working software is the progress, in material form. Demonstrating progress this way makes status meetings disappear!
Scrum's three pillars are: transparency, inspection, and adaptation. These pillars build on one another. Only through the shared understanding of transparency can a team inspect-and-adapt. Concepts such as the 'Definition of Done' aid this shared understanding. Focus is on producing product increments to a regular cadence. The intention is to assess progress not through status, but through working product.
What if RAG reporting is still required in these environments? Start it on red. Only move to green when there is working product that is producing value. This better portrays that the risk is greatest at the start; the point of least knowledge. This will be a difficult sell. Especially in blame cultures. But this is coming from a position of openness. It requires honesty and courage. Focus and commitment will demonstrate its effectiveness.
Boots on the Ground
Rather than keeping activity at arm's length, get involved! Work with teams, the boots on the ground, to set up a sustainable delivery path. Report on progress, not status.
Up front, the incentive is to get something working. To produce an increment that kick-starts development, but also begins to produce value. Through the feedback, plans can be re-adjusted. Features on the 'critical path' may not be as important as suspected. New opportunities present themselves. Large budget overheads become less relevant too. Value streams from the working product provide self-sustaining investment for future development.
Talking about the 'status' moves from the abstract to the concrete. From traffic light colours, to work done. Another feedback loop shortened.