Most outages and nasty surprises are not caused by hackers or hardware. They are caused by someone changing something: a new setting, a software update, a different supplier, a revised price list. Change management is the habit of making those changes on purpose, with a second pair of eyes and an escape route. It sounds corporate, but a small team can run a version of it in about fifteen minutes per change.
What is a change management process?
A change management process is a simple, repeatable way to propose, evaluate, approve, carry out and review changes to your systems, tools or ways of working. Its goal is not to slow people down. It is to make sure that when something changes, the right people know, the risks have been thought about, and there is a plan if it goes wrong. The change can be technical, such as a server update, or operational, such as a new onboarding procedure.
The six steps
1. Request
Write the change down in one place, however small the form. Capture what will change, why, who asked, the desired date and who is affected. A shared form, a ticket or even a pinned document works. If it is not written, it cannot be reviewed.
2. Risk assessment
Ask three questions: what could go wrong, how many people or customers would notice, and how hard is it to undo? Rate the change low, medium or high. A typo fix on an internal page is low. Changing how invoices are generated is high. The rating decides how much of the rest of the process you need.
3. Approval
Someone other than the requester should say yes. For low-risk changes this can be a quick message from a teammate. For high-risk ones, involve the owner of the affected area and agree a time that avoids busy periods such as month end or a product launch.
4. Rollout
Choose a window, tell the affected people beforehand, and name who does the work. Where possible, release to a small group first, then everyone. Keep a short checklist so that nothing depends on memory.
5. Rollback plan
Before you start, write down how to get back to the previous state and how you will know it is needed. This might be restoring a backup, switching a setting back or reverting to the old supplier. Decide a trigger in advance, for example: if errors continue for 30 minutes, we roll back.
6. Review
A few days later, check whether the change worked and whether anything unexpected happened. Record the result and one lesson. This is where the process gets better: patterns in failed changes show you where your risk ratings were too optimistic.
How can a small team keep it light?
- Use two or three risk levels. Low changes need a note and a peer check. Medium changes need written approval. High changes need a rollback plan and a scheduled window.
- Pre-approve routine work. Recurring, well-understood changes such as monthly updates can be approved once as a standard change and simply logged afterwards.
- Keep one log. A single list with date, owner, risk, outcome and a link to the details is enough. Avoid scattering records across chats and inboxes.
- Set one change window. A weekly slot, for example Tuesday morning, makes planning easy and keeps risky changes away from Friday afternoons.
- Allow emergency changes. When something is broken, fix it first and document it within a day. Review emergencies afterwards so they do not become the normal route.
A simple example
A ten-person company wants to move its shared files to a new storage provider. The request notes the reason, a cost saving, and that everyone is affected. The risk is rated high, because lost files would stop work and the move is hard to reverse. The operations lead approves it for a Saturday window and the team is warned a week ahead. A pilot group of two people moves first. The rollback plan is to keep the old storage read-only for 30 days and switch back if the pilot reports missing files. A week later the review finds that shortcuts to old folders broke, so the team adds a fix-up step to next time's checklist.
Common mistakes
- Treating every change the same. If renaming a folder needs the same paperwork as replacing your database, people will route around the process.
- Skipping the rollback plan. Most teams plan the way forward and assume nothing will go wrong. The plan for going back is what limits the damage.
- Approving your own work. A second person catches what the author is too close to see.
- Never reviewing. Without a look back, the process turns into a form and stops teaching you anything.
Making it stick
Start with the next change you plan, not with a full policy. Use a one-page template, one log and one weekly slot, and adjust after a month. If your team already tracks projects and tasks in FulcrumGrid Command Center, you can record each change as a task with an owner, a date and a checklist, so approvals and rollbacks are visible next to the rest of the work. A spreadsheet works too; the habit matters more than the tool.
Good change management is mostly good communication: write it down, ask someone to check it, know how to undo it, and learn from the result.
Frequently asked questions
What is the difference between change management and project management?
Project management delivers new work with a goal, scope and schedule. Change management controls how modifications to existing systems and processes are approved and released so they do not cause disruption. They overlap, but a project often contains several changes.
Does a team of five really need a change process?
A very light one, yes. A shared log, a second person checking risky changes and a written rollback plan cost little and prevent the kind of mistakes small teams cannot afford to repair.
Who should approve changes in a small team?
Someone other than the requester who understands the affected area, usually the owner of that system or process. For low-risk changes, a teammate's confirmation is enough.
What counts as an emergency change?
A change needed right now to restore service or stop active harm. Do it quickly, document it within a day, and review it afterwards so the exception stays an exception.
FulcrumGrid Command Center
Keep changes visible and owned
FulcrumGrid Command Center lets you track each change as a task with an owner, a date and a checklist, alongside your projects and KPIs.