Why I stopped consulting and built a deterministic planning engine for Jira
Hey everyone! đź‘‹
For 25 years, I worked as a Project Governance expert. My job was to make sure massive enterprise portfolios actually delivered. But I kept hitting the same wall: The Planning Lie.
In almost every company, 'Capacity Planning' is just a fancy way of saying 'we hope these people are available.' You have a dashboard that says everyone is at 80% load, but in reality, your lead architect is over-allocated by 200% because of 'corporate noise' and hidden dependencies.
As a consultant, I tried to fix this with better processes. But I realized the problem was architectural.
Jira is a world-class state machine for tracking tickets, but it's not a scheduling engine. To get true predictability, you can't just track a ticket; you have to govern the resource.
I decided to build a system that treats Resource Allocation as the primary anchor, not the ticket date. I implemented a deterministic capacity model—basically a 'Governance Filter' that isolates systemic distractors to reveal the True Effective Capacity of a team.
It was a huge technical challenge to build a lossless round-trip sync with MS Project while maintaining data integrity in the Forge cloud, but it was the only way to move from 'guessing' to 'knowing.'
I'm curious—have any of you built tools to fix 'broken' corporate workflows? How did you handle the transition from being the expert who advises to the founder who builds the solution?
I've documented the technical framework of the 'Planning Lie' here if any of you want to nerd out on the systemic side: [https://be-on-ti.me/guides/resource-governance-guide]
Looking forward to the discussion!
The interesting part is that the product may not actually be competing with Jira planning tools.
Most planning products promise better visibility.
Your post is really arguing that visibility is the wrong layer because the underlying capacity assumptions are already corrupted.
That is a much stronger category position than "better planning for Jira."
I'd be careful not to let the product get framed as another forecasting or resource-planning tool, because the thing that stood out here was the idea of exposing false capacity rather than visualizing work.
Feels like there is a deeper positioning decision underneath the product than the technical implementation.