Leading Projects: Stakeholders, Communication & Teams: The People Half of Every Plan

The project is a new city library building. On the Monday before the move, the director learns that the planning office has not signed off the fire exits, the residents' group has written to the council, the contractor thinks someone else is ordering the shelving, and two people on the team each believe the other is telling the staff what happens on moving day. Nothing here is a scheduling problem. The Gantt chart is fine. Every one of these is about people: who needs to know, who decides, who does, and who dares to say "this is going wrong".

Projects mostly fail through people, not through arithmetic. The planning pieces of this minor give you the schedule and the numbers; this one gives you the other half. Its ideas come from the stakeholder literature, from Fred Brooks's 1975 essay collection The Mythical Man-Month, from team research by Amy Edmondson and others, and from the closing and learning practices of the major project bodies of knowledge.

Stakeholders: who can help or hurt you, and what they need

A stakeholder is anyone who affects the project or is affected by it. The word is wider than "customer": it includes the people who fund it, regulate it, build it, use it, live next to it, and the ones who will inherit it when you leave. The first discipline of a project leader is to list them before choosing anything, because a stakeholder you forgot is the one who appears in month nine with a veto.

Two classic tools sort the list. The power/interest grid, associated with Aubrey Mendelow, puts each stakeholder on two axes: how much they can change the project, and how much they care. High power and high interest means manage closely. High power and low interest means keep satisfied, since they can stop you but are not watching. Low power and high interest means keep informed, because they are your allies and your early warning. Low and low means monitor. A richer model by Mitchell, Agle and Wood (1997) scores power, legitimacy and urgency, which helps when a quiet group with a legitimate claim risks being ignored.

The Sydney Opera House shows what a mis-managed stakeholder relationship costs. The 1957 estimate was £3.5 million with completion by 26 January 1963; the building opened on 20 October 1973 and cost about A$102 million. The architect Jørn Utzon left on 28 February 1966, after the state's Minister for Public Works, Davis Hughes, withheld funding so that Utzon could not pay his staff, and the two men could no longer work together. Engineering uncertainty drove much of the overrun too, so the story is not only about people, but the person who knew the design best and the person who paid for it could no longer talk.

Without JavaScript: a typical placement is director high/high; city finance committee high power, low interest; planning office high power, low interest; library staff low power, high interest; daily patrons low power, high interest; occasional visitors low/low; the moving company low/low; the residents' group high/high.

There is no single correct grid. The point of the exercise is the conversation: someone else on your team will place the planning office higher than you did, and that disagreement is information. Redo the grid at each phase, because people move on it.

RACI: making sure every job has exactly one owner

A RACI grid answers the Monday-morning question "whose job is this?" Rows are tasks or decisions; columns are people or roles. Each cell holds one letter. R, responsible: does the work. A, accountable: owns the outcome and the final yes, and answers if it goes wrong. C, consulted: asked before, two-way. I, informed: told afterwards, one-way. When one person does the work and owns it, write "A/R".

The rule that makes the grid worth drawing: exactly one A per row. Two accountable people means no accountable person, because each assumes the other will decide. No A means the decision belongs to whoever shouts loudest. Every row also needs at least one R, otherwise the task is owned and not done. Two further smells: a column full of R is a person who will become the bottleneck, and a row full of C is a decision made by committee. Variants add detail: RASCI adds S for support, and DACI (common in product teams) names a Driver, Approver, Contributors and Informed. They share the one-decider principle.

Without JavaScript: in the flawed grid, "Approve the design" has two As (Sponsor and Client), "Order long-lead materials" has no A, and "Run acceptance test" has an A but no R.

Channels: why a bigger team talks less to each person

Brooks wrote in 1975 that adding people to a late software project makes it later. He gave the law as: "Adding manpower to a late software project makes it later." His reasoning had three parts: new people take time to learn, they take the time of the people teaching them, and work that needs coordination cannot be cut into independent pieces. On the last point he noted that if every part must be coordinated with every other part, the effort rises as n(n − 1) ÷ 2.

Five people have 10 possible pairs. Ten have 45. Twenty have 190, and fifty have 1,225. Doubling the team more than quadruples the pairs. Brooks's own remedy was structure: a small team with a clear surgeon-like lead and supporting roles, and sub-teams that talk through their leads. Brooks's law is a rule of thumb from experience on large software projects, not a theorem. It holds most strongly when a project is late, work is tightly coupled and the new people need training.

Without JavaScript: 10 people have 45 possible channels; split into two squads of 5 with one lead each there are 10 + 10 + 1 = 21. Twenty people: 190 channels flat, or four squads of 5 with leads: 4 × 10 + 6 = 46.

Truth, safety and conflict: how a team hears its own bad news

A status report has one job: to let a reader decide. A good one fits on a page and answers four questions in order. Where are we against the plan? What changed since last time? What is at risk? What do you need from me, and by when? Reports that say "green" until the week of failure are common enough to have a name: the watermelon (green outside, red inside); Risk, Cost & Project Control (36/93) covers the numbers. The fix is cultural. A team that is punished for amber will report green.

That is psychological safety, defined by Amy Edmondson in 1999 as a shared belief that you can speak up with a question, a mistake or a disagreement without being punished for it. Organizational Behavior & Leadership (34/53) covers the evidence; here is the project use. Google's internal Project Aristotle, reported publicly from 2015 and described in the New York Times in 2016 as an analysis of 180 teams, named five dynamics: psychological safety, dependability, structure and clarity, meaning, and impact. It was one company's analysis, not an experiment, but its message agrees with the academic work: who is on a team predicts less than how they treat each other. For a project leader the practical moves are small: ask for the bad news first, thank the person who brings it, and never shoot a messenger in front of the team.

Meetings are the main place where this is won or lost. A meeting needs a purpose that is a decision or a piece of shared thinking, an owner, and an output (decisions and actions with names and dates). If the purpose is to pass information one-way, send it in writing. Decision rights should be stated before the argument: who decides, who must be consulted, and what happens if two leads disagree.

Conflict is normal and not always bad. The Thomas–Kilmann model (Kenneth Thomas and Ralph Kilmann, 1974) describes five ways people handle it, along two dimensions: how assertive you are about your own goals, and how cooperative about the other person's. It is a model that organises thinking, and the questionnaire built on it is a commercial product; no style is "best".

Mode	Assertive	Cooperative	Often fits when
Competing	high	low	an emergency or an unpopular but necessary call
Collaborating	high	high	both concerns matter and there is time to find a better option
Compromising	middle	middle	a quick, fair split is worth more than the perfect answer
Avoiding	low	low	the issue is trivial, or people need to cool down first
Accommodating	low	high	you were wrong, or the relationship matters more than this point

Distance: time zones and working across cultures

A project spread over several countries pays a plain arithmetic tax: the hours in which everyone is at work. Three teams in Lagos, São Paulo and Manila share no working hours at all. The tool below finds the overlap. Use it before scheduling a recurring meeting, and rotate the inconvenient hour between sites instead of always giving it to the same people. In a distributed team, write decisions down: what was said in a call at 07:00 for one person and 20:00 for another should be readable in the morning by the third.

Without JavaScript: with 8-hour days starting at 09:00 local, Lagos (UTC+1), São Paulo (UTC−3) and Manila (UTC+8) have no hour in common; Lagos and Manila share one hour, 08:00 to 09:00 UTC.

Cultural differences in communication are real and also easy to turn into stereotypes. Anthropologist Edward Hall (1976) described high-context communication, where much is left to shared understanding, and low-context, where meaning is spelt out. Erin Meyer's The Culture Map (2014) put countries on scales such as direct versus indirect negative feedback. Treat such maps as questions, not predictions: differences between individuals, companies and professions are large, and Geert Hofstede's older country scores have been criticised for method and age. A safe working rule is to say how you work ("I will say 'this will not work' directly; please do the same") and to ask a colleague from the other site how they would read a message before you send a hard one.

Vendors and contracts: who carries the risk

Many projects buy work from outside. The pricing model in the contract decides who pays when the work turns out larger than estimated. In a fixed-price contract the buyer pays an agreed sum for a defined scope, so the vendor carries overrun risk; a vendor will often add a margin for it and will price changes separately. In time-and-materials, the buyer pays for hours or goods used, so the buyer carries the overrun risk and the vendor has less reason to be efficient. Cost-plus pays costs plus a fee, and target-cost or shared-saving contracts split overruns and savings by an agreed ratio. Large construction contracts often use published forms such as FIDIC (international) or NEC (UK and elsewhere). This describes how they work; it does not recommend one, and the right form depends on how well the scope is understood. Fixed price suits stable scope, and time-and-materials or shared risk suits work still being discovered.

Without JavaScript: at 150% of the estimate, a fixed price still costs the buyer 100,000 and leaves the vendor at −20,000; time-and-materials costs the buyer 150,000 and the vendor earns 30,000; the shared contract costs the buyer 125,000 and the vendor earns 5,000.

Closing well, and the career map

A project that stops is not the same as one that is closed. Closing normally means: the customer checks the result against the acceptance criteria written at the start (the charter, Foundations 36/90), the work is handed over with training and documents, contracts are finished and paid, the team is released, and someone is named to measure whether the promised benefits arrive months later. The project does not own benefits; the business does.

Then comes lessons learned. Most teams hold a retrospective and then change nothing. Norm Kerth's book Project Retrospectives (2001) gave the practice its standard starting rule, the Prime Directive: whatever you find, assume everyone did the best job they could given what they knew, their skills, the resources and the situation. That makes honest talk possible. A retrospective that changes something has three things: one or two chosen actions, an owner and a date for each, and a first agenda item at the next one: did we do last time's actions? Scrum's Sprint Retrospective (Scrum Guide, 2020) has the same logic on a shorter cycle.

Careers in this field run through professional bodies, and their rules change, so check the issuer. PMI (USA, global) issues the PMP, for people with project-leading experience, and the entry-level CAPM; its PMBOK Guide's 8th edition appeared in November 2025. PeopleCert, which took over from AXELOS, issues PRINCE2 (7th edition, 2023) at Foundation and Practitioner levels. The APM (UK) offers qualifications and a chartered status. IPMA runs a four-level scheme (D to A) based on its Individual Competence Baseline. Agile roles have credentials from the Scrum Alliance and Scrum.org. None is a licence to practise, and none replaces having led something. No salaries are quoted here, since they vary by country and year.

Template: RACI and communication plan

Fill this in at kickoff and change it when people change. It produces plain text you can paste into a document or a chat. Nothing is saved or sent anywhere.

What a graduate just sees

• A forgotten stakeholder is the one who appears late with a veto; list them first and redo the grid at each phase.
• A task with two accountable people has none, and a task with none is owned by whoever shouts.
• The number of possible conversations grows with the square of the team, so structure the team before you enlarge it.
• Brooks's law is a warning about late, tightly coupled work, not a ban on hiring.
• A team that is punished for amber reports green: the status report measures safety as much as progress.
• Every meeting needs a purpose, an owner and an output with names and dates; time zones are arithmetic and culture maps are questions.
• A contract's price model is a risk allocation: ask who pays when the work is bigger than the guess.
• A retrospective that changes nothing is a ritual; the test is whether last time's actions got done.

Where it shows up next

• Risk, Cost & Project Control (36/93): the status report and watermelon problem, and the contract risk split, with their numbers.
• Agile, Scrum & Kanban (36/92): the sprint retrospective, Definition of Done and team working agreements put these ideas on a short cycle.
• Construction Management (34/70) and Operations Management (34/52): contract forms, subcontractors and handover on site.
• Product Management: The Job (36/95): the product role leans on stakeholders and a trio rather than a plan.
• In the world: a hospital building programme, a software migration, a stadium for a world championship, a school refurbishment, a wedding.

If you want to go deeper

• 📘 Textbooks. Fred Brooks, The Mythical Man-Month (Addison-Wesley, anniversary edition, 1995), the classic on team size and software; and Amy Edmondson, The Fearless Organization (Wiley, 2019), on psychological safety at work.
• 📘 Gentler. Norman Kerth, Project Retrospectives: A Handbook for Team Review (Dorset House, 2001), a short guide to running one well; and Erin Meyer, The Culture Map (PublicAffairs, 2014), read as a set of questions, not rules.
• 🌐 Free course. MIT OpenCourseWare 1.040, Project Management (Spring 2009), from Civil and Environmental Engineering.
• 🌐 Reference. Google re:Work, Understand team effectiveness, and the Scrum Guide (2020) for the retrospective event.