Lesson 1 — Team Organization and Resource Management¶

At a glance

Module: 10 — Team Resources & Communication
Level: Intermediate
Estimated time: 45 minutes
Example project: the university admission portal

Learning objectives¶

By the end of this lesson you should be able to:

Compare functional, projectized, and matrix organisational structures.
Explain how team structure constrains system structure, and choose a team shape deliberately.
Estimate the communication cost of team size and use it in decisions.
Apply resource smoothing and levelling to resolve overallocation.
Explain how motivation and autonomy affect delivery, using established models.

Prerequisites¶

Module 06 — Schedule Management

Introduction¶

Every schedule assumes people are available. This module is about that assumption. Resources are the only project input that thinks, negotiates, gets tired, and can refuse — which is why resource management is less like allocating a budget and more like designing a small organisation.

This lesson covers where the team sits in the wider organisation, how it should be shaped, how large it should be, and what to do when the plan over-allocates someone.

1. Where the project sits¶

Structure	Project manager's authority	Strength	Weakness
Functional	Little; work flows through the department	Deep specialism, clear career path	Projects compete for attention with operations
Projectized	High; team reports to the project	Focus, fast decisions	Specialists are isolated; reallocation after the project is disruptive
Matrix (weak / balanced / strong)	Varies along a spectrum	Balances specialism with focus	Two managers per person; competing priorities

Most real software projects run in some form of matrix, and most matrix problems are the same problem: a person who is 60% on your project and 50% on another is not 110% available — they are interrupted, and their effective capacity is well below 60%.

Make the split explicit and get it agreed in writing. "Shared with the operations team" is not an allocation, it is an ambiguity, and it will resolve in favour of whoever shouts loudest.

2. Team shape and system shape¶

Conway's Law (Melvin Conway, 1968) observes that organisations design systems that mirror their own communication structures. A team split by component produces a system split by component; four teams coordinating on one deliverable produce four parts that need coordinating.

The practical consequence is that team design is architecture design, whether or not you intend it to be.

Team shape	Organised by	Good when	Risk
Component team	Layer or module (UI, API, database)	Deep technical specialisation is essential	Every feature spans teams; handoffs multiply
Feature team	End-to-end capability	Delivery speed matters; technology is well understood	Needs broad skills; risks duplicated platform work
Cross-functional team	Mixed specialties, self-contained	Most product work	Requires trust and shared standards to work

Whichever you choose, note the dependency it creates and manage it. A component split makes the integration path the busiest road in the project; a feature split makes shared platform work the contested one.

3. Team size and communication cost¶

The number of communication channels between n people is n(n − 1) ÷ 2.

People	Channels
4	6
6	15
8	28
12	66

Doubling the team roughly quadruples the connection count. This is the arithmetic behind the observation that adding people to a late project can make it later: the new people must be onboarded by the people who are already the constraint, and every new relationship needs maintaining.

Practical implications:

Prefer adding people to a well-scoped, separable piece of work, not to a shared one.
Keep the team small enough for the work, and reduce the need for communication through clear interfaces and written decisions.
Onboard in waves, not all at once.

4. Resolving over-allocation¶

When the same person is scheduled for more than they can do, escalation is not the first tool.

Technique	Effect	When to use
Resource smoothing	Delays tasks only within their float	The deadline can be preserved; some activity has float
Resource levelling	Delays tasks beyond their float	The deadline is flexible and overload is unacceptable
Substitution	Uses a different person	Skills are transferable and quality is maintained
Descope	Removes work	The overload is structural and sustained

Smoothing first, levelling second, substitution third, descoping when the arithmetic says the plan was never possible. Repeated levelling that keeps extending the schedule is a signal that the team is too small for the scope — a fact worth reporting rather than absorbing.

5. Motivation and group development¶

Two models worth knowing, both because they are useful and because they are frequently misused.

Tuckman's stages (Bruce Tuckman, 1965) describe group development as forming, storming, norming, performing — with adjourning added later. A team that is storming is not broken; it is normal, and it is where disagreement about standards gets resolved. A project manager's job changes with the stage: direction at forming, facilitation and conflict resolution at storming, delegation once performing.

Theory X and Theory Y (Douglas McGregor, 1960) contrast two assumptions about people: that they avoid work and need control, or that they seek responsibility and need conditions to do good work. The framework is descriptive, not a licence to declare yourself Theory Y — the observable behaviour is in the management practices, not the stated belief. Micromanagement and autonomy cannot coexist, and forced overtime is the strongest possible signal that time is the lever.

Key terms¶

Term	Meaning
Functional / projectized / matrix	Organisational placements of a project
Conway's Law	System design mirrors organisational communication structure
Feature team	A team organised around end-to-end capability
Component team	A team organised around a technical layer or module
Communication channels	Connections between team members, counted as n(n − 1) ÷ 2
Resource smoothing	Resolving overload within available float
Resource levelling	Resolving overload by extending the schedule
Tuckman's stages	Forming, storming, norming, performing, adjourning
RACI	Responsible, Accountable, Consulted, Informed

Worked example¶

Task: organise the delivery team for the illustrative admission portal. All numbers are assumed for teaching.

Step 1 — State the structure. The project is in a balanced matrix: the IT department owns technical standards, the project owns delivery. Every person therefore has two managers, and the split must be written down. The developer "shared with operations support" is agreed at 20% and recorded as such — with the consequence that they are unavailable on two days a week, which the schedule must reflect.

Step 2 — Choose a team shape. The portal is one end-to-end capability with a hard external deadline. That favours a feature team: four developers, one business analyst, one QA, plus a part-time database administrator. The trade-off to accept explicitly: nobody is a deep specialist in the reporting platform, so a shared standards document is required.

Step 3 — Count the communication cost. Eight people give 8 × 7 ÷ 2 = 28 channels. If the team grew to twelve, it would be 66 — more than double, for 50% more people. That arithmetic is the reason the plan adds a second small team for the reporting work rather than growing this one.

Step 4 — Find the overallocation. The schedule assigns the analyst to requirements workshops and to acceptance-test support on the same three days. Two activities, one person, in the same period.

Step 5 — Smooth first. The acceptance-test support is not on the critical path and has three days of float, so move it. The deadline is untouched and the overload is resolved — the ideal outcome.

Step 6 — Level only where necessary. A second clash cannot be moved within float. Levelling extends the schedule by two days. Report it, because it changes the end date: "Resolving the analyst overload in week 6 extends delivery by two days unless we accept reduced review coverage."

Step 7 — Watch the group stage. In week 1 the team is forming and needs direction. By week 3 there is disagreement about the interface conventions — storming, and the correct response is to facilitate a decision, not to impose one. Imposing it would remove the disagreement and the ownership with it.

Common misconceptions¶

“A part-time resource is proportional”

A person at 50% is not half a person; they are a person with frequent context switches and unpredictable availability. Plan at less than the nominal fraction, and never place a part-time person on the critical path without saying so.

“Adding people accelerates delivery”

Only when the work can be divided cleanly and the new people can be absorbed. Otherwise the essential constraint — the people who must onboard them — gets slower.

“Storming means the team is failing”

It is a normal stage, and the conflict it contains is about standards the team must settle. Suppressing it defers the problem rather than solving it.

Practical activity¶

Design a delivery team. For one example project:

State whether the project sits in a functional, projectized, or matrix structure, and note the authority the project manager actually has.
Choose a team shape and justify it against the alternative.
Count the communication channels for your team, then for a team one third larger.
Build a resource-assignment table and identify at least one overallocation.
Resolve it with smoothing, then with levelling, and state what each costs.
Write a RACI row for one major decision using the RACI matrix template.

What "good" looks like: an honest statement of the matrix split, a team shape justified against its alternative, arithmetic on communication channels, and a levelling decision reported with its schedule consequence rather than hidden.

Self-assessment¶

A person is allocated 60% to your project and 50% to another. Why is their realistic capacity lower than 60%?
What does Conway's Law predict about a team split by technical layer?
When should you smooth rather than level a resource overload?
What is the difference between the two theories X and Y describing?
Apply it — LMS team size. The sponsor suggests adding two developers to the six-person team to bring the date forward. One of the two is a specialist who works from another city; the other is new to the codebase.

Hint: A strong answer quantifies the communication cost and states the condition under which adding people would actually help.

Show answers

Because the two commitments do not occupy neat disjoint blocks: context switching, competing deadlines, and interruptions consume part of both fractions, and neither manager sees the whole picture. Real capacity is well below the sum, and often below the larger share alone.
That the system will tend to mirror the split — a layered system, with integration work concentrated at the boundaries between teams. That integration path becomes the project's busiest and most failure-prone territory.
When the deadline is fixed and the overloaded activity has enough float for the delay, so moving it costs nothing on the critical path. Level when overload is unacceptable and the schedule can absorb the extension.
Two sets of assumptions about what motivates people — that they avoid work and require control, or that they seek responsibility given the right conditions. They describe management assumptions and the practices that follow from them, not fixed types of people.
Communication channels grow as n(n-1) ÷ 2: six people have 15 channels, eight have 28 — 13 more paths, an 87% increase, before either new person has learned anything. In a project with a near date, adding people usually reduces delivered output for a while: the existing team spends its capacity on onboarding and coordination, the remote specialist adds handoff and time-zone cost, and the new starter cannot pick up the critical-path work. Adding people helps only when the remaining work can be partitioned into separable pieces with a clean interface that one person can own end to end — then budget explicit onboarding and name a knowledge-transfer owner. If it cannot be partitioned, look at levelling (shifting work within float) or at reducing scope before adding headcount.

Summary¶

Organisational structure determines how much authority a project manager has, and matrix structures require explicit, written allocations.
Team shape constrains system shape, so choose it deliberately and manage the dependency it creates.
Communication channels grow as n(n − 1) ÷ 2, which is why adding people has a cost before it has a benefit.
Smooth overload within float where possible; level and report the schedule consequence where not.
Group development is staged, and management behaviour should change with the stage.

Further learning¶

Lesson 2 — Communication and Stakeholder Management
The Mythical Man-Month, Frederick P. Brooks Jr. — on team size, communication, and schedule.
Peopleware: Productive Projects and Teams, Tom DeMarco and Timothy Lister.
Melvin E. Conway, "How Do Committees Invent?", Datamation, 1968 — the original statement of Conway's Law.
Bruce W. Tuckman, "Developmental Sequence in Small Groups", Psychological Bulletin, 1965.

Next¶

Continue to Lesson 2 — Communication and Stakeholder Management.