# Issue and Communications Management

> Chapter 14 of the Courseiva PROJECT-PLUS curriculum — https://courseiva.com/learn/project-plus/issue-and-communications-management

**Official objective:** 3.3 — Explain issue management, escalation, and communication management in a project.

## Introduction

Issue and communications management. It is the safety net that catches problems before they become disasters and the megaphone that keeps everyone on the same page. For Project+ exam takers, this is the difference between a project that fails quietly and one that succeeds because the right people knew the right information at the right time.

## The Dinner Party Kitchen Crisis Analogy

Have you ever been in the middle of cooking a big dinner for friends, only to realise the oven isn't heating up? That sudden panic is exactly what an 'issue' feels like in a project. You are the project manager, hosting the party. Your team are the chefs. The oven is your critical system. 

 You stop everything. You don't scream at the stove. You first 'document' the problem: the oven is cold, the chicken is raw. This is the issue log. You then assess 'impact': if we don't fix this, dinner is delayed by an hour. You decide the 'priority' as high — burnt guests are not happy guests. You try the first 'workaround': you check the gas supply. No luck. This is troubleshooting. 

 Now you 'escalate'. You call the landlord (the senior manager) because you cannot fix a broken thermostat yourself. You give them the facts: what is broken, what you tried, and what you need. They authorise a repairman (the change control board). Meanwhile, you 'communicate' with your guests: "The oven has a hiccup. We will serve appetisers first. Main course will be out at 8pm." You update the issue log with the status. You are managing expectations, keeping everyone informed, and preventing a small problem from ruining the entire evening. This is issue and communications management in action.

## Core explanation

At its core, issue management is the formal process of identifying, logging, analysing, prioritising, resolving, and tracking problems that arise during a project. An 'issue' is any current problem that could negatively affect the project's scope, schedule, cost, or quality. This is different from a 'risk', which is a potential future problem that has not yet happened. A risk might be 'the internet might go down', while an issue is 'the internet is down right now'. 

 The purpose of issue management is to provide a structured, repeatable method for dealing with problems so that nothing falls through the cracks. In a project without issue management, problems are dealt with by whoever shouts the loudest, or they get forgotten entirely, causing the same obstacle to reappear later. Issue management replaces this chaos with a clear path. 

 The process typically follows these steps: 

 - Identify: Anyone on the project team or even a stakeholder notices a problem. They report it to the project manager, often through a centralised system like a project management tool (e.g., Jira, Asana, or even a shared spreadsheet). 
 - Log: The project manager enters the issue into an 'issue log' (also called an issue register). This log contains fields like a unique ID, description, date reported, who reported it, current status, priority, assigned owner, and resolution date. 
 - Assess: The project manager determines the impact and priority. Impact is how severe the damage is. Priority is how urgent it is to fix. For example, a bug that crashes the customer's website has a high impact and high priority. A missing icon on an internal tool has low impact and low priority. 
 - Assign: The issue is assigned to a team member (the owner) who is responsible for resolving it. This person investigates, creates a workaround or a permanent fix, and documents their actions. 
 - Resolve: Once a solution is implemented, the issue is updated to 'resolved' or 'closed'. The project manager verifies the resolution is effective. 
 
 'Escalation management' is a special part of issue management. It is the process of moving an issue up the management chain when it cannot be resolved at the current level. There are two types: hierarchical escalation (going to a higher authority for permission or budget) and functional escalation (bringing in a specialist, like a network engineer or a legal expert). Escalation ensures that no issue gets stuck because a junior team member lacks the authority or expertise to solve it. 
 
 Communication management, as defined by the Project Management Institute, is the process of ensuring that the project's information needs are met. This includes planning who needs what information, when they need it, in what format, and through which channel. A communication management plan documents this. It includes the stakeholder list, their information requirements, frequency of updates (e.g., daily stand-up, weekly status report), and the method (email, Slack, meeting, dashboard). 
 
 In practice, communication management and issue management are deeply linked. When an issue is logged, the project manager must communicate the issue to the right stakeholders. This communication must be appropriate — a developer may need a detailed technical description, while the project sponsor only cares about the impact on the budget and timeline. The communication plan tells you how to handle each stakeholder group. 
 
 Together, these two disciplines form a feedback loop. Issues generate communications, and good communications help identify and resolve issues faster. Without a plan, communication becomes ad hoc, leading to information overload for some and total ignorance for others. The Project+ exam tests your ability to recognise the correct process for logging issues, the appropriate escalation path, and the components of a communication plan.

## Real-world context

Imagine you are a project manager at a mid-sized retail company rolling out a new online ordering system. The project is in its testing phase. Suddenly, a tester reports that the payment gateway is not processing credit cards correctly — it charges customers twice for the same order. This is a critical issue. 

 As the project manager, your first action is to log the issue in the issue register. You create an entry with a unique ID (e.g., ISSUE-045), a description ('Duplicate charge on Visa transactions'), the date, the reporter's name, and an initial priority of 'Critical'. You then assess the impact: this affects all credit card payments, which represent 80% of the company's revenue. The timeline impact is a delay of at least two days for the fix and re-testing. The cost impact is potential customer refunds and lost goodwill. 

 You realise this issue cannot be fixed by your internal web developer; it involves the third-party payment processor's API. This requires a functional escalation. You email the vendor's support team, copying your senior manager. You also perform a hierarchical escalation to your project sponsor because the issue delays the go-live date, which they approved. You write a concise escalation report: the problem, the attempted fix (rebooting the test server), the impact (2-day delay, £5,000 potential revenue loss), and the requested action (authorise overtime for the vendor to resolve it within 24 hours). 

 Meanwhile, you update the communication plan. You know the CFO needs a one-line summary in their weekly report. The development team needs a detailed technical ticket in Jira. The customer support team needs a prepared script in case customers call about double charges. You write a brief email to all stakeholders: 'We have identified a payment processing issue. Testing is paused. We are working with the vendor and expect a fix within 48 hours. We will update you when the issue is resolved.' 

 You then monitor the issue daily. After the vendor releases a patch, your tester confirms it works. You update the issue log with the resolution details and change the status to 'Closed'. You also note the lesson learned: 'Third-party API integration requires earlier integration testing in the schedule.' This lesson is added to the project's lessons learned log to avoid the same issue on the next project. 

 The key actions an IT professional takes are: 
 - Maintain and update the issue log daily. 
 - Classify issues by priority (Low, Medium, High, Critical) and impact (Scope, Cost, Time, Quality). 
 - Escalate issues when they are beyond the team's control or authority. 
 - Follow the communication plan to distribute information to the right stakeholders at the right frequency. 
 - Archive resolved issues for future reference and lessons learned.

## Exam focus

The PK0-005 exam will test your understanding of issue management, escalation, and communication management primarily through scenario-based questions. You will be given a short description of a project problem, and you must select the correct next step from a list of options. The exam loves to trap you by making the wrong answer sound proactive but missing a formal step. 

 The key concepts you must memorise are: 

 - Issue vs. Risk: You will get a question that describes a problem that has already occurred. The correct answer will involve logging it as an issue, not analysing it as a risk. The trap is a distractor that says 'perform a risk assessment' — that is for future problems, not current ones. 
 - Issue Log Components: Know the mandatory fields: Issue ID, Description, Date Reported, Reporter, Priority, Status, Assigned To, Resolution Date, Resolution Description. A question might ask what should be included in an issue log — the trap is to omit 'Resolution Description' or 'Assigned To'. 
 - Escalation Paths: You need to know the difference between hierarchical and functional escalation. A question like 'The project manager cannot resolve a technical issue with the server configuration. Who should they escalate to?' The answer is the network operations manager (functional escalation), not the project sponsor (hierarchical) unless the issue also affects the budget. 
 - Communication Plan Components: The exam tests the elements of a communication management plan. These include: stakeholder list, information needs, frequency, method, and escalation rules. A common trap question gives you a scenario where a stakeholder complains they are not getting updates. The correct answer is to refer to the communication plan, not to immediately send more emails. 
 - P-I-E (Priority-Impact-Urgency): The exam might ask you to prioritise multiple issues. The rule is: the issue with the highest impact on the project's critical path and the highest urgency (deadline pressure) gets the highest priority. You must be able to order issues logically. 

 Specific question types include: 
 - 'Which document should the project manager update first?' (Answer: Issue Log) 
 - 'What is the next step after identifying an issue?' (Answer: Log it in the issue register) 
 - 'When should the project manager escalate an issue?' (Answer: When it exceeds the team's authority or expertise) 
 - 'Which stakeholder should receive the most detailed communication?' (Answer: The project sponsor, because they need to make strategic decisions; or the team lead, for technical decisions — depends on the scenario). 

 The exam will also test your understanding of the communication methods: push (email, reports — sent to recipients), pull (intranet, repository — recipients access it themselves), and interactive (meetings, phone calls — two-way). A scenario might say 'The project team is located in different time zones. What communication method is most appropriate for sharing the weekly status report?' The correct answer is 'push communication via email' because it is less disruptive than a meeting. 

 Traps to watch for: 
 - Choosing 'do nothing' when an issue is logged — never acceptable. 
 - Confusing the issue log with the risk register. 
 - Thinking that all issues must be escalated — only those beyond your control. 
 - Forgetting to update stakeholders when an issue is resolved.

## Step by step

1. **Identify the Issue** — Someone on the team or a stakeholder notices a problem. They report it to the project manager verbally or via a tool. The key is to capture it before it grows worse.
2. **Log the Issue** — The project manager enters the issue into the issue log or issue register with all mandatory fields. This creates a formal record and assigns accountability.
3. **Assess and Prioritise** — The project manager evaluates the issue's impact on scope, schedule, cost, and quality, and assigns a priority (low, medium, high, critical). This determines how quickly it must be resolved.
4. **Assign an Owner** — A specific person (the owner) is assigned to investigate and resolve the issue. Clear ownership prevents the issue from being ignored.
5. **Resolve and Verify** — The owner implements a solution. The project manager verifies the solution works and that the issue is truly resolved. This step closes the loop.
6. **Communicate and Escalate (if needed)** — Throughout the process, the project manager communicates status updates to stakeholders per the communication plan. If resolution is blocked, they escalate hierarchically or functionally.
7. **Close and Log Lessons Learned** — Once verified, the issue is marked 'Closed' in the log. The project manager records any lessons learned to prevent recurrence on the current or future projects.

## Comparisons

### Issue vs Risk

**Issue:**
- A current problem that has already occurred.
- Documented in the issue log.
- Requires immediate response and resolution.

**Risk:**
- A potential future problem that has not happened yet.
- Documented in the risk register.
- Requires analysis and a mitigation plan in advance.

### Hierarchical Escalation vs Functional Escalation

**Hierarchical Escalation:**
- Going up the management chain (e.g., project manager to sponsor).
- Used when the issue requires more authority or budget approval.
- The decision-maker is a senior manager or executive.

**Functional Escalation:**
- Going to a specialist or department (e.g., IT security, legal).
- Used when the issue requires specific technical expertise.
- The decision-maker is a subject matter expert, not necessarily a manager.

### Push Communication vs Pull Communication

**Push Communication:**
- Information is sent directly to recipients (e.g., email, report).
- Guarantees the recipient receives it, but may cause information overload.
- Best for urgent updates or formal status reports.

**Pull Communication:**
- Information is stored centrally for recipients to access when needed (e.g., intranet, shared drive).
- Recipient must actively retrieve it; no guarantee of receipt.
- Best for reference documents, policies, or non-urgent updates.

### Issue Log vs Risk Register

**Issue Log:**
- Tracks real problems that currently exist.
- Includes status like 'Open', 'In Progress', 'Closed'.
- Focus on resolution and verification.

**Risk Register:**
- Tracks potential future problems that have not yet materialised.
- Includes probability, impact score, and planned response.
- Focus on avoidance and mitigation actions.

## Diagram

_The workflow of issue management from identification to closure, including the escalation branch._

```mermaid
flowchart TD
    A[Issue Identified] --> B[Log in Issue Log]
    B --> C[Assess Impact & Priority]
    C --> D{Can Team Resolve?}
    D -- Yes --> E[Assign Owner]
    E --> F[Implement Solution]
    F --> G[Verify Resolution]
    G --> H[Close Issue]
    D -- No --> I[Escalate]
    I --> J[Higher Authority/Specialist]
    J --> F
    H --> K[Document Lessons Learned]
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style H fill:#9f9,stroke:#333,stroke-width:2px
    style I fill:#ff9,stroke:#333,stroke-width:2px
```

## Common misconceptions

- **Misconception:** An issue is the same as a risk, just a different word. **Reality:** A risk is a potential future problem (it hasn't happened yet). An issue is a current problem that is happening now. (Beginners often mix up the two because both are 'bad things' in a project. The exam explicitly tests your ability to distinguish them based on the timing.)
- **Misconception:** Escalation means complaining to a manager to get someone in trouble. **Reality:** Escalation is a formal process to bring a problem to a person with more authority or expertise to unblock the issue. It is a neutral, necessary tool, not a punishment. (In many non-IT workplaces, 'escalating' can have a negative connotation of 'tattling'. The exam treats it as a standard procedure.)
- **Misconception:** The issue log is only for technical problems like software bugs. **Reality:** The issue log captures any problem affecting the project, including people issues (team conflict), process issues (approval taking too long), and resource issues (missing equipment). (Beginners think project management is only about technology, but it involves people and processes too.)
- **Misconception:** If an issue is resolved, you can delete it from the issue log to keep it clean. **Reality:** You never delete an issue from the log. You mark it as 'Closed' or 'Resolved'. The log serves as a historical record for lessons learned and auditing. (In everyday tasks, people delete completed items. But project management requires traceability — you need to prove what happened.)
- **Misconception:** All stakeholders need the same information at the same time. **Reality:** Different stakeholders have different information needs. The communication plan defines what each stakeholder receives and how often. (Beginners think 'over-communicating' is always good. But sending every detail to everyone causes information overload and wastes time.)

## Key takeaways

- An issue is a real, current problem; a risk is a potential future problem — never confuse them on the exam.
- The issue log must include at minimum: ID, description, date, priority, assignee, status, and resolution.
- Escalation is a deliberate act: escalate only when the issue is beyond the team's authority or expertise.
- Hierarchical escalation goes up the management chain; functional escalation goes to a specialist team or department.
- The communication management plan documents who gets what information, when, and by which method.
- Resolved issues must remain in the log as 'Closed' — they are never deleted.
- When prioritising issues, consider both impact (severity of damage) and urgency (how soon a decision is needed).
- Communication methods are push (sent to you), pull (you fetch it), and interactive (live conversation); each suits different scenarios.

## FAQ

**What is the difference between an issue log and a risk register?**

An issue log tracks problems that have already happened. A risk register tracks potential future problems that have not occurred yet. Both are separate documents.

**Who should be assigned to resolve an issue?**

The person or team with the skills and authority to fix the problem. This is documented as the 'owner' in the issue log. It could be a developer, a vendor, or the project manager themselves.

**When should I escalate an issue?**

Escalate when the issue cannot be resolved at the current level of authority or expertise, or when it requires resources beyond the project's budget or schedule tolerance.

**What is a communication management plan?**

It is a document that defines who needs what project information, when they need it, how they will receive it, and who sends it. It prevents confusion and ensures everyone gets timely updates.

**Can an issue be deleted from the issue log once it is fixed?**

No. You must change its status to 'Closed' or 'Resolved'. Deleting it erases the audit trail and prevents you from learning from the issue later.

**What is the difference between push and pull communication?**

Push communication is sent directly to recipients (e.g., email, report). Pull communication is stored in a central location where recipients access it when they want (e.g., intranet, shared drive).

## Check your understanding

1. **What document should a project manager update immediately after a team member reports a current problem with the server?**

   Answer: The issue log (or issue register), because it is the formal record for tracking current problems.

2. **When should a project manager escalate an issue using functional escalation?**

   Answer: When the issue requires specialised expertise that the current team does not have, such as legal advice or advanced network security knowledge.

3. **What is the difference between an issue and a risk?**

   Answer: An issue is a problem happening now. A risk is a potential problem that might happen in the future.

4. **A project manager is deciding between sending a weekly status report by email or posting it on a shared intranet page. Which communication method is 'push'?**

   Answer: Sending it by email is push communication, because the information is actively sent to the recipients.

5. **What is the first thing a project manager should do when a new issue is identified?**

   Answer: Log the issue in the issue register with a description, date, and reporter details before assessing impact or assigning an owner.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/project-plus/issue-and-communications-management