Software development project management

A software project has two traits that make it hard to run: the work is invisible (nobody sees a module progress until it is shown) and the scope moves (what the client imagines at the start is not what they want on seeing the first version). Running it well takes three things: a plan by phases that the team and the client understand, a work board that makes the status of each piece visible, and control of hours and changes that does not depend on anyone's memory.

The phases of a software project

PjMan comes with a "Software development" project template with six phases:

1. Discovery: understand the problem, the users and the scope before building anything.
2. Design: decide what the solution will be like, from architecture to user experience.
3. Development: build the product, usually in increments.
4. Testing: check that it works and does what was agreed.
5. Deployment: take it to production.
6. Support: maintain, fix and provide service once it is in use.

When you create the project you pick the template and its phases are copied into the project, with their code (F001, F002…). They are independent copies: you can rename them, reorder them, add others (for example, one phase per release or per module) or delete those you do not need, and each phase accepts sub-phases up to three levels. If you later change the template, projects already created are left untouched. (Creating a project, Master data and catalogues)

If you work in iterations, the template is only a starting point: you can create one phase per iteration and repeat your own sequence in a custom template.

What tends to go wrong

• The scope grows without anyone deciding it. Each "could we add…?" looks small; together they delay delivery.
• Estimates are optimistic. And deviations are discovered at the end, when there is no margin left.
• Bugs get mixed with improvements. A blocking fault and an idea for later end up on the same list.
• Work gets stuck without anyone noticing. A task "in progress" for three weeks is a signal nobody sees on a flat list.
• Decisions get lost in chats. What was agreed and why ends up buried.
• Support swallows the team that should be building the next thing.

How PjMan helps

• A Kanban board of the tasks. Each column is a status and each card a task, with its priority, phase, due date, progress, hours and assignees. Dragging a card changes its status, with an undo option, and you can filter by phase, person, priority or labels. (Kanban boards, Kanban and Gantt)
• Labels per project. Tag tasks and issues with whatever you need (a module, a release, "client review") and filter by them on the boards and in Queries. (Labels)
• Hours per phase and deviation. Each task carries estimated hours, the team logs theirs and each phase shows logged against estimated; the project header gives the total deviation. Progress is weighted by hours. (Guide to logging hours)
• Issues separate from tasks. Bugs are recorded as issues, with severity and priority as distinct axes, assignees, hours and configurable statuses; they have their own Kanban board. (Issues)
• Change requests. Each ask outside scope is recorded with its estimated effort and its decision, instead of being absorbed in silence. (Change requests)
• Comments with mentions. Each task, phase and issue has its own thread, where @ notifies inside the application whoever can see that item. Comments are a history: they are neither edited nor deleted. (Comments and mentions)
• Plan and work. The Gantt chart of the phases (read-only) and the Kanban board, on the same data.
• Assistant. Create tasks, log hours or change statuses by speaking or typing, with a confirmation card, plus analysis of the project's status. It answers with the free model or with your own key.
• Each role, its own view. The PM runs the project, management sees the portfolio read-only and each developer sees their tasks.

A starting point, not a mould

A team working in sprints, one delivering by releases and one maintaining a product do not organise their work the same way. Adjust the phases to the way you deliver, create your own template if you repeat the same pattern, and remember the essentials: few phases, tasks you can estimate and a board that is kept up to date. The guide on how to divide a project into phases and sub-phases gives practical criteria for doing so.

Try it

Create your account, create a project with the "Software development" template and move your first tasks onto the board. Or explore the demo, which includes sample projects.