Launching new products and services is a complex process, and even when businesses think that they have considered everything, any project launch can run into problems. With so many companies now hinging their new offerings on having exceptional digital resources, the demands on software are growing.

Higher expectations means higher complication potential, and just like any other element is susceptible to pitfalls, software is no different. Unexpected problems are to be expected, so there’s no need to make mountains out of molehills.

Manpower: too little, too late – or too much

Development speed can increase with the size of the team, but only to a certain level. If too many newcomers are brought in, this will steal resources for on-boarding rather than actually solving problems. As the project progresses and code complexity increases, this dilemma can grow. Eventually it can get to a point where throwing more human resources into the mix may not necessarily be the most efficient option. Good planning can ensure the right people are in the right place at the right time. A slow project can’t be rectified by merely piling on resources at the end. Instead, get the sequential steps lined up right from the start.

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.

Writing the rules

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.

Planning for 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, 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. The potential load on helpdesk staff should be anticipated and a plan should be put in place to offer support to users.

The costs of incorrect training

It can be easy to assume that others will be able to intuitively know how to take advantage of new software. But that may turn out to be an expensive assumption. Too regularly the excellent systems designed aren’t 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 work-arounds – because they are simply not aware they can easily perform functions in a few clicks.
The best strategy here is to plan training in advance, and organise workshops and webinars to get staff excited about the new system. But not too far in advance –the information needs to be fresh in their mind!

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 the project roadmap well in advance. This will instil confidence and reduce the potential for unexpected issues.

Conclusion

No project is plain sailing, but when it comes to software it’s possible to reduce the bumps in the road.

Setting out each step and its requirements from the beginning will help to assess just how many people will be needed on a project and when. Once the team is settled, efficient and open communication between a business and its developers is the backbone of a project; it’s this that will allow continuous, positive progress. Documentation should be considered throughout the design process so that clear and complete guides can be created to ease any implementation difficulties.

Once the software has been created staff should receive training within good time and knowledgeable ‘champions’ should be appointed, additionally support needs to be in place for any helpdesk staff. Finally, it’s important that the project is reviewed, so everyone can assess the successes and failures and build upon them in the future.

Nick Thompson is the managing director of DCSL Software.