Plan, Stakeholders, Teams & Communication

The Project Management Plan exam

Once a project has been approved, dozens of people need to know the same things: what is in scope, when the milestones fall, how much money there is, who decides what, how risks and changes are handled. If each person keeps their own version, the project drifts apart. The Project Management Plan solves this by putting all of it in one approved document that everyone works from.

Charter vs plan: two different documents

The PMP is easy to confuse with the Project Charter from Part I. A charter is the short proposal written before approval, to win agreement on the project's goals and terms. The PMP comes after approval and explains how those goals will actually be achieved. In one line: the charter wins approval, the plan runs the project.

What goes in a PMP

The W04 slides split a typical PMP into two kinds of content. Project information says what the project is: its summary, money, people, scope, approach and dates. Project governance says how it will be controlled: who is responsible for what, and the planning activities every project must carry out. Each of those mandatory activities has its own Part on this site.

The PM does not write all of this alone. Subject experts write the specialist parts (a test lead might write the quality section, for example), while the PM coordinates them and stays ultimately accountable. And a PMP is not a uniform template: each organisation tailors it to its own standards (PMBOK, Agile) and to the project in front of it.

What PMBOK adds: integration, baselines and the kick-off

PMBOK (the Project Management Body of Knowledge, the Project Management Institute's standard guide; here the 6th edition, chapter 4) treats the plan under Integration Management, the knowledge area about making all the separate pieces of a project fit together. It adds three ideas to the slides' picture.

1. The PMP integrates all the subsidiary plans and baselines. A subsidiary plan is a smaller plan for one area, such as the risk management plan. The PMP pulls all of them into one document, together with the baselines, the change and configuration management plans, and the chosen development approach.

2. Baselining. A baseline is an approved, frozen version of part of the plan (the scope, schedule or cost) that actual progress is later measured against. Before the baselines are set, the plan can be updated freely. Once it is baselined, it changes only through integrated change control: someone raises a change request, and a change control board (CCB), a group with the authority to approve or reject changes, decides. The plan is therefore progressively elaborated: it gets more detailed over time, but only through approved updates.

3. The kick-off meeting, held at the end of planning, communicates the objectives, gains the team's commitment and explains each stakeholder's role.

Two sample templates

The subject shows two sample PMP templates, which make the idea concrete. Notice how much of the fuller template is about control (thresholds, change paths, communication rules) rather than about the product.

Agile: To Document or Not? exam

A formal project leans on a thick plan. Agile projects don't, and that has led to a popular misunderstanding: that Agile teams write nothing down. This section explains what Agile actually says about documents, why Agile teams still document, and what they document.

The myth and the reality

The myth that "Agile means no documentation" comes from misreading the Agile Manifesto's value "working software over comprehensive documentation" (Part III). The Manifesto values working software more; it does not dismiss documents. Some situations always need them: user stories, flowcharts, wireframes (rough screen sketches), notes of client meetings, and regulatory requirements. What Agile does is be "smart" about documentation, in three ways.

Why document in Agile at all? (four reasons)

The W04 slides give four reasons. Learn them as a list; they are a likely short-answer question, and they are the evidence you need to rebut "we're Agile, so we don't document".

1. Stakeholder requirements and organisational memory. The software must be used, operated, supported, maintained and extended long after the team moves on, so what the team knows has to be kept.
2. Communication with external groups, such as outsourced teams. Documents carry the information when stakeholders cannot always be present or the team cannot sit together.
3. Audit and compliance. Some systems must follow a defined process and keep proof that it was followed. A medical system like Medic (the tutorials' case) is an example.
4. Presenting, clarifying and solidifying complex ideas. Writing a complex idea down helps you present it, clarify it and make it solid.

What to document

Formal vs Agile: opposite dangers

The two approaches fail in opposite directions. A formal project has a baselined PMP and changes go through the CCB; its danger is too much documentation, which means bureaucracy, one of the team-killing practices called teamicide (§5.6). An Agile project has a vision and a backlog that the Product Owner re-orders; its danger is too little documentation, which means lost knowledge and failed audits.

Stakeholders and Stakeholder Analysis exam

Projects rarely fail because the code would not compile. They fail because someone with influence was ignored, surprised or turned against the project. Stakeholder management is the discipline of finding everyone who matters to a project, understanding what they want, and deliberately keeping them on side.

Two opening scenarios (W04 slides)

The lecture opened with two situations every developer meets. Both are really stakeholder problems, and the model responses show the habits this section builds.

Scenario 1: the dashboard demo. At a sprint review (the Scrum meeting where stakeholders inspect what was built, Part III), the client calls a behaviour a "bug", and you are sure it is exactly what they asked for.

Scenario 2: the workflow change. Users say the new dashboard approval process is "more complicated than the old way", even though it reduces errors and speeds approvals. Listen first, because some of the complaints may reveal real usability problems. Then explain why the change was made, with evidence, and support people through it with training, quick guides and champion users (respected users who help their colleagues). Pilot the change, gather feedback and iterate.

Stakeholder analysis: five activities

Stakeholder analysis is how you get from "who is out there?" to "what do we do about each of them?". The W04 slides break it into five activities. It is a cycle, not a one-off: as the project changes, you re-assess.

Who the stakeholders typically are

A useful first cut is internal (inside the organisation running the project) versus external (outside it). The slides' typical lists are drawn below; an exam answer that names stakeholders from both rings looks thorough.

The stakeholder register

The first output of identification is a stakeholder register: a simple table with one row per stakeholder under the columns Name, Position, Internal/External, Project role, Contact. The slide example has these rows (names and contact details are left out here):

Note the last row: the project manager can be an outsider. In the Medic case, too, the PM works for BYTE Consulting, not for the hospital.

Executive roles and what each cares about

Senior executives are usually the most powerful stakeholders, and each one cares about something different. So the same project must be framed differently for each: talk to the CFO about payback, not about clinical safety. The W04 addendum describes these roles.

Engagement Levels and the Power/Interest Grid exam

Once you know who the stakeholders are, you need two judgements about each: how engaged are they now, and how engaged do we need them to be? and how much attention do they deserve? The engagement levels answer the first; the power/interest grid answers the second.

Five levels of engagement (W04 slides; PMBOK)

PMBOK's engagement assessment matrix is a table with the stakeholders as rows and these five levels as columns. In each row you mark the current (C) and desired (D) level. The gaps between C and D are what drive the engagement and communication actions: a stakeholder already at their desired level needs maintaining, while a big gap needs a plan. §5.5 fills in the matrix for Medic.

The stakeholder management plan and the stakeholder analysis

The stakeholder management plan can include the current and desired engagement levels, the relationships between stakeholders, their communication requirements, a strategy for each stakeholder, and how the plan itself will be updated.

A stakeholder analysis records each stakeholder's name and organisation, project role, unique facts, interest, influence and management strategies. The slide example shows how it turns into concrete strategies (power / interest given in that order):

The power/interest grid

The grid places each stakeholder by two judgements from the analysis: how much power they have over the project (up the side) and how much interest they take in it (across). The quadrant they land in tells you the strategy.

Placing the slide example on the grid makes the strategies above visible, including one move that uses a relationship between stakeholders.

Formal vs Agile: how stakeholder needs reach the team

The slides contrast two cases. In the formal case, an e-commerce platform for a clothing retailer, the internal stakeholders are IT (the PM, developers and testers), marketing, sales and management (the CEO and CFO), and the external ones are the payment processor and the web host. In the agile case, a food-delivery app, the internal stakeholders are the Product Owner, who represents stakeholders' needs, the Developers, and the Scrum Master, who facilitates communication; the external ones are customers and restaurant partners.

The real difference is the route by which stakeholder needs reach the team.

One model that is not in the slides is the salience model (Mitchell et al.), which classifies stakeholders by power, legitimacy and urgency. Know that it exists; the grid is what the course uses.

Medic: A Full Stakeholder Analysis exam

The exam's case-study questions ask you to apply all of the above to a scenario. Tutorial 4 does exactly that for the Medic case, the running case of the tutorials, and this section works through its answers.

Placing the Medic stakeholders on the grid

Current → desired engagement

The tutorial also gives each stakeholder's current and desired engagement level (C → D). The picture below is the engagement assessment matrix drawn as a chart. Notice how many of the client's people need to move up to Leading.

Justifying a placement (tutorial check questions)

The tutorial tested whether students could justify a position rather than just state it. The pattern in the answers: interest depends on your assumptions, while power, here, comes with the position.

From analysis to a communication matrix

The analysis then becomes a plan of who is told what, how, how often and by whom: the communication matrix. These are the tutorial's columns and answers.

A new challenge: the crisis

Teams exam

Software is built by teams, and how a team is put together and treated has a large effect on whether the project succeeds. This section defines a team, compares the ways a team can be structured, and lists the management habits known to destroy one.

Group vs team

Why teams? (six reasons from the slides)

The problems students fear in group work, such as coordination, uneven workload and unreliable teammates, also occur in industry. They are handled the same way there: through risk management, task and time tracking, and peer feedback.

Four team structures

A team can be structured in four ways, which differ in who makes the decisions. The first three each have a characteristic problem; the fourth, the collaborative structure, avoids them, and it is the one Agile teams use.

XP teams and Scrum teams

In XP (Extreme Programming, Part III), all code is written by pair programming: the driver writes the code while the navigator reviews it, and one member writes the test cases while the other does the testing. Because two people know every piece of code, knowledge is not lost when someone leaves, and juniors and seniors learn from each other.

A Scrum team is a collaborative and slightly democratic variant, and the slides give its size as 7 ± 2. Work happens in fixed-length sprints, preferably 2–4 weeks long. The team agrees how much work to take on, and members sign up for tasks. Several mechanisms keep everyone aligned: the client sees progress every sprint, everyone sees everyone's work, and burndown charts track the work remaining (Part VI).

Teamicide: seven ways to kill a team exam

DeMarco and Lister (Peopleware, 1987) could not write a recipe for a team that works well, but they could list the things that kill one. They called this teamicide.

1. Defensive management. Management shows the team that it isn't trusted.
2. Bureaucracy. Mindless paperwork kills enthusiasm.
3. Physical separation. It prevents spontaneous, casual interaction, which is what drives creativity.
4. Fragmentation of time. Switching between projects prevents concentration.
5. Quality-reduced product. Shipping poor work to cut cost or time is demoralising.
6. Phony deadlines. Artificially tight dates; a form of defensive management.
7. Clique control. Policies that break up teams, for example regularly rotating people.

Distributed (virtual) teams

A distributed team is spread across locations and relies on communication technology; such teams are also called geographically dispersed or remote teams. Organisations use them to serve a region, because staff live there, because people work from home, or to get access to high-level or lower-cost talent.

The Wikipedia reading adds structure. It gives four defining features: geographic dispersion, electronic dependence, national diversity and dynamic structure. It gives three enabling conditions: shared understanding, integration across organisational systems, and mutual trust. And it describes a lifecycle:

Finally, an HBR article (Ferrazzi 2014) reports that only 44% of virtual-team workers find virtual communication as productive as face to face.

How Communication Works and Fails exam

Everything in this Part so far, from stakeholder engagement to team cohesion, runs on communication, and communication goes wrong far more often than people expect. This section explains why it matters so much, how a message travels from one person to another, and where it gets distorted on the way.

Why it is in this subject

Communication management is an ACS accreditation requirement (the Australian Computer Society accredits the degree), and employers treat communication and teamwork as the two pillars of graduate employability; one survey ranks communication 1st and teamwork 4th of 14 skills. Yet graduates often lack them. Fewer than half of employers think graduates are adequately prepared (McKinsey), and Deloitte and PwC retrained Covid-era graduates in 2023.

Challenges at three levels (W04 slides)

The communication model (Shannon 1948)

Claude Shannon's 1948 model of a communication system breaks the journey of a message into five parts, with noise corrupting the signal on the way. The project-management version adds feedback and context.

Listening

Half of communication is receiving it. There are two kinds of listening, and the slides illustrate them with a lecture and a tutorial.

Key PM communication skills (W04 slides)

The skills a PM needs are: conveying their view, motivating and influencing, delegating, solving problems, presenting updates, setting goals and a vision, managing conflict, networking and negotiating. In practice, a successful PM must be able to read the client, run a meeting, communicate accurately in writing and speech, manage the team, influence the environment, and secure alignment and buy-in.

Communication Plans, Channels and Methods exam

A large share of a PM's time goes on communication; the PMI paper puts it at about 90%. Left to chance, that time is wasted on the wrong people, the wrong medium and the wrong moment. A communication plan makes it deliberate, and some simple arithmetic shows why it gets harder as a team grows.

The communication plan

A good plan lets the PM be proactive, sets a common understanding of what happens when, and clarifies who is responsible and who delivers what. You build it from the stakeholder analysis, using the 5 Ws and 1 H checklist from PMI: who, what, when, where, why and how. According to the W04 slides it defines eleven things.

Template 1 (§5.1) also adds rules for "communications conduct": agendas go out 2 days ahead, minutes within 24 hours, and emails are kept short and professional.

Communication channels: n(n−1)/2 exam

Why does communication get harder as a team grows? Because every pair of people is a potential line of communication, a channel, that can carry a misunderstanding. The number of potential channels between n people is a measure of communication complexity:

channels = n(n − 1) / 2

The reasoning: each of the n people can talk to n − 1 others, giving n(n − 1) ordered pairs, but "A talks to B" and "B talks to A" are the same channel, so divide by 2.

Worked examples

5 people:  5 × 4 / 2 = 10 channels        (the reading's example)
6 people:  6 × 5 / 2 = 15 channels
9 people:  9 × 8 / 2 = 36 channels

Team grows 6 → 9:
  headcount  6 → 9      +3   = +50%
  channels  15 → 36     +21  = 21/15 = +140%
  check: the 7th, 8th and 9th people add 6 + 7 + 8 = 21 channels ✓

The same growth explains a famous observation: because channels grow roughly with n², adding people to a late project can make it later. Each newcomer adds communication work for everyone already there.

Medic: 25 people, 300 channels

The Medic core team is the PM (1) + Venkat and Rameez (2) + Kimberly and 12 developers (13) + Anthony and 5 testers (6) + Fatemeh, Craig and Mengyao (3) = 25 people. That gives 25 × 24 / 2 = 300 channels. Nobody can manage 300 conversations, so the PM must structure communication through leads, stand-ups and the communication matrix.

C(7)  = 7 × 6 / 2 = 21
C(10) = 10 × 9 / 2 = 45
increase = 45 − 21 = 24   →  24/21 = +114%
headcount: 7 → 10 = +43%
check: the 8th, 9th and 10th people add 7 + 8 + 9 = 24 ✓

Face to face matters, but read Mehrabian carefully

The slides quote Mehrabian's 7–38–55 rule: 7% of meaning comes from the words, 38% from tone and 55% from body language. The lesson is to pay attention to more than the words, because nonverbal cues shape how others feel about us and how we feel about ourselves.

The slides also list some items to remember. The receiver rarely decodes exactly what was intended. Geography and culture add complexity, through working hours, language and norms. Communication helps manage conflict. Practise, and seek feedback. And choose the channel appropriately.

Channel suitability (W04 slides) exam

The slides rate how well each channel suits each purpose, from 1 = most suited to 3 = least suited. The pattern to take away: relational or emotional matters go face to face; anything that needs a record goes in writing.

The communications charter

A communications charter is a collectively designed, mutually agreed summary of a group's communication norms and practices. It is "guidelines for best practice, not a rule book" (UMD), and it is a living document. It sets out which tools to use for which tasks (synchronous, like a call, or asynchronous, like chat), formats, response times, meeting rules (attendance, cameras, minutes, time zones), how decisions are recorded, and when to escalate.

A charter saves time and cuts message volume. It also includes remote members and helps across cultures, for example with people who are reluctant to report problems to a senior. Its limitations: it can stifle informal interaction and creativity, and it takes effort. Forbes's advice is to build it with the team, so that they own it. Mindtools gives six steps for creating one:

1. Define the purpose.
2. Decide how to create it.
3. Define what it covers.
4. Set guidelines.
5. Incorporate feedback.
6. Implement and update it.

Conflict and Conflict Resolution exam

Put people with different goals, opinions and pressures on one project and they will disagree. The question is not how to avoid conflict but how to resolve it so that the project gains rather than suffers.

Common causes (W04 slides). Conflict on projects commonly arises over the schedule, intellectual disagreements, personalities, project priorities, manpower, technical opinions, administration and cost.

Views of conflict, and which kinds help

Five conflict-resolution modes (PMI reading; PMBOK names in brackets)

The PMI reading describes five ways of resolving a conflict. Each produces a different outcome and fits a different situation. Collaborating is preferred whenever possible, although it takes time.

Matching strategy to source (PMI table, condensed)

The right strategy also depends on where the conflict comes from.

PM skills for conflict (projectmanagement.com): communication, active listening, negotiation, collaboration (aiming for win–win), stress management and emotional awareness.

Kinds of Power

A PM must get things done through people who often do not report to them. Which kinds of power actually work? This is an older exam topic, not in the 2026 slides, but it appears in the predecessor subjects' past papers (Self-test Q8).

Studies of project managers (Thamhain & Wilemon) link expertise and work challenge most strongly to success, and penalty power least. Since a PM's formal power comes from the sponsoring executives, keep the sponsor engaged. (This is also why the Medic project team's power is called expert power in §5.5.)

Self-Test: Past-Exam Questions exam

The questions tagged "predecessor exam" are real questions from the exams of SWEN90016's predecessor subjects (433-443 and 433-341). No SWEN90016 paper is public; the model answers are the study guide's own, not official. Questions Q8, Q9 and Q11–Q16 appear earlier in this Part, next to the material they test.