COTS Methodology

October 20th, 2008   •   no comments   

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. 

read more

Why COTS Projects Fail

October 20th, 2008   •   no comments   

Package based implementations fail just as often as other projects e.g. projects that overrun, are over budget or fail to deliver what the users expected or wanted. Analysis carried out by Templar Consulting has shown that there are common reasons for project failure. These include:


  • Requirements and expectations not adequately defined or communicated amongst the relevant parties
  • Unwillingness to compromise on the part of the business – especially in methods of working or businesses processes
  • Business case incomplete – activities and costs overlooked
  • Flawed selection and procurement processes – failure to reach understanding on key areas such as:
    • What the product will and will not provide
    • How gaps will be addressed, by whom and at what cost
    • How customisation will be achieved and by whom?
    • Impact to working practices and what steps are required to implement changes
  • What services the supplier will provide and what expectations they have on the client that might affect their ability to deliver
  • Poor contract and supplier management
  • Lack of relevant client-side project management experience
  • Lack of project and cost controls
  • Failure to implement Business Process Changes
  • Problems with data quality and data conversion
  • Lack of involvement by the key sponsors and users


The above problem areas span the whole project lifecycle. Indeed, it is vital that the project is properly set up from the very start and controls put in place to deal with these issues. 

read more

COTS Implementation

October 17th, 2008   •   no comments   

On the face of it, especially to the uninitiated, package based projects appear easier than the in house development approach and they can be. However, package based projects present their own difficulties (see reasons for failure) and challenges. Unless steps are taken from the outset to understand these and to put plans in place, problems will inevitably arise that could have been easily avoided if dealt with early on. Some of these problems can be exspensive in terms of cost, time and performance.

Our methodology is designed to prepare the organisation for the difficulties and challenges faced during the implementation process. The methodology addresses the following areas as well as providing document templates which can be used on their own or with PRINCE2.


  • Getting the Project Authorised and Managing Boundaries
  • Assembling the Team and Defining Roles and Responsibilities
  • Managing the Suppliers and the Contracts
  • Agreeing the Vision, Goals and Objectives
  • Reporting and Control Processes
  • Developing a Communications Strategy
  • Understanding the Product/ Package
  • Analysing and Redesigning Business Processes
  • Platform and Network Sizing
  • Systems Integration Requirements
  • Data Mapping, Cleansing and Migration
  • Security, Business Continuity and Administrator Considerations
  • Reporting Requirements
  • Testing and Acceptance Specifications
  • Selecting a Suitable Cut-Over Approach
  • Testing – System, Application, Integration, Acceptance


read more

COTS Selection and Procurement

October 17th, 2008   •   no comments   

It is recommended that the selection, procurement and implementation processes are addressed as separate projects. They are different in nature, require different skills and follow a specific order. The implementation project cannot be defined anyway until the outcome from the selection and procurement processes are completed.

Selecting a COTS package requires a lot of time and effort and there is no real way of getting around this. In fact, within the public sector, certain processes must be followed and this in itself can be onerous. However, unless due process is followed, the results can be catastrophic. Therefore, it is important that a strategy is adopted for dealing with selection and it is usual in these circumstances to use the services of an outside consultant with experience in managing these projects.

The procurement process is often seen as part of the selection process. However, we would offer a word of caution over this approach since this can lead to a blurring of the processes which in turn can result in compromise, especially during negotiation and the definition of supplier commitments.

Part of the procurement process is to agree details of costs, payment schedules, service descriptions and other supplier commitments. This information will be used in order to revise the estimates for the whole project and revisit the business case. These must be completed prior to signing contracts and authorising the implementation project.

The management of the boundaries between the selection and implementation projects is therefore of key importance. It will ensure that the implementation project will not commence until the following are agreed:


  • contracts and legal issues
  • costs – hardware, software, internal, external services
  • product and service descriptions
  • customisation required and other developments e.g. integration, data cleansing and migration
  • roles and responsibilities
  • timescales
  • payment schedules, trigger points, penalties and bonuses 



read more

COTS Overview

October 17th, 2008   •   no comments   

Many organisations have adopted a strategy to implement packaged applications in place of the traditional bespoke systems that were prevalent up until the 1990s. This is partly to do with the lower cost platforms that have emerged to compete with the mainframe but also because the choice of packages has increased. The impact is being felt in those organisations that have legacy systems to replace as well as organisations with no prior systems.

Some of the drivers for choosing packages over other options are seen as:

  • lower cost of ownership (implementation and ongoing costs)
  •  tried and tested (low risk)
  •  quicker to implement
  •  the benefit of a mature product from day one

Although the benefits of the packaged approach are fairly clear and relatively simple to quantify, achieving them requires effective project management from the client side. The supplier will have their project manager to look after their activities but the client organisation, and specifically the business department (not IT) must be responsible for the success of the project as a whole. For example, they must be responsible for:

  • managing resources (Technical, Business and Suppliers)
  • managing organisational change including business process re-engineering
  • managing the budget
  • reporting progress
  • specifying and running tests for acceptance
  •  working with IT to provide the appropriate IT environment

Unlike software development projects, the IT department cannot provide the same level of support and involvement in a packaged application as they are no longer the system experts. They will have specific responsibilities but overall project ownership and project management is usually not one of them. These projects therefore present new challenges to the business. How they deal with these challenges will ultimately mean the difference between success and failure. Templar Consulting have developed a methodology or blue print for dealing with the specific issues of package based projects and this is available as part of our package implementation services. It can be used on its own or with PRINCE2.

read more