One person or a team? How to choose the minimum project setup based on skills, dependencies and risk

Research does not support a simple rule such as "smaller teams are always better" or "larger teams always deliver more".

A 2023 meta-analysis covering 208 independent effects and 21,435 teams found an overall relationship between team size and task performance that was effectively zero, while also finding substantial variation by context. The authors show that the importance of team size changes with factors including task complexity and coordination requirements. [4]

An experiment on a complex crisis-mapping task also showed both benefits and costs of larger teams: collaboration increased with team size, while individual effort patterns changed. In that specific experiment, the largest teams outperformed an equivalent number of independent workers. This is not a universal prescription for every kind of work. [5]

The practical conclusion is simple: headcount should follow the nature of the work, not a magic number.

The 2020 Scrum Guide describes a Scrum Team as small, cross-functional and self-managing. It also says such a team is typically 10 or fewer people. [3]

That is useful guidance within Scrum, but it is not a universal law for every project, service, industry or delivery model.

A construction project, marketing campaign, security assessment, financial system and small informational website have very different needs. One number should not be transferred directly between those situations.

The UK Service Standard requires digital service teams to be multidisciplinary and to have access to an appropriate range of skills. It also says the team should be shaped by what it needs to achieve at a particular stage. [1]

Separate GOV.UK guidance says team size and required roles change across the phases of building a service. [2]

This leads to a practical rule:

first map the work and responsibilities, then identify the skills, and only then turn them into specific people.

You cannot size a team against an unclear scope.

Write down at least:

• the outcome to be produced,
• what is in scope,
• what is out of scope,
• the most important quality requirements,
• time and budget constraints,
• who will accept the result,
• whether the team only delivers the solution or must also operate it.

A project to "build an application" and a project to "design, build, secure, deploy and operate an application for one year" require completely different work coverage.

Instead of immediately assigning job titles, list the kinds of work that actually have to happen.

For a digital service, examples might include:

• understanding user needs,
• designing the solution,
• building the user-facing layer,
• building server-side logic and integrations,
• testing,
• security,
• accessibility,
• deployment and operations,
• coordinating scope and decisions.

A different project type will have a different list.

GOV.UK says a team building and running a digital service needs a broad set of skills covering areas such as user needs, design, build, testing, security, deployment and live operation. [2]

Not every required skill needs a full-time person on the team.

For each area, classify the need:

Continuous - needed regularly and directly influences day-to-day decisions.
Periodic - needed at specific stages or checkpoints.
Available externally - can be provided by another person or team if response time and accountability are clear enough.

GOV.UK explicitly allows specialist expertise to be available to a team without the specialist necessarily being a permanent team member. [1]

This often avoids artificially increasing team size without losing important expertise.

Two people may collectively have every required skill and still be a poor project setup if all work sits in one narrow chain of dependencies.

Check:

• which tasks can happen in parallel,
• which must wait for others,
• who makes decisions that block later work,
• which outside teams or suppliers the project depends on,
• where the absence of one person would stop several areas at once.

GOV.UK lists managing dependencies on other teams among the capabilities needed to build digital services. [2]

When more than one team works on a service, additional coordination of plans and progress is needed between teams. [8]

Some necessary expertise is not visible on a product feature list, but its absence can be costly.

Depending on the project, this may include:

• security,
• data protection,
• accessibility,
• legal or industry requirements,
• reliability,
• data migration,
• integrations with critical systems,
• technology the team has not used before.

GOV.UK recommends access to specialist expertise where a project needs it, and says team composition should also reflect the riskiest assumptions of the current phase. [1]

This does not automatically require a separate full-time role for every risk. It does mean someone competent must have explicit responsibility and a real ability to influence decisions.

One person may know design, development, testing and deployment. That does not mean they can perform all of those kinds of work at the same time under any deadline.

PMI material on resource planning highlights the importance of matching skills, availability, cost and experience to project needs. [7]

For each person, check:

• how much time they can actually commit,
• which tasks compete for their attention,
• whether required work can happen in parallel,
• whether the deadline assumes unrealistic switching between many kinds of work,
• whether someone still needs to operate the solution after launch.

Skill coverage without time coverage is not full project coverage.

A minimum setup should also account for continuity.

Ask:

• what happens if a key person is unavailable,
• whether only one person understands a critical part of the solution,
• whether decisions and knowledge are documented,
• whether someone else can take over the most important tasks,
• whether the project can safely pause during an absence.

Not every small project needs full redundancy. In a short, low-risk project, accepting this risk can be a conscious decision.

In a critical project, the same dependence on one person may be unacceptable.

A project does not need a separate person for every role label.

If one person genuinely has the required skills, enough capacity and does not create unacceptable risk, they can responsibly cover several areas.

For example, in a small project one person may combine interface design with implementation. In another, one person may combine business analysis with scope coordination.

Do not combine responsibilities simply because "someone has to do it". Combining them only makes sense when the person can perform both responsibilities to the required level and has enough time.

One person may be a rational setup when all of the following are true:

• the scope is small and well defined,
• the required skills genuinely fit that person's capabilities,
• tasks do not require substantial parallel work,
• external dependencies are limited,
• risk is acceptable,
• the deadline matches real capacity,
• lack of backup is consciously accepted.

Examples may include a small informational deliverable, a simple analysis, a one-off consultation or a limited implementation in a familiar environment.

It still depends on the specific scope. The label "small project" does not decide the answer by itself.

A team becomes more justified when several of these conditions appear:

• the required skills are too broad for one person,
• many activities must happen in parallel,
• the deadline is shorter than realistic sequential delivery,
• the project has many dependencies and interfaces,
• risk requires independent specialist knowledge,
• the solution must be built and operated at the same time,
• one person would become a critical point for the entire project,
• responsibility spans several distinct disciplines.

In these conditions, adding missing capabilities matters more than simply adding headcount.

Adding people increases the available pool of knowledge and potential capacity, but it can also increase dependencies, handoffs and the need to align decisions.

A study of software projects published in the Journal of Systems and Software found that relationships between team size, productivity, effort and time are complex and do not always match intuitive expectations. [6]

The meta-analysis on team size also shows that outcomes depend on task context and the costs of team processes. [4]

So the question is not "how many people can we add?" but "does the next person remove a real project constraint more than they increase coordination cost?"

Not every important capability has to be present every day.

Permanent presence makes more sense when the person regularly makes decisions, their work has many dependencies with other areas, or rapid response is important.

Periodic support may be enough when expertise is needed at specific points, such as a review, consultation, risk assessment or specialist acceptance.

There is one condition: availability must be real, not nominal. It must be clear:

• who is responsible,
• when they are available,
• what response time is expected,
• which decisions they can make,
• what happens if they find a problem.

Access to a specialist without defined accountability may look good on an organisation chart but fail in a real project.

Suppose the goal is to launch an online booking system.

Variant A: a simple prototype to test the idea
Scope is limited, there are no payments or particularly sensitive data, and the goal is to test the process with a small user group. One versatile person may potentially cover design and implementation, with periodic consultation where needed.

Variant B: a public service with accounts, payments and integrations
More specialisation, testing, risk, dependencies and parallel work appear. A team of several people becomes much more justified.

Variant C: a continuously running service that requires rapid issue response
Operations, monitoring, incident response and continuity of knowledge are added to delivery. The setup needed to launch may not be enough to operate sustainably.

It is the same general product type, but different scope, risk and operating model create different team needs.

1. You start from a ready-made list of job titles instead of the work to be done.

2. You assume every role requires a separate person.

3. You look only at skills and ignore available time.

4. You add people without removing dependencies and bottlenecks.

5. You ignore risk-driven capabilities because they do not create a visible feature.

6. You make several critical areas depend on one person without consciously accepting the risk.

7. You treat the team setup from the start of the project as fixed until the end.

GOV.UK explicitly says team size and roles change across the phases of service development. [2]

That is a sensible principle beyond public services as well:

• early on, more research and problem definition may be needed,
• during implementation, delivery and testing capabilities become more important,
• before launch, security, quality and operational readiness may require more attention,
• after launch, the balance shifts between development and operations.

The minimum setup is a property of the phase and scope, not a fixed number assigned to a project forever.

For every important area, write down five things:

Area of work - what must be done?
Capability - what knowledge and skill are required?
Accountability - who decides and owns the outcome?
Availability - is the capability continuous, periodic or external?
Risk of absence - what happens if the capability is missing or the person is unavailable?

Only then assign specific people.

If one person covers several rows, check their time and dependencies. If one row needs several people, check whether the reason is capacity, independent control or parallel work.

1. Does every mandatory area of work have an owner?
2. Does every critical responsibility have a person with the right capability?
3. Is anyone covering several roles, and do they realistically have enough time?
4. Does the project require parallel work the current setup cannot support?
5. Do we know the main dependencies on other people, teams and suppliers?
6. Do material risks have access to the right specialist expertise?
7. Can one absence stop the whole project?
8. Is the setup enough not only to build, but also to launch and operate the solution if that is in scope?
9. Do we know which capabilities can be periodic rather than permanent?
10. Have we defined points at which the setup will be reassessed after scope or phase changes?

Team design should not start with:

"how many people do projects like this usually need?"

A better order is:

outcome -> work -> skills -> dependencies -> risk -> capacity -> people.

If one person truly covers everything after working through that sequence, one person may be the right choice.

If skills, time, independent review, continuity or parallel work are missing, you need additional people or reliable access to specialists.

The goal is not the smallest team. The goal is the smallest setup that can realistically deliver the required outcome at the required level of risk and quality.

[1] GOV.UK Service Standard - Have a multidisciplinary team
Open source

[2] GOV.UK Service Manual - Set up a service team at each phase
Open source

[3] The Scrum Guide, 2020 - Scrum Team
Open source

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
Open source

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
Open source

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
Open source

[7] Project Management Institute - Solving The Resource Puzzle
Open source

[8] GOV.UK Service Manual - Running more than one service team
Open source

Methodology note: some sources concern digital public services, some Scrum teams, some project management, and some research on teams and software development. This guide uses each source only for the points it supports. The seven-step method for defining a minimum setup is an editorial synthesis of those principles, not a formal standard issued by any of the organisations listed above.