Developing software is not easy. It takes a lot of time, money and effort. But it’s not only the development team where all the effort is focused. The effort also needs to be provided by you – the client or product manager. You can have the best and most technical solution developed but unless people use it, what’s the point?
You can’t build software using the “Field of Dreams” mentality: “If you build it, they will come”
Software needs to be more than just good software. Software needs to be marketed and used repeatedly by users to gain traction and survive. The following article lists several mistakes that can happen when releasing a software.
- Can’t find your champion?
- Getting your team on board – why should they be using it?
- Train your staff.
- Bad timing, bringing in a new system in the middle of a large project.
- You made it for another team but won’t use it for yourself.
Can’t Find Your Champion?
I’m not talking about your favorite character from a book, movie or TV show. Your software needs champions. It needs people who will promote and push the software throughout your organisation and initial users. These people take the software onboard and become the experts. They are there to help other users and explain how to use it, create workarounds for common issues and other things general users might not have known.
Most people generally attribute this type of user to a corporate organisation, but it also applies to start-ups and consumer software. These are the types of user who lives in forums or on social media and are actively promoting it for you. Community champions who will answer questions on your behalf and really believe in the software.
You need these initial users not only because they promote and help your brand exposure. They also come to your defense when needed and act as another line of support for other users. They are the ones who help get adoption past those initial early adopter users (who they normally are, also).
Getting your team on board – why should they be using it?
Most times, within an organisation, software is developed to improve an internal process. With that in mind, it is critical to get your staff on-board with the change, as they are the people who are directly affected by and involved with – the processes you are improving.
If you don’t get your team on board and behind the initiative early, you will constantly face pushback from them. Change is not the easiest thing for people to accept and when something has been done one way for a long time, it may be difficult to change it.
It requires a cultural change and getting your team involved early, allowing them to provide value and finding the “champions” who will drive the change within the team. If you don’t involve the team, you run the risk of creating the wrong thing altogether or at least facing an uphill battle to get the software rolled out and used within your team.
Train your staff.
It’s very rare to find software that can be looked at once and used to its potential. If you think about games, they start off slowly by making the first levels easy, introducing the rules and concepts within the game world.
Most software should be treated the same. If you can’t build in this concept through onboarding techniques, you need to focus on training. We’ve seen software be deployed then find it challenging to get uptake during the transition period, then when the cut-off time from the previous process happens it’s a mad dash to figure out what to do and what needs to change.
There are many ways to train people on the use of new software and a few different varieties should probably be used. People respond to information in different ways e.g. visually, text-based or audio.
Everyone learns differently.
Whether you create user manuals, training videos or hold training sessions you should be encouraged to allow users to play with the system as they are reading or watching their training material. The best way to train and learn how to use something is to provide an environment of encouragement. Have the resources that people need to learn about the software and let them use it at the same time. Just a presentation on its own won’t get you very far.
Bad timing, bringing in a new system in the middle of a large project.
Imagine that you’re in the middle of one of the largest projects you’ve ever worked on. You’re about halfway through and are on-time so far with your deadlines. In the background, someone in your organisation has created a new system to digitise your processes and you will be switching to it on this project.
You hadn’t factored this into the deadline and now on top of managing the project and keeping it progressing, you have to bring a new system online, get it working with the project and hope nothing goes wrong.
This is the reason why you don’t change processes on large running projects, they can affect too much and cause plenty of disruption. They can bring efficiencies which can be lost in the training time, disruption and new risks introduced.
You need to use a phase approach and bring things into projects slowly. The best way is to bring them onto projects that haven’t started. This will allow old projects to operate as is using the old methodologies and the new ones to shift to the new software. This problem gets exponentially worse if the software hasn’t been made properly or isn’t solving the right problems. If you haven’t addressed the above points, then it can go sideways for a variety of other reasons.
You made it for another team but won’t use it for yourself.
Another key mistake that people frequently make is they are building software for their team or the people under them (within the organisational hierarchy) but they will not be using it themselves. This ends up with a problem because you don’t understand all the operational complexity or day-to-day process that your staff are following, or you fail to get them involved in the process.
Even if you do understand the processes, there are the little nuances or hacks that your staff do to do their job. Without knowing what these are or how they do things you can end up creating the wrong requirements and developing software that solves the wrong problem. In some cases, it can even cause extra work for them.
It is critical that the people who will use the system will be involved in its design and can share their requirements. Without this step you risk the chance of building the wrong thing, that serves the wrong people and wastes time and money. This ends up being a story we’ve all heard before: “we built great software, but no one used it”.
Developing a software is not easy, but neither is deploying it and ensuring uptake. If you’re developing a new product or a B2C app, you will face different challenges, but the same outcome can happen, no one ends up using it. It is important to remember to include stakeholders early in the process, find your champions and make sure you are developing software that solves the right problem.
