Issue and Change Management
Tracking tells you something is off. This is the part where somebody does something about it. A project that notices everything and decides nothing produces excellent status reports and misses its date anyway.
In short
- A risk might happen, an issue has happened, a change alters what was agreed. Three different responses.
- Every issue needs an owner and a next action with a date. “Being looked at” is not a state.
- Every change costs something. If nobody names the cost, the team pays it silently.
- Changing the plan is fine. Changing it without a record is what makes a project unaccountable.
Three things that get confused
| Type | Definition | What it needs |
|---|---|---|
| Risk | Might happen; would hurt if it did | An assessment, a response and a trigger — 3.4 |
| Issue | Has happened; is hurting now | An owner, a next action, and a date |
| Change | Alters what was agreed | A stated cost and someone to approve it |
They’re related in an obvious way — an unmanaged risk becomes an issue, and a big enough issue forces a change — but mixing them in one list makes all three harder to act on. The practical tell: if your issue log contains things that haven’t happened yet, it’s a risk register in disguise and nothing on it will get closed.
Working an issue
Five steps, and most projects skip the same two.
- Write down what is actually happening. Observable, not interpreted. “The nightly import failed on three of the last five nights” is workable; “the data pipeline is unreliable” is a mood.
- Assess the impact. What does it cost if nothing changes? A day, a deliverable, the launch? This determines how much attention it deserves and it is the step most often skipped, which is why every issue ends up feeling equally urgent.
- Give it one owner and one next action with a date. Not a team. Not “investigate”. Something someone can do by Thursday.
- Fix the cause, not just the symptom. Restarting the import gets tonight’s data. Asking why it fails gets the rest of the month. A couple of rounds of “why?” is usually enough — the point is to stop at the first cause you can actually change.
- Close it, and say what changed. The other skipped step. An issue log that only grows becomes noise, and noise is why nobody reads it.
One habit worth adding: for anything that took more than a day to resolve, write one line about what would have caught it earlier. That line is the input to the retrospective, and it is nearly free to write while the memory is fresh.
Where a change actually goes
This is the mechanism behind scope creep, and it is worth being precise about, because the usual framing blames the wrong party. Nobody demanded 40% more work. Forty people each asked for something reasonable, and each time the fourth box was chosen by default — usually by someone being helpful.
The four-line change note
You do not need a change control board for a two-day request. You need four lines, which take about five minutes:
- What’s changing — one sentence, in terms of the deliverable.
- What it costs — days, money, or the specific thing that now won’t happen. This line does all the work.
- Who approved it — a name, not a meeting.
- Where it’s recorded — so the baseline and reality don’t drift apart.
Notice what this does to the conversation. “Can you also do X?” is a favour, and refusing a favour is socially expensive. “X costs two days — do we move the date or drop something?” is a decision, and it belongs to the sponsor rather than to whoever was asked. Same request, entirely different politics.
Larger projects formalise this into a change request with an approving body, and that’s appropriate when the money between decisions is large. The four lines are the version that scales down without losing the part that matters.
When to re-baseline
At some point the accumulated changes make the original plan a poor thing to measure against. Reporting a 30% overrun against a baseline everyone knows is obsolete produces alarm without information.
Re-baselining is legitimate when the scope has genuinely changed by agreement, when an external event has invalidated the assumptions, or when the variance is now so large that comparison has stopped being useful. It is not legitimate as a way to make a late project look on time — and the difference is visible to everyone, which is why doing it casually costs credibility.
Two rules keep it honest: keep the old baseline visible alongside the new one, and record why it changed. A project that has re-baselined three times with reasons is being managed. One that has re-baselined three times quietly is being reported.
Escalating well
Escalation has a reputation as an admission of failure, which is exactly backwards — it’s the mechanism for putting a decision where the authority is. What makes it work:
- Escalate early. The value of a decision decays with time. A week spent deciding whether to escalate is a week of the delay you were trying to avoid.
- Bring options, not just the problem. “We can move the date two weeks, cut the reporting module, or add a contractor for a month — here’s what each costs” is a decision someone can make in five minutes.
- Say what you’ll do if there’s no answer. “If I don’t hear by Friday I’ll assume option two” prevents the issue from stalling in someone’s inbox.
- Never surprise someone with a problem in public. An escalation that first appears in a steering meeting damages the relationship you’ll need for the next one.
Where this usually breaks
- The standing issue. The same item is discussed weekly for two months. Nobody owns it, or the owner has no authority to resolve it — either way it needs escalating, not repeating.
- Fixing symptoms. Six issues that are all the same root cause, each closed individually, all recurring.
- Change without cost. Requests accepted because they’re small, until forty of them aren’t.
- Cost without change. The opposite failure: a process so heavy that people route around it and make changes informally, which is worse than not having one.
- Blame in the log. An issue list that reads as a record of who caused what will be curated, and a curated log is a fiction.
How this looks in AB
In AB Projects, tasks typed Bug or Issue sit alongside delivery work, so problems aren’t on a separate list nobody updates — they compete for attention against the work, which is the honest comparison. Comments on a task carry the conversation in context rather than in a thread that will be unfindable in month five.
The change-history tab automatically logs every status and scope shift, so when an issue turns into a real scope change you can see exactly when it happened without anyone maintaining a log by hand. That is also what makes the “where it’s recorded” line of the change note nearly free.
And through the MCP server, an AI assistant can read an issue, post its analysis as a comment, and split it into subtasks — useful for the mechanical part of triage, with every action attributable in the same history.
One convention worth adopting by hand: put the cost in the change note as its own line, in days. Tools record what changed; they don’t record what it cost unless somebody types it, and that line is the entire difference between the third box in the diagram and the fourth.
Terms used on this page
- Issue
- A problem that has happened and is affecting the project now. Needs an owner, a next action and a date — not an assessment. More →
- Change request
- A recorded proposal to alter scope, schedule or cost, with its impact stated and someone named to approve it. What turns creep back into a decision. More →
- Scope creep
- Work added after scope was agreed without a matching change to time or budget. Caused by unstated costs, not by demanding stakeholders. More →
- Re-baselining
- Formally replacing the plan you measure against, because the old one no longer reflects what was agreed. Legitimate with a reason; corrosive without one. More →
- Root cause
- The underlying reason an issue occurred, as opposed to its visible symptom. Worth finding when the same issue keeps returning. More →
- Escalation
- Passing a decision or problem to someone with the authority to resolve it. Fast escalation is a sign of a healthy project, not a failing one. More →
- Change control board
- A group that approves or rejects change requests on larger projects. Worth its overhead when the money between decisions is large. More →
Related reading
3.4 Risk Management
Handling problems while they are still hypothetical, which is considerably cheaper.
3.1 Defining Project Scope
The agreement a change request is a change to — and the exclusions that prevent half of them.
6.3 Reporting Progress
Telling people what you decided, in a form that asks something of them.