Transforming Jira Software projects for general project management purposes

[#1]

The daunting task of catering Jira to Project Managers

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.

Leveraging the Marketplace to transform Jira projects 

What is missing in a Jira project? Just to mention a few gaps that jump to my head:

• Neither start date nor due date
• No budget
• No dependencies between tasks
• No project-level reporting
• No hierarchical team management
• Even sorting through projects becomes difficult once you reach a certain level (at DEISER we estimate the threshold of comfort at about 200projects)
• No prioritization between projects

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.

What can be done about it?

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:

• The expensive way: Buy a big PPM tool and integrate it with Jira. 
• The throwaway: Get MS Project and map it onto Jira. The problem is that you will have lower granularity work on both sides.
• The lightweight transformation: Use marketplace add-ons to transform Jira projects into actual management entities that help you and your managers.

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: 

• It offers a global solution to the flaws of Jira projects
• It's simple, and it doesn’t require the adoption of any methodology or framework
• It’s been endorsed by Atlassian for enhancing project metadata.

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. 

[William LaRue]

I appreciate your statements in this post, but I think that just trying to wedge custom fields into JIRA to make it more acceptable to "true" Project Managers is missing a major point: JIRA is tuned to Product Management, not Project Management. The differences between the two disciplines is lost on many in the Project Management Community, who see Project Management as the be-all and end-all means of doing software development. Appreciation of the boundaries between the two disciplines is paramount in crafting an approach to development that works for all constituencies in the enterprise. Project Management has elements such as budget, contracts, Program Management rollups and other items that require a phased approach; Product Management, which extends for the whole life of the Product, is iterative at its heart and due to the uncertainties involved does not fit into the Project Management framework well. Both entities are needed to do things well.

The challenge, which is partially met by the approach that you describe, is to integrate the two "flavors" of management involved. A more global approach is realizing that true integration of these elements probably needs a toolset that rides atop both systems in play. We are looking at a tool that does just that: links multiple disparate tools that normally are siloed so that coordination of efforts and evaluation of Value Streams can take place. Using that schema, each discipline can operate as needed and each can buttress the other discipline's shortcomings. All this without custom fields.

[Capi [resolution]]

Hi @William LaRue, 

Wow, thanks for your comment! Both for the appreciation that’s in it and for the important nuances you mention.

Of course, I agree with your point of view: Jira is designed for product management (and even for that kind of work it has received accurate criticisms because of its focus on granularity vs the big picture. I guess no product is perfect) and NOT for project management. The point of the article is showing how some (just some) project aspects can be supported within Jira without altering the scope of the tool. In fact, Profields basically extends functionalities at the project level that users already exploit at the lower issue level. Custom fields are just one of them, but possibly the ability to search for projects is as important and you don't have it out of the box with Jira. Imagine how valuable that can be in enterprise settings where virtually nobody has a clear picture of how many projects live in Jira. Not even the Project Management Office tracks them!! For the simple reason that there’s never a 1:1 relationship between Jira projects and project management projects: most Jira projects are ongoing; some others may correspond or be part of actual projects with a project manager. A PMO with access to or even governing Jira will likely only rule on the second set. Thanks to how Profields exploits the information stored in project custom fields, customers can create more facets or sections of their work in Jira that they can look at, show & share or report on for any reason. This can help program managers as well. But I wouldn’t be comfortable saying Profields is a program management extension for Jira, and neither is it a project management extension for Jira. Put succinctly, it allows treating projects with the same or a similar degree of sophistication than issues.

Let me know about your findings for an overarching toolkit! Are you running projects and programs on a second tool that is not Jira?

[William LaRue]

Thanks for the kind words, Jaime! I agree with the ideas that you have
offered; somewhere in all of this goodness, there is the seed of something
powerful. I agree with the idea that integration of projects, if only for
visibility at a higher level. We have attempted to use Portfolio to give us
that visibility and to do things like resource allocation, but the results
didn't really satisfy our needs and the Enterprise PMO was less than
thrilled with the idea. I am currently exploring Tasktop as a solution; it
has the promise of being a sort of universal translator that can link tools
like Clarity, JIRA, Selenium, AppScan, SonarCube, Remedy, etc., into a
chain so that changes can be propagated amongst the "links" and analysis of
the total development Value Stream can be realized. Pretty ambitious goals,
but they look to be doable. I'll let you know how we fare in trying to get
this from concept to reality. If we accomplish this, a lot of the arguments
on both sides of the fence become moot, and we will have the ability to
deliver to our clients in a more efficient and cost-effective manner (not
to mention having a good answer to the "Just why are we paying you guys so
much money for these projects, and why are they taking so long" questions
that invariably come up. I'll take a look at your recommendation for the
custom fields and will be happy to review it. Take care...

[Capi [resolution]]

Thanks for mentioning the tool, @William LaRue! It's really interesting to see how the most valuable product propositions I see lately are data integration umbrellas like Tasktop for software development or Segment for marketing toolkits.

I'd be happy to connect over LinkedIn if you want to be in touch besides the community. Also wondering if you're going to the Las Vegas Summit?

[William LaRue]

The latest (yesterday) indicator that the "higher level integration" schema is taking off is Atlassian's purchase of AgileCraft. They also have integrations with multiple platforms and ride above the platforms themselves, but I think their integration scope is narrower than Tasktop's. It will be interesting to see what Atlassian does with this product, and how Atlassian's move into this sphere will cause other companies to offer similar products. This seems to be evolving quickly; how quickly people line up to pay for the products is less certain.

[Marcin Geb _SoftwarePlant_]

Hi, I pressed 'Like' twice below the article and William's comment.

ad The expensive way: Buy a big PPM tool and integrate it with Jira.

Not to interfere with Profields, but BigPicture (that I represent) is a 'full-size' PPM app for Jira; I wouldn't call it daylight robbery in terms of pricing ;)

ad a toolset that rides atop both systems in play

BigPicture 8, to debut in 2020, transforms into a standalone 'umbrella' app (under the name of BigPicture.one (although it can still operate as a plugin for Jira). For now, BP.one can suck data from Jira (multiple instances) and Trello, but more integrations are underway.

Thanks for the great and comprehensible content.