Generally speaking, vendors develop packages for situations where they believe they can appeal to a large number of customers who all share broadly similar requirements. Typical examples are where legislation governs these requirements or where the requirements will remain fairly static e.g. Payroll Calculations, Council Tax payments etc. This means that public sector organisations such as Local Government and the NHS are typical package users.
Another area where packages have been deployed in both the public and private sector are the so called Enterprise Resource Planning (ERP) systems aimed to provide enterprise level support in areas such as Accounts/Financials, Electronic Procurement, Human Resources etc. These work on the basis that all organisations share common business processes. In all cases, the customer is expecting that the package can deliver the solution quicker, better and cheaper than the alternative bespoke design and build.
Where packages are not appropriate is if an organisation wishes to exploit IT to gain some kind of market advantage or where the system is a key differentiate in their line of business. For example, banks and other financial service organisations are always looking to provide new products that differentiate themselves from their competitors. In this case, packages would not be appropriate and a bespoke development would be more appropriate.
Organisations looking to implement packages must also be prepared for some level of compromise. Inevitably, the package will force an organisation to work in a particular way. This may require changes to the business processes within the organisation and these could be significant and far-reaching. For some, this will be an ideal opportunity to re-engineer those processes to gain efficiencies and other improvements. For others, this may not be desirable or even possible. If this is the case, an alternative approach is necessary.
Often, it is not possible to form an accurate judgement on package availability or the level of process changes required, until some way into the project. Therefore, it is essential that pre-judgements are avoided at too early a stage and time is allocated to revisit the business case and vision before committing to the project. This can only be achieved following a detailed product and supplier assessment, details of which are covered in our methodology.
Our methodology covers the entire lifecycle of the specification, procurement/selection and implementation of the COTS package. It also has the added benefit that it is compliant with the PRINCE2 methodology used by many organisations although can be used in isolation if necessary.