Business Management: Hardware Selection/Software Selection (Package Software)

Description

Hardware/Software Selection for packages is a series of activities through which the client organisation selects a preferred IT solution for purchase as a result of a formal analysis and selection process that documents the rationale for the final selection that is made. This deliverable is applicable anytime a hardware or software selection has been determined as necessary to enable the redesign.

Business Value

This deliverable provides a rationale for expending the funds necessary to proceed with implementation activities, as well as an historical record for the selection.
Without the hardware and software environment being formally defined, further progress on building the IT component of the overall system is halted.

Approach

Hardware/Software Selection may be used when a custom solution is being built to select the development/production hardware and software, as well as when a commercially-available package solution is sought. The difference between the two situations is the “timing” of the deliverable.

For the custom solution, the selection may take place during or after detailed requirements definition. For the package solution selection, it is recommended that the software be selected before detailed process-modeling is conducted during Detailed Process Descriptions, so that the processes can be redesigned to fit the capabilities and features of the selected software.

Survey the marketplace to determine whether a package or “off-the-shelf” solution exists.

Optionally use a market review to study the full options available in the marketplace. Use this where the project team has an incomplete knowledge of the marketplace. Given the size of today’s package marketplace and the enormous rate of technical change, it is increasingly common that no one has a complete understanding of the possibilities.
Ensure that this market review provides an overview of the business and technical possibilities, and establishes that there is at least one apparently feasible solution. Ensure that it provides the initial information upon which to base the subsequent preparation of long lists and short lists for options to be evaluated.
Allow this process to be essentially a fact-finding exercise. Knowledge about the market is picked up from a range of sources e.g. information sources, other team members, software directories, magazines, etc. Present the findings in an informal manner, via a collation and distillation of the facts.

Build a requirements matrix, prioritise it, and weight each factor.

See Business System Requirements for more information.

Define the selection approach

Since most formalised selection approaches rely on some form of scoring, definitely understand that the scoring process is only a tool to assist the Organisation to make the best choice between various solutions, where each has its own competing merits. Typical objectives for the scoring scheme might be:

To ensure that emphasis is placed fairly according to the organisation’s true needs;
To prevent the exercise of personal bias, and to demonstrate the completeness and fairness of the process; and
To highlight all significant differences between the competing solutions,

Examples of such criteria might include:

Price
Past performance
Industry experience
Support
Training facilities
Size, location and capabilities of the vendor
Known ability to address key functional requirements
Usability/user friendliness
Reviews in the press, software guides, etc.

Select a list of possible vendors.

Develop a list of names of software vendors who will be invited to propose for all or part of the overall business solution.
Select the “right” number of vendors to include in the formal Invitation to Tender process. For a very large requirement, where there are likely to be several qualified vendors, five may be too many. For a small requirement, in a field where many vendors have competitive products then it might be possible to evaluate as many as 10 or 15 proposals. As a rule of thumb, two to four vendors give an element of choice without undue effort. To achieve such a small “long list” requires good information and knowledge about the business requirements, the marketplace and the merits of the competing vendors.
Hardware vendors to be involved in the selection process are determined in this step also. In many cases, however, the software candidates that are chosen for the selection process will drive the determination of the appropriate hardware vendors.

Ensure that the Organisation agrees with the findings and decisions and takes full responsibility.

Inform selected vendors about the selection process.

The objectives of this step are:

To give the vendor sufficient understanding of the client Organisation and its needs for new systems, so that the vendor can effectively evaluate how to respond.
To define in detail the specific requirements that must be met in any proposal.
To elicit details about the vendor’s proposed solution in a way that is:
Structured so that it is easy to evaluate and compare with the original requirements and against the other vendors’ responses
Precise and specific so that the vendor must give thorough and genuine responses to the client’s needs
Formal so that it can be made legally binding in the event of the vendor being chosen and contracted with.

Select and prepare an appropriate document to communicate with vendors—e.g. Request for Proposal (RFP), Request for Information (RFI), Invitation to Tender (ITT), etc. While these vehicles may vary in format and level of detail, each typically contains:

Covering letter
Background to the organisation and its requirement for new systems
General description of the requirements in the form of a textual overview
Tendering rules—i.e. details of how to respond etc.
Request for documentation—e.g. manuals, training schedules
Full requirements matrices—detailed requirements and their relative criticality
Other key facts required by vendors—e.g. volumes, existing equipment and software
Background questions—e.g. size of vendor, proposed-software version numbers
Request for costs, in a specified format—covering initial and recurring costs (e.g. licence charges and maintenance fees) and ad hoc costs (e.g. fees for training courses, consultancy or additional documentation).

Obtain formal Organisation acceptance of this document before it is issued to potential vendors.

Conduct a vendor conference and/or respond to vendor inquiries.

After notifying selected vendors, take appropriate steps to provide them with adequate support (e.g. make available appropriate team members or client staff to respond to questions). To be fair, copy any significant additional information disclosed to one vendor to all other vendors.

Evaluate the preferred packages.

Document any issues associated with each compliant bid, and quantify the extent to which these responses meet the detailed questions and requirements. Reject “non-compliant” responses. The following is an example of how an ITT might be scored for a particular requirement:

0 Response does not meet the requirement
1 Modifications are required to meet the requirement e.g. manual processing required
2 Response fully meets the requirement.
3 Response fully meets stated requirements and offers significant additional benefits.

Conduct product demonstrations with a “short-list” of vendors.

Vendors usually have standard presentations and demonstrations that they tailor for each selection team. While this may be of some value, it is usually better to define up-front the precise information and aspects of the system you wish to see presented (allowing a portion of the presentation for the vendor’s general “sales pitch”).
A detailed analysis of the proposed hardware for each alternative generally requires specialised expertise. If hardware is critical to the selection, invite a specialist to assist with the evaluation. At a minimum, ensure hardware analysis covers the following issues:

Compatibility with existing systems
Capacity to support expected load
Expandability and upgrade path
MIS support needed.

Contact user-references provided by the vendor to obtain independent views on:

Functionality, reliability and usability of the software
Corroboration of specific queries or issues concerning the vendor’s proposal
Reliability of the vendor organisation and their suitability as a “business partner”
True implementation experiences (effort, time scales, problems, vendor support).

Existing users are often very keen to co-operate. They will normally be proud of their achievements and be convinced that their decision was right. They will often be keen to encourage more users of the same systems since the size of the user base endorses their personal decisions, leads to greater investment in the products and adds to the strength of the vendor upon which they rely. Referenced users, therefore, tend to present a good picture and may be defensive if defects, problems or inefficiencies, etc. are discussed.

Select the preferred vendor based on a balanced judgement of the best solution based on the information gathered. (A final decision of this nature must be made by the project sponsor and key decision makers within the Organisation, given its risks and broad impacts.)
Negotiate a contract with the preferred vendor.

Negotiate only with a vendor representative who has the authority to ensure any contract is binding. Bargain in good faith, with a view to creating a long-term business partner.
If the existing hardware is being replaced, the client may request assistance with negotiating quotes from used equipment resellers. Be aware, however, that because of rapid changes in technology, used components generally have little more than scrap value. Also, prices quoted by resellers may vary greatly within a very short period of time. Trade-in options sometimes provide the client with an attractive alternative. If possible, obtain quotes early from the reseller and try to “lock-in” the price with a “pick-up” date after conversion.

Guidelines

Problems/Solutions

Be aware that to win a contract, vendors may opt to distort responses. As an extreme example, some vendors may say “Yes” to a requirement when they really mean “Yes, we can do this, but we have to modify the program”. Establish open communications with the client as follows.

Ensure that tendering rules clearly require complete answers with explanations.
Ensure it is clear that the answers will be incorporated into any ensuing contract.
Word questions and statements of requirements carefully ( e.g. “can the standard package as proposed ...” rather than “can your software ...”).
Seek explanations rather than affirmations (e.g. “how does the package ...” rather than “does the package ...”).

Use of a rigid scoring scheme carries a variety of risks, including:

The best solution may not get the overall highest score,—e.g. the highest-scoring solution may have several critical weaknesses, while another solution fits all criteria.
The more questions there are about a particular topic, the larger the influence it has on the overall result. Ensure questions address a broad range of topics in the same detail.
Numbers can give a false sense of “scientific precision” and can unduly influence decisions that might better be decided by weighing a variety of non-quantifiable factors.

Tactics/Helpful Hints

RE: Requests for Proposal

Establish a list of potential vendors using simple, non-controversial criteria such as platform, price, etc., and using the team's knowledge, experience and research. Remember that the details of the selection process may become known to vendors at any time, thus it is important that the method be fair and reasonable.

The use of electronic ITTs and proposals (supplemented by a formal signed paper version for legal reasons) can provide a number of benefits to the client and vendors, including:

Most vendors can respond faster and with less effort.
Vendors can easily incorporate text and data from the ITT in their proposal.
The project team can rearrange the proposals in tabular form, with vendor responses aligned with one another and to the original questions.
The tables of costs can be imported into spreadsheets for calculation and comparisons.
Responses can easily be incorporated into other documents—e.g. issues copied into an Issues List, quotations and tables of costs pasted in the final report or re-used during the subsequent design and documentation of the system. (This can be of particular value where the proposal contains diagrams or tables).

Take care to ensure that a vendor conference “sells” the project effectively “to” the vendor (i.e. to convince each vendor that the project is worth pursuing and will be successful).
Respect the following guidelines when scoring proposals:

Ensure the same individual or group marks all proposals (to avoid having differences in the standards applied by each assessor affect vendors’ scores).
Divide the review by topics giving sections of the proposals to appropriate members of the project team to assess for all vendors.

To foster “buy-in,” encourage client users, MIS and management to participate in the evaluation process (especially if involved in ongoing system use/maintenance).
Make an initial review of proposals first, without attempting to mark them.

RE: “Reference” Users

When consulting users of the software provided by the vendor as “references”, be sure to take the following into consideration:

Are reference users using the same versions of the same applications on the same equipment and operating systems?
Are the contact names provided actually key users? (Make requests for names of other system users, to lead to someone who is less satisfied with the system.)
Is the reference organisation in a similar line of business to the client organisation?
Do they have similar significant business issues (e.g. similar size/volume, geographic sites, legal and cultural environment issues)?

Sometimes reference user organisations find themselves inundated with requests. This can often happen with the first “live” users of a new technology or system. In such cases there may be long waiting lists or the organisation may refuse to accept any further visits. It may be possible to restrict the contact to a telephone call.
It should be understood that vendors are likely to propose sites of only their best customers. It is often useful to obtain a complete client list from the vendor (or from an independent source such as a user group or directory) and select suitable reference sites without the advice of the vendor.
There will always be cases where the proposed solution is so new that there is no reference site available. These situations should clearly be judged on their merits. Sometimes the newest solution is the best solution, but it is often the highest risk option. The lack of a reference site should not be considered as a disqualification for the proposal.
Depending on culture and the industry concerned, it may not be appropriate to seek reference visits to rival organisations. In practice, however, rivals are often happy to be consulted and will usually give honest opinions. Make sure no confidential information is disclosed to them concerning the client organisation.
Sometimes vendors feel it is their right and duty to select the reference user and to act as guide and chaperone throughout the visit. It is usually best to avoid this (politely) and to make all the arrangements through direct contacts once the contact details have been established.

RE: Negotiations With Vendors

When negotiating, it is usually a good idea to hold open more than one possible solution until a satisfactory deal has been reached. This will ensure that the client organisation does have a fallback position and it can lead the vendors to negotiate in a competitive atmosphere. Never be afraid to ask for a discount. Note that discounts in excess of 50 percent have been agreed with some vendors whereas certain others refuse entirely to offer any price reductions.
It is recommended that several people participate in the negotiation team, for example, including the client sponsor, IT manager or lead analyst, the related user department manager, the client’s attorney (specializing preferably in computer contract law) and the purchasing agent.
Ensure oral promises are documented and included in the contract. The vendor’s proposal should be attached to the contract, and its details should be made part of the contract (unless superseded). The final contract should clearly specify all costs and payment terms.
It is important to follow any formal approval procedures the client may have and to seek consent through regular channels. The process may also include special approval forms (e.g. Capital Expenditure Request) that are unique to the client organisation. “Shortcutting” the client’s internal processes may damage the Firm’s image with the client and may create an excuse for assigning blame if difficulties arise later.

Resources/Timing

Allow vendors a reasonable amount of time to respond to the request for tender. It is in both parties’ best interest that sufficient time be given to ensure all aspects can be addressed and high-quality responses prepared. This process takes a minimum of two weeks even in the simplest of cases, although most require a month or longer (depending on the complexity of requirements, solution and ITT).

Thursday, November 7, 2013

Hardware Selection/Software Selection (Package Software)