When a project starts to slip, attention goes straight to the work. Meetings increase, tasks are reassigned, recovery plans are requested and individuals are asked why their part is late. Sometimes that is exactly what is needed. But often the problem was set up weeks earlier, before anyone did any project work at all.
People were assigned late, or assigned on paper while keeping their full day jobs. Roles were described but the handoffs between them were not. A critical skill was assumed to exist in the business and did not. Someone’s manager never agreed to release them. The team was expected to perform before it had agreed how decisions would be made or how disagreements would be handled. In those conditions, pressure during delivery is being used to make up for a team that was never properly formed.
This article explains how to set up a project team before the work starts, particularly in a small business where most project team members also have a day job. It covers what a team needs in place, what a kickoff should settle, how to handle the concerns of people pulled into a project, and a short readiness check to run before the pressure arrives.
A team is a temporary operating system
It helps to think of a project team as a small, temporary operating system rather than a list of names. To work, it needs:
- Enough capability: the skills the work needs, actually available, not just present somewhere in the business.
- Clear roles and handoffs: not only who does what, but where one person’s work meets another’s.
- A shared outcome: what success means, and why it matters.
- Agreed ways of working: how the team communicates, decides and handles disagreement.
- Access: to the information, tools, suppliers and decision-makers the work needs.
- A path through to the end: what happens to people as the project changes phase and closes.
Performance comes from the whole system, not just from the talent of the individuals. A team of capable people can still fail if handoffs are unclear, decisions have no owner or everyone is quietly prioritising their day job.
Role descriptions are not role clarity
A common gap: everyone knows their own tasks, but nobody knows the edges. Who decides when the estimator and the production planner disagree about a workflow? Who tells the supplier the specification has changed? Who signs off that testing is complete? These are the questions that cause rework and friction later, and they are rarely answered by a list of responsibilities.
Spend time on interfaces and decision rights. For each place where two people’s work meets, agree what is handed over, in what form, and who decides if there is a conflict. A simple table of decisions, with one name against each, prevents many later arguments.
It also helps to separate the core team, who are accountable for bringing the work together, from contributors, who provide expertise when needed. If everyone who touches the project counts as part of one large team, accountability blurs. A small core team holds the project together while contributors join for specific pieces.
Match the team to the work
There is no single ideal team structure. Match it to how tightly the pieces of work depend on each other:
- Tightly linked work, such as designing a new product where mechanical, electrical and software choices affect each other, needs close, frequent contact, often daily.
- Work in separable pieces, such as fitting out several rooms to a common standard, can run with lighter coordination and clear handoffs.
- People in different places or on different shifts need stronger written handovers and agreed information standards, because informal conversation does not happen.
Start from the work and its handoffs, not from the organisation chart.
A kickoff should settle real questions
Many kickoffs spend an hour on slides and avoid the hard questions. A useful kickoff answers:
- Why does this project matter, to the business and its customers?
- What does success mean, and how will we know?
- Which constraints are fixed, such as dates, budgets or rules, and which can move?
- Who decides what, and when do decisions go to the owner?
- Where are the riskiest handoffs?
- What do we do when we disagree?
It should also be honest about uncertainty. A plan presented as complete when it is not teaches the team to hide problems. Saying “we do not yet know how the integration will work, and finding out is the first job” builds more trust than false confidence.
Early disagreement is useful
Teams commonly go through a period of friction as people assert views and test roles. The leading discussions and building teams article covers the familiar stages of team development. The practical point here is that early disagreement is often valuable, because it surfaces different definitions of success.
Production may care most about reliability and ease of maintenance. Sales may care about features customers ask for. The owner may care about cost and cash. Those differences exist whether or not they are discussed. Surfaced early, they can be resolved by a decision. Left hidden, they come out later as rework, or as personal conflict that is really a disagreement about priorities. The aim is not to avoid friction but to keep it about the work.
People with day jobs
In a small business, most project team members keep their normal roles. Being allocated to a project tells someone where their time should go. It does not create commitment. People quietly weigh questions like these:
- Will my day job suffer, and will I be blamed for it?
- Will my project work be recognised, or will it be invisible?
- What happens to me if the project fails?
- Will this help or hurt my development and future role?
- What do I go back to when it ends?
Someone formally on a project while protecting their position in their normal role is not lacking commitment. They are responding sensibly to an unclear assignment. Design the assignment so that the answers are clear:
- Agree the time in writing, such as two days a week, and what happens to the day-job work in that time: who covers it, what is deferred.
- Agree how conflicts are resolved: when the day job and the project clash, who decides?
- Make contributions visible: in reviews, conversations and any recognition the business uses.
- Describe what happens afterwards: whether the person returns to the same role, takes on ownership of what the project built, or moves on.
The single most common failure in small-business projects is adding project work on top of a full day job and hoping. It rarely works for long.
When people join and leave part-way
Project teams change. A specialist joins for testing, a contractor leaves after installation, a team member returns to their day job once their stage is done. Each change is a small re-forming of the team, and the same questions apply on a smaller scale. A newcomer needs to know why the project matters, what has already been decided, who decides what and where their work hands over to others. Someone leaving needs to hand over what they know, not just what they did: open issues, promises made to suppliers, workarounds and the reasons behind decisions. A one-page handover note and a short conversation with whoever takes over are usually enough. Without them, the project loses knowledge each time its membership changes, and new people reopen settled arguments.
A readiness check before delivery
Before the main work begins, test the team against seven conditions:
| Condition | Question |
|---|---|
| Purpose | Does the team understand the outcome and why it matters? |
| Capability | Are the critical skills genuinely available, at the times they are needed? |
| Roles | Are responsibilities and handoffs clear? |
| Authority | Does everyone know who decides what? |
| Relationships | Have the key working relationships been established before pressure rises? |
| Ways of working | Does the team know how it will communicate and handle disagreement? |
| Transition | Do people know what happens as phases change and the project ends? |
A team that fails several of these is not ready, even if the schedule says delivery starts on Monday. Fixing the gaps usually takes days, not weeks, and is far cheaper than fixing their effects later. The sponsors who can stop and owners who must deliver article covers the roles above the team.
A worked example
This is an illustration. A 20-person printing business decides to replace its spreadsheets and whiteboard with job management software covering quoting, scheduling and invoicing. The owner names three people as the project team: the production planner, the office manager and the senior estimator. An IT contractor and two press operators will contribute when needed.
The first attempt stalls within a month. All three team members kept full day jobs. The estimator, under pressure from customer quotes, missed two configuration workshops. The planner and estimator disagreed about whether to set up detailed job costing or a simple scheduling board first, and the supplier received conflicting instructions. Nobody knew who could decide.
The owner pauses for a week and runs the readiness check. Several conditions fail: capability (time is not really available), roles, authority and ways of working. The owner makes five changes:
- Time. Each team member is given two days a week for the project. The owner takes over routine quote follow-ups for those days, and a casual staff member covers some office work.
- Priorities. The owner decides the scheduling board comes first, because late jobs are the biggest customer complaint; detailed job costing follows in the second stage. The decision is written down and shared.
- Decision rights. The production planner decides on workflow settings within the budget. Anything that changes what customers see on quotes or invoices goes to the owner. Only the planner instructs the supplier.
- Ways of working. A 30-minute team meeting every Tuesday reviews progress, open decisions and anything that needs the owner.
- Transition. After go-live, the planner becomes the system owner, with that responsibility recognised in their role. The other two return to their roles with the new system in place.
A short kickoff follows, covering why the project matters, what success looks like (on-time jobs, fewer phone calls asking about status) and the riskiest handoff: moving live jobs from the whiteboard to the system. The second attempt still meets problems, but they reach a decision-maker quickly, and the scheduling board goes live in eight weeks.
How this applies to a small Australian business
- Treat team setup as part of planning, not an extra.
- Write down time commitments, and who covers day-job work.
- Agree decision rights and handoffs, with one name per decision.
- Separate the core team from contributors.
- Run a kickoff that settles real questions, including how to disagree.
- Surface different definitions of success early, and decide between them.
- Tell people what happens afterwards.
- Run the readiness check before delivery begins.
Signals worth watching
- Team members missing project work because of day-job pressure.
- Suppliers receiving instructions from several people.
- Disagreements that keep returning without a decision.
- People unsure whether a decision is theirs.
- Project contributions nobody outside the team notices.
- A kickoff that nobody can summarise a week later.
Common mistakes
- Adding project work to full day jobs and hoping.
- Choosing team members for skills alone, ignoring how they will work together.
- Describing roles without defining handoffs.
- Treating early disagreement as a problem rather than information.
- Postponing team setup until the work is under way.
- Leaving people unsure what happens when the project ends.
Frequently asked questions
How long should setup take? For most small-business projects, a few days of focused effort: a planning session, a kickoff and the readiness check.
What if we cannot free anyone’s time? Then the project probably needs to be smaller, slower or partly outsourced. Be honest about it rather than relying on goodwill.
Should the owner be on the project team? Often the owner is better as the sponsor who makes key decisions, with a team member leading day to day. In very small businesses, the owner may need to do both.
What if two team members simply do not get on? Focus on clear handoffs and decision rights first. Many apparent personality clashes are disagreements about priorities that nobody has resolved.
Do contractors count as team members? Treat key external contributors as part of the team for handoffs and communication, even though their commitments are set by their contracts.
Questions to ask
- Does everyone on the team have the time the project needs, in writing?
- Who covers the day-job work they set aside?
- Where are the handoffs, and who decides when they conflict?
- What does each person think success means?
- How will we handle disagreement?
- What happens to each person when the project ends?
Bringing it together
Many project failures are set up before delivery begins. Treat the team as a temporary operating system: give it real capability, clear handoffs and decision rights, a shared outcome and agreed ways of working. Use the kickoff to settle questions that matter, and surface different definitions of success while they are cheap to resolve. Make assignments credible for people with day jobs by freeing time, resolving conflicts and making contributions visible. Then check readiness before the pressure arrives, because a few days spent forming a team well save weeks of recovery later.
Source: KEVOS notes, drawing on teaching material on project team development, team stages and the concerns of staff seconded to projects. Examples and figures in this article are illustrations. This article is general information.
