The Issue Log That Became a Dumping Ground
A logistics company is running a warehouse-management replacement. The issue log has 47 entries. Nineteen are marked 'open' with no owner, eight are actually risks, and three are change requests. The most recent entry says the handheld scanner supplier has confirmed it cannot deliver the new API until week 14, four weeks later than planned. That blocks the goods-receipt timebox in week 11. The supplier's account manager says 'it is with engineering'. The warehouse operations manager has not been told. The project board meets in three days. The team lead wants to mark the scanner item as a risk, close five old issues without review, and continue with other features. The project manager needs a defensible issue-management response.
1. How would you triage the issue log, and what would you do with the unowned and misclassified entries?
Read the worked answer
Triage by definition. An issue is a current problem that needs resolution now. A risk is a future uncertain event. A change request is a requested change to scope or requirements. The log's 47 entries need an owner, severity, target date, and status.
For the 19 unowned entries, run a short triage session and assign an owner to each. If no owner can be found, escalate or close with a recorded reason. For the eight risks, move them to the risk register with probability, impact, response, and owner. Leaving them as issues distorts issue metrics and delays active risk management. For the three change requests, route them to change control and the product owner with an impact assessment.
Do not close five old issues without review. That destroys the audit trail and may hide recurring problems. Instead, review them, record the outcome, and close only with a reason.
The scanner item is currently an issue because it is a confirmed delay with a present blocking effect. It also creates secondary risks, which should be logged separately. It should not be reclassified simply to make the issue log look cleaner.
2. How would you manage the scanner dependency from this point?
Read the worked answer
Contain first. Get the supplier's committed date and the technical dependency in writing. Ask for a recovery plan with milestones, not a status of 'with engineering'. Assess the impact on the week-11 goods-receipt timebox. Is there a manual fallback or the existing scanner API that can support the pilot? If yes, define and test the workaround. If no, re-plan the dependent scope and tell the board what will not be delivered.
Escalate beyond the account manager to the supplier's account director and internal procurement. Set a decision deadline, for example 48 hours. Assign one owner for the issue and one for the supplier relationship.
Inform the warehouse operations manager now. They need lead time to prepare manual processes and brief staff. Add the item to the board report with a red/amber status and a clear ask. Also log the risk of further slippage and the risk of errors introduced by the manual workaround.
Finally, update the issue with actions, owners, and next review date. Reclassifying it as a risk would remove the urgency without removing the blockage.
3. What should the project manager report to the board in three days?
Read the worked answer
Report on one page. State the issue, business impact, options, recommendation, decision needed, owner, and date. Be explicit that the week-11 goods-receipt timebox is at risk and that the supplier date is week 14. Present the manual fallback, its cost and error risk, and the option to reduce scope.
Do not present all 47 issues. Present the five material ones and a trend line. Explain the clean-up of the log: owners assigned, risks moved to the risk register, change requests routed. Ask the board to approve escalation to the supplier's executive level and, if needed, a scope trade-off.
Record the board's decision and communicate it to the team and warehouse operations. The project manager's credibility comes from early bad news with options, not from a clean-looking log. The board should leave knowing what it must decide, not just what went wrong.