Let me paint you a picture…
You spend 18 months planning and building your new custom software system—a comprehensive web-based portal to manage your unique business processes.
It’s time to roll it out to your team. Exciting!
You get it into your team members’ hands…and they hate it. It’s confusing. The workflows aren’t quite the same. They don’t know where to find everything.
Your team goes back to doing things the old way, and the system sits on the proverbial shelf.
Nobody wants to be in that situation—but we’ve seen it happen.
For years, we’ve been refining our processes, doing more due diligence, talking to more users, and educating clients on the realities of custom software development. These things are certainly important, but the true success of a new system can
often depend on how it’s rolled out to the people expected to use it the most.
This guide walks through the most important steps to make your internal custom software rollout as smooth as possible. And while we focus on custom software used by an internal team, the principles still apply to new SaaS, off-the-shelf, and customer-facing
software platforms.
Start Thinking About Your Rollout Now
Grab the template that goes along with this guide and start planning your software rollout.
Before Development Begins
Before you get too far into planning your new custom system, and definitely before you start development, it’s important to gather the right information from the right people. These steps may happen during an analysis phase—or maybe even earlier.
Step 1: Know Your Users
Who will use the new platform? The accounting department? Marketing? Production workers? Customer service team members? All of them?
A successful software rollout depends on having the right people in mind before, during, and after development. Identify all the different types of users, what they’ll use the system for, and what they want and need to accomplish.
To put this information into a digestible format, first make a list of each user group that will interact with the software. From there, document the respective wants and needs of each group at a high level. Ideally, you’ll gather that information
through direct conversations with the users. Take that list and compile a list of high-level desired functionality, then prioritize the list.
Step 2: Get Buy-in
When it comes to implementing a new software platform or web application, you really have to sell it. You’ll want buy-in—if not a healthy dose of enthusiasm—from the user groups identified in step 1, as well as from any executive stakeholders, and, of
course, whoever controls the purse strings.
Ask yourself these questions from the perspective of each group you need buy-in from:
- Why is this new system being built?
- How will it help them specifically?
- What’s the impact of NOT implementing a new system?
- What do they need out of the system to see it as a success?
Each user and stakeholder group will likely need to hear slightly different messages as you go through development and launch. Make sure to talk about what the system will do for them, without overpromising. Will it cut down the amount of time they spend
balancing the books? Will it automate arduous tasks or make their work more efficient? All of the benefits need to be emphasized, but expectations also have to be managed by being open about any negative impacts (real or perceived) the change may
have. Let them know you realize change is hard, but you’re building the system to make their lives easier.
This process doesn’t have to involve talking to every single individual who will touch the system (unless the number of individuals is small). But you should talk to several of the people expected to use the system the most. The more user groups
you identify in step 1, the more people you should be talking to.
During Development
Development shouldn’t happen in a vacuum. Your user groups should be on your mind—and in the system—throughout the development process.
Step 3: Get Feedback
A core component of the scrum software development methodology is working
in an iterative fashion. This process has many benefits, one being that you can get future users into the system to try it out as it’s being built. Getting members of your user groups in the system during development helps identify potential
issues as early as possible—and it also builds goodwill and enthusiasm for the rollout. These results are not insignificant and they lead to a better, more efficient use of your budget, less rework, and a better-quality product overall.
There are different options for getting feedback from future users:
- Set them free in the system – You can give users a login and tell them to have at it. The feedback you get through this method will be sporadic and random—or you may not get any feedback at all. You can reign it in by
asking them to answer specific, pointed questions about their experience.
- Sit together or share screens – When you watch someone using a system for the first time, you can learn a lot—things you’d never get from written feedback. Watch the user try to complete their tasks and ask questions
about what they expected, what they liked, what they struggled with, and what they disliked.
- Provide specific tasks to complete – Depending on how much of the system is built out, you could ask a user to complete a certain task. For example, you could ask an accounting user to create, send, and file a new invoice. Ask
them about their experience. What was easy? What was hard? What was missing or confusing?
- Conduct formalized user research – When certain functionality is crucial to a system’s viability, structured user testing may be a good investment. You can still use your internal team as the users, but you would put more
rigor around documenting and having them complete tests that are repeatable, trackable, and standardized.
Regardless of the method you use, make sure it’s as easy as possible for your “guinea pigs” to share honest feedback. Set the expectation that not all their feedback will be implemented, but reiterate how incredibly important their input
is to making the system a success. After all, you can’t fix what you don’t know is wrong.
Step 4: Create Training and Documentation
A successful software rollout depends a lot on how quickly
your team can use the new system productively. Following the steps above will help ensure you develop intuitive, easy-to-use software, but you’ll likely want to provide some additional resources in the form of a knowledgebase, tutorials, and/or
help text. While you could wait until the end of the development process to develop these resources, we recommend building out these materials as development is happening.
There are two types of training and documentation:
- Process documentation
- Technical tutorials
Process documentation focuses on best practices and expectations for using a system. Without this infrastructure in place, the system could quickly become chaotic. Plan and communicate how your team should label, track, and document different activities
in the system.
To make the idea of process documentation more tangible, think of a CRM. If you just add 15 users to a CRM and tell them to start using it, they’ll use it 15 different ways even though they have access to the same functionality. They’ll tag
customers differently, use different pipelines, and keep the same information in different places. It quickly becomes chaotic and difficult to glean the full value from the system and its data.
Technical tutorials, on the other hand, focus on where information is in the system, how to use the different functionality, and essentially what buttons to click to get where you want to go. This type of training and documentation is often overlooked
because “the system is so intuitive,” but good training goes a long way in a software rollout.
As you’re creating training, tutorials, and documentation, make sure to have a system in place for team members to request or make changes to the documentation as they find things missing or system changes are made. You won’t get 100% coverage
on documentation the first time around—it’ll be a living, breathing resource.
Step 5: Set Up Usage Tracking and Analytics
You’re investing a lot in your system, so you want to make sure your team is using it properly (or using it at all!) and that you’re getting the expected value out of the system. Before the rollout, there are things you can set up to prepare
for your post-launch monitoring and evaluation.
A few things you may want to track—and this is by no means an exhaustive list—include:
- Which users are in the system the most (and the least)
- Which parts of the system are being used the most (and the least)
- How many times certain activities are triggered (i.e., create an invoice, open an order, etc.)
- What tasks are being done on desktop vs. mobile devices
To properly track this information from the beginning, you need to build in mechanisms for capturing the data and reporting on it during the development process. This may come in the form of an analytics plugin, automated usage reports, or a full-blown
custom dashboard. As with all things in custom software, it depends on your requirements, your budget, priorities, and, ultimately, what makes the most sense for you.
Rollout
Fast forward. The first version of your new custom software is ready to be rolled out to the team.
via GIPHY
Step 6: Rollout Plan
It would be great if you could just flip a switch and have everyone seamlessly using your new system. It’s not quite that easy, unfortunately, but a rollout plan makes it a more strategic, purposeful, and smooth process.
A rollout plan addresses the following questions:
- Will the system be rolled out to all user groups at the same time, or be staggered?
- If staggered, determine the order and ideal timing for each group.
- What training—in person or otherwise—does your team need to complete before using the system?
- Are there processes that will stay in legacy systems while more functionality is built out in the new system? If so, how does the team handle those?
- What is the retirement plan for the legacy system?
This list is certainly not exhaustive, and there will be questions specific to your situation and software that will need to be answered and planned for.
Step 7: Implementation
You’ve been preparing for this for months. It’s time.
You’ve planned. You’re ready. You got this.
As you officially roll out the new software, don’t be surprised when you get questions, run into unexpected barriers, and find a whole list of things you want to add or change in the system.
This is all perfectly normal. The key is to keep communication open. Talk to your team about what’s going well, what’s not, and what you expect from them and the system. And make sure communication is two-way so they can share their thoughts,
frustrations, and needs with you. And make sure you listen and acknowledge their feedback. Knowing that they’re being heard will go a long way toward helping them remain patient while any kinks are worked out.
Rollout Plan Template
Need help creating your rollout plan? Grab our template to get you started.
Step 8: Change Management
Change is hard. When you know that going into a rollout, you’re 10 steps ahead.
During the rollout process, refer back to all the work you’ve done to this point. Remind the team why you’re making the change, reassure them that the temporary discomfort they’re experiencing won’t last forever, and how the change
will ultimately be better than leaving things status quo.
Ongoing
Step 9: Monitor Usage
The implementation of the software should not be the end of it. Custom software, and the processes surrounding it, are (or should be) always evolving and changing. Set aside time after the initial launch to review the analytics you set up in step 5 and
investigate any unexpected trends or patterns.
Ongoing monitoring helps ensure longevity, smooth sailing, and a good ROI. You invested a lot into your custom software, and it’s important to continue nurturing it to maximize the value you gain in return. This is only possible with continual monitoring
and evaluation.
Step 10: Feedback
While monitoring usage is important, don’t rely solely on system analytics to tell you what’s working and what’s not. Ask your team—the people in the system every day. What’s working well? What’s not? What could be
improved?
Again, set the expectation that their feedback is incredibly valuable and will be prioritized against all the other work to be done. Some of their suggestions will get implemented, and some won’t, but you absolutely need them to keep sharing their
insights.
Depending on your organization and culture, you can gather feedback in several ways:
- Surveys – These are quick and easy, but often leave much to be desired in terms of getting comprehensive, clear feedback.
- Team Meetings – You can get members of the team and different user groups together to talk about the new system. You’ll likely experience some level of group-think, but the feedback will be more in-depth than surveys and
less time-consuming than one-on-one sessions.
- One-on-one Sessions – If you want the most robust feedback, take time to sit with users individually. Let them show you what they like and don’t like. Ask follow-up questions. Take copious notes. Though it’s more
time-consuming, this approach will likely garner the most honest, clear, and actionable feedback.
Step 11: Maintenance and Enhancements
Ongoing system maintenance is a must for software longevity.
As the initial development phase wraps up, you’ll end that process with a list of improvements you want to make in the system that didn’t make the priority cut. And then when you do the initial rollout, you’ll get an influx of feedback,
requests, and, yes, bugs. You’ll have to prioritize everything that comes in and make decisions about what and how much to fix, enhance, and build.
Planning a custom software rollout is a long process that, if done well, increases the value you get from your system. If a rollout isn’t carried out properly, it could lead to frustration, confusion, and not realizing the goals originally set out
for the project.
The system rollout should be considered throughout the entire system planning and development process, especially when it comes to custom software.
If you have a custom software project in mind or have questions about how to effectively launch your project, reach out and
let’s chat about it.
Get Your Guide
Need help creating your rollout plan? Grab our template to get you started.