
16
Apr
Changing Software Part 2 – Choosing the right software
in General
Comments
In the last article (see “Changing Software – Do we really need to change?”) we considered the question: do we really need to change our software? Maybe it’s holding back our progress, the level of support is not what we expect, or perhaps there is an alternative that might be better suited to where we want our business to go in the future.
Assuming there are some doubts about what we already have is the best for the business, the next stage is to investigate alternatives.

Before starting however, it’s good to be aware of some of the more general potential pitfalls associated with a change in software provider (rather than, at this early stage, technical implementation risks), in order that precautions can be taken to minimise the risk of them happening.
1. Disruption to operations – it will be necessary to have both an extensive implementation plan and training program defined well in advance, ready to accommodate new ways of working
2. Existing (inefficient) ways of working continue – for example, if one of the benefits is to come from replacing spreadsheets, then users need to be on board with the changes from the outset – the easy option is for a disenchanted user to continue with what is most familiar
3. History gets lost or distorted – it is essential that all the valuable information accumulated in the old system is carried across in full, accurately to the new system
When looking at possible replacements for existing software, using the following methodical approach will assist in ensuring the best choice is made from what is currently available.

What does the new software need to do and what problems must it solve?
Essentially, this is a high level list statement of objectives and needs. The team using the current software will be best placed to describe what the replacement will need to do. They will not only be familiar with the workflows but also the pain points, especially those not addressed by the current software. In other words, importantly they can provide an insight into what improvements are needed, what they feel should be possible but is not provided by the current solution – the objective being to use any change to make significant improvements, not merely to maintain the status quo in a different form.
Prepare a detailed list of software requirements
Next needs to be drafted a Software Requirements Specification, along with an importance ranking to assist when filtering alternatives (essential, good to have etc). This is best done again in conjunction the team using the current software, but this time with just a few, maybe more experienced users.
• As before, but now in much more detail, the question to ask is what does the software need to do? In other words what functions does it need to have in order to satisfy the needs of all stakeholders (that includes the business as a whole, as well as the users)?
• Decide on the budget available, again helpful when later filtering out alternatives.
• Reporting requirements need to be specified: who needs what information, and when?
• Versatility – what future changes can be foreseen (growth, new markets etc) and therefore what support will be needed at a later stage? In conjunction with this, and because the market as well as the organisation is dynamic, a software provider will not only need to be capable of accommodating such changes but demonstrate a program of continuous development, based on a proven, detailed knowledge of their particular sector and its changing needs. A detailed investigation of the software provider will need to take place in the final stages of selection confirm this ability and to ensure that they will be around for the long-term, as a partner, rather than merely a third party supplier.
• Technology also needs to be defined, a simple example being whether the solution should be cloud-based or on-premise; Android, iOS or both.
• User preferences – as the current team will be using the new software, they need to feel comfortable with its replacement, without needing an excessive amount of re-training.
List the alternatives

Now comes the research. As well as online research it will be invaluable to make use of a team’s network of contacts. In the field in which CompassAir operates (maritime: chartering and SnP brokers, owners and managers), we know for example that brokers discuss with other brokers what tools they use, including the pros and cons of each. Additionally, newer team members will most probably have experience in using alternatives in their previous positions.
The objective is to first make as extensive a list as possible of the alternatives available along with their important characteristics, including pricing, suitability, etc. Regardless of whether it’s felt inclusion in the list is inappropriate or not, at this stage add everything possible, probably most conveniently managed in Excel – this long list will be shortened at the next stage.
Now take a couple of sweeps to end up with a shortlist of around half a dozen alternatives. The first sweep will be to eliminate those that are most obviously inappropriate, one example could be because a mobile app, regarded as essential, is not available. Do however make a note of the reason for exclusion on the spreadsheet – what is essential now may change over time as we look more closely into what is available. Having eliminated the obvious, now is the time to take that closer look in order to produce a short list of no more than five.
Shortlist: Trials and Demos
Having whittled down the list of contenders, revisit the list of requirements, the objective being to determine which are satisfied and which are not, and to what level. Demos are an efficient way to discover which requirements are met, and for the team, with as many as possible viewing each demo, to ask questions.
However only by actually using the software – which unfortunately is unavoidably time consuming if done properly – will it be possible to tell whether some particular needs are met or not, primarily ease of use (if the software has been used before by a member of the team, or has been recommended, then valuable time can be saved). For this reason a shortlist of 2 or no more than 3 alternatives would be advised.
A simple vendor evaluation matrix such as the following (populated with one’s own specific requirements) will make it easier to compare alternatives:
