Jira isn't just for software teams anymore. Let's discuss how PMOs are using it to manage portfolios

[Manuel Rahman]

I lead an international PMO and we've been on a journey to adapt Jira for business project delivery rather than software development. We're using it for portfolio management, workload planning, governance, reporting, RAID management, executive visibility, and project tracking across multiple regions.

I'm interested in connecting with others who are using Jira as a more traditional project management platform. How have you approached requirements such as Gantt charts, RAID logs, resource management, status reporting, and stakeholder governance? What has worked well, and what challenges have you encountered?

Let's share experiences, lessons learned, and best practices for taking Jira beyond software teams.

[Matthew Sinclair]

Been employing JSM for Intake/Approvals before handing off to Jira - I would also point at Atlassian "Projects" - a platform tool that allows you to quickly push updates at a high level for anyone/stakeholders without digging into the details - while Leveraging Rovo to summarize.

https://www.atlassian.com/platform/platform-apps/projects

If your Org has Teamwork Collection - you very likely already have this free app.

As for challenges - as an Org Admin/Engineer/Architect - understanding terms and what PMO's are looking for. XD

Best practices- keep it simple - you don't need a custom status/field for every-single-thing.

Customization bloat is a big problem - think long term - scalability.

More than ever with the changes Atlassian are making to their billing models.

[Manuel Rahman]

One of our biggest lessons has been to keep things simple. Over time, we've reduced the number of fields users need to complete and focused only on capturing information that adds real value.

Jira's flexibility is a huge strength, but when you're starting out it can also be difficult to know the "right" way to structure things. We learned a lot through trial and error. It would be great if there were a service that could help organisations translate their business requirements into a recommended Jira operating model, helping them avoid unnecessary iterations and reach an effective solution much faster.

I'd be interested to hear from whether others had similar experiences or received guidance that helped accelerate their adoption journey.

[Steven Haworth]

We are using Confluence and Jira extensively for project management.  Our main tool is Tempo Structure, with a Business Jira space defined.  Jira tickets in that space are incorporated into Structure, with dates, assignees, priority, etc.  Structure then builds a Gantt from that, which can be baselined and tracked.

Tickets (ie tasks) have status, and are reviewed as normal task mgmt (overdue, due in 2 weeks, no due date assigned yet, etc).  And Structure (or just link relationships) let you define dependent linkages between tasks, or to milestones, or whatever. We love it!

Risk is managed with a dedicated Software Jira space - each risk is a ticket, with it's own categories, escalation status, owner, etc.  We don't pull those into the Structure, but if a Task is related to a Risk we do link the Jira tickets.

[Manuel Rahman]

We use Jira's native toolset rather than Tempo Structure. Work is organised in a three-level hierarchy: Project → Work Package → Task, all managed through the List view.

Alongside tasks, we use dedicated ticket types for Milestones, Risks, and Issues, giving us a single place to manage project delivery and governance. The Timeline view acts as our Gantt chart for planning and sequencing work, while team members provide updates through Status and Comments on task tickets.

We're also rolling out Tempo Timesheets to capture effort against tasks, with a longer-term goal of supporting capacity planning, although that's still a work in progress.

Our setup continues to evolve, and we're still learning what works best. That's why it's great to hear how others are using Jira for non-software project management.

[Sean Perry]

Hi @Manuel Rahman 
Firstly, I'd say this post doesn't really belong in this group, probably better in Teamwork Lab: Improving our ways of working?

To respond to your question - we use Projects, Confluence and Jira together to manage our Portfolio. Confluence is used as the intake and where we capture Scope. Projects is the company facing tracker where all Projects are updated so progress is visible to everyone, and Jira is where the different Work Packages are tracked, and tickets are raised for Issues, etc.

We use Rovo agents we created during the project lifecycle to generate weekly project updates for clients, at the end of the project to turn the original intake page into a service description for internal Account Managers. We have saved Jira queries for Open Issues, Open Client Questions. Every Friday we have  a weekly Project Review using Atlas as the source of truth.

Still a work in progress, but way better than where were a year ago,

[Manuel Rahman]

Thanks for the suggestion @Sean Perry, and a fair point about the group. I'm new here, so I haven't figured out how to move the discussion to "Teamwork Lab: Improving our Ways of Working" yet.

Our use of Jira and Confluence for non-software project management has evolved organically over time. As we review and refine our approach, it's really valuable to hear how others are using these tools beyond software teams. I'm keen to learn from both successes and lessons learned as we look for ways to improve how we work.

[AMIN EL]

I think this is a great topic worth its dedicated time and group. Could we possibly add all the community and Atlassian resources/links that guides us towards Business oriented System of Work primarily using the Team Collection (Blue Zone)

[Manuel Rahman]

Great suggestion! I'm new to the Atlassian Community, so I don't actually know how to move a discussion to a different group yet.

I'd be more than happy for this thread to be moved to the most appropriate community if someone can point me in the right direction or help make it happen. I’m keen to get the discussion in front of the people who are using Jira and Confluence for project management and ways of working outside of software development.

Thanks!

[Hassan Sajid Malik]

Interesting use case, especially across multiple regions. One challenge I’ve seen is that project tracking and actual resource capacity can become two different views once the same people are involved across several projects.

That’s actually what caught my attention with KolApp  it connects project planning with team capacity, so you can see the work alongside who has room and where overload or resource conflicts are building.

For an international PMO, I’d be interested to know which has been harder to standardize in Jira: the governance/reporting side or resource planning across projects?

[Manuel Rahman]

We've focused on getting the fundamentals right first: project planning, task tracking, RAID management, milestone tracking, and reporting. These were our immediate priorities as we transitioned from our previous project management solution.

Effective capacity and resource planning remains an aspiration, and I'd argue that's a challenge for most organisations, regardless of the platform they're using. We've chosen Tempo Capacity Planner as our long-term solution, but we've deliberately taken a "quality in, quality out" approach.

Before we can rely on capacity planning outputs, we need confidence in the underlying data. For us, that means ensuring work is consistently tracked in Jira, time is logged against tasks, and ideally that other activities consuming people's time, such as meetings and operational work, are also captured.

We haven't cracked this yet, but we're making progress. I'd be really interested to hear how others have approached capacity and resource planning in Jira, particularly outside of software development. What has worked well, and what lessons have you learned along the way?

[Hugo Mora]

Hi @Man 

What strikes me about this thread is that every answer so far solves visibility. Structure for the Gantt, Confluence and JSM for intake, Projects and Rovo for stakeholder updates. All of it answers "what is happening." Almost none of it answers "is this project healthy," which is the question a PMO actually gets asked in a steering committee.

Those are different problems. A status report tells you the project is 60% complete. It doesn't tell you whether that 60% cost what it was supposed to, or whether the remaining 40% is being eaten by rework.

@Manuel Rahman  , if you're designing the PMO layer, I'd argue for instrumenting three dimensions rather than one:

Time — not just dates and milestones, but effort against plan. Dates slipping is a symptom; effort burn tells you why.

Cost — hourly rates applied to logged effort, aggregated per project or per group of projects. This is what turns a portfolio view into something a finance director will actually read, and it's usually the gap between "the PMO has dashboards" and "the PMO gets listened to."

Quality — the dimension almost nobody measures, even though the signal is already in the work items: reopens, defect density, items bouncing between statuses, work that gets redone. Related to this, the lean idea of muda is useful here — if you can see where effort goes into low-value or repeated work, you get a conversation about process rather than about people, which is a far better conversation to have in a portfolio review.

The design constraint that matters is @Matthew Sinclair's point about customisation bloat. Health metrics should be derived from data teams already produce — worklogs, transitions, links, resolutions — not from forty new fields someone has to fill in weekly. Anything that depends on manual upkeep decays within two quarters, and then your dashboard is confidently wrong, which is worse than having no dashboard.

On @Hassan Sajid Malik  's question: governance and reporting standardise fine once you force agreement on definitions — the hard part is political, not technical. Resource planning is genuinely harder, because real capacity lives in HR systems, holiday calendars and people's heads, not in Jira.

Cheers, 

--Hugo

[Manuel Rahman]

I agree with you, @Hugo Hugo. Ultimately, we'd all like to be able to answer the more meaningful questions such as "Is this project healthy?" or "Are we likely to deliver on time?".

For us, though, those questions are predicated on first being able to answer the basics: "What is actually happening?" and "Who is busy doing what?". If the underlying data and visibility aren't there, any higher-level insights become difficult to trust.

We're not quite there yet, but we've been iterating our Jira Projects setup to gradually improve visibility of work, ownership, progress, and effort. It's very much a journey of small, incremental improvements rather than a big-bang solution.

That's one of the reasons I started this discussion. There is plenty of information about what Jira could do, but I'm particularly interested in how people are addressing the fundamentals of managing non-software projects in Jira today: planning, task tracking, RAID management, reporting, resource visibility, and stakeholder communication.

We feel like we're making steady baby steps, and it's been really valuable hearing how others have approached the same challenges so that we can hopefully move faster!

[Steven Haworth]

Good point.  We don't track resource time in Jira, instead we track budget and spend against budget, which is reviewed quarterly.  Contractor billing is tracked manually against their SOWs and forecasts monthly.

For steering cmt-level reports (and note our use case is international, working on a single project for use in multiple regions) we manually generate a slide deck.  We review timelines in Structure weekly, and we review risks / overall status bi-weekly in global meetings (using the Jira data).  But all that gets rolled up into a manual summary which is crafted to executive concerns - ie are we healthy, late, at risk, on budget, etc.