We have about 500 users and over 200 projects, and over 500 custom fields.
How do you guys keep track of what's going on in your Jira instance?
also, unified request/demand management towards Jira admin team - that is, have a dedicated place and rules for users to request anything for their projects. Simple tracking, centralized place for decisions (e.g. if you receive complex requests such as new plugin installation or so, you can involve higher team members to approve/reject the request and so on)
Standardization gives less flexibility. And users hate us more.
There needs to be guidance to the users as to what can be tailored and what cannot be tailored. Having guiding principles for Jira design can help users understand the 'why' for the less flexibility. For example, a principle everyone can buy into is having a stable, performant Jira instance. Other principles to consider are
I absolutely agree with @Stéphane Veraart
To maintain a healthy environment, you'll need more restriction on who can do what, standards, project templates, etc. However, I would also add that you should restrict the use of team-managed projects (if possible) as this allows statuses, workflows, fields, etc. to be generated outside of Jira admin control.
If you're looking for a way to clean up your instance fast and monitor it going forward from a centralized location, I have written an app called Instance Auditor (Jira) that may be useful to you--shameless plug I know, but our customers have been very happy with the app. If you decide to give it a try, I'd welcome your feedback :).
Here's my (non-exhaustive) list :
1. Have a small, trusted group of Jira admins
2. Establish best practices (e.g. "Do not create custom field with same name as an existing one")
3. Clean up entity sprawl - get rid of unused statuses, screens, custom fields, workflows (=inactive ones) and all kinds of schemes (screen, issue types, etc.)
4. Share schemes across projects - permissions and notifications
Thanks for you additions, @Amir Katz (Outseer)
My answer was a very short summary of your more extensive answer.
This is exactly what I came here to say. The standardization has REALLY helped my workflow!
I oppose sharing schemas. Because when one team makes changes immediately another team member jumps in and runs to me and asks to remove changes. It is easier for me as admin to have a scheme per project.
Maybe if you have only one team it will work. Me having 10+ teams am too lazy to negotiate changes with everyone. I have default schemes which I copy every time I create a new project.
I'm just mean about enforcing them and no one else is allowed to create schemes.
1. I use context for every new custom field where I select only projects and issue types that require this field
2. I have a default fields config where all fields are hidden. When I add a new custom field I go to this default config and hide the new field. Whenever I create a new project I make a copy of default config with empty fields and turn on only fields I need nothing else.
3. I use roles for projects. Every user is a part of several groups. Whenever anyone needs access to project I apply a role to a group. Or add the user to the group.
4. Important changes should be documented. I have a project Jira in Jira where any employee can put tasks for me. Whenever I do a change in config I put the ticket number in description or in rule name. This helps me to find out who requested the change and why.
All excellent suggestions which will stop the chaos. I would recommend to use Jira to track all requests and changes. All tools requests are tracked by Component: User Permissions, Custom Fields, Workflows, etc. and by team/Jira project.
Above all, KISS it. For example, if a request comes in for a new Status named READY FOR TESTING and you already have another Status named READY FOR TEST, then use that. Minimize always creating new Assets-- Statuses, Workflows, Resolutions, etc.
this is one of my guiding principles - use existing entities if they have the same type (e.g. for status, the requested status category) and if the name is close enough.
Another best practice - we migrated 2 on-prem Jira servers to the cloud and now we have large number of unused entities. So I would take an existing one (status, resolution, CF) and rename it as per the request thus avoiding creating new ones.
I made a JSM project for Jira and Confluence help requests to help track what people are asking for and keeping it centralized. Like others, I have a few trusted other admins who can self-manage their own subset of projects. I also agree with the other great suggestions listed above.
And I also shut-off letting people create "team projects". When I had this on in the past, people hit limits and then I had to convert them to company managed projects. People also don't know how to set the permissions for those projects and then they are left wide open when they shouldn't be.
Good point. I tell people, "if you create a team-managed project, we (the Jira admin team) cannot support you." That usually works...
I will look into blocking this option completely.
Why not remove the Create team-managed projects ?
https://support.atlassian.com/jira-cloud-administration/docs/manage-global-permissions/
@Rilwan Ahmed : the assumption there is that @Chris Thomas is using a Cloud instance. In which case the option of removing the creating Team-managed is a good choice in these circumstances.
In other circumstances, for on-premise the recommendation would be to limit the Project Admin permissions to basic only instead of advanced admin rights.
I have never looked at our audit log before! Of the first hundred logs, 89 are my actions, so I'm not worried, but I'm super glad to know about a place I can monitor!!
BTW audit log has REST API and I plan to have a scheduled job that will extract logs once in 3 months and store it in appropriate location. Jira cloud deletes logs after some time and it is a good idea to backup them for inquiries.
User Management:
- Create appropriate groups and add users to it.
- Map groups to projects. Use a naming policy. example: For project ABC, group name like ABC-Team, ABC-Admin etc.
- Add only the real users with Jira administration knowledge to jira admin groups. This will restrict other users from creating custom fields, Workflows etc.
- Occasionally send Project admins/leads the list of project users and ask them to review. This will be helpful in maintaining the license count.
Projects:
- Categorize projects
- Try to re-use schemes (workflows, screens, issue types, priorities etc). i.e create project with shared configs for same category.
- Use context for fields
Global Permissions:
- Add appropriate groups for global permissions. Not all users require all permissions.
https://support.atlassian.com/jira-cloud-administration/docs/manage-global-permissions/
Audit log:
- On Random days, check system --> Audit logs. You will come to know what all is happening in your jira
Minor comment - AFAIK, priorities in the cloud are global. There is an open feature request to have priority schemes in the cloud.
Yep, but you may hide global priority in default field configuration and use custom field with same name with many contexts.
@Chris Thomas This page has some good advice: https://www.atlassian.com/blog/jira-software/human-side-scaling-jira-software-governance-custom-fields-admins
Granted it's from a few years ago but the advice applies.
Additional resources and Marketplace apps
These are but a few but have some good options for managing/grooming schemes.
Jira Command Line Interface (CLI)
Has a built-in function of 'removeCustomField' for bulk custom fields deletion
From the original post the number of custom fields looks a bit high, from my sea gull view that looks like 1 custom field per user.
I would do two things:
1) standardise your project workflows - aim for a standard set (with 200 projects that might be as many as 20 standard workflows - but 20 is easier to manage than 200)
2) group your users - as others have suggested
and then make a critical analysis of the custom fields to de-duplicate and standardise them - along the way expect lots of user resistance but hit the low hanging fruit first i.e. fields with low project use.
p.s. you cannot do this in a day, you have several weeks/months of activity ahead of you.
Re de-duping fields - this is easier said than done, speaking from (painful) experience - replacing custom field A with B can be a lot of work, especially if you have
a) many issues, projects and issue types using this field
b) field is used in workflows (conditions/validators/post-functions), automations and other entities that refer to fields.
That's why they have contexts in Jira. Every field with a name and a type can have any number of contexts where you put various initial values, options (in case of lists) and even insight queries. I recommend using contexts as long as they eliminate many problems.
Seems like everyone above has some very valuable information, but to add to that we use a roadmapping/feature tool called Aha that integrates with Jira. It gives a more high level view of features and initiatives than Jira does and Jira and Aha keep each other updated. Just thought it would be helpful given is it is a more birds eye view of what you have in your Jira instance.
There are some stellar thoughts here. It would seem it all boils down to governance. This is a true enterprise class environment and needs to be treated as such. As soon as you do that, you start down the path to honest manageability and rigorous support of the enterprise while maintaining the measured method of supporting the entire organization.
Your analysis is correct, governance is key, be careful to avoid the trap of becoming 'the process police' !
Whatever governance model you select should aim to assist >85% of users, 10% you will need to work on convincing that good governance will improve their lives long term and 5% of users will resist forever so just accept that apply governance and move on :-)
Best of luck with your project to bring this under control.
You hit the nail on the head, @Paul Cooper , If we try to square peg all the people, lots of them will be unhappy with their lot. I have implemented the toolset to where it had 100% penetration across the organization while maintaining rigorous governance. It was the combination of rolling common processes together where possible but also the snowflake processes supported but in the context and view of the entire organization.
One comment of many that told me I had succeeded was when the person that ran payroll told me she would never work anywhere she couldn't manage her work in Jira.
Hi Mike,
"One comment of many that told me I had succeeded was when the person that ran payroll told me she would never work anywhere she couldn't manage her work in Jira."
This type of comment can be treated one of two ways:
- aggressive user threat
- someone who does not understand how consistent processes benefit them
I have encountered this personality many times too (not always in a Jira context), there are a few strategies to tackle them:
1. Majority rule - if nearly everyone else is using common and consistent tools then use this and then ask the complainants to explain to their line managers why they need an exception - oh yes, and then give that manager a support cost specific to the customization i.e. you need xyz to support it
2. Call them out - give them a window of time to adjust and then migrate their work the consistent process - blunt but sometimes you just have to tell people this is what is going to happen and when but don't expect any Christmas cards from them. Sometimes people say 'I am going to leave if xyz happens'. As long as the reasons for the change have clear benefit to the business and are mandated by the leadership team then it's not your problem if someone gets the hump and leaves.
3. Explain how they benefit from the standard process - this can be very effective if you can factually identify the hidden cost of managing non-standard workflows and show how that cost affects the bottom line e.g. less cash available for pay or bonuses as you had to outlay all this support cost. In other examples, like custom fields if users can minimise custom fields and have fields that they can use in different projects but are the same field then that can simply be explained, in a large tier 1 telco supplier I saw 6 x custom fields all named "Project", that made finding the Project field that you needed rather hard - once this was explained we agreed that one field call Project would suffice and everyone was happy.
4. Use the power of management - go above the complainant, explain what needs changing and why to line managers and get them to change their employee's behaviour - this works well if employees you need to change have some influence on your life that you might see as a threat e.g. paying you
I think, in your case with so many disparate teams and projects you need a leadership sponsor, someone in your executive board responsible for change management - top-down may be the only way forward for you.
Best of luck
Paul
(p.s. as VP of Engineering I am the top-down change driver in our company so my life is a bit kinder and we are a lot smaller than you)
In this case, @Paul Cooper , it was a human understanding the benefit of a common environment run for the common good. She got how much it helped her and that her project was linked with AP, HR, and she had her own service desk.
I didn't have a leadership sponsor; I was largely self directed at that time. However, I'd been rather successful at making my user base happy and improving the company's lot so... they let me do stuff.
The only complaints I got was that there was one of me and they all wanted on board the Atlassian bus.
why 500 separate projects ? can you explain why the huge number - what is the correlation / break down on why you've reached this amount of projects ?
It's easy to do in a customer facing shop where every software project has its own documentation, repos, hosting solution...we're a SMALL shop, and we have well over 100 active ones.
using adv roadmap (rm), teams, components and initiatives can keep the sprawl down.
a custom board or adv rm plan for each sprint squad or kanban team can also help.
the plan view adv rm gives, makes it easy to see the overview of where each team / sprint / initiative or "component" level is going / doing. you can quickly swap between efforts by a quick adjustment to a filter on the "overview" plan board.
it does depends on what you're trying to show and achieve - but having hundreds of small projects seems to be a big overhead
The ratio of projects to users is 1 for 2.5 users. That may be slightly high but it is a function of how many template only and sandbox only projects are included in the the 200 project count. We have empty projects for the templates used to create new projects on our instance. We also have 'sandbox' projects to allow users to learn workflows without adding issues to their assigned team projects.
At Disney corporate IT we had thousands
I agree with the suggestions above. In addition, you may want to consider tracking the design element sprawl by getting snapshots of your instance's growth. I highly recommend @Rachel Wright book on JIRA Strategy Admin Workbook. She has good suggestions on how to clean up a 'Jira swamp'. If you have a cloud instance, scripting with API calls will be your best friend.
Locking down admin is a good start - and bias towards standardization also good.
This said, I suggest though that you hold a monthly or bi-monthly Zoom call that is open to all users to pitch ideas around together. Your job is to carefully capture those ideas and requests in a group setting - and report back on the next call your analysis of the request.
They key here is to be both open and accessible while at the same time slowing down the volume of requests. Sometimes multiple requests can be combined into one change request - thus achieving standardization... and letting your users feel empowered.
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Jira Administrator
Configure Jira Software, Jira Core, or Jira Service Management, including global settings, permissions, and schemes.
Managing Jira Projects Cloud
Learn to create and configure company-managed projects in Jira Software and partner effectively with Jira Admins.
Learning Path
Become an effective Jira Software Project Admin
This learning path is designed for team leaders who configure Jira Software projects to match a team's processes.