Hi everyone, how you doing this Monday? 👩💻
I decided to share with you today some of my methods for consulting on new Jira instances, specifically when it comes to plugins (or "apps").
To start, I usually follow three main points, in this order:
- Need
- Usability and maintenance
- Budget
1. Need
This is where everything begins. "Need" means understanding what functionality, features, or powers the team expects to enhance with Jira. Maybe they want better reporting, time tracking, custom workflows, or automation.
Now, I don’t usually hold meetings just to talk about apps when the Jira instance is brand new, because most people don’t yet know what the tool is capable of, let alone what third-party apps can do.
Instead, I listen closely during discovery or planning calls. Teams will naturally give you leads (borrowing the term from sales here) when they ask things like:
- Client: Can we somehow generate user-based timesheets in Jira?
- Me: Not natively, but there are apps that can allow us to do that.
Referencing here, for example, Tempo Timesheets app.
These little questions are gold ✨. They reveal needs that haven’t been formalized yet, and they allow you to suggest solutions organically. Be clever and catch them the moment they appear.
Also, people tend to give you a lot of leads, and with that comes the need to filter and prioritize. I’ve seen Jira instances with two apps doing the same job, like JMWE and ScriptRunner. That’s a red flag. If you’ve got both, sorry to say, you only need one.
2. Usability and Maintenance
With the needs in mind, I need to evaluate the team’s ability to use and maintain whatever apps I might suggest.
It starts with mapping out the team's maturity and comfort level with Jira. Is there someone familiar with the tool already? Do they have experience configuring workflows or handling admin tasks? That’s a good sign.
More importantly, do they have the skills needed to maintain more complex apps? For example, I won’t suggest ScriptRunner if there’s no one on the team who can write a line of code or if they don’t have a consulting partner. In that case, JMWE might be a better fit, it’s more low-code and easier for most teams to manage.
This helps you understand who can maintain what, and it protects your credibility in the long run.
Because : if the app gets misused or abandoned, the client will blame you. So let’s avoid that.
3. Budget
Finally, and only after the other two, I consider budget.
Let’s say a team has 500 Jira users and a budget around $1 per user. That makes JMWE an attractive option due to its cost. But we can’t stop there.
If we go back to the need and skills analysis, it might turn out that ScriptRunner, while more expensive, is a better overall fit in terms of capabillities. So I don’t filter apps by cost from the start. I look at what’s actually needed, then see what can be negotiated.
At the end of the day, an app that’s a little more expensive but saves the team hours of work every week may actually be the cheaper option when you consider the full picture.
So to sum up:
1. Start by understanding what the team needs.
2. Then check if they have what it takes to maintain the solution.
3. Only after that, bring cost into the picture, and remember that price can (and should!) be negotiated.
This approach helps ensure your app recommendations actually stick and bring long-term value, not just quick fixes.
Hope this helps someone out there navigating a new Jira implementation. And if you’ve got your own way of doing this, I’d love to hear it too. 😊
Happy Monday!
