IT acquisition and purchasing decisions are often conducted in an atmosphere of unmet expectations, internal political agendas, vendor promises, and brand name hype. Decisions are driven by executive mandate, rule-of-thumb, or insufficient analyses based on rudimentary spreadsheet comparisons.
This is a sure recipe for failure, as demonstrated by the horror stories published continually in trade magazines and the press. We'll describe a best-practice approach to the assessment, evaluation, and selection of software—and show you how you can reduce the time and cost involved in objectively choosing the right solution.
There are three main phases within Technology Evaluation Centers' (TEC's) software assessment, evaluation, and selection methodology:
Phase 1: Defining Business and Technical Requirements
Phase 2: Software Evaluation and Analysis
Phase 3: Negotiation and Final Selection
TEC's methodology establishes the foundation for the ultimate success of the selection project. Successful evaluation and analysis of a system—and negotiation with a vendor—are irrelevant if the initial definition of business and technical requirements are incomplete or inaccurate. In many software selection projects, there is not enough emphasis on the importance of this phase, which causes many failures, and can even result in disaster for companies during and after implementation.
TEC's decision support system facilitates fast and accurate compilation of business processes, and maps them to the features and functions of a software solution. By closely following the steps outlined within this phase, an organization can produce a complete and understandable specification of all the needs that are to be addressed by the new solution, and is able to keep the assembled data in one easily accessible repository.
The evaluation and analysis of vendor solutions should proceed from finding the right vendors through to selecting a shortlist of two or three finalists. The sheer mass of data collected during this phase can be overwhelming for any organization, and the manipulation of the data even more daunting.
There may be as many as 20 or 30 qualified vendors, and each may have a list of thousands of criteria, all of which have to be evaluated one against the other. Using traditional methods can lead to serious errors—and may lead to choosing the wrong vendor solution. We'll show you how TEC's decision support system alleviates this process and seriously reduces the time required to reach a more informed and accurate choice of the right vendors to include in the shortlist.
The final phase covers the steps within the negotiation and the final selection process with the short-listed vendors. This includes live vendor demonstrations at the client site, where each solution can be rated by the business and selection team to verify ease-of-use, coverage of critical business processes, and functionality.
During this phase, we suggest that your selection team seek out client references from each vendor to verify their implementation, service, support, and training experiences. We'll explain how TEC's decision support system facilitates and shortens this process by loading vendor information into TEC's comparison tool to produce reports and graphs, which will support your selection team's final recommendations.
Phase 1: How to Define Your Business and Technical Requirements
Typical enterprise application selections begin with little mention of technology, since the first consideration is modeling the desired business processes that the new technology will enable, and then matching them to the functional requirements within any given software solution. TEC uses a standardized methodology to model and match these processes. The following steps are critical to ensuring overall success within this phase.
Step 1: Form a Cross-functional Project Team
A cross-functional team ensures that both the business and technical needs of your organization are addressed, and that each group affected by the changes understands the impact of the decision. The ideal team consists of members of the following groups: management; finance or business operations; users; consultants; and members of the IT operations and infrastructure groups.
Champions and subject matter experts (SMEs) should be chosen from each business area to work with the project team. This will ensure complete buy-in from the business side and help promote the new solution within the rest of the organization, as well as provide expert knowledge within the project team on existing processes and day-to-day operations.
Step 2: Model Business Processes Hierarchy through an Internal Needs Assessment
The project team, with the help of the champions and the SMEs, is responsible for defining and modeling business processes. The first goal is to determine the main process groups, which correspond to the individual business areas of the organization.
Within these groups, processes correspond to the high-level divisions of your business areas (see figures 1 and 2 below). Within these processes, subprocesses detail the main departments of the high-level divisions. Subprocesses include the day-to-day tasks within each department. For each activity, there may be business-based rules describing how these day-to-day tasks are to be performed and controlled.
This large volume of data is difficult to track, organize, and manipulate using traditional methods, such as spreadsheets, word documents, and flow charts. But if this critical information is not properly stored, organized, or made easily accessible, it can cause huge time delays—which in turn can substantially increase the cost of the software selection project.
Figure 1: Process group chart
Figure 2: Drilling down from business areas to business rules
Step 3: Detail Processes, Subprocesses, and Activities
The champions and the SMEs are usually responsible for detailing processes, subprocesses, and activities. Details on as-is and to-be processes should be recorded with as much information as necessary. This makes them easier to understand and associate with software features and functions. Details may include system inputs and outputs, information on (or copies of) existing reports or files, and workflow descriptions and flowcharts to visually illustrate each step within any of the processes, subprocesses, and activities.
This can result in “mountains” of information that are difficult to manipulate or store in an understandable manner when using such traditional methods as spreadsheets or Word documents. In fact, this task is sometimes so insurmountable that it's often the step where a selection process comes to a screeching halt.
However, this daunting task can be accomplished faster and more easily. Using the hierarchy and coding structure as defined in Step 2, TEC's decision support tools create a process card for each process, subprocess, and activity. These cards are designed so that the as-is and to-be processes can be described on the same card. Copies of existing reports, inputs and outputs, files, and flowcharts can be attached within the process card.
New flowcharts for the to-be processes and activities can be designed and attached using an integrated flowchart design tool within the process card. As they are using the same coding structure, these process cards can be imported into the same repository created in the previous step. All the information is gathered in one place to facilitate the next important step in the process. It also creates a critical audit trail for work completed so far.
Figure 3: Process, subprocess, and activity cards
Step 4: Map Detailed Processes, Subprocesses, and Activities to Functional Requirements
Translating business requirements into functional requirements often creates tension between the business and technical team members. Challenges include team members speaking different “languages” (business versus technical), having different priorities, and identifying and eliminating redundancies. However, the biggest challenge is managing all the data gathered in the process so far. Traditionally, exhaustive meetings involving huge flowcharts and endless scenarios are used within each business area. The time taken to reach consensus and understanding in this step often pressures the project team to cut corners and miss important—and sometimes critical—factors that will only become evident much later in the process. This can severely affect the implementation, and even the system selection itself.
TEC can help you speed up the process with knowledge bases organized in a hierarchal fashion that make it substantially faster to map processes, subprocesses, and activities to functional requirements using a simple drag-and-drop technique. Any functional requirements not contained within the knowledge bases can be added to the list of requirements by simply inserting them in the proper area.
The advantage to using TEC's decision support tools in this step is that by combining functionality from different knowledge bases, the final result is a customized list of requirements particular to the project. For example, if customer relationship management (CRM) and supply chain management (SCM) functionality are required within an enterprise resource planning (ERP) software selection, they can be easily added.
The final list of requirements can be prioritized by the project team based on their importance to each functional area of the business. Each level within the hierarchy can be individually prioritized from the main business areas down to detailed functional requirements. This prioritization process results in a customized and ranked list of requirements in the request for information (RFI) that will be used in the next phase of the software assessment and evaluation.
Figure 4: Functionality prioritization
This concludes part one of the two-part series Your Guide to Enterprise Software Selection. In part two, we explain how to conduct software evaluation and analysis, as well as the negotiation and final selection phase.
Are you looking to start a successful software selection project? Launch your project here.