Answers
Do I need a strategy tool if I already have a project tool? Often no.
A project tool tracks work that finishes. A strategy tool tracks outcomes that do not. If your plan is genuinely a list of projects with end dates, Asana or Monday or ClickUp is enough and a second system is duplicate data entry. You need one when the question stops being "is this done" and becomes "is this working", because a project tool does not hold the number that answers it.
- Set up with your plan
- Unlimited users
- 30-day pilot
What happens when you use one for the other
Objectives entered as epics never close.
The commonest version of this is not a tooling failure, it is a category error, and it produces the same three symptoms in every organisation that makes it.
Three symptoms
The item that rolls over forever
"Improve customer retention" goes in as an epic. It has no finish line, so it is never done, and it is carried into the next quarter unchanged. After three quarters everyone has learned to skip past it.
Progress that measures activity
A project tool computes progress from tasks completed. Twelve of fifteen tasks done reads as 80 per cent, whether or not retention moved at all. That number is worse than no number, because it is confidently wrong.
A review with no verdict
The board gets a list of in-progress items. Nobody can say which priorities are on track, because nothing in the tool knows what on track would mean.
The difference
Done is binary. On track is a trajectory.
How it works
A project tool answers "is it finished"
Tasks, owners, dependencies, dates. The whole model is built around work reaching an end, and it is very good at that. Migrating the warehouse, shipping the release, onboarding the client: these have a last day, and a project tool is the right place for them.- Work with a finish line
- Progress from tasks completed
- Correct, and enough, for delivery
A strategy tool answers "is it working"
An objective has a measure, a target and a date, and what matters is where the measure is against where it should be by now. Retention at 84 per cent against a trajectory that wanted 87 by October is behind, regardless of how many tasks were completed to get there.- Outcomes that do not finish
- Progress against a trajectory
- A verdict, not a percentage of tasks
Which is why most organisations end up with both
The projects live where the work is coordinated and the objectives live where they are measured, with the link between them being which objective a project is meant to move. Run one in the other and you either get strategy with no measures or projects with no plan.Deciding
Six questions, and a clear answer either way.
Three point at keeping what you have. Three point at adding something. Count them honestly.
The checklist
Is every priority a project?
If each one has a last day and a deliverable, you have a delivery problem, not a strategy problem. Keep your project tool.
Is the plan one team?
A single team with one backlog can hold its priorities in the same tool as its work. The split starts to pay when several teams contribute to one outcome.
Does anybody ask for a board view?
If no governance layer exists, a strategy tool is solving a reporting problem you do not have yet.
Do your priorities have numbers?
If a priority has a target and a date, your project tool cannot track it. That is the clearest signal you need something else.
Do items roll over every quarter?
Carrying the same epic forward three times is the category error showing up as a symptom.
Can you say which priorities are off track?
If answering takes a person half a day of assembling, the tooling is not the problem yet. If it cannot be answered at all, it is.
Questions
Questions about running strategy in a project tool
Can I run OKRs in Asana, Monday or ClickUp?
You can record them, and many teams do. What those tools cannot do is hold a measure against a trajectory, so progress is computed from tasks completed rather than from whether the number moved. That distinction is what decides whether the record is useful at a review.
What is the actual difference between a project and an objective?
A project finishes. An objective is a measure you are trying to move, and it has a target and a date rather than a last day. "Migrate the warehouse" is a project. "Reduce picking errors to under two per cent" is an objective, and the migration might be one of several things you do to move it.
Is it worth running both systems?
It is worth it when several teams contribute to the same outcome and somebody has to report on whether that outcome is moving. For a single team delivering a list of projects, a second system adds data entry and answers a question nobody is asking.
How do the two connect?
By which objective a project is meant to move. The projects stay where the work is coordinated and the objectives stay where they are measured, and the link lets you see that three projects are all aimed at a number that has not shifted, which is the most useful thing either system can tell you.
What is the sign we have outgrown the project tool for this?
Items that roll over every quarter without closing, progress percentages nobody trusts, and a review where no one can say which priorities are off track. All three are the same underlying problem: outcomes being stored in a model built for work that finishes.
Working out whether you need a second system? Ask ANI and get a straight answer.
Keep the project tool. Add the measure.
Start free for 30 days and see your priorities against where they should be by now, with the delivery work staying where it already lives.