Every organization that takes strategy seriously eventually tries to connect its projects to its goals. The logic is obvious: if you know what work is happening and you know what you're trying to achieve, you should be able to say which work is moving which goal.
Most attempts fail. Not because the idea is wrong, but because the implementation creates one of two pathologies: a compliance burden (every task must be tagged, which means nobody tags anything) or a meaningless mapping (goals and projects are linked at the wrong altitude, which means the link carries no information).
Here's how to do it correctly.
The altitude problem
The most common failure is connecting at the wrong altitude. It goes like this: the company has an OKR — "Increase net revenue retention to 110%." The work team is running a project — "Q2 enterprise customer program." Someone maps the project to the OKR.
The mapping isn't wrong. But it's not useful either. The project contains forty tasks. Some of those tasks move the NRR metric. Some of them are administrative overhead. Some of them are actually serving a different goal — customer acquisition, not retention. The project-to-OKR link can't tell you which is which.
The right altitude for a goal-to-work connection is the initiative or work item, not the project. A project is a container. An initiative is a directed effort toward a specific outcome. The distinction matters: you connect the initiative to the goal, not the container.
The five-step model
Step 1: Define the goal with a measurable outcome, not a theme. "Improve customer success" is a theme. "Increase net revenue retention from 98% to 110% by Q4" is a goal. The outcome must be specific enough that you can tell, unambiguously, whether a given piece of work could contribute to it.
Step 2: Define the initiatives that could move the metric. For the NRR goal: reducing churn in enterprise accounts, improving time-to-value for new customers, launching a proactive expansion motion. These are initiatives — each one with a hypothesis about how it moves the metric.
Step 3: Break each initiative into work items with explicit owners. Not "enterprise customer program." Three to five work items: "Audit top-10 at-risk accounts with CSM owner." "Build 90-day success plan template." "Implement proactive health-score alert." Each one: one named owner, a target completion date, and a link to the NRR goal.
Step 4: Review the work-to-goal connection weekly, not quarterly. The question at every weekly review: "Which work items moved the NRR metric this week — and which ones stalled?" Not "is the project on track?" The project is always on track. The metric tells the truth.
Step 5: Let stalled work change the goal view, not the other way around. When work stalls, the goal turns amber. Leadership sees it in the system. They don't need to hear it in the meeting. The connection creates a live signal, not a quarterly report.
The tags problem — and how to solve it
The compliance burden comes from tagging everything. The fix is to invert the model: instead of asking teams to tag their work with goals, create the work item in the context of a goal. The goal link is established at creation, not as a retrospective metadata exercise.
When the engineer creates a task, she creates it under an initiative that's already linked to a goal. The tag is automatic. The discipline is in creating work in the right context — not in maintaining tags after the fact.
This only works if the system is designed for it. If the work system and the goal system are separate, there's no context to create the task in. That's why the architecture matters more than the process.
What the connection makes possible
When it works, three things change:
The portfolio view. Leadership can see, at the goal level, how many active work items are driving each strategic priority — and how many goals have no active work this week.
The root-cause view. When a goal turns amber, leadership drills to the work items supposed to drive it. One has been stalled for two weeks. The owner is over-allocated. That's the root cause. That's the decision that needs to be made.
The prioritization reality check. When a new initiative is proposed, leadership can see whether there are already enough work items behind the goal it's supposed to serve — or whether the goal that most needs help has nothing behind it.
The Vindaris position
The connection between projects and goals isn't a metadata exercise. It's an architectural decision. Build work items in the context of goals — natively, not via integration — and the connection is automatic, live, and trustworthy. Build it any other way and you'll spend the rest of the year maintaining a mapping that nobody trusts.