An HRIS implementation project plan, phase by phase

Many HRIS plans start as a list of dates from the vendor. That list covers the vendor's work. It leaves out most of yours: mapping how things run today, cleaning data, getting Finance and IT to agree, training managers, and deciding whether you are ready to switch.

This plan covers the whole job. It has four phases and a support period after go-live. Each phase ends with a short list of things that must be true before you move on. Those lists are what keep a late phase from quietly eating the time set aside for testing.

Phase 1: discovery and current state

The goal of this phase is to know exactly what you are replacing. People skip it because it feels like looking backward. Then they find the undocumented spreadsheet in week nine.

• Map each in-scope process as it runs today. Hire to onboard, time off, the payroll run, benefits enrollment, offboarding. Write the real steps, including the emails and the re-keying.
• Flag the steps that hurt. Double entry, manual checks, approvals that sit in an inbox. These become your reasons for the project and your test cases later.
• Inventory every data source. The current HR system, the payroll provider, benefits carrier portals, and every spreadsheet someone keeps on the side.
• Log compliance risks. Anything where today's process depends on one person remembering to do something.

Finish before moving on: a current-state map exists for every in-scope process; bottlenecks, data silos and compliance risks are logged; legacy data sources are inventoried.

Phase 2: future state and vendor selection

Design how you want each process to run before you compare vendors. If you pick the system first, its defaults become your process and nobody decides that on purpose.

• Write the future-state steps next to the current ones. Step for step, so the differences are easy to see.
• Turn the differences into requirements. "The start date must trigger the IT account request" is a requirement. "Better onboarding" is a wish.
• Score vendors against those requirements. Use one scorecard and have the same group score every vendor.
• Get Legal to read the contract and the data terms. Do this before the final demo, while you still have room to negotiate.
• Agree the business case. Cost today, cost of each option, payback, and who signs.

Finish before moving on: future-state maps are signed off by HR, IT and Finance; the vendor scorecard is complete; Legal has reviewed the contract and data terms.

Phase 3: configuration, data migration and integration

This is the longest phase and the one where three kinds of work run side by side. Give each its own owner.

Configuration

Pay codes, deductions, tax jurisdictions, time-off accrual rules, approval chains, security roles. Configure from your future-state maps. When the vendor's consultant asks how you want something to work, the map is the answer.

Data migration

Clean before you load. Decide how much history moves, who owns each field, and what happens to records that fail validation. Load into a test environment first and check headcount and pay totals against the old system.

Integrations

The benefits carrier feed and the general ledger export each depend on someone else's schedule: the carrier's and Finance's. Start them early and test them end to end, with a real file landing at the other side.

Finish before moving on: payroll rules and accruals are configured; employee records are cleaned and loaded to the test environment; carrier and ledger integrations are tested; security roles are approved.

Phase 4: testing, change management and go-live

Testing and change management share a phase because they share a deadline. Both get squeezed when phase 3 runs over.

• User acceptance testing. Write scripts for the events that matter: a hire, a pay change, a termination, a leave request. Have HR, Finance and a group of managers run them.
• Parallel payroll. Run the same pay period in both systems and compare the results. Plan for at least two runs. See how to run a parallel payroll test.
• Training. Managers first, then employees. Short and specific to what each group will do in the first month.
• Communications. Tell people what changes, when, and where to go for help. Send it more than once.
• The go or no-go decision. Make it against a checklist you agreed weeks earlier. See the go-live readiness checklist.

Finish before go-live: UAT scripts passed; two parallel payroll runs within tolerance; managers and employees trained; a hypercare owner and channel named.

After go-live: hypercare

Hypercare is the first few weeks on the new system, when the project team stays on call. Plan it as part of the project. If you treat it as an afterthought, the team scatters on go-live day and the first payroll problem has no owner.

• Name one owner and one channel for problems. Tell everyone what they are.
• Log every issue with a severity and an owner. Review the list daily for the first two weeks.
• Watch the first live payroll as closely as you watched the parallel runs.
• Agree the date hypercare ends and who takes over support.

How long each phase takes

It depends on size. A small company putting in one system for one country can plan in weeks. A large company rolling out in regional waves is looking at twelve to eighteen months, with extra work for each region: local process variations, privacy reviews, and works council consultation where it applies.

Whatever the total, a split that holds up well is about a fifth of the time on discovery, a fifth on future state and selection, a third or a little more on the build, and the last quarter on testing, change and go-live. If your plan gives testing less than that, expect to cut tests or move the date.

Three habits that keep the plan honest

1. Write exit criteria at the start. Agree what "done" means for each phase before the pressure arrives.
2. Record who signed off and when. A gate that nobody put their name to is only an opinion.
3. Keep one plan. If the vendor has a plan, IT has a ticket queue and HR has a spreadsheet, the gaps between them are where work gets lost.

Where HRjects fits

HRjects is built around this plan. A new project from the Startup HRIS or Enterprise HCM template starts with these four phases, the exit criteria above, HR workstreams, and a starter list of processes to map. Ticking an exit criterion records who ticked it and when. It does not include a Gantt chart or task dependencies yet; both are planned. You can read more on the HRIS implementation page or start a project for free.