Quick Answer
Communication requirements analysis is the process of identifying what information each project stakeholder needs to receive, from whom, how often and in what format. It is a key input to the Plan Communications Management process in PMBOK. The analysis determines the total number of communication channels using the formula n(n−1)/2 (where n = number of stakeholders), identifies each stakeholder's specific information needs, and documents these in a stakeholder communications matrix that becomes the foundation of the Communication Management Plan. Without it, project communication is guesswork — you end up sending the wrong information to the wrong people at the wrong time.
n(n−1)
÷ 2 — formula for total communication channels
5W
Who, what, when, where, why — for every stakeholder
Plan Comms
PMBOK process this analysis feeds directly into
1st
Step before writing the communication management plan
Poor communication is consistently cited as one of the top causes of project failure — not because project managers do not communicate, but because they communicate the wrong things to the wrong people. A sponsor receives daily operational updates they have no use for. A team lead is excluded from scope change decisions that directly affect their workstream. A regulatory stakeholder only hears about compliance issues when it is too late to act.
All of these failures have the same root cause: no proper communication requirements analysis was done at the start of the project. When you understand exactly what each stakeholder needs to know, how often and through which channel, communication stops being a source of friction and starts being a project strength.
This guide covers the complete communication requirements analysis process — the PMBOK context, the channels formula, a worked stakeholder communications matrix, and the step-by-step approach that feeds your Communication Management Plan.
How this fits in PMBOK: Communication requirements analysis is an input to the Plan Communications Management process within the Communications Management knowledge area. The output of this analysis feeds directly into the Communication Management Plan. See the full Communication Management Guide for the complete end-to-end process, and the Stakeholder Management Guide for how the stakeholder register provides your starting point.
01 — Foundation
What Is Communication Requirements Analysis?
Communication requirements analysis is the structured process of determining what information stakeholders need, when they need it, how they want to receive it and who should provide it. It answers five fundamental questions for every stakeholder on your project:
- Who needs this information? (recipient)
- What information do they need? (content)
- When do they need it? (frequency and timing)
- Where / How should it be delivered? (channel and format)
- Why do they need it? (purpose — decision-making, awareness, compliance)
The analysis draws on three primary inputs: the stakeholder register (who the stakeholders are and their influence/interest profile), the project charter (project objectives, constraints and governance requirements) and organisational communication standards (what formats and channels are standard in this organisation). It produces two key outputs: the communication requirements document and the stakeholder communications matrix — both of which feed the Communication Management Plan.
The most common mistake: Treating communication requirements analysis as a box-ticking exercise — listing every stakeholder and writing "weekly email" for all of them. Effective analysis is specific: the CFO needs cost variance and EAC by the 15th of each month for budget cycle input; the development team lead needs sprint blockers escalated within 2 hours; the regulator needs formal progress reports in a specific format by the contractual reporting date. Generic communication plans produce generic communication — which is a polite way of saying ineffective.
02 — Communication Channels Formula
The Communication Channels Formula — n(n−1)/2
Before planning who communicates what, you need to understand the scale of the communication challenge. As a project team grows, the number of potential communication channels grows exponentially — and with it the risk of miscommunication, information silos and missed updates.
Communication Channels Formula
Channels = n(n−1) / 2
Where n = total number of stakeholders (including the project manager)
Result = total number of possible two-way communication channels
Result = total number of possible two-way communication channels
Worked Example — How Team Size Affects Communication Complexity
| Team / Stakeholders (n) | Formula | Channels | Increase from previous |
|---|---|---|---|
| 2 people | 2(2−1)/2 | 1 | — |
| 5 people | 5(5−1)/2 | 10 | +9 channels |
| 10 people | 10(10−1)/2 | 45 | +35 channels |
| 15 people | 15(15−1)/2 | 105 | +60 channels |
| 20 people | 20(20−1)/2 | 190 | +85 channels |
| 30 people | 30(30−1)/2 | 435 | +245 channels |
Adding a single person to a 10-person project team increases communication channels from 45 to 55 — a 22% increase in complexity for a 10% increase in team size. This is why communication becomes exponentially harder to manage as projects scale, and why formal communication requirements analysis is not optional on large projects.
What the Formula Tells You — and What It Does Not
The channels formula tells you the maximum possible communication complexity. Not all channels will be active — most stakeholders will not communicate directly with each other, and the PM's role is partly to be the hub through which communication flows. However, the formula is used in project planning to:
- Justify the communications management effort required on large projects
- Assess the impact of adding stakeholders or team members mid-project
- Identify where communication bottlenecks are most likely to form
- Appear in PMP exam questions — it is a guaranteed calculation topic
PMP exam note: The channels formula is one of the most frequently tested PMP calculations. You will be given n and asked for channels, or given channels and asked to work backwards to find n. If given channels (C) and asked for n: solve n² − n − 2C = 0 using the quadratic formula. For example, if C = 36: n² − n − 72 = 0, which gives n = 9. Always double-check by substituting back: 9(8)/2 = 36. ✓
03 — Inputs and Outputs
Inputs, Process and Outputs — The PMBOK Context
Communication requirements analysis sits within the Plan Communications Management process in PMBOK. Understanding what feeds into it — and what it produces — ensures you are gathering the right information from the right sources.
📥 Inputs to the Analysis
- Stakeholder register (who stakeholders are, their role, influence and interest level)
- Project charter (objectives, constraints, sponsor, governance structure)
- Organisational process assets (templates, standards, historical comm plans)
- Enterprise environmental factors (corporate culture, available tools, geographic distribution)
- Requirements documentation (scope of deliverables — what will stakeholders need to know about)
→
📤 Outputs of the Analysis
- Communication requirements document (what each stakeholder needs and why)
- Stakeholder communications matrix (who, what, when, how, owner)
- Channel count (n(n−1)/2 calculation for team complexity justification)
- Feeds into: Communication Management Plan (the how-to guide for all project comms)
- Updates to: Stakeholder engagement plan (adjust engagement level based on comms needs)
The stakeholder register is your starting point — not a blank page. Every stakeholder in the register needs to be assessed for communication requirements. Their power/interest position tells you how much communication they need and how formal it should be: high-power/high-interest stakeholders (manage closely) need structured, regular, formal communication; low-power/low-interest stakeholders (monitor) need periodic awareness updates only. See the Stakeholder Management Guide for the power/interest grid and register template.
04 — What to Capture
The Seven Communication Requirement Attributes to Capture for Each Stakeholder
For each stakeholder or stakeholder group, your analysis should capture seven attributes. These become the columns of your stakeholder communications matrix.
| Attribute | What It Captures | Question to Ask | Example |
|---|---|---|---|
| Stakeholder | Individual or group name and role | Who is this communication for? | Project Sponsor / CFO |
| Information Needed | Specific content the stakeholder requires | What do they need to know to fulfil their role? | Budget status, CV, EAC, key risks, milestone status |
| Purpose | Why they need this information | What decision or action will this enable? | Budget approval decisions, escalation trigger |
| Frequency | How often they need it | When and how regularly? | Monthly — by the 10th of each month |
| Channel / Format | How they want to receive it | Email, meeting, dashboard, formal report? | Formal written report + 30-min monthly meeting |
| Owner | Who is responsible for sending it | Who prepares and delivers this communication? | Project Manager |
| Escalation Path | What to do if communication fails | If not acknowledged within X hours/days, who to contact? | If no response in 48hrs, escalate to Programme Director |
05 — Stakeholder Communications Matrix
Stakeholder Communications Matrix — Template With Example
The stakeholder communications matrix is the practical output of your requirements analysis. It documents every communication flow in the project in a single reference document that the whole team can use. Here is a fully worked example for a mid-size IT project with eight stakeholder groups.
| Stakeholder | Information Needed | Purpose | Frequency | Format / Channel | Owner | Escalation |
|---|---|---|---|---|---|---|
| Project Sponsor Executive | Overall status, budget variance (CV/EAC), key risks, milestone progress, change requests pending | Go/no-go decisions, budget approval, risk escalation | Monthly | Formal status report + 30-min review meeting | PM | CEO if no response in 3 business days |
| Steering Committee Governance | Phase gate readiness, strategic alignment, top 5 risks, financial summary | Phase gate approvals, strategic decisions | Bi-monthly | Formal board pack + steering committee meeting | PM + Sponsor | Sponsor if quorum not met |
| Technical Lead Delivery | Sprint blockers, architectural decisions needed, resource conflicts, dependency changes | Technical decision-making, unblocking team | Daily standup | Daily standup + Teams channel for async | Scrum Master / PM | PM if blocker unresolved after 4 hours |
| Development Team Delivery | Sprint goals, accepted user stories, priority changes, dependency updates, demo schedule | Sprint execution, coordination, clarity on scope | Sprint cadence | Sprint planning, daily standup, retrospective, backlog refinement | Scrum Master | Technical Lead for technical blockers |
| Business Analyst Requirements | Requirements change requests, scope decisions, UAT feedback, acceptance criteria updates | Requirements accuracy, change impact assessment | Weekly + ad hoc | Weekly requirements review + JIRA / email for changes | PM | PM if change request not reviewed in 2 days |
| End Users / UAT Team Acceptance | UAT schedule, test environment access, known defects list, release notes | User acceptance testing, sign-off preparation | Weekly during UAT phase | UAT status email + shared defect log | BA / Test Lead | BA if no UAT feedback within SLA |
| IT Operations Infrastructure | Deployment schedule, infrastructure requirements, change freeze windows, go-live plan | Environment preparation, deployment coordination | Monthly + pre-release | Email + change advisory board submission | Technical Lead | IT Director for CAB conflicts |
| Procurement / Finance Financial oversight | Invoices for approval, budget forecast (EAC), contract milestone completions, change order requests | Financial control, invoice processing, budget cycle input | Monthly by 10th | Formal financial report to finance system + email summary | PM | CFO if invoice unprocessed after 10 business days |
How to use this matrix: Download and adapt this structure for your project. Replace the example stakeholders with your own from the stakeholder register. Review it with your sponsor and key stakeholders in the kick-off phase to confirm requirements are correct — stakeholders will often correct inaccuracies when they see their row. Store the agreed matrix in your project management plan. Review and update at each phase gate or whenever the stakeholder landscape changes significantly.
06 — Step-by-Step Process
How to Conduct a Communication Requirements Analysis — Step by Step
1
Start with the stakeholder register
Every communication requirement analysis begins with a complete, current stakeholder register. For each stakeholder listed, note their role, their power/interest position and what their relationship to the project is — sponsor, decision-maker, contributor, affected party, regulator. This gives you the starting list of who needs to be analysed.
Tip: Group stakeholders with similar information needs (e.g. all development team members) to reduce the number of matrix rows and make the plan manageable. Individual analysis is needed only for high-power stakeholders whose needs are unique.
2
Calculate your communication channels
Count the total number of stakeholders (n) including yourself and calculate channels using n(n−1)/2. This gives you a quantified measure of communication complexity to include in your project plan and use when justifying communications management effort to the sponsor.
Example: 12 stakeholders = 12(11)/2 = 66 channels. Present this in your kick-off deck to illustrate why a structured communications plan is non-negotiable on this project.
3
Interview or survey key stakeholders
Do not assume what stakeholders need — ask them. For senior and high-influence stakeholders, a 15-minute conversation at project initiation is invaluable. Ask: What information do you need to do your job on this project? How do you prefer to receive updates? How often? What is the worst communication failure you have experienced on a previous project? Their answers will reveal requirements you would never have guessed.
Tip: For large stakeholder groups (e.g. 20+ end users), use a short structured survey rather than individual interviews. Three to four targeted questions are enough.
4
Document requirements in the communications matrix
For each stakeholder or group, fill in all seven attributes: stakeholder, information needed, purpose, frequency, format/channel, owner and escalation path. Be specific — "weekly update" is not a requirement; "weekly email by COB Friday summarising sprint progress, blockers and next week's goals, sent to the Technical Lead" is a requirement. The more specific your matrix, the more useful it is.
5
Review and validate with the sponsor
Walk through the completed matrix with your project sponsor (and ideally one or two other senior stakeholders) to validate that requirements are captured correctly and the plan is realistic. Sponsors will sometimes identify missed stakeholders, incorrect frequencies or wrong channels. Getting sign-off on the matrix at this stage prevents disputes later about who was supposed to be kept informed of what.
Tip: Also check for communication overload — stakeholders who appear in many rows receiving frequent updates may get communication fatigue. Consolidate where possible.
6
Feed the matrix into the Communication Management Plan
The stakeholder communications matrix becomes a core annex of the Communication Management Plan. The Plan adds the broader context — communication principles, tools approved for use, language and accessibility standards, storage and retrieval of project communications, and the process for updating requirements when stakeholders change. See the Communication Management Guide for the full plan structure.
7
Review and update at each phase gate
Communication requirements change as projects evolve. New stakeholders are added, old ones leave, project phases shift the information landscape, and what the sponsor needed in planning is different from what they need during execution. Review the matrix formally at each phase gate and update it whenever a significant stakeholder change occurs.
Build Your Communication Management Plan
Communication requirements analysis is the foundation. The Communication Management Guide covers everything that follows — planning, executing and monitoring all project communications.
07 — PMP Exam
Communication Requirements Analysis on the PMP Exam
Communication requirements analysis and the channels formula are tested directly in PMP exam scenarios. Here is exactly what to know.
The Channels Formula — Exam Patterns
- Direct calculation: "A project has 8 stakeholders. How many communication channels exist?" → 8(7)/2 = 28
- Adding a stakeholder: "A project has 45 channels. A new stakeholder is added. How many channels now exist?" → First find n: n(n−1)/2 = 45 → n = 10. New channels: 11(10)/2 = 55
- Working backwards: "A project has 36 communication channels. How many stakeholders are there?" → n(n−1)/2 = 36 → n = 9
Process Knowledge the Exam Tests
- Communication requirements analysis is an input to Plan Communications Management — not Execute Communications or Monitor Communications
- The stakeholder register is the primary source of communication requirements information
- Communication requirements analysis determines what to communicate — the Communication Management Plan determines how
- Not all communication channels need to be active — the formula gives maximum possible channels, not required channels
Related PMP topics: Communication requirements analysis is tested alongside stakeholder identification and engagement, Plan Communications Management and the broader Communications Management knowledge area. For practice questions on this topic, see our 200 free PMP practice questions.
08 — FAQ
Communication Requirements Analysis — 7 Questions Answered
Communication requirements analysis is the process of determining what information each project stakeholder needs, how often they need it, in what format and through which channel. It is a key input to the Plan Communications Management process in the PMBOK Guide. The analysis uses the stakeholder register as its primary input and produces a stakeholder communications matrix — a document that maps every communication flow in the project and forms the foundation of the Communication Management Plan. Without this analysis, project communications are based on assumptions rather than actual stakeholder needs.
The communication channels formula is: Channels = n(n−1)/2, where n is the total number of stakeholders including the project manager. It calculates the maximum number of possible two-way communication channels in a project. For example, a project with 10 stakeholders has 10(9)/2 = 45 possible channels. The formula illustrates why communication complexity grows exponentially as team size increases — adding one person to a 10-person project adds 10 new channels (10 existing people × 1 new person = 10 new relationships). This formula is also a common PMP exam calculation question.
A stakeholder communications matrix is a table that documents every communication flow in a project. For each stakeholder or stakeholder group, it records: what information they need, why they need it, how frequently, through which channel or format, who is responsible for delivering it and what the escalation path is if communication breaks down. It is the primary output of communication requirements analysis and becomes a core section of the Communication Management Plan. The matrix is reviewed and updated at each project phase gate and whenever significant stakeholder changes occur.
The project manager leads communication requirements analysis, but the most important inputs come from stakeholders themselves. Senior stakeholders (sponsor, steering committee members, key decision-makers) should be consulted directly — a short conversation or structured interview in the initiation phase yields requirements you would never identify through assumption alone. For large stakeholder groups (end users, operations teams), a brief survey is more practical than individual interviews. The completed analysis should be reviewed and validated with the project sponsor before being incorporated into the Communication Management Plan.
Communication requirements analysis determines what stakeholders need — it is the research and discovery phase. The Communication Management Plan describes how those needs will be met — it is the planning and governance document. The analysis produces the stakeholder communications matrix (who needs what, when, how). The Plan adds the operational framework: approved communication tools, storage and retrieval processes, language standards, escalation procedures, and the process for updating communication requirements when stakeholders change. The analysis is an input to the Plan — you cannot write an effective Communication Management Plan without first completing the requirements analysis.
Communication requirements should be formally reviewed at each phase gate and informally whenever a significant stakeholder change occurs. Common triggers for a review include: a new stakeholder joining the project, an existing stakeholder changing role or leaving, a significant scope change that alters what information is relevant, a phase transition that changes what stakeholders need to know, or persistent communication failures that suggest requirements are not being met. On fast-moving projects, a quarterly review of the communications matrix is a good baseline minimum.
In Agile projects, communication requirements analysis is less formal but no less important. Agile's ceremonies — sprint planning, daily standup, sprint review and retrospective — provide a built-in communication cadence that satisfies many stakeholder needs. However, external stakeholders (sponsors, executives, regulators) who sit outside the Agile team still need their communication requirements explicitly analysed and documented. The product owner typically manages stakeholder communication in Scrum, and their communication approach should be guided by a lightweight version of the same requirements analysis — who needs to know what from the sprint review, what level of detail the sponsor needs in progress updates, and what the escalation path is for impediments that require executive intervention.