An issue is something that has already happened, and it belongs in the issue log. Each issue gets a clear description, a priority, one owner responsible for solving it, a due date, an up-to-date status and the actions taken. An issue without an owner and a date usually never gets solved. Issues are ranked by their impact on project objectives and their urgency, so the ones threatening quality, safety or a critical deadline are handled first.
A common mistake is treating the symptom and leaving the cause, so the problem keeps coming back. Root cause analysis prevents this. The simplest tool is the "5 whys": you keep asking "why?" until you reach the real cause. Another is the fishbone diagram, which sorts possible causes into categories such as people, methods, materials, machines and environment. The analysis is done with the team, not without them, because they are closest to the work.
When a logged risk actually happens, there is no need to improvise: open the risk register and have the risk owner carry out the planned response, then record the event in the issue log and update both. If something unexpected happens, a workaround is used to contain the damage. Escalation comes in when the fix is beyond the PM's authority or the agreed tolerances, and it follows the escalation path set out in the governance plan. The rule: try to solve it at the lowest possible level first, and when you do escalate, bring facts, impact and recommended options, not just the problem.
In agile projects, anything that blocks the team is called an impediment, such as waiting for system access or a late decision from another department. Impediments usually surface in the daily scrum, but they can be raised at any time. The team first tries to solve it themselves, since they are self-organizing; what they can't solve is taken on by the servant leader, such as the scrum master or project manager. The impediment is shown on a board everyone can see and is followed up daily until it is truly closed, and then the team asks: how do we stop this happening again?
💡 Key points
- Every issue in the log has an owner, a due date, a priority and a status.
- Look for the root cause with the 5 whys or a fishbone diagram, not the symptom.
- When a logged risk occurs, run the planned response; escalate only what is beyond your authority, with options.
- Impediments: the team tries first, the servant leader clears the rest and follows up until closed.
🌍 Real-life example
A food factory is running a new packing line, and package-weight errors keep appearing every week. Instead of adding more checks at the end of the line, the PM gathered the operators and asked "why?" five times: the weight is wrong because the scale is off, because calibration gets forgotten, because there is no schedule for it, because the operating procedure doesn't mention it, because it was copied from an old line with no automatic scale. The issue was logged with the maintenance supervisor as owner and a one-week due date, calibration was added to the daily procedure, and the errors stopped.
📖 Key terms
| English | العربية |
|---|---|
| Issue Log | سجل المشكلات |
| Root Cause Analysis | تحليل السبب الجذري |
| 5 Whys | الأسئلة الخمسة (لماذا) |
| Fishbone Diagram | مخطط عظم السمكة |
| Impediment | عائق |
| Workaround | حل بديل مؤقت |