What project management is for a software team
It is the work of making sure the right thing is built, in a sensible order, by people who know what they are doing and when it is due. For a software team that comes down to five things to keep in view: scope, work, time, people and risk.
| What to manage | The question it answers | Where it usually lives |
|---|---|---|
| Scope | What are we building, and what are we not? | A spec or PRD |
| Work | What is being done, by whom, and what is next? | A task board |
| Time | What is due, and is the date still safe? | A calendar or a release plan |
| People | Who owns what, and who can decide? | Roles and assignments |
| Risk | What could stop us, and what are we doing about it? | Blockers, reviews and checklists |
Scope
The question it answers
What are we building, and what are we not?
Where it usually lives
A spec or PRD
Work
The question it answers
What is being done, by whom, and what is next?
Where it usually lives
A task board
Time
The question it answers
What is due, and is the date still safe?
Where it usually lives
A calendar or a release plan
People
The question it answers
Who owns what, and who can decide?
Where it usually lives
Roles and assignments
Risk
The question it answers
What could stop us, and what are we doing about it?
Where it usually lives
Blockers, reviews and checklists
A light system that works
You do not need a heavy method. You need four places, kept in step:
- A place to write the plan. Specs and decisions, so the “why” survives. See how to write a product spec.
- A place to see the work. A board with an owner and a priority on every card. See what is a kanban board.
- A place to see the dates. A calendar for the week and a release page for each ship date. See how to plan a software release.
- A place to talk. Chat that links to the work, so conversations do not float free of it. See why team chat should link to tasks.
The rhythm to keep
- Daily: a glance at the board. What moved, what is blocked.
- Weekly: ten minutes to rank what is next and remove what is dead. See how to plan your week.
- Per release: a plan, a checklist and a go or no-go.
- Every few weeks: a retrospective, with one or two changes that someone owns.
How it changes with team size
The same ideas work from one person to hundreds, but what you add changes. A solo builder needs a plan and a board. A small team adds owners, a shared calendar and chat. A growing team needs written decisions and roles. A large organization needs clear ownership between teams and a shared view of cross-team launches. See growing teams and large teams.
Mistakes to avoid
- Adding process before there is a problem for it to solve.
- Using several tools for the same job, so no one knows where the truth is.
- Cards without owners, or an owner with too many cards.
- Plans that are written once and never changed.
- Treating the tool as the method. A board does not fix unclear scope.
Agile, waterfall or something in between?
The method matters less than whether the team can say what it is doing and what comes next. Still, it helps to know the main shapes.
| Approach | How it plans | Fits when |
|---|---|---|
| Waterfall | Everything is specified first, then built, then tested, in order | Requirements are fixed and change is costly, as in hardware or regulated work |
| Agile (scrum) | Short fixed cycles, each ending with working software | Needs change and the team wants regular checkpoints |
| Kanban | Continuous flow with limits on work in progress | Work arrives unpredictably, as in support and maintenance |
| Hybrid | A fixed date and scope for a release, with agile or kanban inside it | A launch has a date that cannot move, but the way to reach it can |
Waterfall
How it plans
Everything is specified first, then built, then tested, in order
Fits when
Requirements are fixed and change is costly, as in hardware or regulated work
Agile (scrum)
How it plans
Short fixed cycles, each ending with working software
Fits when
Needs change and the team wants regular checkpoints
Kanban
How it plans
Continuous flow with limits on work in progress
Fits when
Work arrives unpredictably, as in support and maintenance
Hybrid
How it plans
A fixed date and scope for a release, with agile or kanban inside it
Fits when
A launch has a date that cannot move, but the way to reach it can
Most software teams end up with a hybrid: a release date set by the business, and a flow of work inside it that the team manages with a board.
The roles that matter
- Someone who owns the problem: decides what to build and what to leave out. Often called product manager.
- Someone who owns the build: keeps the technical work sound and the team unblocked. Often a tech lead or engineering manager.
- Someone who owns quality: checks that it works. A tester, or the whole team sharing the job.
- Someone who owns the date: tracks the plan to a release. On a small team, this is the same person as one of the above.
Titles vary. What matters is that each of these four jobs has a name beside it.
What to measure
Measure few things, and only ones you will act on.
- How long work takes from started to finished, and whether it is steadier over time.
- How many things are in progress at once.
- How many releases slip, and by how much.
- How often something that shipped had to be fixed straight away.
Avoid measuring individuals by how many tasks they close. It rewards the wrong behavior and hides who is doing the hard, slow, important work.
Project management in Kanso
Kanso puts the four places in one workspace: docs for the plan, boards for the work, a calendar and release pages for the dates, and chat and an inbox for the talk. They link to each other, so nothing is written down twice. See the use cases and the templates.
