Top 5 things to consider before and during your migration

#1 Involve Your Employees

This isn’t just some tool your company’s employees use. It’s something they’ve invested countless hours learning and using on a daily basis. If an employee feels they can get something out of it that they personally care about they will engage.  And when you garner employee support and generate interest from Day 1, you’re more likely to be successful.  How can you find out?

 Conduct a Short Survey

Collecting valuable information from users saves time and money. What works. What doesn’t. What they like. What they don’t like.  Wouldn’t it be great if we could get rid of an add-on we never used or switch to another add-on we would use and get more productive?  On the other hand, what if the company decided to remove an add-on that everyone likes but didn’t know because they never asked. 

Sample multiple-choice questions for each add-on could include:

Usage: 

• Use it Every Day
• Use it Most Days
• Use it Occasionally
• Don’t use it At All
• Never Heard of It

Popularity:

• I Love It
• I Like It
• I’ll Take it or Leave It
• I’d use something else if I could
• I Absolutely Hate It

Real Customer Story:

In preparation for multiple upgrades and migration from Server to Cloud we sent all the employees a survey listing all of their current add-ons.

After the first batch of surveys came in we found that most hadn’t completed the “Frequency of Use” question. We later found out that they didn’t answer because they’d never heard of the add-on. We altered the survey to include “Never Heard of It” and in the process found that we could eliminate about 25% of the add-ons nobody used, saving the Company thousands of dollars.

In the end, the “never heard of”, redundant add-on had been requested and installed by one small team who preferred it over another almost identical tool they were already paying for.

#2 – Improve the Tools

After gaining employee buy-in, now it’s time to evaluate the feedback then determine exactly what changes will be effective.  Buying an add-on or adding a feature to your Atlassian suite before identifying it is actually needed often leads to waste.  Here are a few tips to avoid these pitfalls.

 Identify the Problem

Establish your requirements first. Then search for add-ons that meet those requirements. All tools and their add-ons or enhancements should be directly tied back to a problem you’re trying to solve.

It is important to include budget requirements. Budgeting for all this can be arguably a “problem” all by itself. It is for the CFO. You may be happily surprised by some of the reasons one add-on is preferred over another.

Needs vs Wants

Establishing expectations with a little guidance, of wants versus needs, helps focus your employees to prioritize their wish lists ahead of time. If it helps, widen the criteria to help further define the difference between want and need. In short, ask employees to use a ranking system that incorporates purpose or functionality as well as user applicability.

Get Consensus

When two individuals or two groups want two very similarly functioning add-ons, require the teams work together to find common ground and pick the one. Find common ground to pick the one that will work for them both.

IIf the teams can’t find consensus, tell them neither tool will be purchased. Typically, the teams will compromise with one team choosing add-on “A” and the other team choosing add-on “B”.” to “Until the teams can find consensus, neither tool will be purchased.”

#3 – Improve the Process

When’s the best time to change a policy or procedure? Typical answer: Usually never. But there are more ideal times than others. Use this opportunity to take a good long look at what and why you’re doing what you’re doing. New tools often incorporate new methodologies and that might mean adjusting your company’s procedures. If they exist at all.

Problem #1 – A standard operating procedure doesn’t exist, so the tools dictate the process.
Most common in new companies where a tool is implemented without policy to give guidance on how or even why it needs to be done this way. Beware of tools driving the workflow. Your company should come up with a workflow that makes sense for it and then adapts the software to match. Not the other way around.

Problem #2 – Because that’s the way it’s always been done.
Sometimes we come across a company who has an antiquated procedure based on an old or previous tool, and now they’re trying to force this process on a new tool. It’s okay to ask why we’re doing the steps we’re doing when they don’t seem to make sense or have a purpose.

#4 – Standardize Your Projects

This one’s easy but still requires a LOT of employee consensus.  The preferred evolution of a company adopting and implementing Agile eventually includes Program and Portfolio management.  After all, leadership needs a vehicle to convey direction from the top down and teams need a way to report progress and data up.  The largest obstacle to this big evolutionary step is standardizing how similar teams should work and report.  Ideally, all developers should only be required to learn one process, no matter what project they’re working on. All QA/Testers, all UX Designers, etc.

#5 – Empower Your Employees

Simplify your Projects.

Most employees already know how to do their jobs and know the fastest way to perform that job.  So- don’t put constraints on your people with an overly rigid process and tools that think for them. In the end you’ll never foresee every possible permutation anyway so don’t even try.  Instead put delivery requirements & acceptance criteria on your employee’s work product.  Then you can leave the “efficiency” solving to your empowered employees.  They’ll always find the easiest route to the finish line.

Reduce number of workflow statuses. 

The most common mistake seen is creating extra statuses that don’t serve a purpose for transitioning to a new status.  Unless the task is being handed off to a different person in the next status, or the purpose of transitioning isn’t to check a workflow condition or perform a post-function, the employee should know what the next step is they need to perform.

Generalize Statuses

Specific is rigid, vague is flexible. Describe the steps generically, let employees decide what to do within the steps.  After all they know when they’re working on it, “In Progress”, and when they’re actually finished, “Done”. Capturing all of the individual work steps when it adds no value to reporting or efficiency for the worker is simply micromanaging.