#fail: 4 Common Reasons Why Talent Management Software Implementations Fail (and How to Make Sure Yours Isn’t One of Them)

Woman with hand on her head

For most organizations, it is a significant hurdle to build a business case and get funding to support a talent management software implementation initiative. Once you get that far, high expectations for the impact of the technology have already been set. Make sure that you position yourself for success by avoiding these common pitfalls that often impede the initial deployment and organizational acceptance of new technologies.

1. Setting an arbitrary go live date.

There is nothing more defeating than having a go live date set before an implementation project has been properly scoped. Without knowing what requirements must be met, what resources are available, and what task dependencies will affect your timeline, it is impossible to accurately select a production date. And yet, many teams are faced with just that—a go live date has been pre-selected and promised as an organizational objective or individual goal, and you must work to that date whether or not it is realistic. Obviously, if you are in a leadership position or have authority over the project the answer is simple: don’t announce a date until you have the necessary information to provide an accurate target. If this is not the case and you’re faced with an immovable date, manage it another way. One option is to identify the critical items that must be met by that date, and provide a roadmap showing what will be met in the initial phase and future phases. This approach will allow you to define a project that will be successful rather than aiming for a date you are likely to miss. Another option is to create a resource plan showing what can reasonably be accomplished based on currently identified resources, and defining the additional headcount needed to address the full scope within the desired timeline. This course of action demonstrates the possibility of meeting the go live date if additional investment is made.

2. Allowing ambiguous requirements.

Some organizations elect to define high-level requirements, while others do not define requirements at all (see #3 below). Often companies purposely keep requirements vague thinking that this will lead to quick consensus and show commonality across the enterprise. However, it just delays the inevitable. At some point in the implementation, you’ll need to get to the details and differences will be uncovered; the later this happens the less time you’ll have to recover from it. The best-case scenario is to have these detailed requirements documented before selecting a talent management software vendor so you can ensure that your selected provider is able to accommodate your needs. The second-best option is to scope some requirements and discovery time at the front end of your project that either you or your selected vendor/consultant can facilitate. The situation you want to avoid is having configuration delays because your team is confronted with making compromises they hadn’t planned on making, or worse yet, having issues surface during user acceptance testing when you thought your solution was already solidified.

3. Letting the technology lead the way.

Remember the age-old question, “Which came first, the chicken or the egg?” Well, there’s no equivalent here…unless you are in a pandemic.* You must absolutely understand your business objectives and requirements first before creating your solution. All too often, organizations want to see features and functionality and then decide what to use. That approach is fine if you are reviewing functionality in the context of your business needs, but it does not lead to success if you are making decisions based on features alone. If you hear your team making comments like “that looks interesting, I bet we could figure out a way to use it” you know that you are straying off course. The best way to avoid this situation is by always keeping your business objectives in focus and ensuring that each item that you are considering during design and configuration addresses an actual business requirement.

* Companies flocked to virtual classroom technology at the onset of COVID as a way to provide training to employees when in-person instruction was not a possibility. In this particular situation, features and functionality led the way and process was defined after. But this was not ideal and should be viewed as an exception. 

4. Waiting to Identify System Administrator(s).

When someone knows that in the end they will be responsible for something, they have more skin in the game during the implementation. Don’t miss the opportunity to capitalize on this. By selecting your system administrator—and other administrators—before the implementation begins, you’ll have a team that goes into the project with the right frame of mind. By delaying these decisions, you could have people in the room thinking “this doesn’t apply to me” or electing to multi-task because they don’t know that they will be eventually accountable. Establishing planned ownership of systems and processes early will ensure that participants have a keen focus on the areas that they know will directly affect them. [The ultimate #fail? Hiring a system administrator from outside the company and not bringing them in until the end of implementation. They miss all the discussion leading to the configuration, do not get exposure to the rest of the team and what matters to them, and lose countless hours of on-the-job system training. Enough said.]

Implementation is just the first step in an ongoing, dynamic process to effectively leverage talent management software within your organization. Lead the way to better adoption and organizational acceptance by ensuring your implementation is anchored by well-defined business objectives and requirements, realistic scope, and a clearly identified resource plan. By doing what you can to ensure a successful initial technology deployment, you’ll be setting up your organization for future success.

 

Related Content

3 Tips for Effective Software Requirements Gathering

Building Blocks for a Successful Cross-Module Implementation

Comments are closed here.