How RJR Structures an HCM System Implementation

Halfway through a fifteen-week UKG Pro implementation, the client's HR director asks if the system can handle a benefit plan structure that wasn't in the original scope. It can. Configuring it would take three weeks. The go-live date is in seven.

This is the decision point that determines whether an implementation stays on schedule or becomes a six-month project. RJR's answer is not "no." It is: here is what adding that scope does to the timeline, and here is the formal change order. The decision belongs to the client. The consequence analysis belongs to RJR.

Phase-gated engagement structure

RJR structures HCM implementations in defined phases, each with a specific set of deliverables, acceptance criteria, and a formal gate before the next phase begins.

1. Discovery and current-state assessment

Document the existing payroll configuration, identify data quality problems before migration begins, map integrations, and confirm scope boundaries in writing. Open decisions are logged immediately, not left for a later meeting.

2. Configuration

Build the system to the documented specification. Configuration decisions that deviate from the specification require a formal change to the scope document. RJR does not allow verbal scope changes.

3. Data migration

RJR's standard is to assess data quality before migration, not during. Legacy data with known problems (duplicate employee records, missing pay rate history, terminated employees with open garnishments) requires remediation in the legacy system before the migration extract. Migrating bad data into a new system does not fix the data. It spreads the problem.

4. Testing

Unit testing of individual configuration elements, integration testing of connected systems, and end-to-end parallel payroll testing with real employee data. Parallel payroll testing runs a minimum of two complete pay cycles before go-live is authorized. A single parallel cycle is not sufficient to catch period-boundary errors.

5. Go-live and hypercare

Go-live authorization requires formal sign-off against the acceptance criteria established in Discovery. Post-go-live hypercare runs a minimum of two pay periods, with RJR configuration resources available to respond to issues within the current pay cycle, not at the next scheduled meeting.

Open decision log and dependency register

RJR maintains a written open decision log throughout every implementation. Each open item has an owner, a due date, and a dependency flag indicating which downstream deliverables it blocks. When an open item is resolved, the resolution is documented with the rationale, not just the outcome.

This practice exists because HCM implementations span weeks to months, involve multiple stakeholders, and accumulate decisions that affect each other. A benefits configuration decision made in week three may constrain a payroll configuration decision in week eight. Without a written record, the week-eight team doesn't know the constraint exists.

The dependency register documents which deliverables block other deliverables, so schedule risk is visible before it becomes schedule failure. If the client's HRIS data extract is three days late, the dependency register shows immediately which downstream activities are affected and by how much.

Scope boundary management

RJR establishes scope boundaries in writing at the start of every engagement. What is in scope. What is explicitly out of scope. What the process is for adding scope.

Scope boundaries are not a defensive posture. They are a project management tool. A client who knows exactly what is included in the current engagement can make informed decisions about what to add and what to defer. A client operating without clear scope boundaries makes those same decisions implicitly, usually in the form of "while we're in there, can we also..."

Scope changes are handled through a formal change order process. The change order documents what is being added, what it costs in time and budget, and which existing deliverables are affected. The client signs before work begins. This protects the timeline and prevents the situation where a go-live date is missed and neither party is sure whose scope expansion caused it.

What 100+ implementations teaches you

RJR has completed more than 100 HCM implementations across manufacturing, government and public sector, retail, healthcare, financial services, and professional services. That volume means the firm has seen the failure modes: the configuration decisions that look fine in testing and fail in production, the data migration approaches that work for small data sets and break at scale, the parallel payroll configurations that pass on a controlled pay period and fail on a first-of-month or quarter-end period.

The methodology RJR uses reflects what those implementations taught. Phase gates enforce discipline. Written decisions prevent drift. Parallel payroll with real data catches what sample data misses. These are not aspirational practices. They are the specific behaviors that separate implementations that land on time from implementations that don't.