Getty Images/iStockphoto

The most common HR tech implementation challenges

Perennial project problems include incomplete requirements and employees taking time off close to the go-live. Here are some of the most common HR tech implementation challenges.

HR tech implementations often encounter challenges. Some problems occur early in the implementation, while others don't surface until after go-live.

Project leaders should learn about the most common HR tech implementation challenges so they can attempt to avoid them. Here are some of the most frequently occurring implementation problems, why they happen and how to solve them.

Vacationing employees

A project schedule can clash with vacation schedules due to one of the following reasons:

  • The project schedule didn't account for common vacation periods, such as national holidays or the summer.
  • The go-live was scheduled for Jan. 1 when many employees are still on holiday break.
  • Essential project resources planned extended vacations.

These potential risks are all preventable. The project leader may have downplayed the risk or been forced to accept it to receive project approval. For example, perhaps they had to ensure the go-live date didn't overlap with another large project or they built the schedule based on the preferred go-live date, which led to a major milestone occurring on a problematic day.

To mitigate this risk, reject vacation requests that would affect project milestones and plan to run additional training sessions before and after go-live so team members can catch up on any missed material. Other potential solutions include assigning a backup for all critical project resources and adjusting the schedule to avoid potential problems.

Incomplete requirements

Requirements documents are some of the most important implementation paperwork. They define the features your organization needs and list requirements for security, performance and languages, among other aspects.

However, they are often unclear. Here are a few reasons why the requirements documents can be confusing:

  • Document writers assumed a requirement is so obvious that they don't need to mention it.
  • The right stakeholders were not consulted.
  • Stakeholders provided incorrect information.
  • Requirements weren't defined at the project start.
  • Team members forgot to add requirements.
  • Team members assumed they would clarify the requirements during implementation.
  • The data migration plan was not specific enough.

Review the requirements early with the help of subject matter experts to ensure they are clear. As the implementation begins, evaluate the requirements based on the number of questions raised.

Remember that changing requirements once the project starts may result in change requests and additional costs.

Insufficient budget

Getting approval to implement a new HR system can be difficult, especially when company leaders think the project is expensive. However, project leaders may not receive the necessary funds if they do any of the following:

  • underestimate licensing costs;
  • omit a contingency budget or make it too small;
  • omit consultant costs or costs for other temporary help;
  • leave out change requests costs;
  • underestimate the cost for particular requirements, such as interfaces to other systems; and
  • leave off post-implementation costs for addressing issues, enhancement requests and ongoing support.

Project leaders that already made these mistakes and are out of money have a few options. The first is to approach the executive sponsor for additional funds. The second is to consider scaling back the implementation scope and completing some of the work during the next phase.

Another option is working with the implementation partner to find cost-effective alternatives for the most expensive requirements or asking them to move some of the project payments to the next fiscal year.

Change requests

Change requests often come up during contract negotiations with a software vendor or implementation partner. However, the specifics can be unclear. Before signing a contract, make sure relevant stakeholders are clear and in agreement on all of the following:

  • What constitutes a change request? For example, how much does the desired feature deviate from the stated requirement before a change request is required?
  • Is there a fee for estimating the change request effort? If so, what are the rates for estimating the change request? An hourly rate is often provided for the different types of skill sets, such as a software developer or a project manager.
  • What fees are included in a change request besides the hourly rates for the employees implementing the change?
  • What is the process for requesting a change request and having it approved? Ensure that only needed change requests go forward.

If the change request process is not well documented, ask for clarification.

Lack of resources

Implementing a new HR system requires many different subject matter experts and team members. The implementation will likely include, among others, a project manager, a data migration expert and one or more subject matter experts for each module. Consider these questions when assembling a team:

  • Are the people assigned to the project knowledgeable about their area of responsibility, and do they have the right skill set for their tasks?
  • Do the project team members have time to work on the project?
  • Is the project team large enough to implement and support the HR system post-implementation?
  • Is there a backup resource assigned to each key area?

For example, an individual may be too junior for their assigned role. Potential solutions include assigning a more senior member of the team to help them, bringing on additional help or replacing the team member altogether. 

Post-implementation support

Once the HR system implementation is complete, maintenance begins. To ensure the transition from the implementation partner to internal resources is smooth, have a detailed plan in place that includes answers to the following questions:

  • Who will train employees at go-live and beyond?
  • Who is responsible for making configuration changes, and how many people does that require?
  • How are employee questions tracked and who answers them?
  • Is a third-party vendor on board to help support the HR system, and have they signed a contract?
  • Who will create requested reports and dashboards?
  • Who will enter and maintain the system data?

Be sure to create a plan before go-live to avoid confusion about who should do what. Problems may take longer to resolve or may never get addressed once the system is live.

If time is of the essence, develop a short-term plan with key stakeholders while creating a long-term strategy.

Inexperienced implementation partner

Many organizations hire an implementation partner. The arrangement comes with multiple benefits, including the partner's experience, HR system knowledge and ability to estimate required project effort.

However, problems with the implementation partner may arise during the project. Here are some common warning signs that a problem is developing:

  • missed deadlines;
  • multiple change requests;
  • configuration issues;
  • unaddressed requirements; and
  • lack of knowledge in critical areas.

Finding a new implementation partner can be costly and may delay the project. Instead, discuss the issues with the implementation partner and see if they can provide solutions. For example, the partner may replace junior consultants with ones with more experience.

Bringing on more technical resources to support the implementation partner is also an option, but the implementation partner must take part in that decision.

Cutting corners

At the outset of the project, create a list of implementation requirements.

Everyone on the project should stick to that list. If those requirements are eliminated or only half-implemented, the HR system may be difficult to use, unreliable or lacking key features.

Think about the following points before changing or deferring requirements:

  • If a feature isn't implemented, how are end users affected?
  • Can the feature be implemented after go-live without severe negative consequences?
  • If a feature is complex, can a subset of the feature be implemented instead?
  • If migrating all legacy system data before go-live is impossible, how little data can the team migrate and still have the system be functional?
  • Will the company approve delaying the implementation of some items?

The end-user experience suffers when you modify or haphazardly drop features. A negative user experience can lead to additional pressure post-implementation to fix issues.

For poorly implemented features, determine the underlying reasons and then develop a plan to address them. The plan could include assigning additional resources to fix the issues, turning the feature off until it's corrected or providing additional feature training.

About the author
Eric St-Jean is an independent consultant with a focus on HR technology, project management and Microsoft Excel training and automation. St-Jean worked in high tech for over 14 years before transitioning to HR, where he focuses on implementing and managing HCM systems.

Dig Deeper on Core HR administration technology

Business Analytics
Content Management
and ESG