Before a project fails, it develops issues.
Not crises. Not failures. Issues — small, specific problems in a project's documented understanding that are present but unnamed. A requirement that is technically written down but means different things to different people. A scope assumption that no one has verified with the client. A constraint that is obvious to the technical team but absent from the commercial agreement.
These issues do not usually stop a project on their own. They accumulate. Three unresolved ambiguities become four conflicting interpretations in the design phase. One unacknowledged assumption becomes the foundation of a decision that cannot be reversed. By the time the problem is visible, it is no longer an issue — it is a cost.
The discipline of issue management starts with naming them.
What an Issue Is
An issue is a specific, documentable problem in a project's body of knowledge.
It is not a task. It is not a risk. An issue is a deficiency in a project's understanding at a point in time — something that is known to be problematic or unclear but has not yet been resolved.
Issues come in four distinct types, and the type matters.
A gap is information that should exist but does not. The scope boundary has not been documented. The decision owner has not been named. The acceptance criteria for a feature have not been written. A gap is an absence.
An ambiguity is information that exists but cannot be relied upon. A problem statement is present but describes the problem at a level of abstraction that cannot support design decisions. A feature requirement is written but contradicted by a statement elsewhere in the document. An ambiguity is present but unresolvable without further input.
An assumption is a decision made without explicit input. The delivery team has proceeded on the belief that a particular user will behave in a particular way, or that a particular integration will be straightforward, without verifying either. Assumptions are not wrong by definition — some are reasonable and some are validated by experience. What makes an assumption an issue is that it has not been surfaced and confirmed.
A conflict is a contradiction between two documented positions that cannot both be true. The scope document says out-of-scope; the requirements document says in-scope. The brief says the primary user is an operations manager; the SOW says the primary user is a financial controller. A conflict cannot be resolved by reading either document more carefully. It requires a decision.
Why Most Issues Stay Hidden
Issues are not missing because teams fail to notice problems. They are missing because the discipline for surfacing them does not exist.
Most delivery processes treat documentation as binary. Either a document has been produced or it has not. The document exists, the checkbox is ticked, and the project advances.
This binary model has no mechanism for asking whether the document is structurally sound. It verifies existence, not substance.
Problems that would surface immediately under structured review — a scope boundary defined entirely by implication, an acceptance criterion that cannot be tested, a user persona described in one sentence — pass through the binary check undetected.
They remain in the project as unmarked objects. Every team member who reads the relevant document may sense that something is off. None of them have a shared name for what they are sensing, and none of them have a place to record it. The issue lives in people's heads, not in the project's documentation.
The Value of Named Issues
Naming an issue changes what a team can do with it.
An issue that lives in someone's head can only be acted on by that person, in the moment they are thinking about it. An issue that is written down, typed, assigned a severity, and associated with the artifact it was found in becomes something the whole team can see, reason about, and respond to.
This is why issues should be first-class objects in a delivery system — not notes in the margin of a document, not items in someone's personal task list, but structured records that the system can track over time.
A first-class issue has:
- A type (gap, ambiguity, assumption, or conflict)
- A severity (how much this issue matters if left unresolved)
- A status (open, resolved, or deliberately deferred)
- A connection to the artifact where it was found
- A connection to the truth conditions it affects
With this structure, the delivery system can answer questions that would otherwise require manual review: Which issues are still open? Which artifacts have the most unresolved gaps? Which open issues affect whether this project is safe to advance to design?
Issues Are Not the Same as Missing Knowledge
A subtle but important distinction: issues can exist even when a project's foundational knowledge appears to be in place.
A project may have a well-formed problem statement that satisfies the truth condition for project purpose. That same problem statement may contain an ambiguity — the revenue model is mentioned but not described — that has not yet been resolved.
The truth condition is satisfied. The issue is real.
This matters because a delivery system that conflates issues with missing knowledge will misrepresent the project's state. If truth conditions appear satisfied, it will report green. If issues are tracked separately, it can report: "Truth confirmed, but three open ambiguities in this artifact require attention."
The first reading encourages complacency. The second preserves honesty.
This is why issues and truth conditions are separate objects. The truth condition answers whether a fact is established. The issue answers whether the evidence for that fact is clean.
Severity and What To Do About It
Not all issues require the same response. A low-severity gap — a secondary user segment not yet described — may be safe to carry forward while the project focuses on higher-priority work. A high-severity conflict — two documents that define the scope boundary differently — cannot be deferred without accepting a specific and significant risk.
Severity assessment should ask: if this issue remains unresolved and the project advances, what is the most likely consequence?
Some issues, if unresolved, change the scope. Some change the architecture. Some change the commercial agreement. Some have no meaningful downstream consequence.
Naming severity does not resolve the issue. It gives the team the information they need to prioritize and decide what to do next.
That decision — to resolve, accept, or defer — is itself a first-class object. When a team decides to proceed with a known issue, that decision should be recorded with a rationale. The paper trail is not bureaucracy. It is the audit trail that explains, when a consequence materializes later, what was known at the time and what the team chose to do about it.
Issues as an Early Warning System
The cumulative picture of a project's open issues is an early warning system.
A project entering design with fifteen open high-severity issues is not ready for design — regardless of what the documentation checklist says. A project entering development with three open conflicts about acceptance criteria is setting up a scope dispute.
These warnings are only available if the issues have been named. Most teams know, intuitively, that something is wrong. They feel a project's instability as a diffuse sense of uncertainty. They raise concerns in stand-ups that are acknowledged and moved past. They make judgment calls that substitute for missing decisions.
Issue tracking converts that diffuse uncertainty into a specific, auditable record. It turns a feeling that something might go wrong into a list of the specific things that need attention before something does.
That specificity is the foundation of honest project governance.