GISdevelopment.net ---> GITA 1997 ---> Best of the Rest

Selecting Vendors: A Project’s Most Critical Decision

Marv Lisko
ISM Information Systems Management Corporation One Research Drive,Regina, Saskatchewan S4S 7H1


Abstract
Your AM/FM/GIS project will likely be one of the most important projects your organization embarks upon in terms of cost, function, competitiveness and impact to staff. Chose the right Vendors and products and your project has established a solid groundwork for success. Err by choosing the wrong product and Vendors and you run the risk of higher costs, missed schedules, dissatisfied management and a failure that could potentially put your organization at risk. The results of your early project decisions may have repercussions for years to come.

This presentation will discuss a concise and easily managed process for the objective selection and verification of GIS products and Vendors. The process provides a simple but rigorous method that will enable your project team to collect and analyze the information necessary to make an informed decision about your potential project partners for success.

This selection process is structured to allow in-house resources to conduct the process from beginning to end. Completely flexible, you can tailor the process to fit the scope and breadth of your particular project, choosing to emphasize or discard suggested activities as you see fit. The end result will be the selection of Vendors or products that will allow you and your organization the opportunity for a successful GIS project.

Introduction
Selecting a product, supplier, system, or consultant is not a complex process. True, there can be many steps in the process and certain disciplines must be applied. However, the process is one that can be performed within the organization.

The following pages describe a process used to select a GIS software product and software Vendor for an enterprise GIS project. The process represents a comprehensive set of tasks meant to be used for a large project. Tasks maybe eliminated that are inappropriate for smaller projects. The process is equally suited for selecting other GIS related services such as a conversion Vendor or applications developer. It can also be used in a wider context for selecting any software product or service required by the organization.

Why Not Use A Consultant?
This process is not meant to exclude or include consultants. Any or all of the tasks can be performed by a consultant, or by internal resources. What I am attempting to do is take away the mystery regarding the process by presenting a logical series of tasks. Once the tasks and process are known, you can judge for yourself what tasks you wish to include in your process and who you wish to have perform those tasks.

There are certain advantages that may accrue to your organization by performing the tasks yourself. Firstly, you will become intimately familiar with all information discovered during the process. Misinterpretation of information and/or loss of accuracy, completeness and meaning can occur when information is presented to you second hand. Organization and industry-specific knowledge may provide an opportunity for you to ask questions that are more pertinent to your situation. Your knowledge of the decision makers, organization status, history, and information holders within your organization may permit you to gather and evaluate information more effectively than a third party. Lastly, decision makers in your organization may put more value in your recommendations than recommendations from a third party.

There are advantages to retaining the services of industry consultants or third parties. Arguments that internal studies are less expensive than those performed by consultants maybe based on false economies. Consultants may bring with them a wider view of your industry or the specific application or service you wish to purchase. By refinement through experience, Consultant processes may add greater value that internal resources for specific tasks. Consultants may also be capable of performing tasks more quickly, thereby providing additional value.

It’s not a case of all or nothing. Pick the resource that is most appropriate to the task. The choice is yours. But understand that you have choices. By simply understanding the process, you can make a more informed decision as to how you wish to proceed.

Recmirements Document Is The Cornerstone of the Proiect
A complete and accurate requirements document is the foundation of the entire project. Without a complete set of requirements, decisions made within the project are subject to some degree of uncertainty. The level of detail to which requirements are defined in the document will depend to a certain degree on the phase and size of the project. However, completeness is essential. A key factor in the creation of a sound requirements document is involvement of the User. The project team should be involved in the requirements process to advise, to assist, and to perform technical tasks that are beyond the level of skill of the Users. However, Users must be major contributors to the requirements process and decision makers for requirement determination and priority. They are the consumers of the product, service or software. The realization of benefits to the organization will be determined by the User’s level of acceptance of the end product. Their buy-in is essential to the success of the project.

The requirements document will establish expectations throughout the organization. The executive, user community, staff labour associations and the organization in general will look to the document as the description of functionality to be provided and the impact these systems may bring to the organization and to individual positions.

Proiect Structure Is The Foundation For Success
Another critical foundation for project success is the project organization. Key players will help determine success if included, and will surely determine failure if they are excluded. Two of these players are the Executive Sponsor and Project Sponsor. The project must have a champion. The Executive Sponsor should be a member of the highest decision making body within the organization. They should believe in the worth of the project and be prepared to champion the project throughout the organization. The Project Sponsor should report to the executive sponsor and should be accessible by both the project manager and the Executive Sponsor. The project sponsor should have the authority to make most major project and organizational decisions.

Users are key resources to specific tasks within the process and the ultimate decision makers of acceptance and success. Their involvement should be maximized. A User Committee should represent a cross section of end Users (eg draftsmen, technologists, engineering assistants, field staff). This Committee will be heavily utilized at times during the project. The estimate of time for their involvement should be generous. Our experience has shown this estimate is most often considerably understated. One of the best ways to highlight User Committee involvement is to isolate a sub-schedule of only User tasks from the master project schedule and ensure the User Committee members understand their role in each of the tasks they will participate in. Be sure the supervisor of each User Committee member understands the commitment of his resource to the project. The supervisor’s buy-in will make the User Committee member’s life easier during the project. Adequate bacldll should be arranged so the User will be able to focus on the tasks within the project, and not be interrupted by requests for his time from his regular duties.

How Long Should The Process Take?
How long should selection take? Our experience is a reasonably full process will take 7-10 months. We’ve checked with other organizations and their experience is similar. Can you do it more quickly? Yes, obviously you can. There may be steps that maybe inappropriate to your projector that may be done in parallel. However, there are tasks that are crucial to the success of the process and should not be cut short. Two of these tasks are the Vendor response to your document and your evaluation of their response. Establish your time line by creating a detailed schedule of all tasks in your process. Set realistic estimates of time for each task. Review the schedule and get buy-in for the schedule from your executive. A key to maintaining executive support is regular reporting. Keep them informed and their support will continue.

What Document Should I Send To The Vendor?
There are a number of types of documents that you can chose to create: RFP (Request For Proposal, RFI (Request For Information), RFQ (Request For Quote) as well as variations of these documents. The information in each type of document will likely be very similar. However, the tone and perception both within the Vendor’s office and your own may be significantly different for each type of document. I prefer an RFI. It gives you a wider perceived latitude with which to deal with Vendor(s) before you get to the point of writing a contract. Since you may wish to solicit suggestions and alternate strategies on certain issues from Vendors, an RFI may be a more appropriate vehicle.

Before you issue the document, you will likely have to discuss your process with the Purchasing department. I typically make two requests from Purchasing that are not a usual part of their process. Firstly, I ask to issue an RFI. Purchasing is most familiar with a tender process. Whether you issue an RFI or RFP, neither is a tender and you must ensure that Purchasing is aware of the differences and establishes a process that is appropriate for your project and to the document type. Secondly, Purchasing generally performs the bulk of the process during acquisition. I prefer that the project team take on this activity for two reasons: interaction between the Vendor and your organization will be at a very GIS-specific level, meaning Purchasing will not likely be able to interpret or answer Vendor questions adequately or accurately. Secondly the process you have selected is likely significantly different than a tender. It may be necessary to educate Purchasing on the process and the type of document you wish to issue. The end result should be an agreement with Purchasing on the division of responsibilities. As in the case of the executive, sound communications and frequent reporting to Purchasing will maintain a good working relationship. You will require Purchasing support to consummate any contract resulting from the selection process. Keep them on your side. Who Should Be On The Evaluation Team?

Evaluation Team members should be chosen based on their knowledge and roles within the project. You may consider appointing members from the project team (technical input), user committee (requirements and acceptance of solution), IT department (fit of solution to the global IT strategy), and the project sponsor (communication, decision making, buy-in). An issue that may modify your process is that of defensibility. Whatever your selection decision, there will be one winner and several losers. At a minimum, you will have to defend your decision to some extent to authorities within the organization. Depending on the politics of your situation, defensibility may require a significant effort both internally and externally. The easiest defense is to ensure your process is objective, not subjective. One method we’ve utilized to ensure objectivity is to engage the services of an independent industry consultant. The consultant from time to time will audit the process to ensure the process, evaluations and criteria used for evaluation continue to be objective.

Why Have A Written Response, A Presentation And A Demo?
All three forms of response are critical to the proper selection of a software product of this magnitude. Each form of response provides a perspective that is unique and a forum that ensures all subjects are adequately explored.

Firstly, a written response from the software Vendor to your organizations requirement is critical. As well, other information such as references, similar projects, Vendor financial, and response to technical questions are essential. A written response should show that the Vendor understands your project goals and that the product will meet your requirements. Secondly, a one-day presentation allows the selection committee and software Vendor an opportunity to interact with one another and ensure concerns from each party are satisfied. The face to face forum allows each party the flexibility to engage in whatever discussion is necessary to clarify a wide range of issues that may have been unclear or unanswered from the RFI. Thirdly, the 1/2 day demonstration will allow the software Vendor to demonstrate in practical terms how the software will meet each one of your requirements and technical concerns. This is likely the first time you have had an opportunity to view the software.

Components Of The Selection Process
The graphic at the end of this discussion represents major tasks in the selection process and how tasks fit, relative to one another. The process can be broken into four components: Preparation, Response, Short-List Selection and Proof Of Concept. Each of the four components is discussed below, with some comments that may add value to specific tasks.

A. Preparation
  1. Create A Requirements Document
  2. Create An RFI Document

    • ensure major representatives of the selection committee have reviewed the document (Purchasing, Project Sponsor, Executive Sponsor, IT representative)


  3. Create Selection Schedule And Get Buy-in From Purchasing And Executive
  4. Establish Selection Criteria And Critical Factors

    • isolate each requirement or information request from the RFI.
    • maintain the RFI page, section, item number for each requirement for quick reference
    • collapse similar requirements into a single requirement statement
    • group requirement statements into categories
    • pole selection committee to establish critical evaluation factors
    • assign weighting to each category

  5. Create Scoring Forms

    • should include individual forms for each Vendor
    • a line for each requirement statement and it’s associated weight
    • a detailed list of all RFI requirements and their location (for reference)
    • an electronic spreadsheet to record individual scores and calculate group scores

  6. Establish Vendor List

    • research potential service providers well before you issue a document
    • consult industry publications including AM/FM Membership lists, GIS World Source Book
    • conduct a survey of local service providers

  7. Issue RFI

    • send a copy to everyone on the distribution list
    • advertise in selected local and national newspapers
B. Response Period
  1. Respond To Vendor Questions

    • if answers to a Vendor’s questions are of significant importance to all Vendors, an addendum should be issued to make all respondents aware of the information

  2. Letter Of Intent Receipt

    • by requesting a letter of intent from each potential respondent, you can judge the extent of the selection tasks reasonably early in the process

  3. Receive Responses

    • arrange for adequate space to store the responses
    • arrange for the distribution of responses to selection committee members as responses arrive
C. Short-List Selection
  1. Reducing The Number Of Responses

    • if more responses are received than are reasonably able to be put through a detailed evaluation, consider using a subset of selection criteria
    • use criteria that have corresponding information in the responses that is easy to locate and quick to evaluate
    • the number of criteria will likely be small and be of a critical nature
    • record individual scores and then produce a group score
    • result should be a reasonable number of remaining responses that can be evaluated in detail

  2. Individual Response Scoring

    • each selection team member should score each remaining response separately
    • in reality, members will ask each other questions regarding each response and form opinions based on those discussions, but individual scoring is preferred
    • individual scores for each Vendor are recorded on electronic spreadsheets and summed to provide a consolidated score for each Vendor

  3. One Day Presentation, 1/2 Day Demo

    • schedule mutually agreeable dates for presentations and demonstrations

  4. Reference Checks

    • check all references
    • prepare a reference questionnaire before conducting checks and record the results of each reference check

  5. Financial Due Diligence

    • Our project suffered a two year delay by selecting software from a Vendor that became insolvent.
    • To avoid this pitfidl, I recommend your Finance Department be assigned the task of preparing a statement of financial stability for each software Vendor. The report should provide the basis of scoring a Vendor’s financial stability.

  6. Conduct The Presentation/Demonstrations

    • be prepared to ask all questions that have a bearing on your rating of that software Vendor and his product
    • consider recording the presentation for future reference in the selection process
    • consider inviting a small number of additional staff to the demonstration (other executive, other users)

  7. Following The Presentation/Demonstrations, Review Your Scoring Of Individual Software Vendors And Revise Your Scoring Where Appropriate
  8. Create Group Scoring

    • calculate the consolidated score for each Vendor but do not reveal the results to the selection team members

  9. Meet To Make The Short-list Decision
  10. Perform Gut Feel Scoring

    • at the start of the meeting, record each selection committee member’s gut feel about each Vendor, each member rating each Vendors from 1 through n.
    • sum the scores of all of the selection team members and rank the Vendors in order of “gut” preference
    • compare the “gut feel” results to the consolidated scoring results. They should be the same. If they are different, there is likely a flaw in the weighting of the requirements or in the way requirements were rated. The “gut feel” method of scoring is a method of validating your weighted score evaluation method.

  11. Make Short-List Decision

    • you will likely chose 2 to 3 software Vendors to short-list. There may exist a situation where one sofiware Vendor is rated significantly ahead of the others. You may chose to continue with more than one short-listed Vendor although this may not be fair to the second and/or third Vendors. Or, you may chose to short-list only one Vendor.

  12. Notify Vendors Of Decision

    • notify Vendors by telephone and follow-up with a letter
    • offer to debrief all unsuccessful Vendors. This is the only way they have to receive any benefit for their investment.
    • for each short-listed Vendor, congratulate them and inform them of the next steps in the process. Decide if you wish to disclose the number of short-listed Vendors and/or their identity.
D Proof of Concept
  1. Set Proof Of Concept Objectives

    • objectives may include observation of or participation in: training, methodology, build a number of limited applications, modify a limited number of existing applications and/or software testing procedures

  2. Create A Specification Document

    • the document should state your objectives and suggest the activities you intent to pursue to accomplish those objectives

  3. Review And Sign-off Document With Vendors

    • discuss the process with Vendors and create a plan/schedule taking into consideration their comments and suggestions

  4. Establish Evaluation Criteria And weights

    • use a similar process as initial selection
    • base criteria on proof of concept and other critical competencies
    • consider performing a risk analysis

  5. Create Scoring Forms That Reflect The Criteria And Weights
  6. Execute Proof Of Concept Process
  7. Revise Responses Based On Process Discoveries

    • evaluation of satisfaction of requirements, project schedules and costs may change based on information gathered during the Proof Of Concept

  8. Evaluate Vendors Based On Criteria
  9. Make Final Selection Decision
  10. Debrief Unsuccessfi.d Vendors
  11. Begin Contract Negotiation With Successfid Software Vendor



© GISdevelopment.net. All rights reserved.