#fail: 4 Common Reasons Why Implementations Fail (And How To Make Sure Yours Isn’t One of Them)

Woman looking confused with laptop

For most organizations, it is a significant hurdle to build a business case and get funding to support a talent management technology initiative. Once you get that far, high expectations for the impact of the software 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 frustrating 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: 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.

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 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. 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.

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 technologies 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 deployment, you’ll be setting up your organization for future success.

1 Comment

  • Notice: Undefined offset: 180 in /home/khxupnxym8b9/public_html/staging/wp-content/themes/meridian/functions.php on line 303
    educemgr says:

    Having worked with Nyla for many years, I’ve seen #1 quite often. Rarely are project dates decided in a vaccum, and how you decide the date is almost as important as what the date is. My advice (if you “own” the decision) is to think long and hard about how you intend to make that decision and who you’re going to involve in the process. A RACI chart can help you figure out some of those details, bring the “How” to your sponsor – if they agree – you’re in a good place – if they give you a date… look out!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.