Would like to reach out to find out if there are any companies that have successfully used Atlassian across the firm, to manage cross department initiatives; for example, using Atlassian to manage Sales, Software Development, Client Support, Product Management, Project Management
If there are any, it would be helpful to find out how JIRA projects were set up and structured to achieve this
Hi @Elliot Braet and welcome to our Community!
I used to work for the company where Jira Software had been initially implemented for our development team but later on we created more projects for other teams as well. We had one for HR where all the stuff-related activity was tracked (hiring/resigning, birthdays, interviews, calendars, etc.). We had a pretty big one for IT with all the inventory, workstations, network information etc. It also had a great change management and we managed to implement a thorough visual access matrix linking employees with instances and assets. Our marketing team also had their own project. All these projects had their respective spaces in Confluence which gave us the opportunity to document processes, create schemes etc. Naturally Confluence and Jira were linked.
That is the magic of Atlassian - it takes your teamwork to the higher level and helps employees to collaborate throughout the company.
Of course, it requires initial configuration, tuning, and specialists with thorough knowledge of the products but the result definitely worth it.
Thanks for the quick response! Glad to hear how your previous company used JIRA & Confluence across the company.
Would like to ask if you have any tips or pitfalls to look out for, and how to avoid them? I definitely see with very many moving parts, it is easy for a project/epic to become overly cluttered. On the flipside, if the team is small and often double hat, it may increase the administrative workload to separate each functional role into projects; unless this is one of those a little pain for a lot of reward kind of thing
Would also like to understand more about what you mean by "thorough visual access matrix linking employees with instances and assets"
Thank you for your kind words.
In my opinion, to successfully implement Atlassian products in a company environment one needs to
Don't forget about the Atlassian Marketplace - it is a wonderful place to get awesome apps. Almost half of the wow-features in our environment we got from different add-ons (free or paid). Though some of them could be tricky and require additional effort to implement up to some kind of programming skills.
By the way, the notorious "thorough visual access matrix linking employees with instances and assets" was based on the following app:
We had one project for all the employees and another one for all the IT systems and assets (workstations, servers, corporate accounts, resources, even services). We created a number of bidirectional links ("has access to"/"has user", "is hosted on"/"hosts", "is an admin on"/"has admin"...) and intertwined all our entities. That was hard work indeed but the result was awesome. We adjusted our processes in a way that every change, for example when an employee is granted access somewhere, would be reflected in our access matrix. This way when a person is hired depending on his or her role she's granted certain permissions and they are become visible in the matrix. When a person leaves this matrix didn't let us forget to remove their access. Or we could also just click on some server or system and get the comprehensive information about who was the administrator, which user accounts were present in the system etc. along with all the necessary technical IT information.
After a couple of years I started to see that we are limited only by our imagination and almost every wish could be granted inside a single-vendor environment.
This Community has also played a great role. It is a good place to get answers and share your experience. Usually when I'm stuck in a dead-end someone here always manages to help me.
I wish you the same.
Have a nice day!
Hi @Ben Munk ! Thank you.
I agree that this is the trickiest element here. People are inert and usually stick to something they're accustomed to. The thing that worked well is showing how their work can be improved through organising, visualisation, and wow-features. And not only their work as a single worker but rather as a team. We always tried to present just the result - the final process or feature, usually hiding how hard it could be for us to deliver them from technical or configurational point of view.
You know, after a while when people understood and accepted all the advantages they started to be proactive and suggested some improvements themselves. That was the feedback we were hoping for. This can only happen when one first sees how the system works, he then starts to ask "what about that?", "can we do this?", "will this work?" and more often with Atlassian products the answer is "yes".
To tell the truth, sometimes it requires superiors to "push" their workers a little towards using these new things but in the end everyone is happy.
I see how one can easily overload the processes and scare the employees away with all the unnecessary details or moves. Thats why it's important to first hear the needs, gather information, and only after that offer a balanced solution.
Summarising it all: gather information, hear your coworkers, get them involved, demonstrate the advantages, don't overload.
Hello all! What have you learned from your customers lately? Our live-streamed series continues by exploring CX, UX, and the power of research & insights at scale with Leisa Reichelt, Head of R...
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