The 10 Commandments for selecting a new software: Best practice guidelines

If Moses were  a software consultant,
he would probably have the
following tips on his tablets

RIO DE JANEIRO
From the moment corporate IT decided to eschew home-made systems for package software  two decades ago (in the most advanced economies, that is), user organizations have been using different methods to select the best software that matches their needs. My methodology was honed by a 15-year experience which started with Paris-based CXP (briefly part of Giga analyst group), an analyst-cum-consulting firm which was born out of the desire of large French companies to have a vendor-neutral outfit that could provide them with unbiased advice on the booming corporate software industry.

Since then I have been able to see what works, what does not, what tasks in the selection process can be improved. Surprisingly enough, most companies tend to make similar mistakes regardless of size, industry or geography. I am currently helping a client in Brazil navigate the shoals of finding a talent management tool and I am confronting issues similar to ones seen in Europe and the United States.

This post is a description of  what best practice I have witnessed and currently use as part of my software-selection methodology. I have summarized my findings in what I call, a tad pretentiously,  my Ten Commandments of  a software-selection system.

1. Thou shalt link your project to your company's business objectives

The first thing I ask a client when they tell me they are looking for a new HR system is, "What are your company's business objectives?" And I am still amazed to hear the answer, even from an HR leader, to the effect that they have no clue. My first piece of advice is that if you don't know what your company's business objectives are (increase market share? be recognized as the best in your industry? reduce costs? etc.) you better get acquainted with them ASAP. Sometimes I have to brace myself for the realization that the situation is even worse than I thought: the company has yet to determine what its objectives are. I have become known for harassing my clients until they manage to get from senior management clarity on this aspect, otherwise there is little point in the whole exercize. Only then can we move on and start linking the automation of a performance appraisal system or a new payroll to those overall goals. Yes, even payroll. I know that few companies, if any, have ever gained market share or attracted new customers with a brandnew payroll product, but assuming that your previous system managed to pay your employees accurately and in a timely fashion, if you have decided to replace it there should be more drivers than just, "Our vendor has gone under."  In one short sentence, show how this new HR project (regardless of scope) can contribute to the bottom line.


2. Thou shalt shirk away from a lengthy RFP

I am not a lazy person and do not charge my clients by the number of pages an RFP contains. So if I strongly advise against spending time to produce an RFP the size of a door-stopper it is for a good reason. In the goold old days when companies moved from home-made systems to standard software, it made sense to list every single feature needed, to compare which vendor would require the least amount of (expensive) customization. But now that the package-software market has reached functional maturity and that a new breed of vendors, web-based and with no possibility to customize, has emerged, spending an inordinate amount of time on listing every single requirement one can think of does not make sense any more. It is far more efficient to have fewer requirements, but well-chosen ones, which would allow you to differentiate between vendors since, at the end of the day, that is the point of the whole exercize: to select one vendor over others.

It is worth remembering that just because a requirement is crucial it does not mean it has to feature in your RFP. If you are looking at replacing your HR system of record,  there is little doubt that the ability to track employees is key, and yet you don't need to mention that in your RFP since by definition all HR systems worth their salt would have that feature which is now largely commoditized. So, since it will not help you differentiate between various offerings, don't waste your time on it. Similarly, some nice-to-have features which no vendor offers (say, expatriate management in a global HCM system) are not going to help you: since no vendor is likely to offer the feature, it will not help you differntiate between the vendors.

3. Thou shalt pay particular attention to integration points

A summary of my previous point (or commandment) is to focus on what really matters, such as a data model/architecture to reflect the 21st century and not the previous one, or integration points. We are in an industry that moves very fast, and we can be certain of few things about it except that one of the major issues I have been confronted with since I started out two decades ago will probably be around when I retire: integrating the different pieces of your HR system to make it deliver the value you expect. It is therefore key that you identify the different integration point between Payroll<->HR Admin <-> Time Management and of course between your overall HR system and other corporate applications.

Be aware that integration issues can arise not only when duct-taping systems from different vendors but even with products from a single vendor: either because it was the result of various acquisitions or because of lousy design.


4. Thou shalt consult ALL stakeholders

Long gone are the days when the IT department would buy, install, run an application and spring it on HR users unawares. Nowadays, it is more likely that HR will be the in the driver's seat of selecting an HR system, although in less advanced parts of the world it still is not the case. IT still has to be consulted if only to make sure that the system used does fit within the company's overall technology structure. If your company is an SAP shop, you will have to make the case very strongly that your HR-specific requirements need a PeopleSoft or Workday. But there are two types of stakeholders that need to be taken care of.

One are line managers and by extension other casual users. At the turn of the millennium it was enough to make sure that the system provided manager (or employee) self-service transactions and everybody was happy. Now, there is an increasing realization that HR tools are no longer the province of HR but of the whole organization. A successful recruiting drive brings on board not only HR specialists and recruiters but the recruiting (line) manager, other  colleagues-to-be, the applicants, maybe a manager + 1. In other words, HR has become too important to be left to HR only, and by way of consequence so have HR tools become: tools for everybody in the company.

Second, and even more important for global companies, is the need to also take into account the requirements of all types of users in different countries where you have subsidiaries. I still see many global projects where only a token interest is taken in the non-HQ workforce. Many global US-based companies suffer from this attitude, still believing that "If it's good for US it must be good for them." Thankfully, the belief that to be global means to be American everywhere is on the wane and when I take an international assignment I always make a point to visit the most important foreign operations  and meet face-to-face with a variety of users there. Where it is not practical because of time or budget reasons, I set up conference calls. The fact that I speak fluently five global languages is a tremendous help since HR is largely a "glocal" business and many HR users are monolingual: speaking, literally and metaphorically, their language can make or break the deal, so to speak. But regardless of your linguistic abilities, the point is that if you do not take into account all your constituents' needs, the system ends up being used only by a few and rejected by a majority. And for me that is the definition of failure. Not going over budget and beyond schedule. If anything, I'd rather have a system that costs more and took longer than initially planned but which most users like and enjoy using rather than one delivered on time, within budget and which everybody hates. I still see too much of that.


5. Thou shalt work with a vendor shortlist -not longlist

15 years ago when I started advising companies on what was the best HR system for them I would send out that lengthy RFP (decried in §2) to a good half a dozen vendors, often even up to eight, and spend quite some time analyzing the responses before selecting a short list of three. I still see too many companies doing that. And yet it is now a waste of time. If you have devised your RFP smartly, rather than comprehensively, a knowledgeable observer would easily know which top vendors are more likely to meet your needs. If your underlying technology is IBM (DB2) then Oracle EBS does not make sense. If you have unique customization needs and are paranoid about security and data confidentiality, then going true SaaS (such as with Workday) may be a non-starter.

One of the points of a compact, concise and precise RFP (as defined earlier) is that by allowing you to focus on differentiators you can go straight to the production of the shortlist of vendors who will receive your RFI/RFP. The time, resources and energy thus saved can be better employed doing your homework or due diligence.

6. Thou shalt do thy due diligence thoroughly

By due diligence I mean several activities that will allow you to get under the hood of the product and understand the culture of the vendor. Since you are likely to be doing business together for at least half a decade (the life expectancy of an HR system has come down from 7 years to less than 5 now) you better make sure you understand one another. Selecting a vendor is to a large extent akin to entering into a marriage with all its attendant ups and downs.

- Have meaningful, representative use cases to be used in scripted demos. Be particularly careful with on-premise systems which can doctored (customized). I know many companies that are still licking their wounds, the result of too credulous a belief that everything they saw during a demo was standard (or vanilla as we call it in our jargon) functionality when it actually involved hundreds of man-days of consulting work.

- I find it very useful to keep some "trump cards": a use case or a question that are sprung on the vendor during the demo to get an idea on how unexpected requirements (which always happen) can be taken care of, especially if you are planning to go with a web-based SaaS vendor where you don't have the liberty to customize your way out of a particularly complex but crucial need.

- "It's the references, stupid!": a relevant customer using the same system you are considering can provide you with more insight than pages of responses to an RFP and days of demoing. Again, you will place the cursor differently whether you are looking at SaaS or on-premise vendors, since with SaaS customers, everybody will be describing the same beast, whereas an on-premise customer may well be on a different release from the one you are considering and some of the points they are making will therefore not be relevant to you. Also, don't focus exclusively on product aspects but also on service quality, customer-centricity, how good the vendor is (or is not) at including your enhancement requests in future releases. Here again, older, on-premise systems will have to be gauged differently from newer, web-based SaaS products.


7. Thou shalt avoid falling prey to fads

Although the corporate software market, and its HR segment, is made up of literally hundreds of vendors, we are still quite a gregarious bunch, often adopting tools because others have. In the late '90s when I was still with CXP, a client of mine was the French savings bank network Caisses d'épargne (actually one member of the grouping.) I helped them select an HR system and they wanted PeopleSoft even though they didn't have the budget for it. And when I pointed out that another product would do the job just as well, I remember the whine: "But every HR director has PeopleSoft!" Sounded like a kid wanting the same toy as his buddy next door.

Things have not changed that much. Last week, an HR leader told me they were about to select Workday but he couldn't give me an objective reason for that. Actually, remembering point #1, he couldn't even link that decision to a business reason, or even what HR features he wanted, apart from some high-level HR functions. But he wanted Workday because he had heard it was a good system.

Grievous error. As I always tell my client, "there is NOT such a thing as a good product or a bad product." All products and vendors have their pros and cons, you have to match them to your technical, functional, corporate and strategic circumstances and decide which one will be the lowest risk. Workday is undoubtedly the most remarkable corporate and HR tool to have emerged in a long time. And yet it is not the cure-all. In many cases it is not the best tool, it could even be counter-productive to use it. So, Mr./Madam User, please do yourself a favor and refrain from being a software fashionista.


8. Thou shalt have a sponsor

Whenever I get involved in an HR project,  especially at the initial system-selection stage, I always insist on having a "sponsor" or "champion." This is not the key contact that is a liaison between the company and the outside world, but a senior manager (either the Head of HR or the CEO, but preferably a C-level executive) who, when the time comes, will bang heads together to make things happen. Barring such a role, the chances of such a project succeeding will be limited.

The sad state of things is that often such  a person is either not identified or if they are they keep a low-profile apart from attending a launch party or steering-committee meetings. They are often afraid of becoming the fall guy, taking the brunt of criticism should the project not deliver the goods, not realizing that by such an attitude they turn that possibility into a self-fulfilling prophecy.


9. Thou shalt negotiate carefully

"If we only knew" is the perennial cry of the client when things go wrong and they realize that thy have limited recourse options. If you are adopting an on-premise system, where you are basically in charge of everything, make sure that any roadmap promises are not something you overheard at a user conference but a contractual commitment that is part and parcel of the contract. Otherwise, apart from withholding  maintenance fees, you do not have much leverage with your vendor. If you are a SaaS customer, you are in a different situation: at least you didn't pay a hefty license fee upfront to get started, so the revenue your vendor gets from you is the monthly susbcription fee which you can withhold. Because in this model the vendor owns both the software and your data be even more careful before signing the SLA contract, especially if the vendor insists that their template is the only one available and are reluctant to modify it to accommodate your needs.

I am not saying you should base your relationship entirely on legal terms, but make sure that should litigation be unavoidable, you have some good cards to play.

10. Thou shalt hope for the best and plan for the worst

Having a Plan B is always a good idea, whatever endeavor you are in. If you have decided to use a SaaS-based system, make sure that you are covered in terms of disruption to the service, that you have in place a disaster-recovery strategy (in conjunction/addition to what the vendor already offers.) If you are planning on changing your payroll system, don't discontinue the previous one until the new one is up and running to your entire satisfaction, not merely selected. This means way beyond the few months' parallel payroll exercize.


Of course, success cannot be guaranteed until the system has been implemented (and a future blog will address what I am likely to call my 10 Commandments for a successful implementation.) But many seeds for a successful implementation are planted at the earlier, system-selection stage, and as such this stage is crucial. Skip it or skimp on it at your own peril!