Change Log vs Issue Log
Two logs, kept side by side, and items move between them in a way that matters commercially. One holds decisions about what the project has committed to deliver. The other holds things that have gone wrong and need sorting out. Put an item in the wrong one and the project has either added work nobody approved or escalated a problem that needed ten minutes.
Section 4 of the PMBOK® Guide Eighth Edition covers both among a project's artefacts, and the distinction is simplest to hold by asking what the entry is asking somebody to do.
One records decisions, the other records problems
A change log records requests to alter what was agreed, and what was decided about each. Raised by whom, what it affects in scope, cost and time, who decided, when, and the outcome, including the rejections. A change log that contains only approved changes has lost half its value, because the record of what was declined is what prevents the same request arriving three more times.
An issue log records things that have happened and need resolving. A supplier has missed a delivery, a wall is out of tolerance, a permission has expired. Each entry needs an owner, an action and a date, and its life ends when the problem is resolved. Issues are worked; changes are decided.
Three habits that blur them
Recording a change as an issue to avoid change control. Sometimes deliberate, more often kind: the change process feels heavy, the item seems small, and logging it as an issue lets somebody get on with it. The work gets done, the cost lands somewhere, and the baseline no longer describes the project.
Logging changes without decisions. Entries that read raised and then nothing. A change log full of open items describes an approval process that is not running, and it produces a familiar end-of-project condition where nobody can say which variations were ever agreed.
Using the issue log as a task list. Every action anybody owes anybody, in one list, until the genuine issues are buried among two hundred routine items. Issues are the things that are not being handled by the ordinary run of the work, and a log that has become a to-do list cannot show the difference.
Two stickers of a different colour
A property team was taking handover of a refurbished floor, and ran the usual snagging inspection with the contractor. Defects were marked with small coloured stickers as they went: a dense cluster along one architrave where the paint finish was poor, more along a skirting, the usual harvest.
Two stickers on the wall face were a different colour, and they were not defects. One marked a socket the client wanted moved about four hundred millimetres to suit a desk layout that had changed since the design; the other marked a door that the client now wanted fitted with a closer.
Both went onto the snagging list, because that was the list being written that morning and everybody wanted to be helpful. The contractor did the work, which took a day, and invoiced it three months later as a variation, correctly, because it had never been part of the contract.
The client's position was weak, not because the claim was unreasonable but because the record said the items had been raised as defects. The change log showed nothing at all for that week. It was settled commercially, at a cost of some goodwill and about four thousand pounds, over an item that would have been approved in a minute had anybody put it through as a change.
The rule the property team adopted afterwards was one line in its inspection procedure: anything that is not a failure to meet the specification is not a snag, whatever colour sticker it gets, and goes to the change process the same day. The next handover produced three such items, all of them approved inside a week and all of them priced before the work was done.
What a good entry contains
For a change: what is being asked for, why, what it does to scope, cost, time and risk, who decided and when. The effect assessment is the part most often skipped and the only part that makes a decision possible.
For an issue: what has happened, what it is stopping, who owns it, what the next action is and by when. Issues without an owner and a date are observations, and a log of observations grows until nobody reads it.
For a PMP® candidate, the point to hold is that a change alters the agreed baseline and an issue is a problem to be worked, so a scenario where additional work has been done without approval is describing an item recorded in the wrong place. A response that resolves the work leaves the commercial position unrecorded. A structured PMP exam preparation course works through situations where everybody acted helpfully and the baseline no longer matches the project.
Read your own issue log with one question: which of these, if resolved as written, would change what the project delivers? Anything you find belongs in the change process today, while it is still a decision somebody can take rather than a variation somebody can claim.
Interested in going further?
Scope rarely moves through a decision nobody made; it moves through an item logged in the friendlier of two places. Omega's PMP® Exam Preparation works through change and issue records as commercial instruments.
Change and issue records are both described in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A170: Decision Log: The Forgotten Project Control
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?
A169: Assumption Log vs Risk Register
A172: Lessons Learned Register: Use It Before the Project Ends
A167: Project Charter Explained: Purpose, Content and Common Misunderstandings
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
