Project Selection Process S030

S030 - Establish “Long List”

DEFINITION

A list of appropriate vendors to consider is established using simple, non-controversial criteria such as platform, price etc, and using the team's experience, research etc as appropriate.

SUMMARY

Use simple non-controversial criteria to reduce the list of all possible vendors to those where there is no obvious reason why they should be unsuitable.  If a Consultant is used their own experience and that of other members of the project team can be used in this process.  Also, some simple but vital tests can be performed, such as whether a required environment is supported.  Other factors that could be considered would be the platform, price, past performance, industry experience, support, size, location and capabilities of supplier, key known requirements of a "knock out" nature, press information, software guides etc.  In some cases it may be possible to refer to software manuals.

PATH PLANNING GUIDANCE

This process is optional.  It may be used where there is a large list of potential vendors.

DEPENDENCIES

Prerequisites (Finish-Finish):

• Market Review (S010) if appropriate
• Advertise (S020) if appropriate

Dependent procedures (Finish-Finish):

• Finalise short list to receive ITT (S110)
• Issue Invitation to Tender (ITT) (S080)

RECEIVABLES

• Vendor details (from S010, S020 and/or other sources)
• Definition of Requirements

DELIVERABLES

• “Long List” of potential vendors

TOOLS

• Tools: Package Information Sources

DETAILED DESCRIPTION OF TASKS

General approach

This process is intended to reduce the number of vendors to a manageable size before issuing a formal Invitation to Tender to them.  In some cases, it may be found that there is already a reasonable number; if so, it is still normally worthwhile applying the type of checks described in this process to save wasted effort during the full evaluation.

The process should be conducted by the project team using criteria acceptable to the client organisation.  Ideally, the criteria would be defined jointly with the organisation’s management team.  The client organisation should also review and formally accept the findings and, in particular,  the recommended list of vendors. It is very common for the final list to be agreed between the main project sponsor and the project manager.

Note that some organisations may have specific needs regarding how and why vendors are placed on the long list.  In some cases no arbitrary decision would be allowed - this is common in the public sector.  Also note that the details of the process might become known to the vendors and so it is important that the method should be fair and reasonable (although, generally it is recommended to avoid informing vendors about such processes and decisions if possible so as to avoid unnecessary disputes).

In addition to this process (or alternatively in place of it) it may be appropriate to perform a formal “pre-qualification” stage - see Process S050.

Information Sources

A number of information sources may be consulted.  Where there has been a Market Review, External Business Review, or External Technical Review, then the results can be used as the starting point.  Where the opportunity was advertised (see S020) the results from that process should be used.

In addition to this initial information (if any) it may be necessary to perform further investigations and analysis of the various options.  Further information sources may include:

• Consultant’s various international information centres,
• the Consultants  support desk,
• Consultant’s geographical resource centres,
• Consultant’s vendor-specific international competence centres,
• Consultant publications, e.g. The Consultant Directory of Financial Software,
• software reports,
• software directories,
• technical review specialists,
• specialist industry-based magazines,
• specialist IT Magazines,
• on-line and CD-based databases,
• contacts in associated organisations or in professional organisations,
• conferences.

Target number of vendors

The purpose of this process is largely to reduce the potential vendors to a manageable number before sending them a formal Invitation to Tender.  It takes much time for a vendor to respond to an Invitation to Tender, and it takes much time and effort for the project team to read, analyse and evaluate the response.  It is, therefore, important to maintain a good balance between evaluating all reasonable contenders and selecting a good solution in a reasonable amount of time and effort.

The “right” number of vendors to include in the formal Invitation to Tender process will depend on many factors.  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 ten or fifteen proposals.

As a rule of thumb,  two to four vendors gives 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.

In some cases, it may be possible to devise a long list which deliberately includes different styles of solution.  For example, there may be less value in evaluating the best four solutions, than in evaluating the best two solutions.

Criteria

Some requirements may be absolute and easy to check, for example:

• can the required technical environment be supported,
• is the software sold and supported in this country,
• can the key business requirements of a "knock out" nature be met?

Other factors are likely to require some initial value judgements to be made by the evaluation team.  It is important that these be made in a fair and reasonable manner, preferably based on hard facts or experience of the current version of the software.  Where there is an element of doubt regarding an aspect of the potential solution, it should be given the benefit of the doubt at this time - the full detail can be examined during the formal evaluation.

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.

In some cases it may be possible to refer to software manuals for detailed information about the software.

The “Long List”

There is not normally a detailed report of any nature produced by this process.  The findings will be in the form of a list of names of software vendors who will be invited to tender for all or part of the overall business solution.

These findings and the decisions should be agreed by the client organisation which should take full responsibility for the decisions made.

Project Selection Process S020

S020 - Advertise

DEFINITION

A public advertisement of the client’s requirements, to invite potential vendors to register their interest and/or capability.

SUMMARY

Advertisements are placed in suitable media to publicise the client organisation’s interest in acquiring new systems and to invite potential vendors to make themselves known.  The advertisement may call for specific information or even a statement of capabilities such that it can be used as the first step in narrowing down the potential vendors.  It may be appropriate to divide the application process into stages, eg:

• advertise basic details requesting an initial expression of interest,
• send out detailed information requesting a statement of capability and/or information about the vendor’s solution.

In some cases, the respondents might be sent an invitation to pre-qualify - see Process S050.

PATH PLANNING GUIDANCE

This process is optional.  It is normally performed only where required by the client, for example to follow public sector procurement rules.  It may also be used in unusual circumstances where there is no market information available from normal public sources.

DEPENDENCIES

Prerequisites (Finish-Start):

• definition of basic scope and requirements for the project

Dependent procedures (Finish-Finish):

• Establish “long list” (S030) (if applicable)
• Pre-qualification (S050) (if applicable)
• Issue Invitation to Tender (S080)

RECEIVABLES

• Project’s scope and terms of reference
• Definition of Requirements

DELIVERABLES

• Details of interested potential vendors

TOOLS

• (none)

DETAILED DESCRIPTION OF TASKS

Basic Approach

This process is often required by public sector bodies where procurement rules dictate that the opportunity must be made known in a fair manner to all potential vendors.  Although fair, this can lead to a large number of vendors applying for consideration.  These will need to be dealt with and assessed by the project team.

To minimise the work involved, the process can be divided into stages with the intention of reducing the applicants to only the serious contenders by the time that the project team starts to assess them.  Vendors would be given sufficient details to allow them to opt out if they feel their solution is unlikely to be chosen.

A typical example of a two-stage process would be:

• advertise basic details requesting initial expression of interest,
• send out detailed information requesting statement of capability and/or information about the vendor’s solution.

In addition, or as an alternative, to requesting the statement of capability and vendor information, it may be necessary to perform a formal pre-qualification stage (see Process S050).  This is typically the case in certain public sector organisations where all stages of the selection process must be open and subject to formalised fair competition.

It should be clear in the documentation sent out that this process is only a preliminary step before the issuing of a full Invitation to Tender otherwise vendors may misunderstand the level of detail that is required and might be uncooperative when asked for a further tender.  The documentation should set out the intended sequence of stages in the selection process.

In some cases, client organisations will deliberately make the process hard and/or expensive in the hope that this will reduce the number of bidders.  Unfortunately, this can often deter good vendors who know that their statistical chances of winning do not warrant the investment. In extreme cases, usually in specific market environments, there may be a requirement for financial bonds to be placed by the bidders (if so, specialist assistance may be required).

Advertising

In many cases a simple announcement in relevant journals might be placed.  The details should be agreed by the client organisation.  In some cases, it might be appropriate to use professional specialists to help with the preparation of the advertisement, for example,  where the client organisation is particularly keen to enhance its public image.

There is a choice of tactics regarding the naming of the client organisation and the address to submit responses to.  The main options are:

• advertise solely in the client organisation’s name - ensures proper attention is paid to the true customer but can involve an unwelcome amount of contact from salesmen,
• advertise in the client organisation’s name but with a Consultant as the only named contacts - avoids the problem of too much contact from the salesmen and shows the selection process will be serious and fair; it can, however, distance the true customers from the process,
• advertise in Consultant’s name with the client remaining anonymous - completely avoids the problem of unwelcome contacts but makes it difficult to give the vendors a good level of information about the organisation and its needs.

Typical media in which to place the advertisement may include:

• journals specifically designated for such purposes, eg the EC Journal,
• specialist IT newspapers, journals and magazines, eg Computer Weekly
• general “quality” newspapers, eg Financial Times
• industry and/or trade specialised journals, eg the Times Educational Supplement.

Project Selection Process S010

S010 - Market Review

DEFINITION

An initial survey of methods and products available in  the marketplace.

SUMMARY

The market review is used optionally to study the full options available in the marketplace.   It is used where the project team have 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.

The market review provides an overview of the business and technical possibilities.  It establishes that there is at least one apparently feasible solution.  It provide the initial information upon which to base the subsequent preparation of long lists and short lists for options to be evaluated.

This process is essentially a fact-finding exercise.  Knowledge about the market is picked up from a range of sources, eg Consultant information sources, other team members, software directories, magazines, etc.  The findings are presented in an informal manner, comprising a collation and distillation of the facts.

PATH PLANNING GUIDANCE

This process is optional.   It will be of value where the project team has incomplete knowledge of the marketplace.

DEPENDENCIES

Prerequisites (Finish-Start):

• definition of basic scope and requirements for the project

Dependent procedures (Finish-Finish):

• Establish “long list” (S030)
• Issue Invitation to Tender (S080)

RECEIVABLES

• Project’s scope and terms of reference
• Definition of Requirements (a high-level summary is sufficient)
• External Business Review (if performed in Requirements Segment)
• External Technical Review (if performed in Requirements Segment)

DELIVERABLES

• Market Review

TOOLS

• Tools: Package Information Sources

DETAILED DESCRIPTION OF TASKS

First ensure that it is clear what the desired system is intended to deliver and what are the basic constraints.  Normally this information will have been determined by the Requirements Segment, or the client organisation’s own statement of requirements.  At this time, this information can be at a very basic level.  The purpose is to scope the market review, not to define the actual system to be selected.  For example, it may be defined that the review should be restricted to integrated financial applications based on client-server architecture.

Within the defined scope, a wide search should be made seeking to identify any solution which might address the client organisation’s needs.  The information sought should be sufficient to identify whether the solution might:

• be available within the desired timeframe,
• be available on the required technical platform,
• be within the organisation’s financial constraints,
• address the basic business functions required.

The information required may be available from:

• Consultant’s various international information centres,
• the  support desk,
• Consultant’s geographical resource centres, eg The European Resource Centre,
• Consultant’s vendor-specific international competence centres,
• Consultant publications, eg The Consultant Directory of Financial Software,
• software reports,
• software directories,
• technical review specialists,
• specialist industry-based magazines,
• specialist IT Magazines,
• online and CD-based databases,
• contacts in associated organisations or in professional organisations,
• conferences.

Details of some information sources can be found in the Tools document “Package Information Sources”.

The information collected should be collated.  Archive details of any packages which are clearly inappropriate (the information may become relevant at a later time due to changes in the project or for a different project).  Collate the potentially relevant information so that it can subsequently be used to assist in the establishment of the “long list” of potential solutions.

Optionally, the information may be summarised into a brief, informal report to allow the overall findings to be made known to a wider audience, e.g. to the key user management involved in the project.  This document is known as a Market Review.  Care should be taken to emphasize that these results are based on general information discovered in relation to a summary view of the organisation’s needs - it does not guarantee whether any specific named solution is, or is not, appropriate.

Project Requirements Process R220

R220 - Review Client Organisation’s Requirements

DEFINITION

Check that the requirements definition work done by the client organisation has addressed the agreed areas of requirements definition work to a suitable standard.  Check that the documentation of these requirements covers all the necessary contents to a suitable standard.

SUMMARY

The appropriate approach in terms of processes and tasks was considered and agreed in Process R200.  It was agreed further in Process R210 what this meant in terms of deliverables, depth of detail, consultation, review, quality and signoff.

Having agreed the appropriate components of the requirements work, this process deals with the review of work performed against those agreed standards.  The working papers, notes and documentation are examined to assess whether:

• the work has addressed the agreed areas
• the work has been conducted with due consultation, review and signoff
• the requirements are sufficiently well documented
• the results are fit for the client organisation’s needs and represent a fair statement of its requirements
• the results are suitable for input to subsequent Application Software Implementation processes.

Any issues that arise may be discussed informally with the project sponsor and other relevant personnel within the client organisation.  Specific consequences and actions arising will be discussed in Process R230 - Agree and conduct any further work required.

A formal Requirements Review report may be produced.

PATH PLANNING GUIDANCE

This process is normal practice.

DEPENDENCIES

Prerequisites (Finish-Start):

• (none)

Prerequisites (Finish-Finish):

• Agree appropriate processes (R200)
• Agree appropriate deliverables (R210)

Dependent procedures (Finish-Finish):

• Agree and conduct any further work required (R230)

RECEIVABLES

• Client organisation’s work plan / evidence of work conducted
• Client organisation’s “statement of requirements” documentation

DELIVERABLES

• Requirements Review report (RR)

TOOLS

• Application Software Implementation Process descriptions and examples for the Requirements segment
• Skeleton Deliverables: Requirements Review

DETAILED DESCRIPTION OF TASKS

Review the work done

The work performed by the client organisation in preparing the requirements documentation is reviewed to see whether it meets the minimum standard that was agreed in R200.  The reviewers should not repeat the work nor attempt to make up for deficiencies - they should just investigate whether it has been done properly.

Fact finding techniques may include:

• interviewing the staff involved to discover what was done and how they got their information
• examine any work plans and project tracking data
• examine interview schedules and notes
• examine working papers, memos etc
• check with relevant users and IT personnel within the organisation to see whether they feel they were adequately consulted, had adequate opportunity to review the findings and agreed with the resulting documentation.

Review the documentation

The resulting requirements documentation should be examined to evaluate whether it presents a sufficiently complete and accurate statement of the client organisation’s business requirements.  The required level of detail will vary according to the organisation’s needs.  The required approach and standards were agreed in R210.

The documentation should be adequate for the client organisation’s needs.  If the project is to continue as a Application Software Implementation project it should also be assessed whether the standard of documentation is sufficient for the subsequent Application Software Implementation processes - ie the selection and implementation of a business solution to address these stipulated requirements.

Detailed comments and observations may be noted and reported back informally, usually by annotation of the documents.  Significant issues should be noted, discussed and reported formally in the Requirements Review report.  The report should also convey a summary of any significant detailed comments and a general appraisal of the adequacy of the documentation.

Reporting the findings

Findings should be discussed informally with the project sponsor and any other relevant personnel within the client organisation.  It may be possible for them to make minor adjustments without any additional work.  It might also become apparent that some of the work or evidence has been overlooked or some of the initially agreed standards were not, in fact, appropriate.  Issues which cannot be resolved may require further work.  This will be reported, and the detailed actions will be agreed in the following process - R230.

The findings from this Process are documented in the Requirements Review report.  The report will cover:

• the agreed approach (see Process R200),
• the agreed content of the deliverables (see process R210),
• the extent to which the tasks have been completed with an acceptable level of consultation, detail, quality, review and signoff,
• the extent to which the documented requirements convey an accurate and sufficient description of the organisation’s true business requirements
• the extent to which the requirements are adequate for use in subsequent Application Software Implementation processes.

The report should be discussed, agreed and formally signed off by the project sponsor and any other relevant decision makers within the client organisation.