Bugs, issues, and risks: why the distinction matters
Most project teams use these three words interchangeably. That is a mistake. A bug, an issue, and a risk are three different types of problem that require three different types of response. Treating them the same leads to misallocated urgency, inappropriate tools, and — critically — gives Chameleons and Roosters exactly the ambiguity they need to turn a small technical problem into a political event.
Henning Christiansen draws a sharp distinction in Project Management: The Red Pill:
The project manager is responsible for ensuring that every problem in all three categories is properly documented, assessed, and prioritised. That sounds bureaucratic. It is not. It is the mechanism that prevents a small bug from becoming a crisis and a crisis from becoming a Monkey Poker tournament.
Case study: Heathrow Terminal 5 — when the technical succeeds and the operational fails
Heathrow Terminal 5 opening day (2008)
Heathrow Terminal 5 was one of the most ambitious airport infrastructure projects in Europe. It was delivered on time and within budget. It is frequently cited as a construction success. The building was complete. The engineering was flawless. And then opening day happened.
The project team severely underestimated the complexity of getting the terminal operational. Staff were unfamiliar with the layout. The automated baggage system had not been tested at full scale under real conditions. Both of these were issues that existed during the project — they were just never treated as such.
- Staff readiness was never categorised as a risk — nobody asked what happens if staff cannot navigate the terminal on day one
- The baggage system was never stress-tested — integration and load testing were treated as minor items, not critical delivery gates
- External environment was prioritised over operational readiness — public launch pressure overrode internal quality checks
- No one modelled the dependencies — staff knowledge, baggage system performance, and flight operations were treated as independent; they were not
Flawless construction means little if operational systems and end-user readiness are not embedded in the project model. Issues that are not visible in the model are issues that will surface on opening day.
Why project models prevent most bugs and issues before they occur
This is the insight that separates Christiansen's approach from standard bug-management frameworks: most bugs and issues are not random occurrences. They are the predictable consequence of poorly understood dependencies. When a team does not know how one component relates to another, changes and decisions cascade in ways nobody anticipated. The issues that result are not bad luck — they are gaps in the model.
Traditional planning tools — Work Breakdown Structures, task lists, Agile user stories — are excellent at tracking what needs to be done. But they suffer a critical limitation: they do not preserve the connection between goals, tasks, and the relationships between components. They cannot show you that changing the size of a car window will affect the electrical wiring, the insulation, the structural support, and the interior design. A WBS diagram does not provide that insight. A project model does.
"The faster you can identify knock-on effects, the faster the team can adjust and respond to changes in a smart and efficient way. Even a seemingly small change can have wide-ranging consequences in a project."
— Henning Christiansen, Project Management: The Red Pill
What a project model is — and what it gives you
A project model is a structured representation of every significant component in the project, with three elements defined for each:
- Properties — the defining characteristics of the component (dimensions, performance criteria, acceptance standards)
- Actions — what the component does (sends a message, processes a payment, opens a door, authenticates a user)
- Dependencies — what the component relies on and what relies on it (a login system depends on authentication services; the authentication service depends on the database)
A small adjustment to the seat position might require changes to the door placement. That door change could cascade into alterations to the exterior design, the chassis dimensions, and the suspension mounting points. In a traditional task list, that cascade is invisible until someone discovers it mid-build. In a project model, it is visible before anyone picks up a tool.
This traceability is exactly what prevents most bugs. When every component is connected to the goal it serves, every dependency is named, and every change triggers a visible review of related components — the number of surprises drops dramatically. The team is not discovering problems during delivery. They are anticipating them during planning.
Dependencies: the primary source of unexpected bugs
Understanding dependencies is the single most impactful thing a project team can do to reduce bugs and issues. Christiansen identifies three reasons why dependencies matter so much:
- They affect timing — one task might have to wait for another. When that dependency is undocumented, people start tasks before their prerequisites are ready, producing rework.
- They impact risk — if a dependency fails, the whole downstream process can break. An undocumented dependency that fails becomes an emergency nobody anticipated.
- They help manage change — when dependencies are mapped, a change request triggers automatic visibility into everything that change will affect. When they are not, the project manager is guessing at impact.
Agile methodologies often have teams executing sub-tasks simultaneously, even when those tasks are interdependent. This works when the project manager maintains a clear view of the bigger picture. When that view is lost — when parallel tracks are running without a shared model — the rework at the point of integration creates more bugs than a sequential approach would have. Five times more efficient under the right conditions; five times more chaotic under the wrong ones.
When bugs and issues arrive: the two-track response
Even the best-modelled project will have bugs. Issues will arise that no model predicted. The question is how you respond — and Christiansen is very specific that the response must operate on two tracks simultaneously.
Bugs as Monkey Poker: the political dimension
This is the part of bug and issue management that no technical framework covers. Bugs, issues, and risks are opportunities for Chameleons and Roosters to play Monkey Poker. These individuals may exploit problems to shift blame, gain visibility, or undermine others for personal gain.
When a bug is discovered, the Chameleon's first move is often to amplify the crisis — not to solve it. The goal is to be visible in a high-stakes moment. They escalate to senior management before the project manager has had time to assess the situation. They use the bug as evidence that the project approach was always flawed. They propose "urgent" solutions that happen to align with the features they wanted all along.
The Rooster's version is different but equally damaging. They use the bug as an opportunity to pursue technically interesting problems that are not actually the highest priority. They spend time on elegant root cause analysis when a working fix would have been sufficient. They use the disruption to work on the parts of the project they find most personally engaging, regardless of what the project actually needs.
This article references the political dynamics — Chameleons, Roosters, the Monkey King, Honey Bees, Parrots, and the Unicorn PM — that run beneath every project. Full guide: Stakeholder Management and Monkey Poker →
If Monkey Poker around a bug is allowed to escalate, it will eventually draw in the Monkey King — the senior power figure who rarely intervenes but is decisive when they do. The Monkey King will only be drawn in if a Chameleon or Rooster believes they can gain the upper hand. A project manager who demonstrates clear control of the problem — with a model-based understanding of scope and impact, a documented resolution plan, and transparent communication — makes the Monkey Poker move too risky. The Chameleon or Rooster who escalated becomes the person who disrupted the Monkey King. They lose.
Prevention: how to build a project that produces fewer bugs
The most effective bug prevention strategy is not testing — it is modelling. A well-structured project model, with dependencies mapped and properties clearly defined, surfaces most potential problems before a single line of code is written or a single component is manufactured.
Define every model before work begins
For every model and sub-model in the project, the following should be documented: which goal or objective it supports, which skills or expertise are required, the time estimate for development, and any hard deadlines. When this information exists, the team has the context to identify problems with their own work before those problems propagate to other components.
Map dependencies explicitly — then review them at every gate
Dependencies are not stable over the life of a project. As work progresses, teams discover implicit dependencies that were not visible at the start. At every phase gate or milestone review, the dependency map should be refreshed. Ask: have any new dependencies emerged? Have any assumed dependencies turned out not to exist? Have any dependencies changed in nature or timing?
Use the model to evaluate every change request before accepting it
Every change request should trigger a model review: which components does this change affect? What are the downstream consequences? What is the realistic effort to implement it fully — not just the feature itself, but all the dependent components that also need to change? When stakeholders see the full cascade of a change visualised through the model, genuinely valuable changes get approved faster and politically-motivated changes get dropped more quietly.
Record actual vs. estimated time on every task
Time estimation data is the most underused asset in project management. When actual durations are systematically recorded against estimates, two things happen: future estimates become more accurate, and the project manager can see in real time which tasks are consistently running over. That pattern is almost always a symptom — of underscoped work, of hidden dependencies, or of a team member who is struggling but has not surfaced it yet. The data surfaces the problem before it becomes a bug.
What to do — and what to avoid
- Distinguish clearly between bugs, issues, and risks — each requires a different response
- Build a project model with properties, actions, and dependencies before planning tasks
- Map all dependencies explicitly and review them at every phase gate
- Use the model to assess the cascade impact of every change request before accepting it
- Record actual vs. estimated time on every task to surface hidden problems early
- When a bug is found, identify the affected model components before communicating externally
- Stabilise the external environment first — communicate after understanding, not before
- Communicate problems to external stakeholders before they hear through informal channels
- Maintain strict scope freeze during problem-solving — no new requirements until resolved
- Document every bug, issue, and risk — and their resolution — throughout the project
- Don't treat bugs, issues, and risks as interchangeable — they need different responses
- Don't rely on task lists alone — they don't show dependencies or cascade effects
- Don't communicate a problem externally before you understand its scope and resolution
- Don't allow Chameleons to use a bug as an opportunity to push new features
- Don't let Roosters use disruption as cover to work on technically interesting tangents
- Don't skip end-user and operational readiness testing — Heathrow T5 is the warning
- Don't treat parallel execution in Agile as an excuse to ignore dependencies
- Don't escalate to the Monkey King unless you have a resolution plan ready
- Don't accept change requests during a crisis without a full model-based impact assessment
- Don't leave actual vs. estimated time unrecorded — that data is your calibration tool
How the Unicorn PM handles bugs
The model is the diagnostic, not just the plan
The Unicorn project manager does not treat the project model as a planning artifact that becomes irrelevant during execution. They use it as a live diagnostic tool. When a bug is reported, the first move is to open the model and identify which components are affected — before any communication happens and before any solution is proposed. The model makes the invisible visible.
Facts as defence against Monkey Poker
When bugs create political pressure — and they always do — the Unicorn PM responds with facts from the model. Which specific components are affected. What the realistic effort to resolve is. What the downstream consequences of the proposed workarounds are. When stakeholders are required to justify their proposed responses against the model, the political moves lose their traction. A Chameleon's "urgent feature" becomes very difficult to defend when the model shows it would require changing 14 components and add three weeks to delivery.
- Document every problem, every resolution, and every decision — the paper trail is both a learning resource and a political shield
- Praise the team publicly when a bug is found and fixed well — the discovery of a problem is not a failure; it is quality assurance working
- Stay calm when Monkey Poker escalates around a bug — the project manager who demonstrates control wins the game before it starts
- Reinforce the Monkey King's interests through transparent, model-based communication — keep them confident, keep them dormant
Bug and issue management in Proglar
Proglar connects the project model to the bug and issue register, which means that when a problem is logged, its relationship to the affected model components is immediately visible. The cascade of dependencies is not something the project manager has to reconstruct manually — it is built into the platform's structure from the moment the project model was defined.
When a bug is reported in Proglar, it is logged against a specific task or model component. The model shows which other components depend on the affected one, giving the project manager the impact picture before any communication goes out. Time tracking data is visible against each task's estimate in real time, so patterns — tasks consistently running over, components that repeatedly generate rework — surface automatically rather than being discovered at retrospectives months later.
Fewer bugs start with a better model
Proglar connects your project model to your bug register, your dependencies to your change impact analysis, and your actuals to your estimates. Build projects that surface problems early — and manage them without the Monkey Poker. Try free for 30 days.