System selection, done right — Part I

By Michael Burns

Anyone who has been involved in selecting software knows the road is strewn with pitfalls — many of which we covered in “The top 10 software selection mistakes” (www.camagazine.com/selectionmistakes). But how do you avoid those mistakes altogether? In the next few columns, we hope to shed some light on the subject. First, though, a cautionary note: as with any big purchase, you first need a compelling business case to invest in a new system — one that is supported by management. Without that, you will go nowhere. In this first instalment, we’ll look at what needs to be done before the requests for proposals are sent out. Next issue, we’ll focus on what to do after the responses come in. Later, we’ll explain the various roles and how to present a compelling business case.

Our system selection projects usually last about four months and start with a kickoff meeting with our client. There, we confirm the project scope (such as order processing or general ledger), review the methodology, establish milestone dates and identify the critical success factors (CSF) — what the company must do well to be successful. For a public company, one CSF might be to prepare its financial statements on time. We ask the client how a system can help achieve the CSF, given that people are by far the most important factor.

We then ask management to tell us about the key performance indicators (KPI) that measure the CSF. The measure of success is not whether the project goes live or even if it’s on time and budget; it’s whether the goal metrics or KPIs are achieved. For example, in the case of a company that needs to have its financial statements prepared on time, the KPI would be the number of days needed after month end to release the financial statements. The current KPI might be 15 days and the goal might be five.

At our first meeting, we also explain the roles and responsibilities for the project. We typically identify roles for the sponsor, steering committee, project manager, project coordinator, business-process owners, subject-matter experts and technical leads. The idea is to determine which tasks fall within the purview of each role and to name the people responsible. It is essential that the right people be assigned to the project. For example, the project manager must be very organized and subject-matter experts must be highly knowledgeable about their business processes. Also, they must have enough time for the project.

Involving the right people has two major benefits. First, many of them know the business really well and can add a lot of value and input. Second, they are more likely to buy into the selection decision. Some might still resist — not because they are naturally resistant to change, but because they might be concerned about losing their jobs if the system promises to bring big improvements in efficiency. They might also be concerned about the amount of work required during the implementation. These concerns should be addressed early in the process.

After the first meeting has taken place and the roles have been assigned, we review the business processes by interviewing the employees who do the work — usually the subject-matter experts. These could be order-processing clerks or controllers, depending on the process. We ask them to describe a day in the life of the existing process — the inputs, outputs and problems. In order processing, for example, the inputs are order forms or telephone calls, the outputs are the orders, and one problem could be a lack of inventory. We ask these experts to provide screen shots and reports, as details can often be missed when you are just talking. The primary objective here is to reveal the current steps in the process that must be retained, as well as solutions to the problems. These would both be incorporated as requirements into the request for proposals (RFP).

The business-process review can also be used as a basis for building a business case, by documenting the impact of any problems and showing how the new system could resolve them. Plus, it can be used as a script for vendors when they conduct a detailed demonstration. Finally, the business-process review can expedite the implementation, as vendors typically start by documenting what they call the “as is” business process.

At this point, which is usually about two to four weeks after the kickoff meeting, we take all the requirements from the business-process review report and organize them logically in the requirements section of an RFP. We also include requirements that were not discussed in the meetings but that we believe, based on similar projects, could be helpful. In the case of order processing, for example, it could be showing inventory availability by day or by week. The client must confirm each requirement and place it in a priority sequence (critical, high, etc.). To make it easier for the vendors to respond to the RFP, we ask them to respond only to critical requirements.

Next, we identify potential vendors. We generally include three types of systems: those designed for multiple industries (these vendors are generally well known); industry-specific systems (the vendors might be small and not well known, but still successful); and hybrid solutions (vendors such as Microsoft provide a technology platform and marketing reach to their business partners, who then extend their system for a specific industry using the same tools and database).

We think selecting the right implementer is just as important as selecting the right system. But the choice can be tricky. Often, the developer relies on value-added resellers (VAR) to do the implementation. In some cases, it does the implementation itself but also has VARs that can do it. To complicate things even more, the developers have not done a good job in dividing up the marketplace so that it’s clear which VAR to call for a specific industry and company size. So it’s best to discuss the alternatives with the developer and conduct some research on the VAR before sending it an RFP.

In the March column, we’ll look at the next stage, which includes everything from evaluating responses to preparing scripts, evaluating demonstrations, selecting the preferred system and negotiating contracts. Stay tuned.

Michael Burns, MBA, CA.IT, is president of 180 Systems (www.180systems.com), which provides independent consulting services, including business-process review, system selection and business-case development. Contact 416-485-2200; mburns@180systems.com