The 6 worst pitfalls of software rollouts
Any project launch can run into problems. Software is no different, but it obviously helps to plan ahead and try to pre-empt as many potential issues as possible. A responsible and experienced software team should be able to dodge the main issues well in advance. However, unexpected things do happen during the course of most projects. This article outlines some of the more obvious pitfalls to avoid and some of the things you can do to crawl out if you have already fallen into one.
- Manpower: too little, too late – or too much
We all know that it may take a woman nine months to make a baby, but nine women can’t make a baby in one month. However, unlike in the biology world, crafting software is a process where parts can be made separately and assembled into a new “baby” that will have a life of its own one day. Development speed can increase with the size of the team, but only to a certain level. If you bring in too many newcomers, this will steal resources for onboarding rather than actually solving problems. Of course, this dilemma also tends to grow as the project progresses and code complexity increases. You will eventually get to a point where simply throwing more human resources into the mix may not necessarily be the most efficient option. With good planning, you can ensure you have the right people in the right place at the right time. You can’t make up for a slow project by piling on resources at the end. Instead, get the sequential steps lined up right from the start.
- Not imagining life after deployment
Many organisations are so driven by the launch date that they fail to plan for what happens once the software is live. But without a structure for how to manage user adoption, future integrations and support, you may find that the software can’t be used efficiently. It can be extremely helpful to have “champions” of the new software. These are people who can help others get the most out of the solution. You will also want to anticipate the potential load on helpdesk staff and get a plan in place to offer support to users.
- Lopsided communications
The partnership between the developers and the client is very much a two-way street. Sometimes it may seem as if the two are speaking in different languages. Programmers understand code and development processes, while company managers are more familiar with the processes of business management. Companies are often very keen to provide input to a project at the start, with the expectation that there is nothing left for them to do after that. On the other hand, developers might have their heads down working on that code – and simply forget to update the client and reassure them that everything is going according to plan. A good development team should ensure that there are regular meetings to discuss prototypes, advise on progress (and problems) and keep getting continuous feedback from the client. This is where the developers must have enough flexibility to accommodate change. There may be a direct shift in business operations, or the client may have new suggestions for features as they start to better understand the possibilities of the system prototypes.
- The cost of training and the cost of no training
We all know the old cliché “If you think training is expensive – try ignorance”. We’re often perfectly familiar with our own processes, and it can be easy to assume that others will be able to intuitively know how to take advantage of new software. That may turn out to be an expensive assumption. We often see excellent systems that have simply not been fully exploited, because users haven’t been given enough time to familiarise themselves with the tools available to them. Surprisingly often, people revert to old routines or find complex workarounds – because they are simply not aware they can easily perform functions in a few clicks.
It is easy to believe that the software will magically solve all problems, but require no investment in time to learn and apply the new system features.
The best strategy here is to plan your training in advance and organise workshops and webinars to get staff excited about the new system. But not too far in advance – you want the information to be fresh in their mind!
- Who’s writing the documentation?
Coders write code, but they also need to write good documentation. This could be technical information for internal use, or it could take the form of user guides and help features. If the coders don’t document their work, the business should employ specialist writers to do it. A good software development partner will ensure that documentation is not only developed but that it is easy to understand by the client and is kept up to date.
- Failure to learn from failure
Every rollout will have its own challenges. Everyone can benefit from a post-project review to discuss and learn from what went wrong and what went well. An experienced software developer will already have been through many rollouts and accumulated a lot of wisdom in the process, but a client can also learn from the experience in preparation for future projects. Don’t leave everything until the very end, but plan out your project roadmap well in advance. Then you will be confident in your direction and reduce the potential for unexpected issues.