Most technology programmes that disappoint were not technically wrong. People weren't prepared for the change, were trained generically, and had nobody to turn to when the new system met a real working day. JJC Systems' change management consulting runs alongside delivery, so what you build is something your people actually use.
Organizational change management (OCM) consulting is outside support in preparing people for a new system, process or way of working, so they adopt it and keep using it. In a technology project it covers understanding who is affected and how, communicating clearly, training people for their actual roles, supporting them at go-live, and measuring adoption afterwards.
The failure pattern is remarkably consistent. It rarely comes down to the software.
Communication and training are left until testing finishes, when the design can no longer respond to what people say.
People sit through a feature tour and then have to work out how it applies to their own tasks, alone.
Staff look to their line manager first. If managers haven't been briefed or brought along, the message gets lost.
Go-live is treated as the finish line, so workarounds, spreadsheets and old habits quietly return.
A system that is technically live but not used is the most expensive kind of project outcome: you have paid for the build, the licences and the disruption, and you still don't have the benefit. It is the part of the project that determines whether the investment returns anything at all.
We agree the baseline and the adoption targets before work starts, then report against them.
Proportion of the target population using the new process as designed at 90 days, not just in the first fortnight after launch.
Typical reduction in go-live support volume when role-based training and floor-walking replace a single generic session.
How long the expected post-launch dip lasts when readiness work is done properly, against the months it can otherwise persist.
Old spreadsheets and side systems formally retired with a named owner, rather than quietly tolerated.
A trained champion in every affected team, giving people a local, credible first point of contact instead of a ticket queue.
Go-live decided against agreed readiness criteria rather than an optimistic date set months earlier.
How to read these: the figures above are typical ranges we plan and measure against, not guarantees. In your first engagement we agree the baseline, the target and the measurement method in writing, then report against them.
In parallel with delivery, not after it, so people hear about the change from you before they meet it in the system.
Before the design hardens, we establish who is affected and how.
We plan and deliver the messages and training people need.
We support go-live and check whether the change took hold.
Scoped individually or as a full programme alongside your technology project. These are our change management consulting services.
Who is affected, how much, and what each group needs from the change, so effort goes where it matters.
Messages, channels and timing, tied to the project plan, with leaders and managers briefed first.
Training built around real tasks in your processes, so people practise their own work.
Recruiting, preparing and supporting people in teams who help colleagues day to day.
Visible, practical support in the first weeks, with a clear route for questions and issues.
Tracking usage against targets and acting where adoption lags.
Finding why adoption has stalled, and restarting with a clear recovery plan.
Where consultation, safety or professional standards apply, adapting the plan to the rules and relationships involved.
In parallel with delivery, not after it, because the decisions that determine adoption are made during the build.
Understand the change, the people affected and how work happens today.
Agree goals, sponsors, risks and what success looks like.
Plan communication, training, champions and readiness criteria.
Deliver communication and training, and support go-live.
Measure adoption, fix gaps and hand over to your team.
You own everything we produce. Change management is a capability as well as a project, so we hand over plans, materials and methods your team can reuse. Feedback from this work also often changes the design, and that is a good sign.
Change management is often the first line cut from a budget and the reason the programme struggles.
Because we also deliver Microsoft and ERP projects, we can translate between what the system does and what people need.
Go-live depends on documented readiness criteria. If people aren't ready, we say so and show why.
We track real usage after launch and act on it, so success is an observed result and not an assumption.
Where another partner builds the system, we work with them, and our advice is about people readiness and not their sales.
Illustrative engagements, written in the structure we use for real case studies.
The challenge: clinical staff had little time for training and were wary of a system that changed their routines. What we did: mapped role impacts, built short role-based sessions around real tasks and set up ward champions. What changed: staff felt prepared, early support demand was manageable, and adoption was tracked after go-live.
The challenge: an earlier launch had left staff sceptical and still using old workarounds. What we did: listened to why it failed, adjusted training and support, and relaunched with clear readiness criteria. What changed: workarounds retired, sponsors visible, and usage monitored with action where it lagged.
Material for programme sponsors who have seen a launch go quiet.
How to structure impact analysis, communication, training and adoption measures alongside delivery.
Read moreThe difference between feature tours and role-based training, and why it affects adoption.
Read moreQuestions to answer before launch: people, process, data, support and decision rights.
Read moreWhether we are delivering the system or someone else is, we can run the change workstream that determines whether people use it.
A change management consultant helps people prepare for and adopt a new system or way of working. They analyse who is affected, plan communication, design role-based training, support go-live, and measure whether the change has stuck.
ERP change management is the people side of an ERP implementation. It prepares teams for new processes, roles and data responsibilities, and supports them through training, go-live and the weeks after, so the ERP is actually used as designed.
As early as possible, ideally before design is finalized. Early impact analysis lets the project respond to what people need, whereas starting just before go-live mostly means telling people what has already been decided.
Project management delivers the system on time and budget. Change management makes sure people are ready, willing and able to use it. Both are needed, and they work best together.
We agree measures at the start, such as training completion, system usage against targets, support demand and a follow-up check some weeks after launch. These show whether new ways of working have stuck.
Yes. We support Microsoft 365 and Teams rollouts and Dynamics 365 projects, including Finance, Business Central and Sales, and we can work alongside other delivery partners.
It depends on the size of the change and the number of people affected. Most run alongside the project, from early design to a few weeks after go-live. We give a plan after an initial conversation.
The price depends on scope, the number of people affected and how long support is needed. We agree it before work starts.
Describe the situation in your own words.
