Change management tools: the two different jobs sold under one name

Somebody is asked to "find us a change management tool". They search, and the results split down the middle. Half sell a way to plan announcements, map stakeholders and measure readiness. The other half sell a queue of change requests, approvals and rollback plans for production systems. The two have nothing in common except the phrase.

That split is the real problem, so this article is about it. It sets out the two things called change management tools, which readers want which, what the requirements actually are in each case, the United Kingdom duties that turn a vague topic into a dated one, and what to ask a supplier instead of comparing feature counts. It names no products, ranks nothing and quotes no prices.

Where a change alters who reviews whom, in what order, and who signs it off, the process itself has to be reconfigured rather than announced. See how New Dynamics workflows let you shape the stages, participants and approvals around how your organisation actually works.

Four things sold as a change management tool

Organisational change management. How people are brought through a change: who is told what, when, by whom, what they are asked for, what training they get and what happens to the ones who object. The buyer is HR, internal communications or a transformation lead. The "tools" here are mostly frameworks, plans and records.

IT change management. The controlled process for altering a live system: a request, an assessment, an approval, a release, a check and a way back. The buyer is IT or service management. The tooling here is genuine software, and the useful part of it is the audit trail.

Two smaller senses borrow the name. Project change control means managing changes to a project's scope, cost or dates, and lives in whatever tracks the project. Contract variation means changing what a supplier has agreed to deliver, and lives in the contract. Neither is what most searches want, and this article covers the first two.

The quickest way to tell which you need is to finish this sentence: "we are changing ___ and the people affected are ___". If the blank after "changing" is a system and the people are its users, you want both. If it is a structure, a location, a shift pattern or a set of terms, you want the first and no amount of the second will help.

A tool does not manage change

This is worth saying plainly before any requirement. Software can hold a plan, send a reminder, record an approval and show you what happened. It cannot consult anybody, decide whether a change is a good idea, absorb an objection, or make a manager have a conversation they are avoiding. Every one of those is a person doing something difficult.

The failure mode is specific and common. A tool is bought, a plan is loaded into it, the dashboard turns green as the tasks are ticked, and the change still lands badly, because the tasks measured activity rather than agreement. A communication plan that was fully executed and reached nobody who could object is not evidence of good change management. It is evidence of a tidy project.

So the honest order is: decide what is changing, work out who has a right to be consulted and what you owe them, write that down, and only then ask whether a tool would help you keep track of it. Our post on organization development covers the diagnosis that should come before any of this.

Organisational change management: the tools are mostly documents

Search for organisational change management tools and you will be offered platforms. What practitioners actually use, in most organisations, is a short stack of documents, and they work.

• A stated reason. One paragraph saying what is changing and why, in language a person outside the project can repeat. If it cannot be written, the change is not ready.
• A map of who is affected, and how. Not a stakeholder grid by influence and interest. A list of groups, what changes for each, and what each one loses, because that last column predicts the resistance.
• A consultation record. What you asked, who answered, what they said, and what you changed as a result. This is the document that matters most, and the one most often missing.
• A communication plan. Which message, to which group, through which channel, on which date, from which named person. Our post on internal communication tools covers the channels themselves.
• A training and support plan. Who needs to be able to do something new, by when, and how you will know they can.
• A decision log. What was decided, when, by whom, and what was ruled out. Six months later this is the only defence against "nobody told us".

There are well known stage models and branded methodologies in this field. We do not rank or endorse any of them, and the choice matters far less than whether the six records above exist and are kept current. A model tells you the order to think in. It does not tell you what you owe the people affected, and in the United Kingdom some of that is not optional.

Where UK duties bite, and what they say

This is the section that separates a change plan from a legal risk. It describes the position in the United Kingdom and is general information, not legal advice. Take advice on your own facts.

If the change is a redundancy situation, consultation is a statutory duty. GOV.UK's guidance on redundancy consultations states that "You must follow 'collective consultation' rules if you're making 20 or more employees redundant within any 90-day period at a single establishment", and that "If you do not consult employees in a redundancy situation, any redundancies you make will almost certainly be unfair and you could be taken to an employment tribunal". Its tables give a minimum consultation period before dismissal of 30 days for 20 to 99 proposed redundancies and 45 days for 100 or more, and the same deadlines for notifying the Redundancy Payments Service on form HR1. On that notification the page warns: "You can be fined an unlimited amount if you do not notify RPS."

The statute behind it is section 188 of the Trade Union and Labour Relations (Consolidation) Act 1992, which requires that "The consultation shall begin in good time and in any event", at least 45 days where 100 or more dismissals are proposed and "otherwise, at least 30 days, before the first of the dismissals takes effect". It also fixes the subject matter: consultation "shall include consultation about ways of (a) avoiding the dismissals, (b) reducing the numbers of employees to be dismissed, and (c) mitigating the consequences of the dismissals, and shall be undertaken by the employer with a view to reaching agreement with the appropriate representatives". Subsection (4) lists what must be disclosed in writing, including "the reasons for his proposals" and "the proposed method of selecting the employees who may be dismissed".

Two official sources currently differ on the trigger, and it is worth knowing why. GOV.UK still states the "single establishment" test. legislation.gov.uk shows a new subsection (A1) inserted into section 188, applying the duty where an employer proposes to dismiss "at least the threshold number of employees (see section 195A), or 20 or more employees at one establishment", noted as "inserted (6.1.2026 for specified purposes) by Employment Rights Act 2025 (c. 36)". Section 195A says the threshold number is to be set by regulations and that "the regulations may not provide in any case for the threshold number of employees to be lower than 20". Until those regulations are made the threshold number is not set, so GOV.UK's test is the one to plan against, while treating a multi-site redundancy exercise as something to take advice on. Our post on the redundancy process sets out the sequence.

If a transfer is involved, TUPE adds its own duty. Regulation 13 of the Transfer of Undertakings (Protection of Employment) Regulations 2006 requires that "Long enough before a relevant transfer to enable the employer of any affected employees to consult the appropriate representatives", the employer informs them of the fact and proposed date of the transfer and the reasons for it, "the legal, economic and social implications of the transfer for any affected employees", and the measures envisaged in connection with it "or, if he envisages that no measures will be so taken, that fact". There is no fixed number of days: "long enough before" is the test, which is harder to project-manage, not easier.

Standing information and consultation arrangements may already exist. The Information and Consultation of Employees Regulations 2004 apply to undertakings employing at least the number of employees in Schedule 1, which has been "At least 50" since 6 April 2008. Under regulation 7 a valid employee request to negotiate an agreement must come from "at least 2% of the employees in the undertaking", subject to a floor of 15 employees and a ceiling of 2,500. If an agreement is in place, a significant change is a matter to take through it rather than around it.

If terms change, there is a written statement deadline. Section 4 of the Employment Rights Act 1996 provides that where there is a change in any of the particulars required in the statement of employment particulars, "the employer shall give to the worker a written statement containing particulars of the change", and that it "shall be given at the earliest opportunity and, in any event, not later than one month after the change in question". Acas is direct about the consent point on its guidance on changes to employment contracts: "Any changes must be agreed by both the worker and employer", and "Employers should avoid 'fire and rehire'. They must consult before dismissal."

None of these four duties is satisfied by a tool. All four produce records, and a tool that holds those records in one place, with dates, is doing something useful.

IT change management: this is where the software earns its money

The other sense is narrower and far better served. The job is to make sure a change to a live system is requested, assessed, approved, released, checked and reversible, and that you can say afterwards exactly what changed and who agreed to it.

The United Kingdom government's own guidance is a good statement of what good looks like. The GOV.UK Service Manual page on deploying software regularly, last updated on 23 October 2024, sets four principles: "deploy little and often", "deploy quality software", "use auditable deployments" and "use zero downtime deployments where possible". On auditable deployments it asks teams to "know which version of your service is running in each environment at all times" and to "be able to trace changes back to the initial code commits in the source code repositories after a deployment hits production".

Two of its points cut against the heavyweight change board that organisations often buy tooling to run. On small releases it says "you identify bugs and cyber security issues more easily because fewer things are changing at the same time: this means they're cheaper to fix", and that "Deployment should be a low-risk process". On approvals it is blunt: "a product owner should not have to sign off a security fix in a user acceptance environment." A process that makes every change expensive produces fewer, bigger, riskier changes, and an unrecorded habit of working around it.

So the requirement is not "a change management module". It is that every change to a system you care about carries six things: what is changing, why, who approved it, when it went in, how to put it back, and what happened after it did. If the tool you already use for work tracking can hold those six fields and will not let a change close without them, you have a change management tool.

The figure nobody official publishes

You will be told that a large majority of change programmes fail, usually with a specific percentage. We checked, and no United Kingdom official statistical source publishes a success or failure rate for change programmes. The Office for National Statistics does not produce one, and neither GOV.UK nor Acas publishes a figure of that kind. The numbers in circulation come from consultancies, vendors and books, and are repeated without their original method.

That matters practically, because the number is usually deployed to justify a purchase. If a supplier quotes one, ask for the publication, the sample, the definition of failure and the date. Our HR statistics hub collects what official sources do publish, and the thresholds and deadlines earlier in this article are the figures that will actually be used against you.

What to ask for instead of comparing features

Ask each supplier to run the same scenarios with your own data.

1. Record a change that affects terms. Show the written statement obligation being tracked with a date, and show what happens when the month is nearly up.
2. Run a consultation. Capture a question raised by a representative, the answer given, and the change made as a result. If there is nowhere for the third one, the tool records communication rather than consultation.
3. Show the decision log six months later. Who decided, when, on what information, and what was rejected.
4. Push a change through with a field missing. Silent acceptance is wrong.
5. Roll one back. Show the previous state and the record that it was reversed.
6. Run an emergency fix. A process that cannot accommodate one will be bypassed on the day it matters.
7. Log in as an affected employee, then a manager, then an administrator, and see which records each can read. Consultation notes about individuals are personal data.
8. Export everything. If the audit trail cannot leave the tool, it is not evidence.

Our post on HR software selection covers running a selection without a feature-count spreadsheet, and HR tools maps what a stack already does, because the answer here is often a system you already pay for.

No rankings here

Many searches for the best change management software, the top change management tools or a free change management tool want a ranked list. This site does not publish those, in any category, including our own. The reasoning is set out in why we do not publish a top 5 HRIS list: rankings are often shaped by commercial relationships a reader cannot see, and even an honest one cannot know what you are changing, who it affects, or whether you have a legal duty attached to it.

Frequently asked questions

What is a change management tool?

The phrase covers two unrelated things. One is anything that helps bring people through an organisational change, which in practice is a set of documents: the reason, who is affected, a consultation record, a communication plan, a training plan and a decision log. The other is software that controls changes to live systems, through requests, approvals, releases and rollback, with an audit trail.

Do we need change management software?

Usually not as a separate purchase for the organisational sense, because the work is consultation and the records can live in tools you already have. For the IT sense you need something that will not let a change close without recording what changed, who approved it and how to reverse it, and that is often already part of your work tracking.

What are change management tools and techniques?

In the organisational sense they are frameworks and records rather than software: a stated reason for the change, a map of who is affected and what each group loses, a consultation record, a communication plan, a training plan and a decision log. Stage models order your thinking. They do not tell you what you owe the people affected.

When does a change legally require consultation in the UK?

Several duties can apply at once. Collective redundancy consultation under section 188 of the Trade Union and Labour Relations (Consolidation) Act 1992 applies where 20 or more dismissals are proposed, with GOV.UK giving minimum periods of 30 days for 20 to 99 and 45 days for 100 or more. TUPE regulation 13 requires information and consultation long enough before a transfer. The Information and Consultation of Employees Regulations 2004 apply to undertakings with at least 50 employees. This is general information, not legal advice.

How long do we have to confirm a change to someone's contract in writing?

Section 4 of the Employment Rights Act 1996 requires a written statement of the change at the earliest opportunity and in any event not later than one month after the change. Acas adds that any change must be agreed by both the worker and the employer, so the written statement confirms an agreement rather than imposing one.

Is it true that most change programmes fail?

No official statistical source publishes a rate. The Office for National Statistics does not produce one, and neither GOV.UK nor Acas publishes a figure of that kind. The percentages in circulation come from consultancies, vendors and books, and are usually quoted without the method behind them, so ask for the publication and the definition of failure before relying on one.

Your next step: name the change before you shop

1. Write one sentence saying what is changing and who it affects. If you cannot, the change is not ready for a tool.
2. Decide which sense you are in. A system change needs an audit trail. A structural change needs a consultation record.
3. Check the duties against your facts: a redundancy situation, a transfer, an existing information and consultation agreement, or a change to terms. Any of them puts a date in your plan.
4. Look at what you already own before buying anything, then run the eight scenarios above against it.

For the people side, read and download our change management guide, which covers who to involve, when, and what to do with what they say. If the change is a reduction in headcount, the redundancy and workforce change guide covers running one properly. Both are free to read, and the PDFs use our short download form.

To see how a process with named stages, participants and approvals behaves when the structure underneath it changes, book a New Dynamics demo and bring the change you are planning. You can also email contact@new-dynamics.com.