I joined ClearTax as a Technical Program Manager in December 2023 and found something familiar to anyone who has worked in a fast-growing product company: twenty-plus initiatives moving in parallel across three product teams, and no shared way to see what was actually happening. Each team had its own Jira project, its own naming conventions, its own definition of done. Leadership was reconstructing status from Slack and spreadsheets every Monday.

By September 2024 we had a centralised Jira board, a Confluence structure that tied initiatives to strategy, and a leadership update cadence that took twenty minutes to consume instead of four hours to assemble. That structure was still in use when I rolled off. Here is what I did, what worked, and what I would change.

The actual problem (it was not Jira)

Most teams blame Jira for their PMO problems. Jira was not the issue at ClearTax. The issue was that each team had set up Jira to optimise for their own delivery, and nobody had ever bothered to optimise for how leadership consumed the work. The result was three coherent local optima and zero global view.

Specifically:

• Statuses did not match across teams. Team A used "In Review", Team B used "Code Review", Team C had a custom "PR Open". Same thing, three names.
• Initiative was a custom field on one team and a label on another. Both worked locally. Neither could be JQL-joined cleanly.
• Confluence was a graveyard of dead pages. Project briefs from 2022, half-finished RFCs from 2023, no clear "current state" for anything.
• Weekly leadership updates required a person to manually pull from each team, normalise the data, and stitch it into a slide. That person was the TPM. That person became me.

The cost was hidden until you measured it: roughly four hours per Monday to assemble the status pack, plus a 30-minute leadership meeting that turned into a "let me explain what each team meant" session.

The approach

I made three decisions early that ended up driving everything else.

1. Pick one Jira structure and impose it

I designed a centralised Jira project with a fixed seven-status workflow, a "theme" custom field, an "initiative" custom field, and required fields at story creation. Teams kept their own Jira projects for backlog work, but every story that mattered for leadership got linked to an epic in the central project.

This was unpopular for a week. Teams resented filling in another field. Two things flipped that:

• I built the dashboards first. Once teams could see their own status reflected back in a clean view, they stopped arguing about the field and started suggesting improvements.
• I made it cheap. JQL queries plus saved filters meant no manual reporting. The team that adopted the structure first stopped getting status emails from leadership. That was a strong signal.

2. JQL dashboards by team and by quarter

I built four dashboards. One per team, plus a quarterly view that sliced across all three. Each dashboard had:

• Burn-up of initiative completion against the quarterly plan.
• A bottlenecks gadget showing stories in In Review for more than three days.
• A "what changed this week" gadget driven by a JQL with updated >= -7d.
• A risks gadget tied to labels.

Build your own with my JQL Query Builder if you want to skip remembering the syntax.

3. Confluence one page per initiative

Every initiative got exactly one Confluence page. Linked to the Jira epic. Required sections: Goal, Approach, Current state, Risks, Decisions. I deleted everything that did not follow this template. (I am exaggerating — I archived. But teams thought I deleted, and behaviour changed.)

The risks and decisions section became a default RAID log. If you want a more rigorous version, use my RAID Log Builder.

What worked

• Weekly status assembly went from four hours to twenty minutes. Dashboards loaded clean. No manual normalisation.
• Leadership stopped asking what each team meant. The 30-minute weekly review became a 20-minute decision meeting.
• Cross-team dependencies surfaced earlier. When the JQL across all three teams returned the same story labelled three different ways, it was obvious something was off.
• The structure outlasted me. Six months after I rolled off, the dashboards were still in active use and the template had been adopted by a fourth team that came online.

What I would change

• I should have automated the Confluence enforcement earlier. I personally chased page hygiene for the first two months. A simple n8n flow checking for missing sections would have saved that time.
• I underestimated change management. The first week of pushback was harder than I planned for. I should have aligned with two team leads as champions before announcing the standard.
• I did not invest in onboarding docs. When the fourth team came online, they had to rediscover the pattern. A 30-minute onboarding video would have removed that.

If you are about to do this

Three things to take from this if you are facing a similar PMO build:

1. Build the dashboards before you ask for compliance. Compliance follows when the team sees their work reflected back cleanly.
2. One Jira structure. Refuse exceptions for the first quarter. Exceptions in month one become permanent.
3. Use the tooling to enforce the standard, not the people. A required field is cheaper than a Slack reminder.

I am building tools for this kind of work at sathvickollu.com/tools/ — a Sprint Estimator, RACI Matrix Builder, RAID Log, JQL Query Builder, and twelve more. All free, all browser-only, all built with Claude Code in single sittings. If you want a tailored version for your team, drop me a note.