Project management software: questions to ask before you buy

Choosing project management software is a decision about how you work before it is a decision about which product to buy.

Every project management tool holds a view of how work should run, and buying one means adopting that view.

That makes the category harder than it looks. These products are not neutral containers for any method; they encode a method, and if it is not yours, you will spend a year fighting the software, then blame the software.

So decide how you want to work first, and only then find the tool that assumes the same thing.

What to take away

Three shapes of product

Behind hundreds of names there are three broadly different designs.

The task tracker. Items with an owner, a status, and a due date, organized into lists or boards. Fast to adopt, almost nothing to configure, and it does not model time, dependency, or capacity. Excellent for teams whose work is a queue. Silently inadequate for work where the order and timing of things is the actual problem.

The plan-and-schedule tool. Tasks with durations and dependencies, resources with availability, and a schedule that recalculates when something slips. This is what you need when the question is "if this is two weeks late, what else moves?" It requires real discipline: a plan that is not maintained is worse than no plan, because it looks authoritative and is wrong.

The configurable work platform. A database with views, custom fields, automations, and forms, which can be shaped into either of the above and into a dozen other things. Extremely powerful, and it moves the difficulty from "the tool cannot do this" to "somebody must decide how we do this, and maintain it".

Most disappointment in this category is a mismatch: buying the third when you needed the first, or forcing the first to answer questions only the second can answer.

Decide these before you look at any product

Answer these honestly. They determine the shape you need, and they are much easier to answer without a sales engineer in the room.

The custom-field ratchet

Configurable tools have a characteristic failure that is worth naming before you meet it.

Someone needs a field, so it is added; another needs a slightly different one for their team, so both are added.

A status is needed for an edge case, then another. A year later, there are forty fields, half empty, three overlapping status schemes. Nobody remembers which are required for reporting; nothing can be removed because something somewhere might depend on it.

The ratchet only turns one way unless you build the reverse in from the start:

The same applies to automations. A rule that quietly changes something is very useful and very hard to debug later, especially when the person who wrote it has left. Keep a list of what automations exist and what they do.

Where these tools actually fail

Reporting. This is the most common disappointment. The tool tracks work beautifully and cannot answer the question the finance director asks. Test this with your real question, using real data, during the trial, not with the demo dashboard, which was designed to look impressive against sample data. Ask specifically whether you can report across multiple projects, whether you can group by your own fields, and whether the report can be scheduled or exported without a person doing it by hand.

Dependencies at scale. Linking two tasks is easy everywhere. What matters is what happens when a task with twenty downstream dependencies moves: whether everything reschedules automatically, whether you are warned, and whether you can see the consequence before you commit to it.

Permissions. Frequently coarse. Common requirements that are surprisingly hard to meet: a client who sees one project and nothing else; a contractor who sees tasks but not commercial fields; a manager who sees everything read-only. Check whether the field-level and project-level controls you need actually exist, because working around a coarse permission model usually means duplicating projects, which destroys the reporting you bought the tool for.

Notifications. These tools generate a lot of them, and the default settings assume you care about everything. If they cannot be tuned centrally, people will mute them entirely, and then the tool stops informing anyone of anything.

External collaborators

Whoever is not an employee (clients, contractors, agencies, suppliers), is the awkward case in every product here.

Establish three things before shortlisting: whether guests cost a full seat, exactly what a guest can see beyond what you deliberately shared, and whether guests can be audited and removed centrally. The second one catches people out: a guest given access to one project can sometimes see the member directory, the project list, or comments referencing other work.

If external collaboration is central to how you operate, this stops being a detail and becomes the first filter you apply.

Migration is unusually hard in this category

Moving between project tools is harder than moving files or mail, for a specific reason: the value is in the relationships between items, and relationships are what exports lose.

What typically does not survive:

Estimating that work honestly is its own discipline. The useful habit from the GAO Cost Estimating and Assessment Guide is to write down what the estimate excludes. Then a later surprise is a known omission rather than a mistake.

The practical consequence: plan to move open work and leave closed work in a read-only archive. Attempting to migrate years of completed history is where these projects overrun, and the benefit is usually much smaller than the effort.

Trial it with a live project

Sample data proves nothing. Run something real.

Before you commit

The price of switching later

None of that is a reason to stay somewhere unsuitable. It is a reason to spend longer on the decision than the price suggests, and to prefer the tool whose built-in opinion is closest to how you already work.

Where to read next

Three neighboring products overlap with this one and are frequently the reason a tracker is unnecessary. If the real problem is coordination rather than tracking, the collaboration decision is the one to make first.

If the truth currently lives in a spreadsheet, the suite decision matters more than any tracker. Attachments hanging off work items are a storage question, covered in the storage decision, and if your status reporting is really a weekly call, the meeting decision is where that cost sits.

Common questions

How do we know whether we need this at all?

Write down the question a senior person asks that you currently cannot answer, and check whether a tracker would answer it. If the question is what is everyone working on, a tracker helps. If the question is why is this late, a tracker will record the lateness and not explain it.

Who should own the configuration?

One named person with time in their week, reviewing it twice a year and allowed to delete things. Shared ownership means no ownership, and configuration in these products only ever accumulates unless somebody is permitted to remove it.

Should managers have their own views or one shared view?

One shared view, built once, with filters. Individually built views diverge, and within a year two managers are reporting different numbers from the same data, which destroys confidence in the tool faster than any outage.

What do we do with years of closed work?

Leave it in a read-only archive and move open items only. The effort of migrating completed history is large, the reporting value is small, and the imported timestamps are usually wrong anyway, which makes the resulting history misleading rather than useful.