It was also recognised that requirements are likely to change in the long term. There is no guarantee that the software vendor
will develop the package to fit newly emerging requirements and so the issues of tailoring and work-around will again have
to be considered. Most package selection takes place against current requirements and so this approach is well-suited to
circumstances where requirements rarely change and, if they do, they are specified by legislative bodies and the software
vendors must make the changes to keep their product compliant. Payroll and integrated accounts applications are typical of
this. Applications that are subject to long-term changes (such as the production process at Flexipipe) and do not require
legislative compliance, are less appropriate to this approach.
Absence of mature procurement process and management expertise
It was recognised from the outset that Flexipipe did not have an established process for software package selection and
implementation. This was a very risky project in which to try and establish a process and select an appropriate package. Lack
of procurement expertise in general has been a problem in the past for the company when a key supplier of raw materials
for the pipes went out of business. This caused short-term production problems, although an alternative supplier had
eventually been found. However, procurement still only employs two people full-time and they are relatively junior and overworked. The company appears to have a very immature procurement process.
The long-term commitment to an external supplier is very problematic in software supply, where moving formerly in-house
applications to a new supplier can be technically difficult, expensive and disruptive. In general, there are significant risks
associated with the long-term viability of software suppliers and the maintenance of software applications that are critical to
the company. Companies go out of business, as in the case study scenario, and companies are sold. It is feasible that a
software supplier might be bought by a competitor of Flexipipe, threatening long-term supply. These problems are largely
absent in bespoke development, particularly if this development is undertaken in-house. The software program code belongs
to the company (not the supplier) and its long-term development is under its control.
(b) In the context of the Flexipipe project, here are some of the issues that could have been addressed by a formal software
package evaluation process. It is important that candidates identify elements of the process relevant to the Flexipipe scenario.
A generic evaluation process is insufficient.
18The business case for all software procurement projects should be assessed to see if a package is an appropriate solution.
In some instances a bespoke IT development may be better suited. As mentioned in the answer to the first part of this
question, the Harmon grid considers process complexity and strategic importance and it could have been used as a guide to
assessing the appropriateness of the software package solution approach. If it had been used at Flexipipe then it seems likely
that the software package approach would have been abandoned at an early stage of the project.
The requirements must be carefully and comprehensively specified before embarking on a procurement exercise. Difficulties
with specifying requirements may again lead to a re-consideration of the bespoke approach. In the case study scenario,
mention is made of the system failing to fulfil a number of functional requirements, such as monitoring process variance. The
inference is that these requirements were either not specified or were incorrectly specified in advance and so were not part
of the package assessment. Similarly, problems with ‘usability’ may be due to the failure of defining specific usability
requirements in advance and so these were not considered when the package was evaluated.
The tendering method has to be made more formal and competitive. A post-project review has shown that there were at least
three other packages which should have been considered in the evaluation process. A more formal process would have had
a mechanism for finding these potential suppliers. The openness of the tendering process would also have been assisted by
advertising in trade magazines and internet tendering sites, which may have also brought forward other potential suppliers.
This is an important step because it allows a transparency in the process, and avoids selecting a supplier purely on the
recommendation of one internal employee: as in the case of Flexipipe. It would have avoided the situation of a package being
selected solely on the basis of a visit to an exhibition.
Suppliers who submit tenders must be evaluated against criteria agreed in advance. Buying a software package leads to a
long-term relationship between the supplier and the customer, so the latter must be comfortable with the supplier’s
credentials. In the context of Flexipipe this would involve setting standard measures and minimum values for liquidity, gearing
and profitability. There also has to be some way of off-setting the supplier’s suitability with the suitability of the product. That
is, how a package with limited functionality from a well-established, financially sound supplier is evaluated against a more
functional, usable package from a newly established company with high financial gearing and low turnover. The balance
between such factors has to be established in advance, often using a high-level weighted matrix. In the context of the
scenario, appropriate financial checks should have identified the high gearing and poor liquidity of the supplier that eventually
led to its collapse.
A proper process also needs to be in place to evaluate the potential solution against the specified requirements. It is
important to establish the ‘fit’ between the requirements and the potential solution and to use this ‘fit’ in the final selection.
It has been stated elsewhere that it is unlikely that a package solution will exactly fulfil all requirements. However, if the ‘fit’
is known and understood in advance then negotiation with users may lead to them dropping, modifying or finding workaround for these gaps. Perhaps some of the functional shortcomings identified by users might have been tolerated, if they had
been known and understood in advance.
Finally, a planned implementation is an important part of the process. Perhaps the lack of usability of the software was down
to the absence of training and the belief that users could ‘to pick up the software as they go along’. This is a risky approach,
even in circumstances even with experienced users and in a situation where the software product is a good fit with their
requirements.
