# Project management for software teams, explained

> Project management for software teams in plain words: what to manage, a light system that works at any size, the rhythm to keep and the mistakes to avoid.

Project management for a software team is keeping the plan, the work, the dates and the talk in step. A light system, kept up to date, beats a heavy one nobody opens.

Web page: https://kansohq.app/guides/project-management-for-software-teams

Updated: 5 October 2026

## 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 |

## A light system that works

You do not need a heavy method. You need four places, kept in step:

1. **A place to write the plan.** Specs and decisions, so the “why” survives. See [how to write a product spec](https://kansohq.app/guides/how-to-write-a-product-spec.md).
2. **A place to see the work.** A board with an owner and a priority on every card. See [what is a kanban board](https://kansohq.app/guides/what-is-a-kanban-board.md).
3. **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](https://kansohq.app/guides/how-to-plan-a-software-release.md).
4. **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](https://kansohq.app/guides/team-chat-linked-to-tasks.md).

## 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](https://kansohq.app/guides/how-to-plan-your-week.md).
- **Per release:** a plan, a checklist and a go or no-go.
- **Every few weeks:** a [retrospective](https://kansohq.app/guides/how-to-run-a-retrospective.md), 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](https://kansohq.app/guides/project-management-for-growing-teams.md) and [large teams](https://kansohq.app/guides/project-management-for-large-software-teams.md).

## 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 |

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](https://kansohq.app/product/docs.md) for the plan, [boards](https://kansohq.app/product/boards.md) for the work, a [calendar](https://kansohq.app/product/calendar.md) and [release pages](https://kansohq.app/product/releases.md) for the dates, and [chat](https://kansohq.app/product/chat.md) and an [inbox](https://kansohq.app/product/inbox.md) for the talk. They link to each other, so nothing is written down twice. See the [use cases](https://kansohq.app/use-cases.md) and the [templates](https://kansohq.app/templates.md).

## Questions

### What is project management for software teams?

It is keeping the plan, the work, the dates and the talk in step, so the right thing is built in a sensible order. In practice it means a written plan, a board of owned tasks, a view of the dates and a place to talk.

### Do software teams need a project manager?

Not always. Small teams often share the job between a product lead and an engineering lead. As a team grows, someone has to own the plan and the dates, whatever their title.

### What is the best project management method for software?

There is no single best. Kanban suits continuous flow, scrum suits teams that want fixed cycles, and many teams mix them. Start with the lightest approach that keeps work visible.

### What tools does a software team need?

A place for specs, a task board, a view of dates, and a way to talk that links to the work. Some teams use four tools for this; others use one workspace that covers all four.

## Keep reading

- [Choosing project management software for a dev team](https://kansohq.app/guides/choosing-project-management-software.md): How to choose project management software for a software team: the questions to ask, the kinds of tool on offer and how to test one on real work.
- [Project management for growing software teams](https://kansohq.app/guides/project-management-for-growing-teams.md): What breaks as a software team grows from 5 to 50 people, and the small changes that fix it: owners, written decisions, shared dates and a steady rhythm.
- [Project management for large software teams](https://kansohq.app/guides/project-management-for-large-software-teams.md): How to manage software work across many people and teams: clear ownership, one view of cross-team launches, roles, written decisions and the right tools.
- [PRD template: a free product spec to copy | Kanso](https://kansohq.app/templates/product-spec.md): A free PRD template for software teams: problem, solution, who it is for, scope, success measure and open questions. Copy it, or start it in Kanso.
- [Sprint planning template: goal, work and risks | Kanso](https://kansohq.app/templates/sprint-plan.md): A sprint planning template with the sprint goal, committed work, stretch, risks and what is out of scope. Copy it, or start it in Kanso.
- [Software launch checklist template to copy | Kanso](https://kansohq.app/templates/launch-checklist.md): A software launch checklist template covering product, quality and go-to-market, launch day and after launch. Copy it, or start it in Kanso.

## Parts of Kanso used

- [Kanso Docs](https://kansohq.app/product/docs.md): Pages with headings, to-dos, tables and code, kept inside the project they describe, next to its board and its release.
- [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done.
- [Kanso Releases](https://kansohq.app/product/releases.md): A release page gathers the work behind one date into sections, with an owner, a due date and a status on every line.
- [Kanso Chat](https://kansohq.app/product/chat.md): Channels and direct messages that link straight to the task, page or release being discussed.

[Kanso home, with plans and prices](https://kansohq.app/index.md)