There’s no question that Jira has become the standard collaborative work management tool for software developers. That’s a great thing for team productivity, but many project managers are visibly unhappy with Jira: as anybody who hasn’t hidden underground for the last 20 years knows, software developers have embraced agility and thrown away the traditional notion of a project. One of the reasons they like Jira is precisely because it disregards basic project management ideas in favor of a continuous flow of collaboration. To add insult to injury, Jira’s popularity is eroding traditional, phase-based, predictive project management well beyond the realm of software development.
It's true that there are projects in Jira; but they are merely a way to cut off issues, to tell them apart from other sections of work and to apply rules that are specific to that team (the schemes).
There’s a big risk: when Jira lies at the core of a company’s toolkit, Jira projects can be a limit to how projects are run and conceived in the entire company. If a project is just a container of issues, then it's no longer a project in the traditional sense: "a piece of planned work or an activity that is finished over a period of time and intended to achieve a particular purpose", as the Cambridge English Dictionary says.
Of course, that means that if your company runs projects in the strict sense, whoever is responsible for them may push back against the adoption or expansion of Jira. They may be project managers, but also PMOs, CIOs, IT managers, among many others.
When your corporate tool doesn’t support your project management needs, you will want to find a way around, storing project documentation, reports, and post-mortems in Word, Excel and corporate wikis – including Confluence. But generally speaking, many project managers don’t like having information scattered, and would rather have stronger project entities within Jira.
What is missing in a Jira project? Just to mention a few gaps that jump to my head:
Basically, the project as a control and management unit doesn’t exist in Jira. And I’m not even mentioning dependencies between projects, which are a cornerstone of project-based management and PPM.
Well, you can ditch Jira. But if you don’t want to do that, the reality is that you’re going to have a growing number of projects and no easy way of managing them and their information in the same tool. This is bad per se, even if you’re not a PMBOK enthusiast. So what can be done about it?
There are several ways to take this thorny issue by the horns and find a way to make your project advocates happy while still using Jira. Here are some possibilities:
There’s a bunch of add-ons in the Atlassian marketplace. There are even specific apps for implementing SaFE®!
One of the more useful alternatives is DEISER’s Profields (full disclosure: I work for DEISER). There may be other solutions that can help you, but Profields is a valuable approach for three reasons:
Profields cures Jira projects in Jira’s own terms; i.e., it transforms Jira so that it's both excellent at tracking issues and at tracking projects. Custom fields are its core functionality, and they allow to add dates, budget, resources, status, or priorities.
Once you have the power to create project-level information, you can decide how much you want to modify your projects. It's probably not wise to create strict waterfall methodologies on Jira, but many customers around the globe are quite happy adding deadlines, budget, status, and exploiting information to get project-level reporting.
Capi _resolution_Marketplace Partner
Hello Atlassian Community! Feedback from customers like you has helped us shape and improve Jira Software. As Head of Product, Jira Software, I wanted to take this opportunity to share an update on...