Internal Challenges in Implementations and How to Solve Them

August 24, 2020


Written by Drew Simmons


When I was growing up, my mother would always tell me, “nothing worth having in life is ever easy.”  It was one of those sayings where I would always roll my eyes every time I heard it.  I’m sure we have all had similar experiences as children.  However, this is one of the few sayings that I came to fully understand and appreciate later in life from my experience as an HR/Payroll System Implementation Consultant. Every major initiative has its challenges. Software implementations are no different. To ensure successful implementation projects, it is essential to consider the challenges that exist with these types of projects and devise methods to resolve those challenges. Here are some of the challenges I frequently observe clients encountering when working on implementations and ideas for how to overcome those challenges.


Taking on too much at one time

As a consultant, the first step I take when beginning a new implementation project is to review the client’s sales contract with their software vendor and the accompanying scope of work (SOW) document. These two documents outline what specific modules or functionality are set to be deployed during the implementation project, as well as the targeted timeframe for deployment. There are times when I review a project’s scope and think, “Is the client sure they want to (or can) do all this at one time?”. Fast forward to project kickoff, where I receive a list of contacts at the client organization that I’ll be leading through the implementation project. These lists are often short, indicating that there are not enough people working on the project. Based on my experience in previous system implementations, it is easy to tell when the client is taking on too much work at one time.  When deciding to implement a new system, it is important to determine what is feasible, given your team’s size and bandwidth. Be realistic here, so you don’t set your team up for failure. If your organization’s leadership team gives direction to deploy certain modules, it is your job to help them understand what is feasible or what should be prioritized, based on available resources. After all, you, the project team, your leadership team, and your consultants all want the same outcome: a successful implementation.

Conduct a resource evaluation before you kick off a system implementation to determine if what you’re setting out to do is realistic. Based on your resource evaluation, if you find that you or your team are taking on too much, consider a phased implementation. You also might want to request additional resources such as client-side support or adding more team members from your organization to help out with the implementation.


Not employing enough resources

Working on system implementations will require a multitude of team members across different roles in your organization. For example, if you’re implementing a core HR, payroll, recruiting, and benefits system, you’d want representatives from each of those teams to help with certain portions of the project. You wouldn’t limit your team to only those in the payroll department helping out. It is easy to underestimate how many people and what types of job roles will be needed for successful deployment.  A project team will need an Executive Sponsor who can sign off on major decisions and acts as a point of escalation to “unstick” projects when there are problems. A Project Manager is necessary to hold team members accountable for accomplishing project milestones in accordance with the project timeline. Subject matter experts (SMEs) share valuable knowledge on business processes, and how the new system will impact their respective areas of the business, which is essential insight.

Most clients are familiar with these types of project roles and have team members assigned to cover those roles. However, there are some additional roles that are often overlooked yet essential for implementation project success.  A change agent or change management team ensures that communications are created and distributed to strategically inform users about relevant areas of the project, with the intention of educating them and boosting user adoption.  Involving a technical resource will allow you to consider, develop, and test integrations and evaluate any security provisions that must be made to protect the organization. A program manager may be helpful if there are multiple projects being conducted simultaneously in your organization. The program manager would ensure that all projects are completed in a timely and synchronized manner, with the goal of moving all projects forward together to create a new data infrastructure for the organization.  A System Administrator must be designated to complete system configurations on the client-side that are needed before the software can be deployed.  Since testing is critical for project success, the client may also want to consider a User Acceptance Testing (UAT) task force. A UAT task force would include a team of employees who are brought in to help test the system.  The most effective UAT task force is one that is comprised of testers who have not been heavily involved with the project and have little exposure to process design decisions until shortly before testing begins. The goal of your UAT task force is to help to identify problems that end-users would experience and to solve those problems ahead of your system go-live.


Not identifying single points-of-failure or potential bottlenecks

Some of us may remember the Life cereal commercial campaign in the 1970s and 1980s. In many of the commercials there would be children around the breakfast table, refusing to eat Life cereal.  In one of the commercials, they say, “Give it to Mikey!  He’ll eat anything!”  In organizations, there is usually someone like Mikey who is exceptional at their job, or they dominate that one area that no one else can seem to master.  For this reason, the Mikeys of organizations are always sought after to help out with important strategic projects. While we encourage you to assign the Mikeys of your organization specific roles and tasks related to your implementation project, keep an eye out for signs that your Mikeys are becoming overburdened with their project duties or the combination of their duties in your project and the many other organizational projects they’re involved with. You don’t want to discover that your team’s Mikey is overburdened at a critical point in the project, when there is no time to stop and re-evaluate the roles of project team members (e.g., user acceptance testing, client-specific system configuration). In this instance, this person on your team has become what is known as the single point of failure.  Despite this term’s tone, it does not necessarily mean that they will fail at their role on the project. The single point of failure is defined as the person or component of the project that is critical because if it stops functioning, the project comes to a screeching halt.

To identify potential points of failure, consider the following questions:

  • Of all the roles on the project, does this person have more than one role?
  • If so, can they feasibly accomplish the tasks required in this role in a timely fashion?
  • What will happen to the project if this person leaves the organization?

Based on the answers to these questions, you may want to consider adding more resources to the project or consider the next point.


Relying on tribal knowledge to drive the project

In many cases, project teams can eloquently and effectively articulate their processes in detail during implementations. However, when someone subsequently asks for a written process document or a flowchart, it is sometimes like entering a field of crickets because no one has any answers. This phenomenon is known as tribal knowledge.  Tribal knowledge is when the team has unwritten information that is known to them, but not to anyone outside of the team.  Tribal knowledge is dangerous when trying to implement systems, especially when combined with the presence of a single point of failure (see the previous point). To ensure project success, eliminate the tribal knowledge by documenting processes. This helps all project team members (on both the client and implementation consulting side) to obtain a clear and consistent understanding of processes that allow them to assist in configuration, testing and training.

If you enjoyed this post, be sure to check out my other industry blogs:

Things You Can Do With Your HR Technology That Will Make Your Employees’ Lives Easier

Workarounds Lead to System Breakdowns


HRchitect can assist in mitigating the challenges cited above, and much more. Our expert consulting teams have decades of experience with HCM systems, and we work alongside you during system implementations to ensure your project is a success. Over the past two decades, HRchitect has helped thousands of organizations across the globe align their HCM technology initiatives with business objectives to achieve extraordinary results. HRchitect is a name you can trust, and the one-stop-shop for all your HCM technology needs from strategy, evaluation and selection, implementation, change management, ongoing support, and everything in between.


About Drew Simmons

Drew Simmons, HCM Implementation Services Consultant, has over 25 years of experience in the field of Human Resources.  Drew began his career as an HRIS practitioner but has also worked in the areas of Recruiting, Benefits, Compensation, Diversity and Inclusion, and HR Management.  Drew has worked in a multitude of industries that include banking and finance, healthcare, public relations, marketing and communications, and advertising.  Drew’s experience has given him a proven record of accomplishment in project management, system implementation, conflict resolution, and troubleshooting critical business issues.