BPI Hardware Selection/Software Selection (Package Software) - Design High Level Phase

Description

Hardware/Software Selection for packages is a series of activities through which the client organization 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.

Client 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. External Consultant 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, prioritize it, and weight each factor.

See Business System Requirements for more information.

Define the selection approach

Since most formalized selection approaches rely on some form of scoring, definitely understand that the scoring process is only a tool to assist the client organization 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 organization'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, then 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 'long list' requires good information and knowledge about the business requirements, the marketplace and the merits of the competing vendors.
Hardware vendor 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 client organization 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 organization 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

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 organization and its requirement for new system
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 client 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:

Response does not meet the requirement
Modifications are required to meet the requirement e.g. manual processing required
Response fully meets the requirement
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 specialized 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 organization 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 client organization, given its risks and broad impacts. See Examples for tools/templates)
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 External Consultant to assist 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 organization in a similar line of business to the client organization?
Do they have similar significant business issues (e.g. similar size/volume, geographic sites, legal and cultural environment issues)?

Sometimes reference user organizations 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 organization 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 organizations. 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 organization.
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 organization 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 organization. '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.

The following table shows a number of common negotiating issues and discusses some of the tricks or catches that should be noted.

Consideration	Comments
Price	Different components may be priced in different ways. Typically there are one off payments and/or regular payments. Most vendors will agree to discount their prices. Note, however, that while it is easy to focus on purchase price, the initial payment may be a small component of the total costs of the system and it is wise to negotiate the other details as eagerly.
Recurring charges: rental charges / licence fee / maintenance charges	Most hardware and software items have regular charges for their use in addition to the initial 'purchase' price. These are often calculated as a percentage of the full quoted price, which means they are not automatically discounted if the purchase price is discounted. It may be worth negotiating discounts separately (although vendors are usually keen to defend these charges as it is their main recurring source of income).
First year fees	First year recurring fees are often included in the initial payment

Consideration	Comments
Stage payments and acceptance	It is common to agree to pay initial payments as a number of part payments during the installation, configuration and acceptance of the system. For example, it might be agreed to pay 25% upon delivery, 25% upon installation acceptance, 25% upon system test acceptance and 25% upon live running. It may also be possible to negotiate a 'free trial period'.
Definition of where licensed items can be used, and by whom.	It is important to define the limits of the licence and support arrangements to be suitable for the planned methods for development and live running. It is also wise to anticipate possible changes in the use of the system and either agree that these are allowed in the initial deal or agree discounts and terms that would apply. In particular, check: external staff and consultants working for the client organization can have access to the system the software can be run on development, testing, live, and standby computer configurations the system can be transferred to another computer or the existing equipment can be upgraded without undue difficulty and at a reasonable agreed price the system can be sold or transferred to another party, particularly, for example, in the case of mergers or demergers use by subsidiary or related organizations, in the event of the financial failure of the vendor, the client organization will retain the right to use the software and have access to the source code.
Hours of operation and support	Support out of office hours may not be available unless agreed. It may require additional recurring payments or it may be charged on an ad hoc basis. Vendors will often agree to specific standby arrangement during critical times subject to additional payments. This might be of particular value during the transition to live running.
Free training	Establish the amount and nature of any free training included in the purchase price. Try to establish that this may be used at the team's convenience. Agree whether training should be provided at the vendor's specialized facilities or on site. Check that proper set-up time, preparation and training materials will be included

Consideration	Comments
Vendor support and consultancy	Support and consultancy from vendors can be of variable quality, particularly if the client does not have the choice of personnel. In addition to agreeing prices and discounts, the availability of appropriate staff should be guaranteed along with guarantees of the overall quality of work performed. If appropriate, negotiate the availability of specific known specialists.
Error correction, costs, response times	What guarantees does the vendor give concerning response times to correct errors? What is the escalation process to ensure due attention is given to urgent problems? Are there any costs attached to urgent support? How long would it take the vendor to get a support specialist to the client organization's site?
Provision of routine upgrades	Are all upgrades free, regardless of size? Are routine error-correction upgrades provided free of charge or at what charges? Is there a need for specialist assistance to apply upgrades? Are automated tools supplied to assist in the transfer of data between releases, and at what cost (if any)?
Technical performance levels	Try to establish solid undertakings regarding performance, based on the stated client organization requirements. For example, the client's needs can be met by a specified hardware configuration, response times will be less than a quoted time for specified transaction types, disk storage space should not exceed a given limit. Note, however, that vendors are usually reluctant to do this as it is very difficult for them to make such accurate performance predictions.
Liquidated damages for non-performance	It may be possible to negotiate standard penalty payments for any failure by the vendor to meet the agreed contractual undertakings and standards of service, technical performance etc. This should not, however, be allowed to affect the overall right to reject the solution and demand full compensation if it is wholly unacceptable.
Documentation	Which manuals and what other documentation are included in the purchase price? What are the costs for additional volumes? What arrangements are there for the issuing of updates to the documentation, e.g. automatic or on request, prices etc.?
Consideration	Comments
Dates and plans	The availability and delivery dates should be clearly stated and agreed. The vendor should agree to deliver components and services to met any declared overall project plan. (Acceptance of this and knowledge of the plan can affect to their liability to consequential damages should they fail to deliver.)
Attachments to the contract	It should be explicitly agreed (and noted in writing) that all statements made by the vendor, particularly those made formally in the proposals and further correspondence, will be considered to become part of the agreement unless more specifically excluded or overridden. This may include the proposal, subsequent correspondence, supplied literature and advertising materials, meeting notes, vendor supplied documentation etc.
Modifications or custom programmed components supplied by the vendor	Any solution involving modifications to the packages or custom programmed components will deserve special consideration and negotiation. Considerations may include: costs, support charges, delivery timetable, client's right to monitor progress, client's right to monitor quality, acceptance criteria, support, maintenance in future releases, ownership of any custom code developed, use of the custom built components in future releases of the main packages, warranties, guarantees, quality management, languages, tools used, escrow, etc.
Client's right to amend source code	Is the client organization permitted to amend the source code of the standard or modified components and what effect would this have on the support, maintenance and charges etc.? Will the unchanged elements be supported? Should the client organization maintain a pure version of the system upon which they would need to replicate faults before support would be provided?
Maintenance of old versions	Will the client remain supported and receive maintenance if they choose not to move to new releases of the system? How long does the client have to move to the newer version? How many older versions are supported? How are the maintenance charges affected
Increases in charges / charges for new versions	Attempt to establish limitations or at least a policy statement regarding future increases in the recurring and ad hoc charges. Establish what costs (if any) are attached to taking upgrades to the supplied package. It is common practice for upgrades to be provided free of charge, but this tendency is becoming less normal with smaller cheaper software packages.

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, April 6, 2017