Change Control · Issue & Risk Log
Change Control & Issue/Risk Log
What is change control?
- Change is managed through process, not blocked
- An issue is something that has happened; a risk is something that might
- Put the log first on the agenda, and the meeting becomes a place for decisions
What a team gains from change control is not the power to block requests but a language for putting a price tag on them. Once you can answer “just one more thing” with “that adds 3 days of development and 2 days of review,” the discussion shifts from emotion to trade-offs. The bigger change in practice is that the date of each request and the requester’s name are on record. Without that record, when people look for accountability for delays after the project ends, the person who worked the most overtime ends up taking the blame.
If every change gets the same weight, the process itself becomes the bottleneck. That is why practitioners split approval tiers by impact size. For example, changes that affect the schedule by 3 days or less and the total budget by 2% or less are decided by the PM alone, and anything larger goes to a Change Control Board (CCB) that meets every two weeks. The line between a risk and an issue also needs an operating rule. The moment a risk becomes reality, move it to the issue log and close the original risk entry as “occurred.” A workable approach is to score risks by probability times impact, attach response plans only to the top 5 to 7, and reassess the rest once a month.
If you treat an issue log as the same thing as the action items in meeting minutes, it quickly falls apart. Minutes record a single day, but the log is one list whose item numbers persist until each item is closed. In the weekly meeting, first skim only the new and overdue items, and for each closed item, leave a one-line note of who closed it, when, and how. Months later, when the same problem recurs, that one line is the fastest clue to finding the fix.
A common misconception is using change control as a way to say no. When requests are rejected over and over, business teams bypass the process and call developers directly, and you end up with a clean baseline document but a different actual deliverable. The same goes for logs. An item with “Planning Team” in the owner field and “TBD” in the due date will still read “in progress” three months later. One person’s name as the owner and one date as the deadline keep a log alive.
John KimAuthor of B2B Marketing Design and CEO of Nanum Consulting
Eunpyo HongExpert in company analysis, startups, and venture fundraisingIt was formalized in the Integrated Change Control process of the Project Management Body of Knowledge (PMBOK) and, combined with change control concepts from configuration and quality management, became a standard management practice across industries.
Company A, a mid-sized Korean cosmetics OEM manufacturer (340 employees, annual revenue of KRW 115 billion (≈ US$86,039,200)), ran an 8-month ERP rebuild. By month 4, business requests were piling up only in chat messages and verbal asks, the remaining development backlog had grown to 62 items, and the go-live date had already slipped twice. (Hypothetical example)
- The PMO lead spent a week gathering requests scattered across messengers and emails into a single sheet, and found that 38 of 62 were additional development with no approval record.
- When the sales division’s executive director asked, “Wasn’t this in the original contract?”, the PMO lead checked each item line by line against the original RFP and ruled 34 as new requests and 4 as within scope.
- Since then, every change request must state the development effort (MD) and review days. Changes of 5 MD or less are decided by the PM alone, and anything larger goes to the biweekly Wednesday CCB, where the head of Information Strategy and the CFO decide together.
- We merged issues and risks into a single sheet and had owners enter a person’s name instead of a department name. Only overdue items are covered in the first 5 minutes of the weekly meeting, which cut the meeting down to about 40 minutes.
- Three months later, of 41 new requests, 19 were deferred to the second release and only 22 were approved, cutting the backlog to 23 items. The ERP project closed three weeks behind the original plan.