I work in City Government and we are building a platform to track implemention and monitoring of our climate action plan. Our plan has
- 4 high level goals
- 6 focus areas, 12 strategies, and 60+ actions, (each focus area has roughly 2 strategies and 10 actions).
- 6 strategic initiatives, spanning actions from different focus areas (useful for reporting)
I'm looking at three different options for organizing this plan:
1. One Jira Core project, containing all of the above actions as issues. Using a label or component to track the cross-focus area initiatives.
2. Six Jira Core projects, one for each focus area. Using a label or component to track the cross-focus area initiatives.
3. Sixty+ Jira Core projects -- one for each action. Each action could rightly be a project in itself and will be implemented in coming months or years, so maybe that's a reason to consider this model.
I'm choosing Jira for this application for its power, flexibility, and low cost; in the hope of making it an open source template that other local governments can use. I have looked at many of the best practices posts, but I would really appreciate recommendations from other project admin humans. I'm happy to provide more detail as needed. Below is a link to the actual plan, if that is of interest.
The concept of a Project in Jira is very team focused. The way permissions, workflows, etc work best is when the Project is built for a single team, or at least a case where multiple teams basically operate in the same manner. It sounds like you are trying to manage a portfolio, so you may also want to look at some of the portfolio tools that are available for Jira. Unfortunately, Atlassian's Jira Portfolio is not ideally suited for use with Jira Core, but you can take a look at Tempo Planner, Big Picture and Cycle Control to see if one of those Apps might help fill in the blanks.
Without having much information about your process, I would be inclined to consider option #2, as I think this will probably work the best. I hope that is helpful information in your decision making process.
Thanks, having looked at this for a while, I believe that option #2 would be the most functional.
Follow-up question -- one requirement of this project is to be able to graph the changing values in a custom field. An example in my case would be graphing pollutant levels over time.
I was not able to find other good examples of this in the other questions. Is this not easy to do in Jira? Or, perhaps I don't have the right search term.
Jira doesn't natively have a way to do this. It might be possible to do this using EazyBI, though. The problem that you will have is with the way Jira stores values in its custom fields, though. When you add a value and then change it, what happens "under the hood," is that Jira replaces the original field value with the updated one. It then writes the change to the field in the History table (you see this when you click the "History" tab in the issue.) You may need to have EazyBI look at some of the data for each entry in the History table. If you make the custom field numeric, it would be easier to identify a pattern and have EazyBI plot the graph for you. Sounds like a fun experiment to get this working. Another option would be to use the SQL for Confluence App and pull the data from the Jira DB, then use it to plot a graph that you display in Confluence. Either way,it would be a bit tricky to get this working.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events