Selecting a new business system is something most mid-sized New Zealand businesses do every five to seven years. The decision to select a new system can represent either an opportunity or a threat.

It’s an opportunity if the right system is selected - one that can improve decision-making and customer service, and decrease costs. The wrong selection, however, threatens business with increased costs, damaged staff morale, loss of customers, and thwarted decision-making. The following is an industry insider’s perspective on the seven deadly sins that are commonly committed.

The information is straightforward and commonsense but nevertheless is often ignored. Follow it and you’ll potentially save yourself money, time... and pain.

Deadly Sin #1: Wrong people involved
Possibly the main factor in any successful system is involving the right people with the right knowledge and skills. Whether the selection process was successful or not will not be judged immediately after going live but rather a year or more after that. Throughout that entire period it’s critical to have the right people involved with the right authority, knowledge and skills. Several of the most critical roles are;

Executive Sponsor: The first thing required is senior executive, preferably CEO, sponsorship of the selection process and project. This visibility heightens the approval of the project and the involvement of people in the organisation. The sponsor’s assistance will be vital to clear the internal roadblocks organisations raise in response to change. If an executive sponsor with clout isn’t available, then give the project a miss!

Project Manager: Ideally the project manager will manage both the selection and implementation process. This ensures maximum ownership of the outcome. The success of this role is not so much determined by what the project manager knows but by what the people they bring together know. The right person will have a combination of good organisation, business and people skills. Technology skills should be considered a bonus.

Selection Team Members: Often selection teams don’t recruit the ‘actual’ workers. This is a red flag as often a system will be selected that meets the requirements of the organisation the managers think they run as opposed to the ‘real’ one. It’s critical that the people who actually do the work are involved.

System Owner: Probably the most underrated role in terms of importance. The System Owner is the person with the responsibility for the ongoing smooth and effective operation of the system. They need to have a good knowledge of the business and the system and above all, be passionate about its objectives. They will address issues in a timely fashion and monitor the system use to ensure practices are in line with defined processes and that people have the right training. They will work with the vendor to ensure that escalated problems are resolved in a timely manner.

Deadly Sin #2: Unclear problems
When faced with problems the human tendency is to jump into solving them before spending time clearly defining the problem. The IT industry often takes advantage of this by touting, or at the very least implying, that technology is a general panacea for business problems. More time is thus spent looking at software solutions than at the business problems. It’s no surprise then, that organisations seduced by ‘solutions looking for problems’ end up disappointed with the return on their investment. In fact, most core business problems that technology can impact are process or people related, not technology related. As such, all areas need careful examination otherwise the defined solution will be incomplete at best.

Deadly Sin #3: Fuzzy benefits
With a clear set of business problems that technology will be an enabler to solving, you need to clearly document the benefits (the age of decision makers lightly making IT investments went with the demise of dot-coms). Systems should not be exempt from ROI analysis any more than any other type of capital expenditure. Quantifying benefits wherever possible can be hard work but using three simple questions will help. “So what?”, “How much?” and “Bottom line?” will enable you to develop a business case based on hard numbers as opposed to intangibles. You will need to ask these questions repeatedly to identify each specific tangible benefit. This is important not only in improving the chances of obtaining the right budget and approval but also because it helps guide the implementation. The purpose of establishing a benefit is not about making an accurate prediction in itself. It is to clearly establish goals that will drive the implementation of the technology.

Deadly Sin #4: Buying mainly on price
The saying “quality is remembered long after price is forgotten” could not be truer for buying systems. Remember, the objective is to create benefits for the business by selecting the right system rather than saving on upfront costs by buying the wrong system. Price should rank down the list of considerations. The key is not what you pay, but the net return you receive from the implementation. However if you don’t have those benefits clearly established then you’re likely to be unduly influenced by price and will suffer accordingly. That said, price still has to represent good value. Here are a few guidelines for evaluating what the ‘real’ price is:

Five Year Cost of Ownership: This should include software, services, maintenance and related infrastructure, costs like servers, operating system licences etc. You should also factor in costs for regular training and upgrades.

Cheap Software: Be particularly wary of ‘cheap’ software particularly from Tier 1 vendors, as they often sting with implementation costs.

Low Rates: Don’t be seduced by a low hourly rate as it’s the rate x the hours taken that costs. Ensure you get guarantees as to the experience of the person you’re getting.

Fixed Price: A bargain price, particularly if it’s very low, is often not the bargain it appears to be. All it guarantees is a fixed cost – not a system that works on time and delivers the expected benefits.

Scope: Often the buyer and seller having agreed on a price in the past, find they had not spent enough time agreeing what the price included. Intelligent ways to keep costs down include: buy only software you absolutely need now. Surveys show 20% or more of software ends up “shelfware”. Keep the design very focused on addressing your big issues. Avoid customisations where possible. Financing the software which spreads the cash flow impact.

Deadly Sin #5: Relying on others
It’s worthwhile to take on board the advice and experience of others but don’t place undue reliance on it as everyone’s frame of reference will be different. Two sources of opinion that can be either helpful or unhelpful are reference sites and consultants.

Reference Site - The absence of reference sites certainly is a red flag, but the fact that an organisation can produce reference sites only indicates a success percentage indeterminately greater than zero. You certainly want to talk with satisfied customers but be wary of cultivated ‘tame’ clients. To get the most value from the interview, concentrate equally on their experience regarding selection and implementation, as on their opinion of the service provider and software. It should not be necessary to talk to more than three or four sites.

Independent Consultants - If you’re very unsure of selecting a package, you may think of using self styled ‘independent consultants’ – an oxymoron if ever there was one! It’s quite unreasonable to expect that anyone with experience does not have bias and there are many ways you can be affected by a consultant’s bias without you realising it. Blatant conflicts of interest are more common than you may think!

Deadly Sin #6: Swayed by the pitch
Question: What’s the difference between a used car salesperson and a software salesperson?

Answer: The used car salesperson knows when they’re lying. This joke may let software salespeople off the hook but certainly not you. To be forewarned is to be forearmed so here are a few of their favourites.

Size Matters! Well it may or may not. It really depends how size is used. Big does not necessarily mean better, nor does small mean more personal service. That said, the minimum size of a mid market service provider is increasing because of the resource demands of technology and what it takes to be a full service provider.

Buy Kiwi! Maybe it’s a good way to select peanut butter but it’s not logical as a point of reference for buying software. As long as systems comply with local tax and reporting requirements then their country of origin isn’t that important. Whether the development team is 1,000km away or 10,000km away makes little difference to any mature software package as developers shouldn’t need to come on site. Be careful however in buying from organisations that don’t provide you with a choice of local service providers.

Legendary Customer Service! You won’t meet a software company that doesn’t claim this and can’t produce a few tame reference sites to back it up. To get to grips with the likely reality for you, review their customer service processes, insist on visiting with their customer service/ support team and if possible, go to a customer event such as a user group meeting (these should be held quarterly if they are a good service provider).

100% referenceable! If you believe doctors never lose patients then you might believe this one. Given that the success of an implementation does not rest 100% on a software provider’s skill (just as a patient’s recovery isn’t 100% based on the doctor’s ability) then it stands to reason that some implementations will be unhappy ones although not primarily because of the software provider. The point is that even assuming a service provider is perfect (which you never should) any organisation that has implemented any reasonable number of sites will have a number of detractors.

Deadly Sin #7: Lack of selection process
It shouldn’t be surprising that the quality of the selection process will directly impact the correctness of the decision. System selection is a project in itself and as such should have a planned timetable. A selection process could be structured as follows:

1. Assemble selection team.
2. Perform Needs Analysis taking into account business strategy and objectives.
3. High level review of possible vendors.
4. Prepare Business Case and obtain approval.
5. Prepare Statement of Requirements for vendor response.
6. Short list three vendors.
7. Complete scenario based evaluations.
8. Select preferred vendor.
9. Complete Implementation Planning Study engagement with preferred vendor.
10. Obtain final approval.

Compile a statement of requirements before you have detailed discussions with vendors. This will ensure focused discussions and enables the vendor to more effectively provide you with information. Make sure when developing a statement of requirements that you talk with the right people in your organisation and stay focused on where the potential business value lies in changing systems.

Use Business Processes to Help Define Software Requirements

When selecting software systems, it is important to build a picture of exactly what you need the systems to be capable of, so that options can be evaluated eff ectively. “The devil is in the detail with systems selection”, says Ivan Seselj of business process management solution provider Promapp. “The difference between companies that get their requirements right and those that don’t can be as costly as a systems replacement within a few short years”.

Seselj says it takes a team effort to form a clear understanding of the capabilities that are needed from the new systems.

“Put together a team which includes subject matter experts (SMEs), as well as members with expertise on requirements. This will help later when it comes to ensuring buy-in to new business processes.”

He recommends working with SMEs to define “current state processes” – these provide a baseline for the capabilities needed to at least produce existing outputs.

“It’s not always easy for teams to recall all the processes they are involved in, because everyday business activity is not necessarily conducted in ‘process-speak’. If staff are having difficulties, activity analysis sheets can be a useful tool. Teams record the activities they are involved in as they perform them for say a week. These are then collated and activities are allocated to the processes they belong to – which can often identify additional processes that have been missed.” Seselj says the next step is to define optimum “future state processes”.

“Find out exactly what is driving the need for this new software, and then create high level designs of the desired processes that are enabled by the new system’s capabilities,” he says.

A key advantage of using a process-based framework to form an understanding of requirements is that it provides a structured approach for comparing the current state processes with future requirements.

“When the two are compared, the resulting ‘gap analysis’ can give a very clear picture of new capabilities required. When these are rated for importance, they can provide clear criteria to use in software selection.”