Most HR and IT leaders don’t set out to “fail an implementation.” But the data is brutal: depending on whose study you look at, only about 30–35% of large IT projects are fully successful, with the rest either over budget, late, or failing outright. OpenCommons+1

HR technology and HRIS projects are no exception. One SHRM summary of recent survey work notes that nearly 1 in 4 HR tech implementations fail to meet adoption expectations, and Gartner has found that the average HRIS is actively used by only about a third of employees. SHRM

For a platform like Rippling—where HR, IT, payroll, spend and identity all converge—the stakes are even higher. A failed or “limping” implementation can poison the well for years: people stop trusting the data, avoid the system, and rebuild shadow processes in spreadsheets and email.

At thePeopleStack, we’ve led consultative and managed Rippling implementations across dozens of clients and industries. The patterns are remarkably consistent: by the time we’re called in to rescue or optimize a struggling rollout, the root causes look very similar.

This post is about those patterns—and how to avoid them.

1. The uncomfortable truth: why implementations fail so often

Across ERP, HRIS, and broader digital transformation projects, research points to a familiar cluster of failure modes:

• Unclear objectives and requirements
• Lack of executive sponsorship
• Weak change management and poor communication
• Insufficient training and support
• Bad or incomplete data migration
• Unrealistic timelines and under-resourcing netsuite.com+2ClickLearn - Digital Adoption Platform+2

Academic work on HRIS failures reaches similar conclusions: a systematic review of HRIS projects identified leadership, planning, change management, communication and training as the five dominant factors behind failure. ResearchGate

Multiple practitioner studies on HR system rollouts reinforce that top management support is the single most critical success factor; when senior leaders treat the project as optional or “HR’s problem,” failure rates rise sharply. Exude Human Capital+1

In other words: most failing implementations don’t die because of the software. They die because of how the organization approaches the change.

2. Pattern #1 – “Install the tool” instead of “solve the business problem”

What goes wrong

Many implementations start with a sentence like:

“We’re implementing Rippling to replace our old HR system.”

That sounds reasonable—but it’s not a business outcome. So projects drift into:

• Endless debates about configurations and edge cases
• Scope creep (“since we’re in there anyway, can we also…”)
• Misalignment between HR, Finance, and IT on what “success” actually is

When we’re brought in to triage, we often find no agreed success metrics beyond “go live on date X,” and no shared future-state process maps.

What the research says

HRIS and HR tech case studies consistently list lack of clear goals and system requirements as a top implementation mistake. Organizations rush to configure without first defining what the system is meant to enable—leading to mismatches between features and actual needs. ROCKCREST+1

How to avoid it (and how we approach it at thePeopleStack)

Before we touch configuration, we push clients through a short but sharp Discovery & Architecture phase:

• Define 3–5 concrete business outcomes, e.g.:
  • Reduce average onboarding time from 10 days to 3
  • Achieve 100% completion for mandatory compliance training within 30 days
  • Eliminate manual payroll adjustments except for true exceptions
• Map “today vs. tomorrow” for key processes:
  • Hiring & onboarding
  • Job changes & compensation
  • Offboarding & terminations
  • IT access, device, and app provisioning
• Translate those into Rippling design decisions:
  • Which modules in phase 1 vs. later
  • What data needs to be clean on day one
  • Which workflows and approvals must exist at go-live

Once those outcomes are explicit, “success” is something you can measure—not just a date on a project plan.

3. Pattern #2 – Weak executive sponsorship and governance

What goes wrong

From the outside, a Rippling implementation looks like a “People team project.” Internally, that often translates into:

• HR owning everything, with limited engagement from Finance, IT, or Operations
• No clear executive sponsor who can resolve cross-functional conflicts
• Project work being done “off the side of the desk”

Studies on IT and ERP projects repeatedly point to executive sponsorship and user involvement as key differentiators between success and failure. thestory.is+2en.tigosolutions.com+2

How to avoid it

You need explicit governance:

• A named executive sponsor (often a COO, CFO, or CHRO) who:
  • Publicly champions the program
  • Sets expectations that Rippling is how work gets done
  • Clears roadblocks and approves policy decisions
• A cross-functional steering group with HR, Finance, and IT that:
  • Meets on a regular cadence (weekly or biweekly)
  • Owns decisions on data ownership, approvals, and integration priorities
• A project owner on the client side who:
  • Has real time allocated (not 5% on top of their day job)
  • Is empowered to make design decisions with guidance from us

At thePeopleStack, we treat governance as non-optional. If there’s no real sponsor or steering group, we flag the risk early and help the client fix it before configuration runs ahead of alignment.

4. Pattern #3 – Underestimating change management and adoption

What goes wrong

A surprisingly large number of HR tech projects still assume:

“If we configure it correctly, people will use it.”

In reality:

• Managers continue submitting changes via old spreadsheets or ad-hoc emails
• Employees ignore self-service because it feels confusing or untrustworthy
• IT keeps using separate tools for devices or app provisioning

Research on HR tech adoption shows that a meaningful share of projects “fail” not because the system doesn’t work, but because adoption never reaches critical mass. SHRM+1

Change management studies for ERP and HR systems emphasize that technology is rarely the bottleneck—people are. Resistance increases when the “why” and “what’s changing for me” aren’t clear, when training is thin, and when managers don’t model the new behaviors. prosci.com+1

How to avoid it

For Rippling, we design change and adoption like a product launch:

1. Stakeholder mapping
   • HR & PeopleOps
   • Finance & Payroll
   • IT / Security
   • Front-line managers
   • Employees / contingent workers
2. Tailored messaging
   • Executives: visibility, control, risk reduction, cost savings
   • Managers: faster approvals, fewer emails, clear tasks
   • Employees: one place to go for time off, pay, benefits, devices, and learning
3. Training and support model
   • Short, role-specific training sessions (30–60 minutes) instead of generic “all-hands” demos
   • Asynchronous assets: short video walkthroughs, Rippling-friendly job aids, FAQ pages
   • Office hours the first few weeks after go-live
4. Governance around “shadow processes”
   • Clearly retire the old ways of working (and enforce it)
   • Use Rippling workflows and tasks—no “workaround spreadsheets” for core processes

When we manage implementations, we treat change management as a major workstream—not an afterthought.

5. Pattern #4 – Data quality and migration treated as “IT’s problem”

What goes wrong

Data migration is often where projects quietly derail:

• Decades of inconsistent job titles, locations, departments
• Duplicate or conflicting employee records across payroll, ATS, and legacy HR systems
• Missing or incorrect tax, banking, or benefits data
• Contractor vs. employee statuses that don’t match reality

ERP and HRIS implementation research consistently lists poor data quality, inadequate data cleansing, and underestimated data migration effort as core failure factors. Software Connect+3ClickLearn - Digital Adoption Platform+3netsuite.com+3

In the Rippling context, dirty data doesn’t just mean ugly reports:

• Workflows route to the wrong managers
• Access and devices are misprovisioned
• Payroll runs with incorrect classifications or tax settings
• Compliance reporting becomes unreliable

How to avoid it

We treat data as its own mini-project:

• Canonical data model
  Define the single source of truth for:
  • Legal entity, location, and cost centers
  • Job architecture (levels, families, functions)
  • Manager relationships
• Data profiling & cleansing
  Before migration, we:
  • Run reports from legacy systems
  • Identify anomalies (e.g., employees with no manager, duplicate emails)
  • Work with HR/Finance to fix them at the source
• Iterative test loads
  Use multiple test imports into a Rippling sandbox:
  • Validate workflows, permissions, and analytics
  • Catch misconfigurations around pay types, policies, and permissions

This is where a managed implementation partner pays off: we’ve seen most of the common failure patterns already and can spot issues in the data before they hit production.

6. Pattern #5 – Ignoring integrations and architecture until too late

What goes wrong

Rippling rarely lives alone. You usually have:

• Applicant tracking (Greenhouse, Lever, Workable, etc.)
• Finance and accounting (NetSuite, QuickBooks, Xero, Sage Intacct)
• Time & attendance, scheduling, or POS systems
• Industry-specific tools (clinical systems, logistics platforms, etc.)

Common failure modes:

• Treating integrations as a “Phase 5” problem instead of core to the initial design
• Assuming vendor-native connectors will cover every scenario
• Underestimating how approvals, coding, and data flows will work end-to-end

Modern ERP and HRIS literature constantly highlights system integration and compatibility as key implementation risks: misaligned data models and workflows lead to inconsistent records and broken processes across systems. Outsail+2PeopleSpheres+2

How to avoid it

We bake integration thinking into the blueprint:

• System inventory & data flow map
  Clarify what system is the system of record for:
  • Employees & org structure
  • Time and attendance
  • Financial dimensions and GL coding
  • Devices, apps, and access
• Integration strategy
  • Native Rippling connectors where they fit the use case
  • Middleware or custom functions where needed
  • Clear ownership: which team fixes issues when data breaks

Rippling’s platform is powerful, but power without an architecture can create “automated chaos.” ThePeopleStack’s role is to design coherent flows so automation amplifies good processes instead of bad ones.

7. Pattern #6 – Unrealistic timelines and under-resourced teams

What goes wrong

A classic pattern:

“Let’s get this live in 6–8 weeks, and everyone can work on it alongside their full-time jobs.”

Research on HRIS implementations notes that teams often underestimate the time and dedication required, leading to rushed decisions, insufficient testing, and burnout. Helios HR+1

ERP analyses tell the same story: compressed timelines, fluctuating budgets, and inadequate resourcing correlate strongly with failure, rework, and cost overruns. netsuite.com+1

How to avoid it

For Rippling, we design timelines based on complexity, not vendor marketing:

• Number of entities and countries
• Modules in scope (HRIS only vs HRIS + Payroll + IT + Spend + LMS, etc.)
• Integration depth with external systems
• Internal capacity for testing and change management

Then we build a realistic plan:

• Phased rollouts instead of “big bang,” e.g.:
  • Phase 1: Core HR + org structure + basic approvals
  • Phase 2: Payroll and time tracking
  • Phase 3: IT, devices, apps, and spend
  • Later: Performance, learning, advanced analytics
• Clear RACI between:
  • Client HR/Finance/IT teams
  • thePeopleStack implementation team
  • Rippling support

Managed implementations are essentially a way of “renting a project team” that knows the terrain, so your internal people can focus on decisions—not figuring out what questions to ask.

8. Pattern #7 – “Go-live = success” and the missing optimization phase

What goes wrong

Even projects that reach go-live often stall after the first payroll run:

• No clear plan for incremental improvements
• New business needs (e.g., new entities, new pay policies) piled on ad-hoc
• No owner for analytics, workflows, and policy evolution

But HRIS best-practice guides emphasize that post-implementation optimization—continuous review, configuration refinement, and new feature adoption—is what turns a working system into a strategic asset. community.sap.com+1

How to avoid it

We treat go-live as the end of Phase 1:

• Define a 90-day optimization plan:
  • Capture feedback from HR, managers, and employees
  • Triage issues vs. enhancements
  • Tune workflows, approval chains, and permissions
• Set up regular health checks:
  • Quarterly review of:
    • Data quality (missing fields, bad values)
    • Workflow performance (stuck approvals, SLAs)
    • Security and access (role creep, orphaned accounts)
• Optionally move into a managed services model where:
  • thePeopleStack owns ongoing configuration changes
  • You get a roadmap of improvements tied to your business goals

This is where many self-implemented projects quietly drift into “we have Rippling, but we still do half of this in spreadsheets.” Our goal is to prevent that drift.

9. A practical checklist: how to de-risk your Rippling implementation

Whether you’re starting fresh or trying to rescue a struggling rollout, here’s a condensed checklist:

1. Outcomes & scope
   • Have we defined 3–5 measurable business outcomes?
   • Do we have clear “in scope / out of scope” for phase 1?
2. Governance
   • Is there a named executive sponsor?
   • Do HR, Finance, and IT all have seats at the table?
   • Is there a cross-functional steering group with a meeting cadence?
3. Change & adoption
   • Do we have a change management plan beyond training sessions?
   • Have we mapped messages and training to each stakeholder group?
   • Have we explicitly shut down old processes and tools?
4. Data & integrations
   • Have we profiled and cleansed core HR, payroll, and org data?
   • Do we know what systems will integrate with Rippling and how?
   • Have we run multiple test loads and end-to-end scenarios?
5. Timeline & resourcing
   • Is the plan based on complexity, not wishful thinking?
   • Are key people allocated real time for the project?
   • Do we have a phased rollout strategy?
6. Post-go-live
   • Is there a defined 90-day optimization window?
   • Who owns ongoing configuration and improvements?
   • How will we measure success over time (KPIs, adoption metrics, error rates)?

If you can’t answer “yes” to most of these, you’re carrying avoidable risk.

10. Where thePeopleStack fits in

Because we focus specifically on Rippling consultative and managed implementations, we tend to get involved in one of three scenarios:

1. Greenfield implementations
   A company wants to “do it right the first time” and brings us in from discovery through go-live and optimization.
2. Rescue / re-implementation
   Rippling is live, but:
   • Workflows are inconsistent
   • Data is messy
   • Adoption is low
     We stabilize the foundation, then rebuild the architecture around business outcomes.
3. Managed PeopleOps / Admin
   The organization doesn’t want to build deep in-house Rippling expertise. We:
   • Own configuration changes and optimizations
   • Partner with HR, Finance, and IT on roadmap and governance
   • Provide ongoing training and support

Across all three, our goal is the same:
Turn Rippling from “a system we bought” into “the operational backbone of how we run People, Payroll, IT and Spend.”

‍