The Tool That Doesn’t Exist

Planning and tracking are different jobs. The seam between them is where agents earn their keep.

• Why thirty years of unified planning-and-tracking tools have produced consistently weak results

• The structural reason a single tool cannot do both jobs well

• What production teams have actually been doing in the gap, and why it isn’t clerical

• Why an agentic workflow between two specialist tools beats any promised unified one

The first project management tool I ever used was Microsoft Project. Before getting into the game industry, I had exposure to the tool for planning construction projects. I didn’t know what lead or lag me” meant. Critical path was a phrase I’d encountered in a textbook and dismissed. Task relationships looked like spaghetti. The plan I built was beautiful in the way a child’s drawing of a house is beautiful, and about as accurate when held up to the real building.

It worked for planning. It fell apart for tracking. I spent most Friday afternoons guessing what percentage complete each task was. Sixty-five? Seventy? The number didn’t mean anything except that I had typed it into a cell, and then the Gantt would update, and the report would go out, and the project would carry on bearing no obvious relationship to the chart.

That was the start of a thirty-year search for one tool that could do both jobs. I want to write down, before I forget, that I think the search was a mistake.

The tour

Before Jira, the best bug database I ever built was in FileMaker Pro. This will sound mad to anyone under forty. FileMaker was the GOAT of QA tracking in the late nineties because you could hand-roll a relational database with a layout designer in an afternoon, give the QA team a form, and have ticket fields that actually fit your studio’s workflow. Custom statuses, custom severity, custom triage paths, custom resolution workflows. The bespoke nature was the point. We tracked thousands of bugs through ship windows and the producers who maintained those databases were treated with the kind of respect normally reserved for tools that work.

What FileMaker couldn’t do was plan. There was no Gantt, no dependency, no critical path. You had a tracker. You had nothing to track against. So you ran two systems anyway.

Jira arrived and I assumed the search was over. It wasn’t. I have spent more than half my career looking for the perfect Jira plugin, the next major release that would finally make roadmaps fit my use case, the marketplace add-on that would close the planned-versus-actual gap. Tempo. Structure. BigPicture. Advanced Roadmaps, then Jira Plans, then whatever Atlassian is calling it this quarter. Plugin trials, evaluations, pilots, budget justifications. I have written more business cases for project management tooling than I have for actual projects.

Then came the Jira replacements. We had a serious bake-off between ClickUp and Monday.com in one studio, which generated more political heat than the actual game we were trying to ship. After that I went down the premium roadmap tool route, accepted that two systems was the price of admission, and let the production team pick up the manual plan-and-actual reconciliation. Which they did. Friday after Friday, spreadsheet open on one monitor, Jira open on the other, producing a status report that looked at the world both ways.

I never let go of the idea that the right tool would arrive. It always seemed close. The next version, the next plugin, the next migration.

Planning is a story about the future. Tracking is a record of the present. The two have never agreed and they never will.

Why no tool can be both

The reason no unified tool works well is structural. Planning and tracking want opposite things from a data model.

Planning wants estimates. It wants capacity, milestones, lead and lag, what-if scenarios, dependency graphs, the ability to drag a bar across a calendar and have the consequences ripple through. The data is editable, opinionated, and forward-looking. A good plan is a thing you argue about with stakeholders.

Tracking wants ground truth. It wants the current state of a ticket, the actual time logged, the actual blockers, the actual transitions. The data is append-only and backward-looking. A good tracker is a thing you do not argue with, because it just reports what happened.

These are different shapes of information. The buying committee keeps asking for them in one tool because the diagram is simple and the demo is impressive. The vendors keep promising it because the diagram is simple and the demo is impressive. The result is always weak at both jobs. Jira Plans is fine for a roadmap and weak for a planned-versus-actual report. Smartsheet is a good planning canvas and a poor home for engineering workflow. Monday and ClickUp try to do both and end up doing neither with conviction. The Atlassian Marketplace has hundreds of add-ons partly because the base product cannot resolve this tension.

The market data confirms the pattern from a different angle. The average organisation runs eleven project management tools and ten team collaboration apps, and 79 percent have taken no steps to consolidate. Workers lose roughly 9.3 hours a week to searching for information across these systems. The tools are not delivering the unified picture they were sold on. They are producing more places for the picture to live.

The honest read is that planning tools and tracking tools are different categories of software pretending to be one. The unified tool is a marketing position.

What producers have actually been doing

The reconciliation work has been done all along. By producers, on Friday afternoons, in spreadsheets, by hand.

I want to be careful about how I describe this work, because it has been routinely underestimated by everyone who has not done it. It is not data entry. It is judgement. It is knowing that Ahmed’s tickets are always two days behind reality because he updates them in batches on Friday morning. It is knowing that the Environment lead is honest to a fault about percentages and will report sixty when most people would report eighty. And it is recognising which “in progress” is real work and which is a ticket that got dragged across the board after a stand-up because someone felt guilty.

A good production status report is not a screen-grab of Jira against a Gantt. It is a synthesis of the plan, the tracker, and the producer’s working model of which humans report which way. Tools have tried to automate this for two decades and have not succeeded because the inputs are dirty and the rules are situational and the judgement is local.

The reconciliation work isn’t clerical. It’s a judgement about which gap is a signal and which is a person who forgot to update a ticket.

This is the work that gets squeezed when a project is busy and the producer has eight other things to deliver. So it gets a quick pass, or a delegated pass, or no pass at all. The report goes out late, or wrong, or as a bare reflection of the tracker with no producer interpretation laid over the top.

The example

Last week I ran one of these reports for a project I’m producing. I pulled a Smartsheet export of the plan as of that morning. I pulled the current Jira state. I gave both to a workflow I’ve been building, told it the format I wanted, and let it produce the synthesis.

The output read like a status report a competent producer would write. Section by section: art tracks against plan, RAG-coded, with the cascade risks called out. It picked up that one track had not been activated in Jira at all, despite the plan saying several stages should already be complete. It connected that to a downstream gate that was due to start two days ago. It identified three open plan risks I had previously flagged in a briefing document and noted that none were blocking today but each could re-sequence mid-sprint. It recommended I check the track directly with the lead, because the gap between plan and Jira state could mean either work happening off-ticket or work that genuinely hasn’t started.

That is the report I would have written. It took fifteen minutes instead of two hours. The agent did not fix the underlying data problem, which is that ticket discipline is uneven, but it did the synthesis I would have done with the data as it stood. I will run it again this evening against fresh Jira state. The plan is to wire it directly to the Smartsheet API so I do not have to download a snapshot to drive it.

The piece that matters: I used the time I saved to validate, not to compile. The output of the workflow is a draft I review and edit, and the editing is the producer work I should have been doing all along.

This is different from the single source of truth

Every project management vendor for the last fifteen years has sold some version of the single source of truth. The pitch is always the same: bring planning and tracking into one tool and you will have one place to look. It has never landed. The two jobs cannot share a schema without one of them being deformed to fit the other.

The agentic approach starts from the opposite premise. Keep the two tools. Let planning be planning, let tracking be tracking, let each be best in its category. Compute the bridge on demand.

The bridge is not stored. It is recomputed every time you need it, which means it is always current as of the last data pull. There is no reconciled artefact that sits in a third system and immediately goes stale. There is no nightly job that produces a report that is wrong by lunchtime. You ask the agent for the picture, the agent walks the two sources, the picture comes out.

This is a different shape of solution. It does not depend on the two underlying tools agreeing about anything except their respective domains. It does not require a migration. It does not require everyone to abandon the planning tool they like or the tracker they have invested in. It treats the two systems as facts of life and adds a layer on top that does the work a person was doing anyway.

What changes for producers

The reconciliation has been an invisible cost for as long as I have been doing this work. Producers do it, leadership rarely sees it, and the time it takes is loaded onto the producer’s other work without being booked anywhere. Removing it changes the shape of the producer’s week.

The first change is obvious. Less time compiling, more time validating. I still read the output. I still push back on the agent’s conclusions where they look wrong. I still talk to the leads about what the report is missing. The work is now editing rather than typing.

The second change is sharper than I expected. The “people are not updating their tickets” problem does not go away, but it stops being invisible. When the agent surfaces a track with no activated tickets against a plan that says work should be three stages in, the next conversation is unavoidable. Either the work is happening and not being captured, or it is not happening. Both answers are useful. Neither was reliably surfaced before, because the producer compiling the report was tired and Friday was nearly over.

The third change is about scale. One producer running these workflows against a portfolio of projects can cover more ground than the same producer compiling reports by hand. The judgement is still the constraint. The compilation is no longer the constraint. That ratio matters when studios are running lean.

Stop looking

I have spent thirty years looking for the tool that doesn’t exist. The honest answer is that the tool I was looking for cannot be built, because the requirements contradict each other.

Pick the best planning tool you can find. Pick the best tracking tool you can find. Let them be different. Wire an agent between them. The bridge will be computed, current, and good enough to act on, and the producer will get the Friday afternoon back.