top of page

12 Signs Your CMiC Implementation Is Failing, and How to Stabilize It

Rachel Barker
5 days ago
4 min read

Short answer: a CMiC implementation is failing when the dates keep moving, the parallel runs do not reconcile, and the people closest to the work have started keeping a spreadsheet on the side because they no longer trust the system. Here are the 12 signs we see most often in rescue engagements for ENR-ranked contractors, and how a stabilization actually works.

What are the 12 signs a CMiC implementation is failing?

Grid of the 12 signs a CMiC implementation is failing, numbered 1 to 12, from a go-live date that has moved more than once to integrations repaired by hand each cycle
  1. The go-live date has moved more than once. One slip is a schedule problem. Two or more usually means design or data problems nobody has named yet, a dependencies silently missing from your plan, data migrations behind schedule, or misalgined expectations about support case resolution times.

  2. Payroll or GL parallel runs cannot be reconciled to the legacy system. If the variance is being explained rather than eliminated, the configuration is wrong somewhere.

  3. Job Cost reports are not trusted. Project managers are rebuilding cost reports in Excel. This usually gets worse after go-live.

  4. Month-end takes longer in the new system than the old one. Close should get shorter. If it is getting longer, the GL mapping or subledger controls are wrong.

  5. Your team is out of hours. A handful of people are running their day jobs and the implementation at the same time, so decisions get rushed, and rushed configuration decisions have lasting consequences. When one internal owner carries most of the knowledge, they are also a single point of failure. If they leave, the knowledge leaves with them.

  6. There is no conference room pilot (CRP) or mock go-live on the plan. A CRP proves the configuration against your real business scenarios before anyone commits to a date. A mock go-live proves the cutover itself, with converted data, real users and real timing. Skip either and the first true test of the system is the day you go live on it.

  7. Data migration is behind schedule or data isn't correct. Data migration has a major impact on implementation schedules and the success of your go live. A mock go-live only means something when it runs on real converted data. If migration is late, the rehearsal is a rehearsal of somebody's sample file, and you find out what the real data does on the day it counts.

  8. The answers from your consultants or CMiC support do not add up. Explanations that are incomplete, contradictory, or arrive as "that is just how CMiC works" are a sign that the people advising you do not fully understand the configuration either. A good answer is specific, and it can be tested.

  9. Nobody can produce the decision log. Ask why a configuration choice was made. If the answer is "that is how it was set up," there is no log.

  10. Risks are not being tracked. Every implementation has open risks: an integration not yet tested end to end, a union agreement not yet configured, a conversion not yet reconciled. If nobody can show you the list, with an owner and a date beside each item, the risks are being carried in someone's head. That is where they stay until they become incidents.

  11. Nobody can explain how payroll burden costs will land in Job Cost and the General Ledger. Having full clarity on payroll burden cost posting to both job cost and the general ledger is critical to preventing variances that surface at month-end and in the job cost reports - or even worse your job billing. If you charge to jobs at a standard cost or charge rates a full costings plan is needed to make sure your financials are accurate.

  12. Integrations are repaired by hand each cycle. Someone re-keys the rows that failed. That person is your integration, and they take vacations.

What a CMiC rescue is not

It is not starting over. Most troubled implementations have a sound core and a handful of design decisions and data problems that compound. It is also not a blame exercise. The vendor's team, your current partner and your own people are usually all still needed. The rescue changes who owns the plan and what the plan is built around.

How does a stabilization work?

Five-step CMiC stabilization sequence: Health Check first, stop the bleeding, reconcile before you trust, reset the date with evidence, hand it over
  1. Health Check first. A rapid, independent review of configuration, data, testing, integrations and governance, ranked by risk, with a written opinion. Days, not months.

  2. Stop the bleeding. Get data migration back on schedule and fix the two or three things corrupting data right now, usually in payroll, the Job Cost structure or an integration. Everything else waits.

  3. Reconcile before you trust. Parallel runs and tie-outs until the variance is zero and explained, not small and explained.

  4. Reset the date with evidence. A go-live date backed by a readiness checklist and a realistic view of vendor response times and availability, not by the calendar.

  5. Hand it over. Runbooks, a decision log, and mentorship hours so your team owns it.

What does it cost to wait?

Every payroll cycle run on a misconfigured system creates corrections that someone has to unwind. Every month closed on a wrong cost structure makes the historical reports less comparable. The earlier a troubled implementation gets an independent review, the less there is to unwind.

If three or more of the 12 signs sound familiar, our fixed-scope Implementation Health Check is the low-risk first step. Call 951-395-0951 or use the contact page.

Frequently asked questions

How quickly can a troubled CMiC project be assessed? A Health Check is scoped in days. You get a ranked list of what is wrong and what to fix first.

Can a failed go-live be recovered without going back to the legacy system? Almost always, if payroll is stabilized first. Sometimes one more legacy cycle is the responsible choice. The assessment tells you which.

What if the implementation is already live and we have issues? Yes, we can still help, and a live system with bad data is a common starting point for us. We work alongside your team to correct the data itself, including accounting, job cost and job billing, not just the processes around it. Our construction accounting and forensic accounting specialists, each with more than twenty years of experience, sit with your team, assess the data and walk you through what comes next.

Impact Integrated Technology Inc. is an independent consultancy and is not affiliated with, endorsed by, or a partner of CMiC. CMiC is a trademark of its owner, used here for descriptive reference only.

 
 
 

Comments


bottom of page