Software Adoption is More Important than Deployment

Businesses are adopting software at a faster rate than ever before. Many companies are adopting cloud/SaaS apps for things like Sales Force Automation or Cloud Cost Management at unprecedented rates. But just because you’ve implemented a new piece of software doesn’t mean everyone will use it. Even if that application can save time, improve processes, or help users be more productive, people are resistant to change. It pays dividends later to have a plan early to ensure adoption when seeking new software. 

“78% of mobile apps are abandoned after only a single use, and web applications and software don’t fare much better”

Doesn’t matter how fast you implement software if no one uses it 

This may sound obvious, but it’s an important point. So much time and effort are focused on going faster, sometimes we miss the point. Speed is great but racing to a finish line where no one uses it is simply a waste! Glad we got that out of the way. Now let’s look at some of the factors that make software adoption more important than deployment. 

Software adoption is a process of change — organizational & personal  

In order to achieve full adoption, it’s important to consider the entire organization that will be using it. For example, if you buy a self-service automation solution to serve infrastructure to engineering teams and they don’t use it, it doesn’t matter if it’s easier, faster, and more secure. 

When implementing any new system, there are many stakeholders who need to be involved in the decision-making process (and ideally will also feel ownership over its success). The trick is getting these various groups on board with the idea of adopting your new solution and making sure they know what they’ll need from it once it’s up and running. In the case of cloud operations management, you have an IT audience, an Engineering audience, a Finance audience, and often a Security audience. A successful project starts with pulling together key stakeholders and understanding their needs. 

Adoption starts when evaluating new software 

The best time to start talking about adoption is when you’re evaluating new software systems. 

The process of adopting a new product or system can be broken down into three phases: 

• Implementation – getting the technology up and running in your organization (hardware, software, integration) 
• Roll-out – training and communicating with users about how to use it once it’s ready  
• Adoption – making sure that users incorporate the technology into their daily workflow

Think early about use in a daily workflow. Do you use incentives? Do you get leaders to adopt 1st and “show” others the benefits? Do you use negative consequences? Understand your audience’s daily workflow and show how/where new software improves it with minimal effort. 

THE KEY – A comprehensive plan  

The plan needs to include key applicable parties. It’s not enough for your technology team to create or buy new software, but also for everyone involved in the project to understand how it will be used and how they will benefit. You can’t just develop or buy an amazing capability, then expect people within your organization to adopt it on their own; you need everyone at every level of your company on-board with your vision and mission before major changes are made. In my example above, this would include ITOps, DevOps, FinOps, SecOps. 

The best way I’ve found for achieving this is by creating an end-to-end strategy: one that includes all aspects of the project’s lifecycle – from initial requirements gathering through post-production maintenance – and making sure each applicable team understands how they fit into this process. This way if someone has questions about something they’re working on, they know who should help them out with particular issues because we’ve already discussed what needs to be done beforehand. It also ensures we don’t miss anything important when building out new processes or approaches because we’ve covered everything during the planning stage. Cannot stress enough how feeling like part of the answer early is a huge help for adoption later. 

Don’t get too caught up in demoing features or checking off list items 

Instead, focus on the user(s). Help them think about how this software is going to improve their lives and compare it to what they do today. You’ll find that users will be more engaged with your ‘product’ when they recognize its value early on. Show them why they need it. Show them what’s needed to get up and running. Speak in the language of your users. If they call something “Blue” when everyone else calls it “Red”, use their terms. And that’s when your team will have an easier time delivering something impactful!  

Using my example above, this could be showing the development team how much time you can save by automating delivery. Or could be showing the finance team you can tag, track, and accurately report on resource use to properly chargeback and plan. Or could be showing the security team how you can prevent bad behavior from ever happening in the first place. 

Think about users’ needs and goals first, then work backward 

We often talk about the importance of understanding user needs, goals, and business requirements before delivering software. But we don’t often talk about how important it is to understand your software architecture for the same reason: because it’s hard to iterate on a system without knowing what that system is going to do first. 

To make sure of an optimal design, there are several steps to follow: 

• Start by understanding the problem space.  
  • How big are your problems? (e.g. provisioning resources takes too long & difficult to track usage) 
  • Who are they affecting? (e.g. engineers, finance, IT) 
  • What is your goal with this project (expected outcome)? (e.g. reduce provision times by 50%+ & be able to showback 80%+) 
• Look at potential solutions to those problems and assess their pros and cons (the list could be long). Focus on what matters most to you, your users, and your situation (e.g. resources available-both human and technology). 
• Identifying key stakeholders within each department so we can ensure everyone understands how they will benefit from using this new product/service/tool/etc… (e.g. ITOps, DevOps, FinOps, SecOps) 

Conclusion 

If you’re planning a software rollout, chances are you’re thinking about adoption. That’s good! But remember that adoption is just one part of the process. To make sure everyone on your team is on board with your plans and prepared for change, you need to start by understanding their goals—and making sure they understand yours as well. Do this early, it will pay dividends later.

The post Software Adoption is More Important than Deployment appeared first on CloudBolt Software.