Project management pricing follows seats, not the work getting done

Project tools are sold by the seat and used by the project. That mismatch is where the budget goes wrong, because the people who cost you the most are frequently the ones who use the product least.

Before looking at any price list, count your population honestly: who does the work, who assigns it, who only wants to see it, and who is only here until March.

What to take away

Count the population before the price

Automations and reporting connections often need an account of their own. An account that exists to be used by a machine is a licensing question and a control question at once.

Treating those accounts as first class, with an owner and a review date, is the position taken in the guidance on identity and access management. It is cheaper to adopt while you are still counting seats than after somebody has created nine of them.

Watchers and approvers are where the surprises live. A tool that charges everyone the same rate can double a budget for people whose entire interaction is reading a weekly view. The workaround people invent is to email screenshots, which defeats the purpose of buying the tool.

What the entry tier usually holds back

The published entry price rarely includes the things that make the tool useful at scale. Check each of these against the tier you are actually being quoted.

Two of these usually force the upgrade. Identify which two apply to you before the first conversation, because a requirement stated after a quote is a weaker position than one stated before it.

The cost that is not on the invoice

The larger cost in this category is the time spent maintaining the thing. That cost rises with configuration, and configuration rises on its own unless somebody stops it.

Custom fields, statuses, automation rules, and views pile up because each addition seems reasonable alone. Soon creating a task takes four minutes, and nobody can say which of the eleven fields is required.

The price list never warns you. It is the single most common reason a team abandons a tool that was working.

Budget for it as a named responsibility rather than as goodwill: someone owns the configuration, reviews it twice a year, and is allowed to delete things. The category overview sets out how the accumulation happens.

Model the second year, not the first

Take a page and build the model yourself, in your own units.

Public sector cost estimating helps here, and the GAO Cost Estimating and Assessment Guide says a credible estimate documents its assumptions and exclusions.

Your model should state what it left out, in writing. Then a later surprise is a known omission rather than an error.

Line seven is usually blank and should not be. Work item history is one of the least portable things in this category, and a tool with a poor export is a tool you will keep paying for after you have decided to stop using it. The migration overview covers what actually survives a move.

Where this sits against the rest of the estate

Three checks are worth running before signing anything.

Whether your office bundle already includes a work tracking product you are not using. That is a common finding and a genuine saving. Whether your chat tool's paid tier includes enough of what you want, so a separate purchase is not needed.

And whether you are about to pay twice for storage. Most project tools include some, and your file storage already exists.

Comparing the model against the numbers in collaboration pricing and office bundle pricing is the fastest way to find the overlap. The seat count itself should be reconciled against your account administration records rather than a spreadsheet somebody maintains by hand, because that is where the accounts nobody remembers creating turn up.

Common questions

Is a free tier ever the right answer?

For a small team with one project and no obligation to keep records, sometimes. Understand what happens to history when you outgrow it. A free tier commonly limits how far back you can look rather than how much you can store, and that limit is invisible until you need something old.

Should we pay annually?

Not in the first year. The discount is real and so is the risk that you discover in month three that the tool does not fit how your work is actually sequenced.

How do we handle a client who needs to see one project?

Ask for the exact answer in writing: what an external participant can see, whether they can be confined to one project, and whether they bill. Then test it with a real account. This is the question most often answered optimistically in a sales conversation and precisely in the interface.

Is a cheaper tool with fewer features a saving?

Only if the missing feature is one you were never going to use. The expensive outcome is a cheaper tool plus a spreadsheet that recreates the missing feature, because now you are maintaining two systems and reconciling them by hand.