Software Selection: An Approach

Introduction

In the life of an IT organization, selecting a software package has become somewhat of a routine occurrence. What makes this task challenging is the type of software being evaluated relative to its scarcity and expansiveness in scope. The approach, fortunately, can be independent of these factors. These factors may mean that more time is needed to complete the project but the basic steps can essentially be the same. The emphasis and priority placed on specific steps, however, can change to suit the situation and package being considered.

This article presents an approach that is dubbed the probe approach. It is analogous to poking your finger into a balloon. You keep moving your finger inward until either you get to the other side or the balloon pops. This approach attempts to quickly identify the potential best package solution, at least on paper, until you are satisfied through a demonstration that it is the best solution (i.e. finger reaches the other side of the balloon) or the selected solution misses the mark on several fronts (i.e. the balloon pops) and you move on to the next promising candidate. Accordingly, you do not drill down to the same depth for all package candidates at the same time. You proceed on a more gradual, deliberate basis. Obviously, if your initial choice proves to be correct, you have saved valuable time and should reap benefits from the software sooner. If not, you have lost nothing from a more traditional approach.

The diagram below illustrates the overall approach at a conceptual level.

The Approach

This article examines each step in the approach, describes the functions of various components, and, when appropriate, the resulting documentation.

Form Steering Committee and Project Team

Does it make sense to worry about the steering committee before you have a project team? It does if you have to want the right personnel assigned to your project. The steering committee is comprised of two to three members of executive and senior management who are knowledgeable in the area where the software is to be utilized. The steering committee essentially functions as a tie breaker or referee. Its responsibilities include review scope and progress, review and approve decisions, resolve cross-organizational issues, and define the key business requirements and drivers of the company. However, do not lose sight of the fact that, as project manager, the most valuable service that the steering committee can perform is to approve changes in scope and obtain requested resources.

The project team is comprised of key members of your company's staff who are the real workers and can make the project a success. You will quickly know the importance of the project by whether you get your first choices and the subject matter experts. This may be an excellent opportunity to use outside consultants to provide expertise in new technology, insights into state-of-the-art solutions to existing problems, and familiarity with the marketplace. With the new software, you should be as interested in doing current tasks quicker as you are in doing them better. The project team conducts interviews, defines business requirements and required process flows, documents and analyzes findings, and presents recommendations to the steering committee. Because team members will typically work independently, teamwork and close communications during the project are essential. As the project manager, one of your roles will be to promote this confidence and dialogue.

Document Process Flows

Someone once said that all projects consist of three phases: fact find, analyze, and report. This step satisfies all three phases. Key to fact finding is that you include a representative sampling of the company activities. This means that, if there are multiple locations, the unique requirements of each location must be understood and appreciated. Having a project team with representatives from the key locations can help to satisfy this need.

In this step you need to concentrate on what makes your company unique in the marketplace and industry. You may have peculiar unit of measures (UOM) and UOM conversion requirements. You may use unique methods for determining product yields. You may have special governmental reporting requirements. For example, you need an accounts receivable module in an ERP solution. You would expect to use the software to invoice customers, receive payments, and post to correct entries to the general ledger. What is unique is that you use factoring and you have established credit limits based on factored balances. This is what needs to documented.

Particularly in this step, the project team needs to think out of the box but still within the four walls of the company and within reason. If you always wanted to process information, material, goods in a different manner, now may be the time to raise and explore these issues. Also, realize that you are not just thinking about today. You need to shine up your crystal ball and consider requirements three to five years down the road. Try to anticipate your future growth and the need for expandability and adaptability.

In your efforts to keep communications flowing in both directions, at the conclusion of this step you should review your findings with the steering committee. Concentrate and seek validation as to the accuracy, completeness, plausibility, and acceptance of the data collected. Without achieving these objectives, you should not proceed to the next step.

Prepare RFP and Rank Selection Criteria

Up till now, you have been creating documentation for internal purposes. In this step you need to make this documentation fit for public consumption. Internal axioms that are second nature and obvious to your company need to have sufficient specificity to avoid confusion and misunderstanding on the part of vendors. Suggested sections for the request for proposal (RFP) are:

• Company Background
• Hardware, Network, and Software Environment
• Application Requirements
• Existing Database Structures
• Provide Typical Data Elements for Mapping
• Evaluation Criteria
• Key Dates and Submission Requirements
• Response Format: Hardcopy and Electronic

As shown on the diagram to the right, the response format typically includes a columnar list of specifications by functional area. The vendor would indicate whether their software exceeds, meets, meets with modification, partially meets, or does not meet the required specification. With respect the vendor's willingness to modify the software to meet a specification, the vendor would indicate the cost of said modification.

To put vendors on notice that you expect a reasonable, demonstrable response, it helps to include a statement that the vendor's proposal will be an addendum to the signed contract.

A key section is the evaluation criteria to be used for vendor proposals. Possible evaluation criteria include degree of fit, hardware and software compatibility, scalability, use of technology, implementation support, and, of course, cost. Within each criterion, for example degree of fit, detailed conditions would be specified by which to evaluate a vendor's proposed solution. Once the criteria have been defined, priority or weights are assigned to each criterion; the higher the weight, the more important the criterion. Weighted criteria are an attempt to promote an objective and unbiased scoring of vendor proposals. Note that these criteria, not the ranking, are shared with the vendors.

Ranking of the criteria must be approved by the steering committee. The rankings should also be shared with department executives so that they have an appreciation of the methodology and objectivity.

Identify Vendors and Issue RFP

There are several sources for identifying potential vendors. A survey of the literature and trade groups in your industry is a start. TechnologyEvaluation.com is an excellent web-based source for identifying software vendors for the process industry. Using Internet search engines, you can find all of the software vendors you could hope for and probably more than you wanted. The problem will be in developing a short list of three to five prospective vendors. This list, then, needs to be reduced to two to three finalists. Developing the list of finalists can be made by talking to existing clients, word of mouth, reputation in the marketplace, financial background checks, and, if available, request of a demo CD.

Critical to issuing the proposal, in addition to the actual RFP, is the establishment of key compliance dates, to include:

• Vendors' conference, date specific
• Proposal submission, date specific
• Follow-up on-site demo, week of date
• Contract negotiations, month of date

Hold Vendors' Conference

Key to this step is that the vendor's conference be structured to ensure that all vendors receive the same competitive advantage. You should be prepared to answer vendor questions and, by doing so, give each the same consistent message. You may elect to publish the responses to questions to further ensure consistency and completeness. It would be beneficial to explain the evaluation process and the criteria but not the assigned ranking and weights. From a timing standpoint, a vendor's conference is typically held a week, but no later than two weeks, after the RFP is issued. Psychologically, this tells the vendor that you are prepared to move at a rapid and defined pace and forces them to read the RFP. At the start of the conference, you should state that the conference is not to review the RFP but to answer vendor questions.

Evaluate and Rank Vendor Proposals

Each project team member evaluates, independently, the functionality aspects of the vendor proposals. At this point weights have been agreed to and assigned. The evaluation is in the form a 4-point must system. In satisfying a criterion, the vendor will receive one of the following grades:

Through simple arithmetic, you determine a vendor's functionality score by multiplying the weight assigned to each criterion by the grade and then summing the resulting values. The higher the combined score, the better the vendor's software appears to be in satisfying your functional requirements. You are taking the vendor's response at face value. But remember that the vendors have been told that their response to the RFP will part of the signed contracted.

The cost of modifications will be rolled into the total cost of the proposal and will offset what could be viewed as a high grade of 2. The proposal costs to include software, annual maintenance, implementation assistance, and modifications can now be evaluated against the functionality scores. If a vendor has a high functionality score but is also high in terms of total costs, you must determine if the costs justify the functionality.

After team members complete their evaluations, a consensus must be reached and vendors are ranked. This is your preliminary list of vendors and sequence in which you will continue to probe the validity of the vendor's claims.

Finalize Vendor Selection

You have now ranked the vendors and have accepted the vendor's responses with little or no question. You are ready to confirm your selection and responses by participating in demonstrations of the vendor's software. Prior to the visit and to make the demonstration time-effective and productive, prepare scripts for functions that you expect the vendor to walk through. These scripts should allow you to confirm vendor responses to your more critical specifications and requirements and are similar to the processes that you would develop for a conference room pilot. Additionally, these scripts should be provided to the vendor in advance to allow for software setup, data loading, and testing.

Assuming a positive conclusion of the demo, you should screen and check references, conduct a site visit to a vendor installation, and confirm your functionality grades. At this point, if you are comfortable with the results of the demonstration, reference check, and site visit, you are ready to finalize your selection. If not, you will want to proceed to the next vendor in the ranking.

To be honest, it takes considerable self-control not to see, at least, one other vendor's demonstration. While this may prolong the selection process and corresponds to a more traditional approach, you already have the necessary material and procedures for the demonstration. The most important result is that the project team feels comfortable in their selection and, as the project manager, you need to provide the mechanisms to achieve this comfort level.

Present Vendor Recommendations and Review Implementation Plan

In this step you should present your recommendation to the steering committee. The presentation should include an overview of the process used, a review of the ranked criteria, results of the vendor ranking in sufficient detail to demonstrate and justify the slotting of vendors, and the results of the demonstrations, reference checks, and site visits. It will easier for the audience to comprehend if you separate the financial analysis from the functionality.

To prepare for smooth transition to the software implementation phase, it would be appropriate to provide an initial glimpse of the implementation plan, timeline, hardware acquisition, and costs.

Don't leave the purpose of the meeting hanging in midair. Seek to obtain the steering committee's approval of your selection and to initiate the next phase of the ongoing project.

Bonus Section

As an added bonus for those of you that have read this far, let's quickly review the project deliverables, evaluation workplan, and organization.

The deliverables from a software selection project are:

• Request For Proposal
• Selection Criteria and Ranking
• Reference Checks
• Results of Site Visits
• Implementation Workplan

Below is the typical workplan for a software evaluation project:

Finally, appropriate project team organization would be:

Project Team Organization The reason for designating multiple project managers is to allow representation of both the IT and user communities.

Summary

The benefits of this approach are that it considers current and future requirements. Use of the ranking and grading methodology helps to eliminate the subjectivity and bias from the decision making processes. The project team approach creates company ownership in the new software and develops team building and knowledge transfer between the vendor, consultants, and your company's personnel. Finally, if appropriate, the probe methodology can be cost and time-effective, providing the potential of using the software in a more expedient manner.

Before starting on any software evaluation and selection process, review the steps discussed in this article for appropriateness to your situation. Then, tailor the sequence and emphasis of the steps to suit your special needs.

If you would like a PowerPoint presentation of this approach, please e-mail me.

About the Author

Joseph J. Strub has extensive experience as a manager and senior consultant in planning and executing ERP projects for manufacturing and distribution systems for large to medium-size companies in the retail, food & beverage, chemical, and CPG process industries. Additionally, Mr. Strub was a consultant and Information Systems Auditor with PricewaterhouseCoopers and an applications development and support manager for a Fortune 100 company.

He can be reached at JoeStrub@writecompanyplus.com.