Let me just say up front that I love Jira in so many ways and I know there will be plenty of people out there using Jira to run a portfolio. So before any unhappy emojis are directed at me, this article is not about issues, frustrations or gaps that I have with Jira or any tools. It is however about scalable portfolio management and why, while it is a critical tool to manage work, you will find some limitations in Jira when using it in a full Portfolio Project Management framework. This does include using the add-on Jira Portfolio which again has a very clear purpose which it serves incredibly well, but it does support a portfolio in full.
To begin with, let’s establish the point of reference for what I mean when I use the word 'limitation'. To do so, I’m going to borrow a quote from British Philosopher Betrand Russell: “Limitations imply possibilities. A problem is a challenge”. So when I am describing a limitation of Jira to run a portfolio, it is based on the identification of opportunities to help build a better portfolio practice and avoid some of the mistakes I have made over time. Ultimately it is based on past experiences using processes or tools to meet a need which they were not built to support, or in other words, trying to fit a square peg in a round hole.
So what is Portfolio Management anyway?
It is probably best to ensure we all are on the same page regarding aspiration of Portfolio Management. It is about the organisation as a whole (not just one product or project) and is intended to take a significant, complex data set (Epics, Stories, tasks, sub-tasks, milestones, risks, issues, dependencies etc. etc.) and interpret it in a relevant, meaningful way for decision making. Good portfolio management practices can significantly enhance an organisation's assurance that value will be realised against the investments made.
Portfolio Management Definition
Portfolio management is the selection, prioritisation and control of an organisation’s programmes and projects, in line with its strategic objectives and capacity to deliver. The goal is to balance the implementation of change initiatives and the maintenance of business-as-usual, while optimising return on investment.
Definition from APM Body of Knowledge 7th edition
Meeting that definition is most definitely a challenge and it will take disciplined processes, skilled practitioners and yes, purpose-built tools to do so. It is also worth noting that nowhere in that definition is there a mention of a roadmap. Product roadmaps, while a critical and useful view within a project or portfolio (rolling up multiple projects’ data) do not assure the outcomes of a portfolio therefore should not be confused when we look at the role Jira plays.
So what are the limitations of Jira for a portfolio?
Excellence in portfolio management needs to focus on all levels and attributes of a Portfolio Project Management (PPM) framework and hierarchy. Most project or initiative focused processes, tools and techniques were simply not meant to manage a mature, enterprise framework. Sure you can bend them into the shape you need however this will only allow you to mature your capability to a point, which will add some risk to return on investment and meeting strategic goals. I find the below image is useful to illustrate this point:
Essentially if you get to a point where things are working, but then settle for what you have, the best outcome you can hope for is to be somewhere above the ‘suck threshold’. Instead of staying within your limits, exploit them to get better outcomes.
So let’s look at what some of those limitations are and what that means for your portfolio.
The limitation of organic growth
One of Jira’s strengths is as a highly configurable and flexible tool for Team level activities. As a result its expansion in an organisation is usually through team adoption with different teams using it for different purposes or with different methodologies (Kanban, scrum, issue management, ‘to-do’ lists). This is a bonus for Project Managers who will need highly configurable, easy to use task management tools to organise work however a challenge should an organisation ever want to align all initiatives into a portfolio.
Portfolios are created once an organisation reaches critical mass in the number or complexity of projects being managed. Single-team Projects become multi-team programs and eventually a portfolio is needed to establish control and establish processes such as demand management and prioritisation to reduce risk and deliver strategic outcomes over time. Portfolios also need reporting which will usually come through a standardised data hierarchy model. So going back to the way the projects have been set up and are being run in Jira, what you start with will be a wildly varied sets of data. Trying to wrangle an organically grown project jungle within Jira into your PPM framework is hell. To help you visualise what that is like, below is another GIF of me when I had to do just that.
So where to start when faced with such a scenario? Break your approach down into three phases.
1. Establish
- Educate senior leadership
- Design the project organisation and the required roles (what they do, how they interact and the processes they use)
- Select and implement your PPM tool
- Configure Jira and your PPM tools in alignment with your reporting, planning, prioritisation and other processes
2. Tune
- Tune your teams from their current way of working back against a common model - there is no need to constrain the freedom teams have but every game needs rules
- Build your portfolio backlog
- Develop your roadmap (as an option this can include a standardised approach to release management across all projects)
3. Run
- Establish iterative planning cycles at an enterprise level
- Establish steering forums and terms of reference
- Establish portfolio reporting - trust but verify project delivery
Over time you’ll see the level of excellence in your delivery capability increase, processes will become repeatable and you’ll cross the ‘kicking-ass threshold’ in no time.
The Bi-modal portfolio
Use of Jira in a Portfolio will usually mean very happy product engineering and development teams however that will be specific to their context rather than that of the enterprise. Portfolios have stakeholders such as Executives (“where my $$ are being spent and what value am I getting”), PMOs (“are we doing things the right way”), Finance (“better data and transparency for my reporting and decision making”) and of course Portfolio Managers (“I don’t want to have to trawl through project boards to create portfolio reporting”). For portfolio roles, most of their needs come down to standardised, trustworthy data which rolls up all the details in a meaningful way. Jira will support this up to a point (release level) but does require some guardrails for teams to work within for that to be effective. Part of that approach will need to include a good hard look at the multiple modes of delivery teams are using for their projects.
According to a 2019 Global Study of Product Team Performance Survey almost 40% of organisations have a blended or bi-modal methodology for their product development. This is a decreasing number as Agile adoption is on the rise however this is a key factor when looking at how a portfolio should be structured and what role Jira plays within it. For ‘Greenfields’ companies and start-ups this is unlikely a problem given the ability to start with a single agile methodology from a clean slate. However for the majority of companies, there will be legacy ‘keep the lights on’ projects, infrastructure and perhaps non-technology projects such as compliance investments underway at any given time.
Should a single methodology and tool get wrapped around a portfolio which contains other project methodologies, it is likely you will start to see major fragmentation and poor practice at Program level which in turn diminishes portfolio visibility and capability. With these limitations, program managers or governance teams will resort to use of tools like PowerPoint (yes I have actually seen supposedly experienced practitioners copy and paste Jira burn-down charts into a slide show - the horror) as workarounds. This will never work for a Portfolio Manager and Executive stakeholders who need to see the performance of their project investments.
Limitations imply possibilities
So going back to the good advice from our friend Betrand said, let’s not think of limitations in a negative way and instead look at the possibilities created. Hopefully there are insights that can improve your portfolio management process irrespective of whether we all agree on what is a limitation and what is not. Looking at the possibilities there are a lot when establishing a best proactive portfolio but I’ll call out my top 3.
1. Data attributes
Jira is one of the best tools to manage attributes of an Agile portfolio but can be hard to translate to a more traditional audience looking at Program, Project and milestone view.
Mapping your top down PPM hierarchy (i.e. the way you want to report) to your Jira data is critical and will help should you want to integrate tools. Map Project to Initiative, Feature to task, Release to milestone (as one example of a key date) and also break your portfolio down into logical program increments and iterations (sprints). These can translate across all methodologies and will be easily rolled up in portfolio reporting. Fixing costs against these items can simplify project accounting however be sure to consult your finance team should your portfolio have a Capex component as to how this gets treated.
2. Horses for courses
Create an application architecture for your portfolio management that is based on native integration, lowest cost and process efficiency. There can be numerous ways to automate processes and reporting as well as achieve the required amount of governance and control without immobilising teams with bureaucracy. In accepting limitations in a tool like Jira, it does create a gap that will need to be plugged by other Apps so think this through carefully. In the same way I am advocating to not try and make Jira do too much, it was not purpose built for, careful selection of a fit for purpose PPM tool is best. To enable this, look at your PPM hierarchy with its different stakeholders and data consumers. Map their requirements into your PPM application options and there will usually be a clear contender that works for you.
3. Link Strategy and Execution as a measurable process
As I have mentioned, the whole point of a portfolio is based around the effective management of strategy execution. Given a strategy will likely span multiple years, ensure your processes can create a reporting loop that can measure incremental realisation of strategic goals. Ongoing transparency of the key attributes of projects, programs and the portfolio itself is key but be wary that, at times, make teams uncomfortable given the constraints it can often introduce. With a good PPM tool, Teams should ideally be free to manage Jira as they need to (within the guardrails) and the integration and reporting processes should bear the load of any governance overhead.
Your leadership in whatever capacity you have in the portfolio is key and look at setting up an Accountable Executive for the Portfolio as a whole who can influence or (where required) direct what needs to be done.