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
During the last few weeks in California, we had the High School Graduation season, and that reminded me that I still have to complete the second part of the article Hurdling while adopting Atlassian (Hurdles 1 to 6), with the hope that we can all achieve the Atlassian adoption phase to become an Atlassian Mentor.
In this article (Part 2), I will share more hurdles that I had to overcome while we adopted and configured our Atlassian Platform.
During the initial rollout of the tools we added substantial consideration to the training aspect, as in any software implementation, we know that well-trained users will set a solid foundation for the adoption of the product. For instance, in healthcare software implementation, the total cost of ownership could be impacted with a 60% to 70% of the effort dedicated to users' training (depending on the training approach adopted). Unlike the initial attempt, continuous education doesn't keep the same relevance, and a regular mistake is to lower it close to 0% with the assumption that users already had the training needed and that they could mentor others. However, I still have some questions about it, How about team changes, upgrades, or onboarding new team members?.
Set… Go. A continuous education program needs to be in place and continuously upgraded to keep pace with changes in processes, features, and overall platform. To accomplish our goal, we tried small pieces of training; basically, microlearning units of 2 to 3 minutes focus just on the changes and provided regular refresh training as well as keeping the inner circle of champions up to date so they can mentor other users. Besides, we created a Training Task Force with representation from all the areas using the products. Members of that group have early access to new features to measure the impact on their teams and participate in monthly workshops to develop content for their area.
All Atlassian products had evolved for years, and functionalities are added or changed in every new version released. The number of features bundled with the products could be overwhelming for the users if we don't dose them according to their role and daily responsibilities.
Set… Go. We need to help with the learning path, identifying the "have to know asap" against what could be learned later one, the "nice to have" features. On this article about basics with Confluence, I created the group with the basics items that should be considered during the first steps using the product.
We all know that getting to know the basics of any discipline, subject or software could help us to quickly move forward, enough to get to a level of a comfort zone that would guarantee a pleasant and smooth ride. The challenge is in how you can motivate your team or trainees to break out of their comfort zone without any fear.
Set… Go. Making a compelling argument won't be enough, what I tried was to at least show the outcome and best practices of other users that made an effort by featuring their job and case studies. However, to remove the fear of causing any issue to the organization by making a mistake, I encouraged our team to provide a sandbox platform, where users can practice in a safe environment.
There are multiple situations when we implement a Confluence app that creates reports or uses external resources affecting the overall performance of the platform, Unfortunately, those scenarios are not easy to identify during testing as the usage is limited, and in general escalation impact is coming after a while, when more users are applying the related macros.
Set… Go. Troubleshooting this is overwhelming, but necessary, and by isolating them, you can get an idea of which one is impacting the system. To be prepared for this, you need to have comprehensive apps testing scripts, monitor the usage, and establish a workaround just in case it needs to be disabled. Having access to power users is a plus as they can assist with the troubleshooting effort.
Having a good onboarding training plan is critical to keep your platform up and running without interruptions. However, we need to keep this training plan updated and in synch with the reality of the teams using the implemented platform.
Set… Go. New members should be trained based on the expected behavior, but at the same time, they need to be aware of real-world discrepancies to avoid frustration or the feeling that they were misled. They need to understand what is expected and encourage them to reach the highest level possible mastering the collaboration tools provided. Have your pool of mentors identified so they can assist new users beyond initial training; ideally, the pool should contain mentors from all teams and discipline.
As mentors we dream with a clean learning path for new users. Unfortunately, due to the learning curve and individuals background we know that we have to be close to them providing the best guidance available and sharing lessons learned.
Reducing the number of emails is the main goal for many collaboration tools implementations, but it will be achievable only if the team could work entirely inside the platform using boards, dashboards, or task tray. Unfortunately, the email communication is part of our daily activities, and the tools could be very chatty some times, as a consequence, emails are ignored or sent to a folder that is never open. I call emails the "silos generator."
Set… Go. The first thing I recommended for both Confluence and Jira was to reduce the notifications to the minimum. The first action in our Confluence training is to edit users profile and email settings. Also, we created a dummy space without any activity, so they can select it when they access Confluence for the first time and are asked to follow one area. Unlike Confluence, Jira the user doesn't have the luxury of editing their own profile email settings, and they are affected by the type of project notification scheme associated with their projects. To mitigate it, we provided to our team two standards notification scheme being one of them a light one, with just essential announcements. To complement their project awareness, we encourage them to use personal dashboards and filter with subscriptions
We previously discussed that, to increase the Return On Investment, we could add new apps to our instance. We are probably adding just one app, but in fact, you are adding a lot of new features based in macros (in the case of Confluence) where the 1 to 1 relationship is rarely happening, on the contrary, one app could mean a good number of new macros added into the macro browser.
Set… Go. Do not underestimate this impact and be sure you include them on the app training so the users can be aware of it and explore most of the new features available. Be ready for the new features tsunami by getting familiar with all the functionalities added, especially new macros in Confluence.
These two characteristics of a collaboration platform are part of the team empowerment, they need to get used to being open to knowledge sharing. If allowed, by security restrictions or clearance, the content should be accessible by all team members. What better way to learn than seeing how other teams are doing a great job, using the right templates, issue types, or workflows.
Set… Go. Feature best practices, invite those champions to share their tips and tricks and engage your team to learn from colleagues. Generate a featured article registry and promote it with blog posts. Use another communication mechanism as newsletters, posters, etc. to encourage short webinars sharing good ideas and use of the tools. Being open will allow other team members to access to the promoted areas.
On my previous article about Marketplace apps selection, I emphasized that it is crucial to address the business needs of your teams so you can provide the tools to bolster their effectiveness and performance.
Set… Go. Set a system to capture the Voice of the User and evaluate their feedback. If someone requests an App, help them to build a solid business case so your Atlassian team could determine if alternative solutions exist to avoid spending the money in more apps. Set an Atlassian Steering Committee (read Rachel Wright books about good governance ideas) to assist on the evaluation and prioritization.
Managing multiple teams, numerous projects in Jira or spaces in Confluence could be a challenge when one of the team request help to address, promptly, a new business need, or a problem with the platform.
Set… Go. Define and communicate clear parameters to be considered under these circumstances. By having clear ground rules, users will know what to expect and when to expect it. It is our responsibility to honor those rules, so our reputation and trust are maintained. A registry of requests could assist as in any project, setting priorities, building a backlog to be groomed, etc. The methodology and timing have to be consistent and effective, in some cases will require to hire more team members or change parameters that we will be able to maintain.
I mentioned the importance of acquiring skills to do your job, and as you grow, you will gain access to the environment, eventually, if your career permits, it will include admin knowledge. This expertise could be a hurdle if you don't have the right permission on the platform. It will remind you of how vital "yoga" is. Believe me, you will need to manage your breathing, close your eyes, and ask for patience. You know what can be made, but unfortunately, you don't have the right permission to do it based on your current role.
Set… Go. Nothing to do with permission. So, the only element you can manage is to share that wisdom to those that have the right permission by addressing them on the requirements and proposed solution explanation. As an admin (without permission, but with enough knowledge), you will know how to present the information that facilitates the completion of the request. As an example, with a custom Jira workflow, you will be able to build a clear diagram, a Statuses and Transitions table, define post functions, screens, notifications, etc.
This one is coming from a comment in one post, what happens when you need to train a person that will be your backup or eventually your replacement. Answering this is not easy as it is related to job security or co-administration of the platform.
Set… Go. As in any other position, set the basic knowledge that the person should have to obtain admin access, prepare a comprehensive role-based training, and be cautious for the Admin role is essential. Establish the level of access and responsibilities based on their knowledge acquisition progress, keep in mind that admin permission opens doors that allow the execution of tasks or changes in the configuration that will impact the whole platform.
The definition of an assumption is:
"a thing that is accepted as true or as certain to happen, without proof."
Assumptions are common in any project, but they need to be associated to a risk.
I heard once the story of a multinational company that won a contract to implement a government administrative computer system for a whole country. The multi-million deal was appealing, and in the well-prepared agreement, there was a clause that specified that all the users (thousands) will be trained in how to use the system. Perfect, not visible risk. However, when the implementation team tried to roll out the order they found an unexpected issue, most of the users were "computer illiterate" and to fulfill the contract the company will need to provide first necessary computer skills training to proceed with the application training.
What it failed there was to specify the assumption that the users "should have, at minimum, basic computer skills" and establish an evaluation system to measure that. Identifying and managing assumptions is one of the keys to succeed in any Atlassian Implementation.
Set… Go. Don't assume that all the users will get pre-required online training before going to classroom training. Learned the hard way, while we provided almost 10 waves of training, we asked the trainees to focus on the online application training before attending the classroom training. We didn't enforce it, we just recommended. It was clear on the day of the training that not all of the attendees followed the advice, and our assumption was wrong. We didn't implement any evaluation before providing the classroom training. Be sure you document the assumptions, identify the risks, and properly communicate them to stakeholders, including those that are the recipient of any decision.
Well, there is no end for this "race," and hurdles will be in front of us all the time. It is really up to you if you can move from adopter to a mentor, helping with other people's hurdles removal with the primary goal of providing a clean "track or field" for them. However, you are not alone in this challenge.
Set...Go. My recommendation is to work with the Community, if you are not finding a response on the documentation or another real answer in community.atlassian.com, post your own question. In that case, be sure that you accept the right solution and, if asked, provide more information to clearly express your problem. Be respectful of other community members' time and their help narrowing and solving your issue, share in the same question how you did it and what piece of advice you applied. Many users will probably need to address a similar situation in the future.
As we acquire knowledge we will have the chance to remove hurdles for other users. However, while we do it, we need to be sure we are not adding new ones in their learning paths.
I am sure the list could go forever if we all join our experiences. I hope some of the hurdles overcoming ideas I shared will trigger some solutions for the problems you face and I would like to invite you to share your own hurdles as comments as well as the strategy to overcome them. Other community members like you could benefit from those challenges.
As soon as we understand that success is a team effort, we will more than eager to mentor our colleagues so the team performance is improved towards our goals.
Fabian A_ Lopez _Community Leader - Argentina_ Florida_ California_Community Leader