You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
We are working in some companies managing a lot of projects.
With Profields we have managed to have all the important information about our projects in Jira and searchable. But too much information can make you lose focus so we were wondering which were the three most important fields to have in a Gadget to have a good overview of all your projects.
Right now we are working with:
** All fields are script field type
Would you change any of the fields? When you are managing a lot of projects which things do you need to be aware of everyday?
One of the problems I have found is when the instance have several Jira projects, how can managers or project manager track all their projects. Maybe Profields can help to track their projects. The easiest solution is using something similar to BigGantt or Tempo.
Besides, @Adolfo Casari your solution sounds interesting. So you create one Jira project and, each issue is a project itself and you track your projects with Portfolio for Jira? Can you attach any snapshot in order to have a clear idea?
Hi @Francesc Arbó,
Yes, one (or a few) JIRA projects that have a issue scheme where one of the issues represents a project. Here's an article that describes the approach:
Thank you @Adolfo Casari. It seems an interesting aproach.
I'll try a PoC just to understand better this solution and find it's strengths and weaknesses.
Just another question, all these date custom fields are set automatically or manually? Do you use them in reports or in a Gantt?
The date fields are planned start/end dates for every Phase and are set by the owner of the project (or whoever holds responsability). One of the things the scheme does is that you can't set a duedate on a subtask if it's later than the planned end date of the Phase it belongs.
The real start/end dates are set automatically when the first subtask moves to In Progress and when the Phase is closed by the project owner, respectively.
Using JWT and Jira Automation, you can do all sorts of metrics to show in a dashboard.
@Adolfo Casari interesting approach. I too have taken the 1 JIRA-project to many actual projects approach and I do see some advantages. The trouble I'm having is creating buy-in for key individuals leading development on those projects; using the JIRA-project's board to show progress, etc.
Many of these folks are very comfortable using a checklist in a spreadsheet to understand what they need to do next, and tracking on what they've done. With that, many of the tasks within these projects are standard, and repeat from project to project.
I'm curious to know if you have run into some the challenges I'm seeing and if you have suggested approaches. I'll also check out your blog. Thanks!
Hi @Jason Warfe,
Key to using one JIRA project to hold many initiatives is to implement an (automated) issue hierarchy: this is what PMbok calls a WBS. By automated I mean that this hierarchy is created automatically by the workflow once you create an initiative.
In that regard I was able to configure hierarchies for handling Incidents and Projects that follows a phased approach (i.e. first analisys, then design, construction, etc.). For incidents I used a parent issue and a fixed number of subtasks and for projects a fixed number of phases linked to a main issue (i.e.the project) and subtasks under the phases.
In particular with the project hierachy I was able to configure custom fields that represents metrics for each initiative that can visualized in a filter gadget. For configuring these custom fields I used Jira Workflow Toolbox + Jira Script Runner. Here is a sample, each row is a project:
I have worked in a large organization where each Project had it's own JIRA Project. It just made sense from all angles:
- different issue ID to help differentiate
- clean boards without having to use labels or components to differentiate
- clean reports for each project
- less human error (ie. create a story and forget to label it for a particular project)
- flexibility on issue type schemes (some projects were simple and only needed Task, Bug, Request while others Needed Epic, Story, Task, Bug, etc)
The way we were successful is that we standardized a few JIRA artifacts: screens, workflows, statuses, etc across the organization. Note we did allow for a little flexibility based on justification.
I cannot imagine using one JIRA project for the entire organization!
Thanks for your feedback!! but in this case I was talking as a JIra Administrator or Project Administrator not as Project Manager... Probably it would be a better a name "how to administer a lot of projects" for this discussion! ^_^
@Leo Diaz _ DEISER- We manage Jira systems with Hundreds of projects for various customers. Your question if I understand it correctly is "As a Jira Administrator how do I keep my Jira system clean so that only the truly active projects remain available and visible in the system?"
Here is what we do as a minimum for any customer:
- Establish an Archive and Read-Only Permission Scheme
- Establish an Archive and Read-Only Project Category
- Run automated queries that look at fields very similar to what you have Last Activity, and Issue Count. We personally don't focus on Open status because it can be very misleading. I have seen projects have Open Issues for years just because it was an abandoned project which is why we look at Last Activity.
- You can also automate some emails from these Queries that you send to Project Leads and Project Administrators. The Subject line of the email says something like "Your project has been Inactive for more than XX Days - It will be Archived within the next 30 days if we see that there is no activity on the project". This usually wakes people up to either claim the project or it goes archived. The archived permission scheme will allow you to do On-Line Archiving and someone comes back to you after you have archived it, no big deal, just reset the permissions on the project.
Then you can use the Permission schemes and Project Categories to manage the projects and keep it as organized as possible.
We have found this kind of process really helps.
This is what we do at the minimum and then you can always go one step further by implementing another check through a JIRA request process. Basically when you get requests from someone to make a change/addition in Jira you reconcile any project they are a part of.
Hope this helps! Good Luck!
Thanks for your feedback!, It's not a question, it's just a discussion! ^_^, I like your feedback about run automated queries, it's a fantastic practice!!