The first part of any selection process is the realisation that a new system is needed. More often than not, this comes out of a growing dissatisfaction with the current system from the users and their managers, although other factors (such as support for old systems being withdrawn) sometimes come into play. In many firms, the next part of the process is to identify one or two market leaders and ask them in for a demonstration. This assessment will often also include ringing around friends in other firms and asking what they are using, and how well it works. Following this, a supplier is chosen and the system implemented.
While this approach can seem to be effective, it lacks any form of assessment as to whether the solution was suitable or not, and whether it delivered value to the business. It also fails to make any objective assessment of the available systems or comparisons between them. This matters because no firm has an unlimited budget or unlimited resources, and failing to get the best value has a knock on effect on other projects. To put this in context, a firm may put in a new back office system for, say, the marketing department. The project went well, and the system is running and appears to have delivered the required solution. What is not so apparent is that the overall cost of this solution was higher than it needed to be. More importantly that additional cost, both financial and in terms of resources, represents another project that was not achieved. The marketing director and indeed the partners may be pleased with the new system, but elsewhere the human resources department did not get the new training system they needed. Of course, this example assumes a successful project, but in many cases a poor selection method also leads to a poorly implemented system and unhappy users.
What has to be done to get a good system? A few simple steps will help ensure that the right system is chosen for the business, and that it can be demonstrated that it is the right system and is delivering value. Just as importantly, following these simple steps will significantly reduce the risks of the project and increase the chances of success.
Define the goals
There must be a reason for requiring a new piece of software, whether it is replacing an old one or performing some entirely new task. The latter case is very unusual now. Even where there is no single system currently used, a planned new application will normally be replacing a collection of smaller systems that have grown up over time to support the business in that area.
A clear definition of the goals in business terms should be able to be expressed in one or two paragraphs, and this can then be agreed and supported by senior management and other stakeholders. Ideally, some of the goals will be expressed in quantitative terms so that the results can be measured, using easily available figures that are not subject to interpretation. It is also useful if these figures are available from the current system to show the comparison and improvement. Examples might be staff entering 20% more items of data in a day, or taking half the time to process certain types of form.
Design the business processes
The second stage, before anything involving a computer is even looked at, is to define the work of the business that is being supported. This may be a simple case of looking at current processes, but the goals will usually imply that business processes must be changing as part of the new system. Terms such as ‘improve efficiency’ or ‘enable greater flexibility’ in the goals are all unachievable if business processes are left untouched.
Ideally, the new processes should be drawn out in a flowchart, or even better a ‘swimming lane’ style diagram, so everyone can see what is planned, and more importantly so everyone can look at their part of the work and highlight any problems with the proposed design.
Find some solutions
Selecting a shortlist of solutions can achieved in many ways. In many cases, the legal sector has clear market leaders for particular systems, and these should not be ignored. Similarly, asking other firms of similar size will help identify possible solutions. What should always be borne in mind is that other firms will have been solving different problems and have had different goals. The right solution for them may not be the right solution for another firm.
The most important system to consider as a solution is the one that is already in place. Just because some goals have been set and new ways of working have been defined does not mean that the existing system cannot handle them. If it can, and these changes achieve the goals that have been identified, then serious questions should be asked if this route is not chosen. Too many IT projects are driven by prestige rather than by the requirement; it may look good to have ‘implemented new x million pound software system’ but if the reality is ‘spent x million pounds unnecessarily’ then it was not a good business decision!
Choose a solution
From the systems that have been identified, it is possible to accurately compare how well they could support the business as defined by the processes already designed. This will involve not only looking at the process diagrams, but also in more detail at the supporting data that needs to be entered, stored and reported on to achieve these working practices.
It is certain that compromises will have to be made and that each possible solution would have to be implemented in a different way. It should be possible to identify which solution best fits the operation requirements. As a final step the cost of each system will need to be considered and compared against the requirements. Some small changes to processes may allow a particular system to be used and save a lot of money. Small changes required to use other systems may have too large an impact on what is trying to be achieved and the defined goals.
An important point to note is that features that are not required are of almost no value. One system may come with a whole set of extra features, but if these have not been identified as being of use, then they probably will be of no use.
Implement the system
Once a system has been chosen, it can be implemented. Having followed an organised method of selecting it in the first place, this should now be very simple. All too often it is only as the supplier’s consultants come in to talk about the implementation that firms start to think about how they want the system to work. This either leads to disappointment, as it becomes apparent that it cannot do what they require, or the business becomes entirely designed around the software.
Throughout the implementation, the original goals should be remembered, and the detailed business reasons for selecting this system. This should allow the new software to be implemented quickly and accurately, and meet everyone’s expectations when it goes live.
Measure success
The most important part of any project is to make sure that is has achieved what it set out to do. Once implementation is complete, the goals should be revisited, both by the people involved in the project and by the rest of the senior management, to ensure that they were achieved.
Both subjective business goals and the objective measurable targets should be looked at. Any failure to achieve them should be examined closely, and steps taken to rectify the problem. If the system was selected and implemented carefully based on the original aims and the designed business processes, there should not have been any problems at this stage. Indeed it should be possible to list additional benefits that have come out of the project over and above those identified before the project started.
A project that can be clearly defined as a success will benefit everyone involved in the decision-making process (as well as assisting the business by its successful implementation). The IT department, the manager responsible for the business processes being supported and the firm’s executive management will all have visibily demonstrated their ability to deliver.
Refine the solution
A typical situation in many organisations is that a new system is left untouched once it has been successfully implemented. A better approach is to look for continuous improvements. Each of these can be treated in the same way as the selection project but on a smaller scale and using the existing software. Simple goals for improvement can be defined, and then changes to business practices defined and implemented. As with the original project, it is important to make sure that these continuous improvement projects are assessed at the end to make sure they achieve what they set out to.
Eventually, after many cycles of improvement, the goals will get larger and it will become apparent that the business is no longer effectively supported by the current software, and the process becomes a system selection again. Note that choosing new software has now become part of a continuous process of improvement, rather than an isolated major project that drives change as a one-off exercise.
Summary
Selecting software is not a project in its own right. What should actually be happening is that software is being selected to support new or changed ways of working. For this to be done reliably, it is important to define in advance what you are trying to achieve, then make your changes, and finally check that you did achieve what you wanted.
Organisations that follow these basic principles will have the satisfaction of knowing that they made the right choice when they selected their new system, and also will have significantly reduced the risks involved in making the change.
Adam Westbrooke is the managing director of Firstcourt, a strategic IT solutions company specialising in helping professional services firms: 0870 350 3660 or see www.firstcourt.co.uk.
