It is not all about the tools... but they are pretty damn important!

In this article we will take a look at technology selection, specifically relating to recruitment and staffing software. Included here is our recommended process for buying and selling software (practical & effective), some common missteps, and of course, the implications of getting it wrong. To see common project failures for recruitment system change-out, checkout our article four here.

We have seen the software buying/selling process from all angles, so we have plenty of insider knowledge from both perspectives (both vendor and buyer) to share with you in this article. 

Sellers of tech products or implementation services, are well versed in responding to tenders and requests for quotes, more so than the experience that a buyer perhaps has in requesting them! The vendors' expansive tender exposure gives them an unfair advantage over buyers in this initial and crucial stage.

As independent technology consultants, we to know when buyers are making good or bad decisions. In some of our previous engagements we have done little else but walk buyers through their buying cycles. We endeavour to pass on some of our knowledge on the buying process here. Feel free to also read our previous articles relating to strategic alignment and project implementation. 

Implications of poor selection

There are many obvious tactical implications of choosing the wrong system including unhappy users and lack of productivity improvements. However, it is much harder to quantify the impact on upside benefits (a McKinsey study indicates that ~50% of projects significantly underdeliver), and that loss is, in fact the most damaging. This loss of upside is very hard to spot from the inside (because there is nothing to compare to), and is really only noticed by outsiders who have seen many new systems implemented and adopted successfully.

Following a new system implementation (and a well run education/change program), there should be noticeable improvements both in productivity and user satisfaction, if this has not the case, and people remain unhappy, or there are multiple ongoing issues, it is quite possible that the net impact is negative and will continue dragging on the organisation until it breaks or is changed again.

Recommended software system selection process 

Given the above mentioned implications of selecting the wrong system, here are some steps we recommend you take to avoid a misguided recruitment software choice.

Spoiler alert! Doing it right will take more time and energy than most people expect (and are comfortable to undertake), but all the indicators are that this effort is well worth it. 

1. Get clear about what your business' requirements (not what others need or think you need) - Agree and lock it in - avoid change and be confident! 
2. Take the time to estimate the value and impact of the new system at a detailed level. This will allow you to make informed decisions and set goals to hit after the new system goes live.
3. Only engage the market after you have set down requirements - vendors can add value to your requirements with suggestions, but they should not be relied upon to do your requirements analysis for you. Vendors have an inherent bias and may influence your decision.
4. Do your best to have vendors describe their systems' capabilities in line with your project scope and business objectives, so that you can compare features and benefits fairly. 
5. Involve a few, or several people from your organisation in the selection process. Different system users/buyers have their own biases too! 
6. Make your decision on hard data, including the fit between your requirements and the available systems, but also softer factors like usability and cultural fit (more on this below).
7. Remember that on most occasions the sales people will not be involved in the implementation and on boarding (or held accountable) after the deal is signed.

The softer side of decision making

Selecting a new system is not all about features and functions, there are other less absolute considerations that will have an impact on the overall outcome of your project. Here we provide a short list for reference along with some guidance:

• Non-functional requirements 

These are similar to basic functional requirements but more supportive, for example for hosted systems, where is the data housed? Do you have a legal requirement for it to be house in your own country? What service level agreement do you require? 

• Selection criteria 

These are softer still, and often include attributes of the vendor rather than the system they sell. For example: does the vendor have case studies or experience in your industry vertical? What size agencies are they currently supporting?

There may be 5 to 20 selection criteria that are significant enough to rule out any individual provider. Selection criteria need to be assessed because they are often judgement calls, for example how easy is a system to use.

• Flexibility in costs & negotiation

The actual fees for a system and a project are often less straight forward than they seem, and often costs can be negotiated and structured. Some vendors may be willing to modify their fees in return for other non-financial outcomes, for example acting as a reference site, or being a beta site for new components and features. Insider knowledge is helpful in exploring these options.

You're into the project and it doesn't seem like it's going well…

Here is what to look out for.

• A stressful implementation

This can be a sign of a poor match between your requirements and the system capabilities, or perhaps between the styles and expectations of you and the vendor. In our experience, this is most often a result of poor preparation; so as a first action review how detailed your scope is and if the system matches it well.

• Confusion/doubt that doesn't dissipate by a ? into the implementation

It is normal for implementation projects to be confusing at first, as there is a lot going on and steep learning curves are often experienced by the buyer. However, if confusion or lack of confidence continues well past a third of the implementation timeline, there may be something to be genuinely concerned about. 

• The vendors' internal teams (pre and post sales) do not agree (if they are different people)

Lack of consistency between pre and post sales team members is an indication that you have been ‘oversold’ and it is unlikely that you will get what you expected. 

• It's not written down, or people are resistant about writing it down

Everything to do with the project and its implementation should be documented, that might take a little extra effort, but without it there will be problems. Everyone involved with IT projects know this well, so if people aren't documenting there maybe a reason for it. Make sure you keep notes and get them verified by suppliers. 

• The relationship with your vendor is poor

Frayed relationships are an indication that there are already challenges or at least that the teams are not working well together. Good relationships help when the wheels start to fall off and teams are called upon to go above and beyond or when people need to be more proactive - this can only be witnessed in the presence of solid relationships. 

• He-said-she-said

If you are hearing defensive/aggressive conversations inferring that someone else made assurances, or did/did not take actions as promised, it should ring alarm bells. Not necessarily about the particular issue in question, but more widely about the project and team. These conversations indicate that proper process may be being neglected and/or that trust is lost, both are larger concerns than any individual issue. 

Getting back on track

Whilst there is no single silver bullet for fixing the problem of poor product/vendor selection, there are some approaches you can try. 

Focus on the outcomes (quantify) - review the project objectives, and if necessary go back and explicitly capture the project objectives. Can these objectives be derived from the selected system and vendor? Following this process will help you identify if the project is salvageable or needs to be terminated. 

Critical Success Factors - you can review the list of CSFs and think about the project from this perspective. Do you have these covered off? If so, it is possible that the project can be a success even though you may not hit it out of the park. If the fundamentals are in place then it is possible that issues are cosmetic. 

Critical Success Factors - Download here

Need for senior input - any significant change will require senior stakeholder input. This could include a renegotiation of agreements with the vendor, or modifications to the project parameters. With fundamental issues like poor system selection, remedial action is going to be required, even if it is a straight resetting of expectations, and this needs to be lead from the top. 

Salvage learnings and use for re-launch - If the decision is made to restart a project based on different systems, there is plenty that can be salvaged. This includes the overall organisational learning and more tactical items like documents, data and skills that if deployed will accelerate the new project. In fact much of the ‘client-side’ work needs.

In summary, reversing out of a technology change-out or restarting a project is no simple task, so it is well worth investing extra effort in the selection process. Larger organisations follow strong governance processes to ensure these important decisions are made well, even with the additional cost, time and money. 

We recommend utilizing multiple decision making processes including requirements matching and (more qualitative) assessments.

Expect some lack of clarity towards the beginning of the project as the teams start working together, but it is not a good sign if issues continue beyond the initial third of the project timeline. 

If you recognise that the project is faltering due to poor product or vendor selection, reassess the project in terms of it's objectives and CSFs. 

If the project is terminated, remember that valuable components can be salvaged. In fact, much of the ‘client side’ work can be reused if it has been undertaken in an orderly fashion.