Case Study: Project Management Tools (Jira Included) Don't Suck.

Complaints about project management tools are an old cliché in the software development industry. They can be heard from people in many roles, in companies of all sizes, and from all countries. When listening to them, one could come to believe that, oddly, none of the more than one hundred tools existent in the market solves the problems it should.

On top of that, it's particularly interesting to note that the most popular tool in the industry, Jira Software, is notably the most infamous. Most project management tool users, both heavy and light users, have a negative opinion of Jira — weirdly, even those who have never been in direct touch with it. Several times, I have heard statements like: "I've never used Jira, but I know it sucks," and "Project management tools such as Jira are counterproductive because they slow down the team." It's almost like companies were adopting Jira just to go against the grain.

Not surprisingly, though, such comments usually come from teams that follow no specific methods and processes of work and in which no one has significant experience with project management.

As someone who — sometimes as a consultant, sometimes as a mere observer — has been walking amongst a wide range of companies, of all sizes and from different countries, and meeting in these companies plenty of people with negative opinions about PM tools for almost two decades, I’ve developed my own strong, but divergent — and sometimes a little uncomfortable — viewpoint about this discussion. And here I will share, in form of a fictional case study, the basic points that support my viewpoint.

Remember, although I will be mentioning specifically Jira in this fictional case, the scenario and arguments are mostly valid to any other PM tool. Also, consider, evidently, it is not the goal of this article to discuss any differences (pros and cons etc.) among different PM tools.

Backstory

123XYZ Software Co. is a European software development company. It was founded five years ago by two engineers, Antoine and Oliver, and it grew exponentially in the latest two years. Now, its engineering team has sixteen people. Antoine is the company's CEO and Oliver the CTO.

Due to the fast growth of the company, 123XYZ's engineering team was facing a lot of recurrent problems. Requirements for changes and new features, plus reports of bugs, were cascading down from the business departments through different means, with poor specifications/descriptions and no explicit difference of priority among them. The team was working on multiple initiatives at once, but not much properly working code was being shipped in a consistent manner. Sometimes, different people were working on the same tasks, without one knowing about the another, and sometimes, different people were working on incompatible things, which they would only discover in later stages, after wasting a good deal of valuable time. The team had no defined process to deal with pull requests, to review code, or to test and ship changes reliably. They were mainly "somehow making it happen" (a.k.a. eXtreme GoHorse Process). Even shipping a small piece of code could be challenging and frightening. As one would expect, they could not accurately estimate deadlines or plan future initiatives beforehand. And, as a result — not unexpectedly, though — other departments were constantly complaining about the lack of visibility of what was going on, unreliable ETAs, lack of a trustworthy roadmap, severe bugs in production, poor communication etc. You get the idea.

Under such storm, CTO Oliver took the decision to adopt Jira. After all, "PM tools are designed to solve such problems".

One engineer, who had been a Jira user for a couple of weeks in another company, was then assigned to do the initial setup of the tool, although she had no specific experience setting up Jira or knowledge on project management. Anyway, she performed the task within a single day, as requested, thanks to Atlassian Community and, of course, Stack Overflow. Then Jira was introduced to the engineering team, and they immediately started using the tool that would, supposedly, solve their problems.

Fast-forward a few months. Despite the investment of time and money made on Jira, things got even worse. Initial problems persisted, and new ones were popping up. As a consequence, other departments were losing trust in the engineering team, not to mention multiple problems with customers, product losing space in the market, and everyone becoming unhappier.

On top of that, a new sentiment was added to the equation: the engineers hated Jira, and for multiple reasons. Jira not only hadn't solved the problems "it was supposed to solve", but it was an unfriendly and restrictive tool, slowing down the team. And, above all, they hated the tool because, due to Jira, requirements for changes and new features, plus reports of bugs, were cascading down through different means, with poor specifications/descriptions and no explicit difference of priority among them; the team was working on multiple initiatives at once, but not much properly working code was being shipped; sometimes, different people were working on the same tasks, without one knowing about the another; and sometimes, different people were... Well, you get the idea. "Jira sucks!"

Problem

If you have followed me so far, I'm sure you've got a clear understanding of my fictional scenario. 123XYZ adopted Jira expecting it would solve their multidimensional problems: product management, project management, and software development problems. Jira, according to their blind faith, was supposed to be a silver bullet. After all, that's what PM tools are designed for, no?

What they ignored, though, is that, as any other PM tool, Jira is only an artifact to support certain methods and processes. If your team doesn't have product management, project management, and software development methods and processes* in the first place, any PM tool you might adopt will become just another loose, annoying issue to be dealt with — often an expensive, heavy one.

*(To avoid repetition, from this point on, I'll use only the term "methods and processes" to refer to "product mgmt, project mgmt, and software dev. methods and processes.")

Using a PM tool that natively supports certain methods and processes (Waterfall, Scrum, Kanban, Continuous Integration, etc.) doesn't mean your team follows those methods and processes — not even close. Think on the difference of having a car set to perform death-defying stunts and being able to execute those stunts.

A second problem, as you might have noticed, is there was no mention of a project manager/lead/consultant in the backstory. That's because 123XYZ also ignored, as many companies do, that project management is, above all, a human thing, and, that being the case, it demands humans.

A third easily seen problem was the fact that the tool was set for use by someone with neither the proper experience to do such a task or the proper time to learn how to properly do it (and, please, bare in mind that learning from scratch about product management, project management, and software development methods and tools would demand quite a lot of time). But, of course, since the team didn't have proper methods and processes in place to begin with, even an in-depth custom setup made by a top-notch expert wouldn't make much difference.

The point being, though, the initial setup made by "whoever is available" is one of the most common mistakes companies make. People expect to "plug and play Jira", neglecting that it is a complex tool, and, as such, it demands not only a proper setup, but regular maintenance and improvements, which is the reasonable onus of adopting such a highly customizable tool: it's a tool that requires qualified effort to properly "behave."

On the bright side, with such a customizable potential, it's likely the right person with the proper time could mold Jira into whatever your team needs — or at least something close to it. And not only regarding the support to project management tasks. For example, with some tweaks (and perhaps a few add-ons), Jira can offer solid support to manage a product roadmap, code reviews, quality assurance, continuous integrations, deployments, pipeline reports, and so on.

(To close this segment about the problems of our fictional case, I feel driven to mention two points that go beyond the specific problems of 123XYZ's.

First: Regarding the third listed problem, it's clear it is a matter related to a few specific tools only, rather than the whole spectrum of PM tools, since most won't require much setup and maintenance efforts. Well, needless to say, there are pros and cons. And the mais counterpoint is clear: less effort required in one hand, less customization and automation capabilities in the other.

Either way, somehow, the tool you use must work in coordination with your own methods and processes. Therefore, if you can't customize your tool, either you must find a tool that works according your own methods and processes (and then, I suppose, you won't be able to change them, as in you won't be able to improve them) or adjust your team's methods and processes according to the tool you'll be using, which sounds, hmmm, somehow weird*. Think of having to restrict someone's astonishing cooking methods due to constraints of your oven.

*(As pointed out by my friend Jakub Paczkowski, this scenario could work for teams that have no methods and processes in place and would like to take advantage of a tool's native methods and processes as an initial baseline to educate themselves on such approaches. I tend to agree with Jakub, although, of course, a project manager could be more helpful in such scenario.)

Second: One could argue my fictional scenario is too ludicrous and say she or he belongs to a team that hasn't gone through any similar messy circumstances, but they still don't get along with their PM tool. To those, I'd kindly ask: Please, look at the wherefores instead of specific ornaments, then reflect about them in relation to your team's problems.

Solution

Now let's puzzle out 123XYZ's three main problems:

First: Before adopting any PM tool, your team must have clearly defined methods and processes. And by "have," I mean they should be in use, as in the team understands and systematically follows the proper steps, practices, and rituals. Plus, such methods and processes should work even without the support of any PM software tool (they shouldn't be interdependent). For example, you should be able to manage your pipeline flow using the help of post-its only. That may require more effort, but it would even be helpful to test your methods and processes in a genuine Agile approach (think MVP/Magic of Oz etc.), then adjust them before effectively hiring a software tool and automating stuff etc.

Second: Someone must be in charge of all project management activities. Doesn't matter what you name such a person — project manager, team lead, process master, Dorothy, or Mr. Wolf — as long as you have someone able to orchestrate efforts, streamline methods, tweak the tools, have an eye on continuous improvement, make the communication flow, remove obstacles, support the team etc.

Needless to say, this person must have a solid understanding of product management, project management, and software development methods and processes.

Third: With methods and processes in place and someone leading project management, we can start talking about a PM tool.

So, returning to 123XYZ's case: Since they already have Jira in place, for the next step, the team should outline how they would like the tool to support their methods and processes, then kick-off a project to (re)setup and (re)customize Jira properly.

For example, the team creates a wish list with everything they would like from Jira, both from their own ideas and from their findings from benchmark. Note that, at this point, it's possible that unrealistic requests pop up (we often see people expecting from PM tools things that have no relationship with project management), but since the team now has a project manager, while facilitating the process, she or he will bound the spectrum of requests and remove any scope creep.

Then each wish from the list should be classified by level of priority (e.g., life-and-death, would be nice, cute, not sure about it etc.) and estimated effort to implement (hard as hell, done by tomorrow, a few cups of coffee etc.). Other common points to consider are the occasional need of add-ons for certain tweaks and integrations, hiring a freelancer or a company to help with certain of these customizations, and whether you have a budget for such.

From there, actions should follow as in any other regular project: tasks for setting up Jira are created, prioritized and assigned, resources allocated, implement, test, roll-out, repeat etc. Some companies will work on this list of tasks/wishes gradually, along other initiatives, while other companies will stop other ongoing initiatives temporarily to make their p.m. tool work as they expect in the first place (choices - tell me about them).

Bottom Line

A project management tool is nothing more than an artifact to support product management, project management, and software development methods and processes. It won't make your team proficient on those methods and processes by itself.

Also, methods and processes shouldn't be dependent of a tool. Therefore, your team must have its own methods and processes in place to begin with.

Then, when you decide to implement a PM tool, bear in mind its goal is to support your methods and processes, so it should fit inside them, never the other way around.

Last but not least, your team needs a project manager. And it's okay if you decide to name the role something different.

Final note

Thanks to my friend Jakub Paczkowski for the review and feedback.