Project management

What this shelf covers

Planning work across people and keeping track of whether it is happening: tasks with owners and dates, dependencies, capacity, milestones and the reporting a stakeholder asks for.

The line with task management is real. One organises a person’s day. The other coordinates several people whose work depends on each other, and that coordination is what justifies the extra weight.

Personal lists and small team boards sit in task management. Time and billing belong in time tracking.

Match the tool to how work actually arrives

Three patterns cover most teams, and products favour one.

Continuous flow suits work arriving unpredictably: a board, a queue, limits on how much is in progress. Iterative delivery suits teams planning in fixed periods with estimates and a review at the end. Scheduled delivery suits work with real dates and dependencies, where a slip in one place moves everything after it.

Buying a scheduling-heavy product for a team that works in flow produces elaborate plans nobody updates. Buying a lightweight board for construction work produces missed dates. Decide the pattern first, then judge the software.

The features that earn their weight

• Dependencies, when one piece genuinely blocks another with a date attached.
• Capacity, to see who is overloaded before the deadline proves it.
• Custom fields and views, so one dataset serves several audiences.
• Automation, for status changes and handovers nobody should do by hand.
• Reporting, aimed at people who will never open the tool.

Everything on that list costs something in setup and discipline. Adopt the ones you will maintain, since a half-configured system misleads more than a plain list.

Adoption decides everything

Every failure in this category looks the same. The plan stops matching reality, people fall back on chat and memory, and the tool becomes a museum of intentions.

That happens when updating takes effort disproportionate to the value returned. Look at how many actions it takes to move a task, add a comment, change a date or hand something over. Look at whether the phone application can do the daily minimum. Look at whether notifications tell people what changed without burying them.

Then decide the conventions before rolling out: what a status means, who owns a task, what happens to work nobody picks up. Software does not supply those, and their absence is what produces four hundred items in an untouched backlog.

Working with people outside the team

Clients, contractors, auditors and executives usually need to see without editing.

Check guest access, what it costs and what a guest can see by default. Then check reporting for people who will never log in, since a weekly summary that arrives by mail is often what actually keeps a stakeholder informed.

Approvals and proofing matter in agency work, where the same document goes back and forth. Products built for that use case handle it far better than general tools with a comment field.

What it costs, and how it grows

Per user per month is standard, with automation limits, reporting depth, permissions and single sign-on setting the tiers.

The cost that grows quietly is seats. Everyone who touches a project gets an account, dormant ones are rarely reviewed, and a team of twelve ends up paying for twenty. Audit that quarterly.

Migration is the other consideration. Tasks and comments usually export, while attachments, custom fields, automation and history frequently do not. Test an export early rather than at the point of leaving, and read what pricing pages hide for the surrounding arithmetic.

Signals that you have outgrown a task list

Teams usually move to project software later than they should, and then configure far more of it than they need.

The honest signals are specific. Two pieces of work are waiting on each other and nobody can say which is late. Somebody is overloaded and it only became visible when a deadline passed. A stakeholder keeps asking for a status that takes an hour to assemble.

Any of those justifies the extra structure. None of them requires every feature the product offers.

Start with owners, dates and one view that reflects how the team actually works, then add dependencies or capacity when a specific question demands them. A system configured beyond what the team maintains produces confident reports built on data nobody updated.