How to Specify and Select Packaged Business Software

MML's approach to developing a design specification is set out diagrammatically below.

It has been developed through more than two decades' practical experience of specifying, selecting and implementing packaged software. It has been shown to reduce the cost and time taken to make the selection and to minimise the risks involved. It is designed to:

• develop a consensus among the management team about the requirements that a new system must meet;
• define requirements that directly support business objectives such as:
  • reducing operating costs;
  • improving customer service;
  • reducing working capital requirements;
  • supporting growth without the need for commensurate increases in headcount or space;

• select a good combination of software functionality, vendor capabilities and technical platform;
• establish a contract that provides the purchaser with adequate protection in technical and commercial as well as legal terms;
• provide the capability to support on-going improvement of the business.

The emergence of large software packages that claim to be “all things to all businesses” has led many companies to take short cuts in system selection. Even today, no one package offers all of the capabilities necessary for every business. Also, in general, the broader the capabilities of a package, the more time, effort and cost it will take to implement and the higher will be the on-going operating costs.

It is vital, therefore, to strike the right balance for each individual business between functionality that supports real business needs and the cost and effort of implementation and on-going operation. Our strong belief in the need to follow a rigorous, structured selection process is built upon our experience of helping several companies to recover from the consequences of taking short cuts.

The basic structure of a sound selection process has been well established for many years:

• specify the needs of the business;
• find packages that support those needs at acceptable cost;
• select, from among these, a package where the vendor can provide the range of supporting services that the business needs.

Ideally, the choice of technical platform would be a function of the chosen vendor. In practice, most companies have a heavy investment in their existing infrastructure and skills, and making good use of these is a significant business need.

The above, traditional structure pre-supposes that the management team have a clear picture of the needs of their business. We find in practice that there are often conflicting views and sometimes a good deal of uncertainty about what those needs really are.

To address this problem, it is essential to view the information system as a support tool and not an end in itself. Taking this approach, we have developed a process for defining a Statement of Requirements that is built upon developing an understanding of the business processes through which the new software will deliver measurable benefits.

A particular advantage of this approach is that by building understanding, we build consensus about the system capabilities necessary to support these processes. Just as importantly, by focusing on the business objectives and the processes that will deliver them, a statement of requirements can be produced quickly and with greater confidence.

The following sections briefly describe the key elements.

Successful software selection begins with a good understanding of:

• the existing business and how it works;
• alternative techniques and approaches to running the business that might be used to improve performance, particularly those that are seen as “best practice”;
• the capabilities of available software packages and how those can support the different possible approaches to improvement.

Most companies know, collectively, how they work. However, that knowledge may be scattered among many people, much of it may not be recorded and some people may have serious misunderstandings about how the actual processes, as opposed to the official ones, really function. It is often necessary, therefore, to map existing processes to gain an in-depth understanding of how they really work and of their strengths and weaknesses. This also helps to identify critical business-specific requirements that might otherwise easily be missed.

We have developed a fast, effective, easily taught approach to process mapping that can be applied by your own staff. This is described in our document “How To Produce Usable Business Process Maps”, which also covers the detailed design of new business processes.

It can be hard for the management of a company to keep pace with the many new developments in business processes and in tools and techniques for performance improvement. It is even harder to develop and maintain knowledge of the software market and to separate to real capabilities from hype. This is an area where consultants with practical experience of working with new techniques and modern software can provide valuable input.

When selecting software it is vital to arrive at a clear, concrete answer to a fundamental question - ”Why are we doing this?“.

Implementing a new package of any size is a major investment. If the business is to obtain a satisfactory return on that investment the top management team need to develop a measurable definition of the benefits the system will enable them to deliver, for example:

• increased profits;
• reduced capital requirements;
• growth.

Management also need a clearly understood, explainable, series of steps that will show how, once implemented, the system will deliver these results. Without this they cannot be confident that the investment will be worthwhile. Worse still, the priorities for the whole project will be unclear, leading to conflict and wasted effort during selection and implementation.

MML has developed a structured, effective approach to defining business objectives and building a high-level process model that overcomes these problems. It is described our document “How To Develop A Specification for Designing a New Process”.

This key, creative step is often left until after the software has been chosen. Such an approach restricts the opportunities to improve business performance that are offered by the implementation of a new system. Further, without a process design it is difficult, if not impossible, to be clear about what capabilities are needed.

Designing processes before selecting software offers many advantages, for example:

• it encourages staff to think constructively about the way they work and how they will go about delivering the business objectives defined in the design brief;
• there are no limits to prevent the business from exploring novel, “outside the box” solutions that may have the potential to deliver order-of-magnitude improvements. Whilst an industry-standard solution may often seem the obvious choice, you do not become a leader by following the pack;
• the task of business process design, if carried out correctly, builds consensus about how the business will work in the future and makes clear the mechanisms through which pay-back will be delivered. This makes it much easier to identify essential software functionality and separate it from “nice to have” features. It also enrols staff in the project;
• it provides a solid foundation for developing a statement of requirements and for evaluating packages through demonstrations and reference visits - without a clearly defined set of “to be” processes it is impossible to define system performance requirements with any confidence, something that is essential if the contract for the system is to give the purchaser adequate protection;
• it reduces the time between making a major capital investment and beginning to realise the benefits.

A tried and tested approach to business process design is outlined in our document “How To Produce Usable Business Process Maps”.

Received wisdom used to have it that package selection should ignore IT infrastructure issues and focus purely upon functionality. Twenty years ago, when most companies where selecting systems for the first time, this made some sense. Today, with massive existing investments in infrastructure, data and skills it is rarely a realistic option.

Interworking with other systems and the avoidance of unnecessary replacement costs are real business needs that must be included in the selection process. A clear understanding of the overall objectives and of the ways in which the new system will deliver benefits make it much easier to define objective trade-offs between functionality, performance and the cost of replacing existing infrastructure.

It is remarkable how many package implementations run into difficulties because the original requirements were not clearly specified. The resulting misunderstandings frequently lead to acrimonious relationships between the purchaser and the vendor, delays, rapidly escalating costs and, sometimes, even litigation. On the other hand, where requirements have been clearly specified and agreed it is usually possible to resolve even quite serious problems without relationships breaking down.

To protect the purchaser, it is important to include in the contract a clear definition of what the vendor will provide, in terms of:

• functionality;
• performance;
• security and resilience;
• upgrade path;
• services;
• warranties.

An effective way to achieve this is to prepare a formal statement of requirements that is first used as a basis for the selection process and then, subject to any agreed changes, incorporated into the contract.

The statement of requirements should list the functionality and performance required to support the new business process design in a check-list format that can form the core of an Invitation To Tender and provide a structured starting point for package and vendor evaluation. Writing such a specification is a skilled task. If in-depth experience of drafting such documents is not available in-house, it can be very cost effective to use an experienced consultant.

If the right decision is to be reached, it is important for the purchaser to drive the selection process. Software vendors employ highly skilled sales teams and devote considerable effort to closing sales. Unless a rigorous process is followed decisions can easily end up being taken for the wrong reasons.

A short list of potential vendors is prepared on the basis of market knowledge. Typically the short list is not less than three, two presents a high risk of being left with only one bidder and a weak negotiating position. More than six creates unnecessary work and may make some of the most capable vendors reluctant to bid.

In certain cases, where a few, critical requirements may eliminate many vendors, a pre-qualification questionnaire can be used to reduce a longer list to a short one.

The Statement of Requirements is incorporated into an Invitation To Tender (“ITT”) to which vendors are asked to respond. They are asked to respond explicitly to each, individual requirement on the basis that the ITT and the successful vendor's responses will be incorporated into the contract.

Vendor responses to the ITT are scored and this provides an objective basis for an initial ranking of responses. It is important in scoring to separate mandatory requirements, without which the new business processes cannot be operated effectively from desirable requirements, which may provide benefits but are not show stoppers.

Scoring and ranking are followed by vendor demonstrations and presentations. Key elements of the new business processes are identified and information packs prepared containing sample data and descriptions of the process elements that vendors will be required to demonstrate. At this stage, it is appropriate to allow vendors' pre-sales consultants on site to gain a more detailed understanding of the context to the requirements. However, if possible, their salesmen should be excluded.

Demonstrations are a key test of whether the vendors have taken the trouble to understand the requirements. If they don't make much effort to demonstrate the functionality specified in the information pack before the contract is signed, there is little chance that they will make the effort to deliver what is specified in the Statement of Requirements afterwards.

Vendors who survive the demonstration stage should be asked to provide a long list of references from which the purchase can choose whom they will contact. Taking up references is primarily for the purpose of finding out about the vendor and about software reliability. Reference visit are particularly important as these should provide opportunities to ask end users about their experiences.

If possible, the evaluation process should reduce the short list to two preferred vendors. The decision as to which these are should take account of subjective factors, such as the fit between the vendor's and purchaser's cultures as well as hard technical issues. The ultimate choice should be made by business management, with technical specialists acting strictly as advisers.

There are two key objectives in negotiating the contract:

• to establish contract terms that give the purchaser adequate protection;
• to arrive at the most favourable price (not necessarily the lowest);

We are not qualified to give legal advice and advice on the legal aspects of contracts should be sought from a qualified lawyer. However, we have extensive experience of negotiating the commercial and technical aspects of system contracts.

In general, the standard contract terms offered by software vendors are designed to protect the vendor, not the purchaser. The aim of negotiation should be, therefore, to amend the contract so as to make the vendor responsible for meeting the business requirements, not just providing standard software. This represents a fundamental shift from most standard terms and conditions and may require some tough negotiating.

It is also important that the contract defines clearly what is to be provided. Standard terms and conditions can be extraordinarily vague about what a software package comprises.

The most favourable price is generally not the lowest on offer. Vendors often prune apparently unimportant items from the specification in order to achieve a lower price. This can lead to serious trouble later. It is critical to separate the question of what will be delivered from what is to be paid for it.

In the end, it is important to recognise that signing the purchase contract is the start of a long-term relationship that should have the potential to deliver benefits far in excess of the purchase price. It is, therefore, worthwhile to ensure that the deal is even handed, being seen as reasonable by the vendor as well as the purchaser.