In Part 1 of this series , I made the case that project management is broken — not the people, but the processes. The core problem is a fundamental inversion: PMs are forced to chase developers to update tickets, manually drag sliders in scheduling tools, and maintain a separate layer of project overhead that has little to do with the actual work.
My argument is simple: tickets should drive the project, not the other way around. If a developer doesn’t update a ticket, the tool takes a static snapshot. If something slips, it’s on the developer — not on the PM to discover and manually correct. This also means every slip is recorded, timestamped, and traceable. No more “death by a thousand cuts,” where a year-long project ends up six months late with no coherent record of how it happened.
So we did something about it. Using Claude Code, we rebuilt the tooling from scratch. Here’s what we came up with.
A Snapshot-Driven Project Dashboard
The tool produces an HTML page that gives you a complete project snapshot at a glance. There are two main tabs: Project Status and Dependencies & Critical Path.
Project Status
The Project Status tab tells you the health of your project — and more importantly, why it’s in that state.
Key metrics include:
- Total Slip Days — In our prototype, this read 224 days. That number alone tells a story.
- Unresolved Slip Events — In this case, 7. Every slip in the system requires a documented reason. If a slip doesn’t have one, it’s flagged here until someone provides it. This is enforced at the data level — the reason is captured in a JSON file that can be updated through the tool or through other integrations.
- Baseline vs. Projected End Date — The baseline is what you committed to at kickoff. The projected end date is recalculated in real time from ticket data. Color coding tells you at a glance whether you’re on track. (In the prototype, a 224-day slip showing green is admittedly a data artifact — but the mechanism is sound. You can see exactly when the project was originally planned to finish versus when it will actually finish.)
This is something that’s genuinely missing from most PM tools. You can see the delta. You can trace it.
Dependencies & Critical Path
The second tab renders a Gantt-style chart showing your critical path sequence — what can run in parallel, what’s blocked, and what’s blocking everything else.
Crucially, none of this is manually entered. It’s derived entirely from the tickets themselves — in this case, simulated Jira tickets, but the principle applies to any ticketing system. The dependencies, the sequencing, the parallel tracks — all of it comes from how the development team has structured their work.
Compare that to the traditional approach: a PM opens Microsoft Project, adds tasks manually, and then painstakingly wires up predecessors and successors. That’s a separate artifact that immediately starts diverging from reality. Our approach makes the tickets the single source of truth and derives everything else from them.
What About Non-Code Tasks?
A fair question: what about coordination work that doesn’t involve code? Meeting notes, decisions, reviews, cross-team dependencies?
My answer: use the ticketing system for those too.
If you have a weekly sync, that’s a recurring task in Jira. Meeting notes go in the ticket. Each meeting can be a sub-ticket under a parent, with a summary in the parent. The result is that everything lives in one place. You don’t have to ask yourself: Is it in email? Is it in Confluence? Is it in SharePoint? Did someone send a Slack message?
It’s in the ticket. That’s it.
This is a meaningful paradigm shift for a lot of organizations — especially in tech, where we’ve grown accustomed to sprawling tool ecosystems and the low-grade chaos that comes with them. I think we’ve normalized that chaos to the point where we’ve stopped questioning it. We shouldn’t.
Reflections
Speaking personally: I genuinely dislike updating sliders in tools like Reiki (essentially an online Microsoft Project). I don’t want to spend my time as a PM being a nag — chasing developers to update tickets, then going back and manually reconciling what I find with a separate scheduling tool. I’m a technical PM. I want to work on things that matter.
The problem isn’t the people. It’s the absence of a coherent process that says: tickets are the source of truth, and we derive everything from them. Management has to buy into that. Without that commitment, you end up right back where you started.
The inversion I’m proposing — tickets drive the project, not the PM — has the potential to meaningfully change how project health is measured, how accountability works, and how slippage is tracked and explained over time.
What’s Next
This wraps up the two-part series on reimagining project management. The tool is a prototype built with Claude Code, and I’m actively considering whether to open source it.
There’s also a real opportunity to pilot this on a greenfield project in a live environment. That would be the real test — not simulated Jira tickets, but an actual team, actual deadlines, actual slips. I’m looking forward to it.
If you have thoughts, pushback, or want to collaborate — reach out.