Software Evaluation, Selection, and Procurement Part Two: Recommendations for Improvement

Recommendations for Improvement:

Take a Guide

Software evaluation and selection is a learning process. The selection team will learn a great deal about itself, the company requirements, external software vendors, application software tools, and outside consultants. During this "journey of discovery" it is often helpful to take a guide � someone who has been there before and can lead you through the process.

When looking for a consultant to guide you through the process, look for a firm that is unbiased and has no hidden agenda. Many consulting firms resell software or have close financial alliances with software vendors. While these consultants may be very useful during the implementation phase, their judgment may be impaired during the selection phase. Also closely examine the specific individuals who will work on the project.These are the people you will work closely with on a daily basis, so choose them wisely. Evaluate their skills, past experience, market knowledge, industry expertise, honesty, integrity and references. Be wary of any consulting firm that will not clearly identify the resources for your project.

Don't rush the process!

This seems like heresy in today's corporate climate where everything must be done yesterday. The key here is to maintain the paradigm of software as a capital investment. Look at similar corporate decisions regarding machinery, real estate, facilities, etc. and use that as a guideline for your decision-making timeline.

Obviously there is a balance between "analysis paralysis" and constructive action toward a known objective. Effective management is crucial at this early stage to ensure the team continues to make progress and does not bog down in over analyzing the selection.

Build a strong business case

Probably the most important deliverable in the entire evaluation and selection process is the business case, which serves as the "guidebook" for the remainder of the project. A strong business case establishes the project expectations and guidelines including:

• Project scope
  
  
• Expected costs
  
  
• Expected benefits
  
  
• Project performance metrics
  
  
• Risks
  
  
• Overall implementation approach and timeline
  
  
• High level project workplan
  
  
• Resource requirements
  
  
• Assumptions

But it is not enough to simply produce these documents and call the business case complete. Sufficient analysis must be performed such that the project expectations are realistic and supported by factual evidence. For example, saying that a project will result in $1M in cost savings due to "more efficient supplyy chain processes" is not sufficient analysis. One must identify the specific performance metric that will improve due to the new system, discuss how the software will actually improve that metric, assign an "owner" responsible for delivering that benefit, and then calculate the expected financial results.

For example, if your project is expected to reduce raw material inventory, a thorough business case will record this as follows:

Expected Benefit #1 - Reduce raw material inventory in category A by 25%

• Justification:
  • Software and business process enhancements will reduce the purchasing cycle from 4 weeks to 3 weeks. This 25% reduction will allow a corresponding reduction in raw material inventory on hand. This benefit assumes that the three week purchasing cycle will not result in additional transportation costs due to increased shipment frequency or less than truckload shipments (this assumption is supported by the evidence presented on page XXX of the business case).
    
    
• Owner:
  • Bob Jones, Director of Purchasing
    
    
• Savings Summary:
  • Expected annual savings = $125,000
    
    
  • Expected one-time reduction in working capital investments = $1,250,000
    
    
• Savings Detail:
  • Current average raw material inventory value in category A = $5,000,000
    
    
  • Expected inventory reduction = 25%
    
    
  • Expected annual return on invested capital = 10%
    
    
  • Annualized Dollar Savings = $5,000,000 x 25% x 10% = $125,000
    
    
  • Reduction in working capital = $1,250,000

As you can see, a more detailed set of benefits will remove ambiguity, assign ownership and give the project team a clear set of goals and metrics to target. Developing a business case at this level of detail is a key component in gathering executive support for the project.

In addition, a strong business case serves as the project reference manual. As the implementation begins questions will arise surrounding scope, objectives, budget, resources, deadlines, milestones, etc. The business case must be used to guide the decision making of the project management team. Without an effective business case, and managers who use it properly, an implementation can quickly lose focus and wander off course.

Involve all affected departments on the selection team:

What seems to be a simple concept is often bypassed for political, personal, and resource/schedule constraints. But there should be no compromise here. A software evaluation and selection team that does not include affected parties will invariably face high-levels of resistance and increased risk of failure. When implementation troubles set in or questions arise over the software capabilities, organizational buy-in and support will help you manage through these issues. Without it, the project can and will lose momentum.

Be thorough in your requirements definition

Again this is a simple concept, but one that is often bypassed due to expediency or difficulty. A comprehensive set of business functional and technical requirements serves multiple purposes:

• Acts as a basis for software evaluation
  
  
• Acts as a basis for defining software gaps
  
  
• Acts as a basis for final software testing (system, performance, user acceptance, etc.)
  
  
• Acts as a basis for training
  
  
• Establishes project scope

Concentrate on data

Many legacy systems are weak and ineffective because they don't provide the information desired by the Executives to effectively run the business. Often, the needed data does not exist in the legacy system. Hence the company embarks on the implementation of a new, modern system.

When analyzing the new system, concentrate on the required data elements. These data elements may not be readily available in your company, and without them the new software will not work properly. As part of the evaluation process, assess your company's ability to provide the requisite data to the new application. If additional data gathering is necessary, consider how this will be done (manually, or through automated means such as bar code scanning, or through interfaces to other systems, etc.). Also consider the cost associated with this data gathering effort, as it can often be substantial.

To illustrate, a large, multi-national semiconductor company recently initiated a project to implement a state-of-the-art supply chain planning system. The new software was purchased and initial analysis begun before a major data issue was brought to light. The new system required consistent item information. Unfortunately, item master information for the company was located on several different systems, with little consistency between applications. The data problems were so large that the new system was simply unable to perform properly. To rectify the problem, the company embarked on a 12-month item standardization process that delayed all efforts pertaining to the supply chain planning system. When finally completed, executive support for the supply chain planning system had eroded and the project was shelved. Over $2M in software, hardware and consulting services was wasted.

Prototype the software BEFORE buying!:

During the heyday of application software sales in the mid-to-late 1990's, large application software contracts were being signed regularly and without rigorous buyer evaluations. Except in certain circumstances (i.e., large buyer in strategic market), software vendors were reluctant to expend abnormal amounts of effort convincing a customer to buy their software. Pre-configured demos, high-level brochures and limited technical documentation were the basic info given to the buyer. Demands for additional evaluation hurdles were often met with delays, excuses, and even flat refusal.

But the times have changed and the power is now most certainly in the hands of the buyer � where it should be. Returning to our capital investment paradigm and machinery analogy, an organization would never consider buying a key piece of production machinery without ensuring that it had been thoroughly tested for quality, ease of use, and engineering/supplier/customer acceptance. Software should be no different.

In short, before signing the final contract and buying a piece of software, put the selected candidate package through a rigorous set of tests. Require the vendor (or an implementation partner) to build a prototype using real data and execute a test using real processes. Produce extract files and reports that are close approximations of technical interfaces and user requirements. Allow users from various business departments to see, touch and manipulate the system. Basically build a prototype.

You should expect to compensate the vendor for his time and effort to build such a model since the work product serves as a solid basis for full project implementation. But a small amount of time and money invested up front to discover gaps, product issues, and vendor capabilities is invaluable. This prototyping effort will limit the project risk and provide an option to stop the project before wasting significant time, energy and money.

Don't focus on price!

Price is obviously a key component of any business purchase, and software is no different. But price is not the right factor to weigh. The cost of the software itself is minor compared to the long term costs associated with its "care and feeding". Instead look at Total Cost of Ownership (TCO), which includes support costs (both internal and external), service fees for implementation, enhancement and ongoing growth of functionality, maintenance fees, vendor viability risks, software upgradability, and hardware requirements.

Often the cheapest software solution ends up being the most expensive over its lifetime. For example, one factor that significantly impacts the total cost of the solution is software customization. Modifying packaged software is strongly discouraged due to the high-cost and complexity in supporting and upgrading the software over time. Often the lowest priced software lacks functional depth, driving companies to adopt a software customization approach. When a software customization path is chosen, expenditures for software development, long-term support costs, and upgrade costs must be included in the total cost of ownership and ROI models. Invariably, when TCO is considered, the lowest priced solution becomes more expensive and the benefits of the cheap price are lost.

Conclusion:The implementation of any mission-critical software application is fraught with risk. As the Standish Group statistics at the beginning of the article note, over 30% of implementations fail, and over 50% cost more than twice the original estimates. Those are very bad odds that most organizations should not accept. Pursuing an alternative strategy for software evaluation and selection based on the capital investment paradigm and the principles outlined above is an effective method to mitigate this inherent risk.