← ArticlesFrom Work Group to High-Performing Project TeamProject Delivery · Project Leadership and TeamsLesson 3/8← PrevNext →
GuidePublished 13 Aug 2026Updated 14 Aug 202619 min readBy Kevin Joginproject leadershipproject teamsfrom work group to project teamleading project teams

Project Delivery · Project Leadership and Teams

From Work Group to High-Performing Project Team

Diagnose group maturity, guide teams through development stages and create the conditions for coordinated project performance.

Handbook guide 20 min read Reviewed 2026-08-14

Executive Summary

  • Distinguishes a collection of contributors from a genuinely interdependent project team.
  • Explains predictable development stages, group roles, norms and performance conditions.
  • Provides leader actions for formation, conflict, stabilisation, performance and closure.

Practical Outputs

  • Team maturity diagnosis
  • Stage-specific leader actions
  • Team working agreement

Practice note: Article at a glance Projects are not delivered by individuals — they are delivered by groups of people who have learned to act as teams. This article unpacks the social machinery behind that transition: how groups form, why they sometimes fail catastrophically through Groupthink, how five-stage team-development model developmental stages play out on real defence programmes, the genuine pros and cons of team-based delivery, and what changes when the team is distributed across major shipyard, engineering precinct, two distant shipbuilding locations.

1. The "Why" — Hooking the Project Manager

Walk onto the floor of the major shipyard in an Australian shipbuilding region on any given Tuesday and you will see something that no Gantt chart can capture: hundreds of welders, electrical fitters, combat-systems engineers, acquisition authority liaison officers, a prime contractor programme managers, and sub-contractor representatives coordinating through a dense web of formal meetings, informal side-conversations, messaging groups, collaboration channels, and shared coffee queues. The complex naval-platform programme is, on paper, a schedule of work packages. In practice, it is a social system — a vast constellation of interdependent groups and teams whose ability to coordinate, trust, challenge each other, and absorb bad news will determine whether the ship is delivered on time.

Project managers who treat this social system as background noise — something HR or the "soft skills people" worry about — consistently deliver late, over budget, and with a trail of burned-out staff. Project managers who understand how groups and teams actually function treat the social architecture as a first-class deliverable, equal in importance to the technical baseline.

As The supplied research put it, the PM's job is only nominally about tasks and dependencies. In reality, it is about building, maintaining, and sometimes dismantling the human structures that do the work.

Practice note: Why groups and teams have become more important Three structural shifts in the modern workplace have elevated teams from a nice-to-have to a non-negotiable:

  1. Flattening of organisational hierarchies — fewer middle managers means more decisions are pushed to working-level teams.
  2. Real or apparent delegation of power and empowerment — teams are now expected to self-direct within defined boundaries.
  3. Rising complexity of decision-making — no single individual in a modern defence programme holds all the technical, commercial, regulatory, and operational knowledge required to decide well.

In the Australian defence context, those shifts are amplified by programme scale. No single person at a prime contractor understands every interface on a complex naval-platform programme. Decisions about combat-system integration, export-controlled componentry, AS/NZS welding compliance, and public-sector customer acceptance testing must be made by groups — and those groups must function as teams, not as random collections of specialists sitting in the same video call.

2. The "What" — Groups, Teams, and the Difference Between Them

2.1 A group is not a category

A common error is to treat any collection of people as a "group". It isn't. Sociologists distinguish between three things:

Concept Definition Example in a defence context
Social category A classification based on a shared attribute. No interaction required. "All staff at the same organisational level"
Social aggregate People who happen to be in the same place at the same time, but are not acting together. Everyone in the queue for the major shipyard site-access gate at 0645
Group People with shared norms and interlocking roles who act together to achieve a common goal. The complex naval-platform programme hull-block integration team for Block 03

Practice note: Working definition (the supplied research) A group consists of people with shared norms and interlocking roles, acting together to achieve common aims or goals.

The distinction matters because PMs routinely misdiagnose their problem. A "team" that is failing to deliver may not actually be a team at all — it may be a social aggregate of specialists who have never agreed on norms, never negotiated interlocking roles, and have no shared goal beyond "attend the 0900 stand-up."

2.2 Why people join, stay in, or leave groups

There are at least five reasons a person commits to a group — and understanding them is how a PM retains critical scarce specialists on a five-year shipbuilding programme:

  • Security — the group offers protection, stability, identity
  • Task complexity — the work is too big or too technical to do alone
  • Social interaction — the intrinsic human need for company and belonging
  • Propinquity — physical or virtual closeness; you bond with whoever is on your bench
  • Exchange — the group offers rewards (money, status, learning, network) in return for contribution

A PM who loses a senior systems engineer three years into a programme should not default to "we need to pay more." That addresses only the exchange dimension. The person may have left because propinquity collapsed when the team went hybrid, or because task complexity dropped below the level that made the work interesting.

2.3 Roles inside groups — task, socio-emotional, and destructive

Every group member plays roles. These are not job titles; they are behaviours people adopt in the moment. The supplied research and others classify them into three families:

A healthy team balances task behaviours (which push work forward) with socio-emotional behaviours (which maintain cohesion). When one dominates, the team fails. A team that is all task-roles burns out and fractures under pressure. A team that is all socio-emotional roles becomes a warm, supportive club that delivers nothing. Destructive roles are the ones PMs most often ignore at their peril. The "Shelver" who quietly defers every uncomfortable decision, the "Recognition Seeker" who hijacks risk reviews to talk about their own contributions, the "Blocker" who vetoes every proposal without offering an alternative — these behaviours quietly kill programmes. The PM's job is to notice them early and challenge them directly.

Practice note: PM heuristic If you can't name the task, socio-emotional, and destructive roles currently being played in your team, you are not yet observing your team closely enough.

2.4 Groups vs. Individuals — who performs better?

A question worth asking honestly: for any given piece of work, is a group actually the right answer?

When groups outperform individuals When individuals outperform groups
Many complex tasks must be performed simultaneously Tasks can be performed sequentially by one capable person
Work requires diverse skills and perspectives Work requires sustained deep focus
Decisions need legitimacy across stakeholders Decisions need speed and decisiveness
Risks are better managed collectively Risk is contained and well-understood
Creative synthesis is required (synergy) Routine decisions of familiar type

Group performance is enhanced by synergy — the condition where the group's output exceeds the sum of individual contributions — and eroded by social loafing, the tendency of individuals to reduce effort when they believe their contribution is invisible within a collective output. Every PM has seen both.

3. Groupthink — The Destructive Norm That Sinks Programmes

3.1 Formal and informal norms

Groups develop two kinds of rules governing behaviour:

  • Formal norms — explicit, documented, often in writing (the team charter, the RACI, the safety case, the stage-gate criteria)
  • Informal norms — implicit, unwritten, learned by observation ("we don't challenge the Chief Engineer in front of the client", "we always agree with the Programme Director by the time we leave the room")

Informal norms are not inherently bad. They often play a protective function — they allow the group to preserve itself against overly rigid or repressive formal norms. A team that technically follows every acquisition authority process step but privately develops an informal norm of "raise emerging risks to your manager before the formal review so they aren't blindsided" is using informal norms healthily.

But informal norms can also become destructive. The most dangerous destructive norm is Groupthink.

3.2 the supplied research eight symptoms of Groupthink

The term groupthink emerged from analyses of failed high-level decisions. The supplied source identifies eight symptoms that, together, indicate a group has replaced rigorous thinking with the pursuit of consensus:

Symptom What it looks like on a defence programme
Illusion of invulnerability "We're a prime contractor — we've delivered frigates for decades, this schedule risk is nothing."
Rationalisation Warning signs from the integration lab are explained away as "test artefacts."
Belief in inherent morality "Our cause (defending Australia) is so important that normal cost discipline doesn't apply."
Stereotyping acquisition authority is dismissed as "bureaucrats who don't understand engineering."
Direct pressure The junior engineer who raises a welding-qualification concern is told to "be a team player."
Self-censorship The systems engineer privately doubts the integration timeline but says nothing in the review.
Illusion of unanimity Silence in the room is interpreted as agreement.
Mindguards A senior manager "protects" the Programme Director from hearing bad news before the monthly board.

3.3 The false-consensus paradox — Groupthink's quieter cousin

A second destructive norm worth naming is the false-consensus paradox: the situation where a group of people collectively decides on a course of action that no individual member actually wants, because each assumes the others want it and nobody wants to be the dissenter. The classic telling involves a family driving 53 miles in a North American site heat to a terrible diner in the destination, only to discover afterwards that none of them wanted to go — each agreed to avoid disappointing the others.

On programmes, the false-consensus paradox shows up when a PMO adopts a tool, process, or schedule commitment that nobody privately believes in, because everyone assumes the Programme Director or the customer wants it. The cure is the same as for Groupthink: explicit, structured dissent.

3.4 How to avoid Groupthink

Practice note: Anti-Groupthink strategies a PM can deploy tomorrow

  • Formally assign a Devil's Advocate role in every major decision review, and rotate it.
  • Split the team into sub-groups that analyse the same problem independently, then compare.
  • Invite external experts into key reviews — and genuinely empower them to disagree.
  • Use anonymous pre-reads (e.g., independent risk submissions before the meeting) so positions are formed before social pressure kicks in.
  • As the leader, withhold your own opinion until others have spoken.
  • Schedule a "second-chance" meeting after consensus appears to have been reached, specifically to re-open the decision.

4. How Teams Form — five-stage team-development model Developmental Stages

The five-stage team-development model, first presented in 1965, (later expanded to five stages) remains the most widely used framework for understanding how a collection of individuals becomes a high-performing team. Every PM running a new project team should be able to name the stage their team is currently in — and should expect to move through all of them.

Stage What's happening PM's primary job
Forming Polite introductions, ambiguity about roles, dependence on the leader, cautious probing Provide structure, clarity, a clear charter, and psychological safety
Storming Conflict emerges over roles, methods, status; sub-groups form; leadership is tested Do not suppress conflict — surface it, mediate it, turn it into productive disagreement
Norming Norms and working agreements settle; trust forms; the team develops its own identity Codify the agreements, protect them from disruption, step back slightly
Performing The team works with minimal supervision, high trust, high output, healthy dissent Remove blockers, supply resources, delegate, protect from external interference
Adjourning The project ends; team disperses; members grieve or celebrate Run a genuine retrospective, recognise contributions, ease transitions

Practice note: five-stage team-development model is not a one-way street Teams regress. Adding a new senior member, losing a trusted one, a major scope change, or a failed milestone review can all push a Performing team back to Storming overnight. The PM's job is to recognise the regression and re-lead the team through the stages — not to pretend it hasn't happened.

4.1 the supplied research five illusions about teamwork

The supplied research is a useful counter-weight to the "teams solve everything" narrative. It identifies five common illusions:

  1. Teams can do anything — no, some work is genuinely individual, and some problems are genuinely unsolvable regardless of team composition.
  2. Good teams are purely task-oriented — no, task-only teams burn out; socio-emotional work is not optional.
  3. Teams don't need leaders — no, leaderless teams under pressure either crown an informal leader or disintegrate.
  4. Everybody belongs in a team — no, some people genuinely perform better alone, and forcing them into teams reduces output.
  5. Teams are accountable — collective accountability is famously slippery; without individual ownership, accountability evaporates.

5. The Pros and Cons — An Honest Ledger

A mature PM does not assume teams are always the answer. Here is the honest balance sheet:

Pros of teams Cons and failure modes
Generate many new ideas Not needed for routine decisions
Recall information accurately Not always good at long chains of dependent decisions
Deploy diverse task + socio-emotional roles Allow destructive role-playing to dominate
Make available wide-ranging skills and experience Conform to narrow group norms (Groupthink)
Represent democracy in the workplace May be simply "ideological hype"
Modify authoritarian power Not everyone is a team player
Coordinate efforts Personal politics can overwhelm collective good
Speed up communication in flat structures Minority tyranny when consensus is forced
Produce creative solutions via synergy A dominant individual may overwhelm the team
Manage risks more competently Intra-group squabbling reduces coordination
Increase motivation through participation Associated with "corporate anorexia" in downsized orgs
Introduce helpful delays (reflection, review) A mediocre team produces low-quality, high-risk output
Produce unstably radical decisions
Succumb to inertia
Difficult to make responsible collectively
Can be slow and costly

Practice note: The PM's decision rule Don't form a team out of habit. Form a team when the work genuinely requires simultaneous diverse expertise, shared accountability for a complex outcome, or stakeholder legitimacy. Otherwise, assign the work to the best individual and get out of the way.

6. Virtual Teams — The New Default

A virtual team is one whose members are not always in the same physical or geographical location, and who communicate through electronic media. For Australian defence programmes, this is no longer the exception — it is the norm. A complex naval-platform programme working group routinely includes members in major shipyard, engineering precinct, a government customer site (acquisition authority), a European engineering site (a prime contractor), and an overseas customer liaison site (a naval service liaison), collaborating across 14 time zones through Teams, work-tracking software, and classified networks.

Virtual teams inherit every challenge of co-located teams — and add several of their own:

  • Propinquity collapses. Bonding through physical closeness stops working.
  • Informal norms are harder to form and transmit. New starters can't learn "how things work here" by osmosis.
  • Non-verbal cues are stripped out. Tone, body language, and side-conversations are lost.
  • Destructive roles become invisible. A "Shelver" is much easier to spot in a room than on a video call where their camera is off.
  • Groupthink risk rises. It is harder to sense silence-as-dissent over video, and easier to assume unanimity.

Practice note: Ten habits that improve communication in any team — virtual or co-located

  1. Be aware of why people join and leave groups (security, complexity, interaction, propinquity, exchange).
  2. Know the preconditions for social loafing and actively reverse them.
  3. Strive for an ideal balance of task and socio-emotional role behaviours.
  4. Reinforce healthy formal and informal norms; challenge unhealthy ones.
  5. Stay alert for Groupthink symptoms.
  6. Know what five-stage team-development model stage your team is in, and actively move it toward Performing.
  7. Be aware of the strengths and weaknesses of teams and speak up when weaknesses surface.
  8. Learn and practise core communication skills — assertiveness, feedback, questioning, listening, reframing.
  9. Learn and practise negotiation and conflict-resolution skills.
  10. Learn and practise leadership, meeting, and group-facilitation skills.

7. The Pitfalls — What Goes Wrong on Real Programmes

Practice note: Common pitfalls on heavy-engineering and defence programmes

  • Mistaking a social aggregate for a team. Putting ten specialists on a video call does not create a team. Norms, interlocking roles, and a shared goal are not optional.
  • Ignoring destructive roles. The "Shelver" and the "Blocker" will quietly kill your schedule. Name the behaviour, not the person, and address it.
  • Treating Storming as failure. Storming is a normal, necessary stage. PMs who suppress it force the conflict underground, where it becomes toxic.
  • Assuming silence means agreement. On classified programmes with strong hierarchy, silence almost always means disagreement that the junior person won't voice. Ask directly.
  • Letting virtual teams skip Forming and Norming. Distributed teams need more explicit norm-setting, not less.
  • Over-teaming. Forming a team for routine or well-understood work wastes time and dilutes accountability.
  • Never re-forming. When a key member joins or leaves, run a short re-forming session. Don't pretend the team is unchanged.
  • Trusting unanimous decisions. On complex programmes, unanimous agreement in a high-stakes review should raise your suspicion, not lower it.

8. Key Takeaways

  • A group is people with shared norms and interlocking roles acting toward a common goal — not just any collection of humans in the same space.
  • People join groups for security, task complexity, social interaction, propinquity, and exchange — PMs must manage all five to retain key staff.
  • Every team plays task, socio-emotional, and destructive roles. A healthy team balances the first two and manages the third.
  • Groupthink has eight symptoms; the false-consensus paradox is its quieter twin. Both are defeated by structured dissent.
  • five-stage team-development model (Forming → Storming → Norming → Performing → Adjourning) are descriptive, iterative, and reversible. Know your current stage.
  • Teams have genuine pros and genuine cons — form one only when the work genuinely needs one.
  • Virtual teams are the new default and require more explicit norm-setting, role clarity, and anti-Groupthink practice, not less.

9. Knowledge Check

Practice note: Self-assessment

  1. A senior engineer on your combat-system integration team has stopped raising concerns in formal reviews, despite raising them privately to you afterwards. Which Groupthink symptom is most likely operating, and what two specific interventions would you deploy this week?
  2. Your complex naval-platform programme working group has just gained three new members from a merged sub-contractor. The team was in Performing last month. Which five-stage team-development model stage should you now assume you're in, and why is pretending otherwise dangerous?
  3. A consensus decision has emerged in your monthly risk board to defer a schedule re-baseline. Nobody spoke against it, but you privately suspect three members disagree. What is the name of this failure mode, and what single structural change would most reduce its recurrence?
  4. Your programme has gone hybrid. Propinquity-based bonding has collapsed. Which two of the five reasons people join groups are now most at risk, and what concrete action addresses each?

Integrated Insights from the Supplied Source Set

The archive contains several overlapping treatments of this subject. The following sections retain the most distinct practical material while avoiding a second article that teaches the same core topic.

staged team-growth model Team Development Model

Integrated source perspective — Source 16: This section preserves distinct material from an overlapping source treatment.

The staged team-growth model studied teams specifically (not generic groups) and its vocabulary is more diagnostic — useful for self-assessment.

  • Infant Team (undeveloped): feelings suppressed, objectives fuzzy, leader-dominated.
  • Exploratory Team: active listening emerges, brief introspection, more openness.
  • Consolidation Team: cooperation, clarified task, agreed procedures.
  • Mature Team: flexibility, contributory leadership, accountability to the wider organisation.

The staged team-growth model's mature-team stage is the only one of the four models that explicitly recognises a team's responsibility to the organisation outside itself — a critical concept in defence environments where IPTs must answer to acquisition authority, the prime's PMO, and government end-users simultaneously.

Quantifying the Trade-off

Integrated source perspective — Source 17: This section preserves distinct material from an overlapping source treatment.

A simple framing used in cost-of-quality analyses applies equally to communications:

Ctotal = Cinformation + Cfailure

Where Cinformation is the cost of producing and distributing reliable information (document control, stand-ups, status reports) and Cfailure is the cost of rework, downtime, and bad decisions caused by its absence. The optimum is not zero information cost — it is the point at which one more dollar of information saves less than a dollar of failure.

Leader Behaviours That Move the Needle

Integrated source perspective — Source 29: This section preserves distinct material from an overlapping source treatment.

Each performance determinant is influenced by specific leader behaviours. This is the project manager's lever map — use it to diagnose which determinant is weak and then apply the matching behaviour.

Leader Behaviour Performance Determinant Most Affected
Visioning, expressing confidence, celebrating progress Task commitment, collective efficacy
Recruiting and selecting competent members Member skills, collective efficacy
Coaching, training, clarifying roles and priorities Member skills, role clarity, individual and collective efficacy
Planning and organising team activities and projects Efficiency, internal coordination, collective efficacy
Team building and constructive conflict resolution Mutual trust and cooperation, team identification
Networking, monitoring the external environment Adaptation to change, external coordination, strategy quality
Representing, promoting, lobbying, negotiating Resources and political support, external coordination

Notice that the first three behaviours are internally focused (the team itself), the middle two are relational, and the last two are externally focused (the organisation around the team). A PM who only exhibits internal behaviours ends up with a cohesive team that starves for resources. A PM who only exhibits external behaviours ends up with a well-resourced team that cannot execute. You need the full spectrum.

Sports Teams vs Work Teams: Similarities and Differences

Integrated source perspective — Source 68: This section preserves distinct material from an overlapping source treatment.

Management literature loves the sports-team analogy. It is useful but dangerous when pushed too far.

Similarities Dissimilarities
Need training and preparation Goals are clear in sport; often unclear or contradictory at work
Need coordination and communication Sport: individual goals can't diverge; work: they can (though undesirable)
Goal-setting motivates Sport: rules are known; work: rules mix official and unofficial
Exhortation can improve performance Sport: clear time frames; work: open-ended, multiple
Synergy is achievable and gratifying Sport: stable information environment; work: turbulent
Sport: physical effort dominant; work: mental effort
Sport: aggression channelled; work: usually inappropriate
Sport: team is the end (entertainment); work: team is a means (product/service)
Sport: compete with other teams; work: collaborate with other teams
Sport: culturally homogeneous; work: culturally heterogeneous
Sport: differential pay (superstars); work: ideally similar pay

Applying the Guidance as a Controlled Practice

Use this subject as a decision aid, not as a label applied after the event. Start by defining the delivery problem, the people affected, the authority available and the consequences of a poor decision. Record assumptions before selecting an intervention. That simple discipline makes later review possible and prevents a preferred leadership style from being treated as the answer to every situation.

Six-Step Application Cycle

  1. Define the trigger. State the decision, behaviour, team condition or delivery risk that requires attention. Separate observation from interpretation.
  2. Map the context. Identify the project phase, task uncertainty, dependencies, stakeholder interests, time pressure, team capability and formal authority.
  3. Choose a proportionate response. Select the smallest intervention capable of improving the condition. Explain why it fits the evidence and what alternatives were rejected.
  4. Agree ownership and boundaries. Make decision rights, escalation points, review dates and non-negotiable safety or ethical limits visible to the people involved.
  5. Act and observe. Monitor both delivery indicators and human signals such as challenge, information sharing, participation, trust and follow-through.
  6. Review and adapt. Compare the result with the original intent. Retain, adjust or stop the intervention, and capture the learning for the next phase.

Evidence and Verification

Required record Purpose Verification question
Team maturity diagnosis Makes the selected approach and its basis visible. Can an independent reviewer understand why this response was chosen?
Stage-specific leader actions Translates intent into owned actions, interfaces or boundaries. Does every critical action have an owner, timing and escalation path?
Team working agreement Preserves evidence of follow-through and learning. Does the record show what changed, what did not and what happens next?

Evidence should be proportionate to the project's risk and governance needs. A short decision note may be sufficient for a routine team adjustment; a high-consequence change may require sponsor approval, formal consultation, controlled records and a scheduled assurance review. Documentation must support judgement rather than replace it.

Review Questions

  • What observable condition are we trying to change, and how will we know if it improves?
  • Whose perspective is missing from the diagnosis or decision?
  • Are authority, accountability and capability aligned, or are we asking someone to own an outcome they cannot control?
  • Could the intervention suppress challenge, conceal risk or create dependency on one individual?
  • What evidence will trigger escalation, adaptation or closure?

Practice boundary: Frameworks in this article organise thinking; they do not guarantee performance. Project context, contractual obligations, safety duties, workplace requirements and approved governance remain controlling.

Continue learning

Building a Defensible Project RACI MatrixGuide · Project Leadership and TeamsNEXT LESSON →Leading Cross-Functional Project TeamsGuide · Project Leadership and TeamsProject Human Resource Management Across the Life CycleGuide · Project Leadership and TeamsChoosing Self-Managed and Virtual Team StructuresGuide · Project Leadership and Teams