A change request workflow is the fixed path a proposed change takes from the moment someone asks for it to the moment it is approved, built, checked and closed. The simplest version that works has seven steps: submit, log, assess, decide, schedule, implement and verify, close. Each step has one owner and leaves a written record. Below we walk through each step, what the request form should hold, who should approve, how to treat urgent changes, and how to tell whether the process is working. It is written for small and medium businesses, not for a 500-person IT department.
Table of Contents
- What is a change request workflow, and how is it different from change control?
- What are the steps from submission to closure?
- What should a change request form include?
- How do you assess the impact of a change?
- Who should approve a change request?
- How do you handle urgent, routine and high-impact changes?
- How do you track requests and know the process is working?
- Where does software fit in?
- Our perspective: keep the workflow inside the system you already use
- Want your change workflow built into one system?
- FAQ
- Sources
What is a change request workflow, and how is it different from change control?
A change request is a formal proposal to alter something that has already been agreed: a project scope, a system, a business process. The workflow is the sequence of states that proposal moves through. NAIT's change management procedure describes a Request for Change as a document with everything needed to approve or reject the change: the reason, the impact, the benefits and the potential risks.
"Change control process" is the wider term. The Association for Project Management describes change control as capturing, evaluating, and then approving, rejecting or deferring every request to change an approved baseline. In plain terms:
- The workflow is the route and the states: new, under review, approved, in progress, done.
- The change control process is the workflow plus the rules around it: who may decide, what must be documented, and how the original plan is protected.
If you run a services business, the baseline might be a client's signed scope, your own internal pricing sheet, or the way invoices are raised. Any of these can drift if changes arrive by hallway conversation. A workflow stops that drift without slowing everyone down.
What are the steps from submission to closure?
Different sources number the steps differently, but they agree on the order. The APM workflow runs from logging in a change register, through initial and detailed evaluation, to a recommendation, a plan update and monitored implementation. Here is the same logic in seven steps a small team can adopt this week.
- Submit. The requester fills in one standard form. A written form gives reviewers a consistent starting point, and it filters out half-formed requests.
- Log. Someone enters the request in a single change register, with a unique ID, so nothing lives only in an inbox. The intake step should also say what happens to incomplete requests and who sends them back for clarification, and it should prevent duplicate records when the same ask arrives by email and by phone.
- Assess. The owner of the project or system writes up the impact on scope, schedule, cost, resources, risk and quality.
- Decide. An approver approves, rejects or defers, and records the reason. Deferring is a real answer: "good idea, not this quarter" is better than silence.
- Schedule and assign. After approval, one named person gets the task and a target date. The plan, budget and any affected documents are updated, and stakeholders are told.
- Implement and verify. The work is done, then checked against what was approved, not against a rough approximation of it.
- Close. Record the final status, the actual impact compared with the estimate, and what you learned.
The practical value is in steps 2 and 7. Logging makes the work visible. Closing, with actual versus estimated impact, is what makes your next estimate better.
What should a change request form include?
Large IT shops ask for a lot. The University of Calgary's change management standard lists a unique identifier, the requester, how, why and when the change is wanted, approvals, current phase, impact, urgency, priority, risk, roll-out and back-out plans, test results and an audit trail. That is right for a university network. A ten-person firm needs a shorter form built from the same ideas.
A practical small-business form has these fields:
- Request ID and date
- Requester and the person or client affected
- What should change, in one or two sentences
- Why: the problem it solves or the outcome it enables
- Desired date, and whether anything depends on it
- Affected systems, projects or customers
- Urgency and priority (see the table below)
- Estimated impact on scope, schedule, cost and risk, filled in at the assessment step
- Options considered and a recommendation
- Decision, approver and date
- Implementation notes, including how to undo the change if it goes wrong
Keep the requester's part short. Anyone should be able to complete it in five minutes. The assessment and decision sections belong to the reviewer. If requesters have to fill in risk scores, they will skip the form.
How do you assess the impact of a change?
Use the same six lenses every time. ProjectManager.com's guidance on impact assessment names scope, schedule, cost, quality, resources and risks. Walk through them in writing:
| Lens | Question to answer | Example for a services firm |
|---|---|---|
| Scope | What work is added or removed? | Client wants a second reporting dashboard |
| Schedule | How many days does it add or remove? | Plus four working days |
| Cost | What is the budget effect? | Additional billable hours, or absorbed |
| Resources | Who or what else is needed? | A second developer for two days |
| Risk | What new risks appear, and which disappear? | New data source could delay go-live |
| Quality | Does it change the standard of the deliverable? | More testing needed on invoice totals |
Document the result in writing. It is the basis for the decision, and it is your protection if a client later says they did not know the change would move the date.
For IT-type changes, the Calgary standard also ranks impact by how critical the system is and how many users are affected. A change to the system that issues invoices matters more than a change to a internal wiki, even if both take an hour.
Who should approve a change request?
The right approver depends on the size of the change, not on seniority alone.
- Project manager analyzes, sponsor decides. The University of Waterloo's project office has the project manager lead the impact analysis while the sponsor approves or rejects. The form is filed in the team's document repository.
- Authority is set in advance. Nova Scotia's Integrated Change Control Guideline ties approval authority to the project charter and to the signing authority of the person's role. Small changes within contingency can be approved by the service provider. Larger ones go to the project sponsor.
- A board for bigger organizations. The University of Ottawa's IT change document describes a Change Advisory Board as a team that meets to assess a request and recommend authorizing or rejecting it.
For a small business, a committee is usually too heavy. A single approver, often the owner or the operations manager, can stand in for a board on smaller projects, as long as the decision and the reason are recorded in the register. Write down a simple threshold, such as "anything under a set dollar amount or two days of effort, the project lead approves; anything above, the owner approves." Then the rule exists before the argument does.
How do you handle urgent, routine and high-impact changes?
Not every change deserves the full route. Most frameworks split changes into three types. NAIT's procedure defines them as emergency (a critical service is disrupted), pre-approved (low risk, frequent, from a predefined catalogue) and normal (needs risk assessment, planning, approval and scheduling first).
| Type | Example | Handling |
|---|---|---|
| Pre-approved | Adding a new staff member to the scheduling tool | Follow a written checklist, log it, no review needed |
| Normal | New approval step in the invoicing process | Full seven steps |
| Emergency | Booking system down on a Friday afternoon | Fast approval, document immediately, review afterwards |
Two details are worth copying. First, NAIT requires approval from at least two members of its emergency board, and where two are unavailable, a retrospective review within 24 hours. Second, NC State's change management guide derives priority from impact and urgency, each rated low to high, and allows emergency change documentation to be deferred by no more than one business day.
For a small firm, that translates into one rule: an emergency can skip the queue but never the paperwork. Fix first, write it up within one business day, and review it at your next regular check-in. Review your pre-approved list every few months, so that things that have become risky do not stay on it.
How do you track requests and know the process is working?
The register is the heart of tracking. Nova Scotia's guideline calls its change control log a central repository kept as a living document, reviewed weekly by the project manager and service provider, and monthly by the sponsor. Final decisions are logged and communicated to the requester and anyone else affected.
The same guideline suggests four simple metrics: changes requested, approved, outstanding and completed. It also recommends periodic reports on new, open, pending, approved and resolved requests, with cancelled and deferred ones available for reference.
That is enough to start. Add two measures of your own:
- Time to first response. Set an acknowledgement target for when a request is reviewed, not when the work is finished. Requesters forgive a slow build far more readily than silence.
- Estimate versus actual. At closure, compare the estimated impact with what happened. If changes consistently run 30% over, your assessments are too optimistic.
Don't forget the people side. The University of Waterloo publishes a change management plan template that helps leaders identify stakeholders, plan communications and training, and define how adoption will be measured. A change that is approved and built but never adopted has not really been completed. If your changes involve AI tools, our guide to AI change management for Canadian businesses covers that side in detail.
Where does software fit in?
A spreadsheet is a fine change register for the first few months. Problems start when requests arrive through email, chat, phone and a shared drive, and the register is updated by whoever remembers. At that point the workflow lives in people's heads.
There are two kinds of tools worth knowing about. The first is a feedback board for ideas from customers or users. A good overview of the end-to-end route from idea to shipped change is this feature request process, which shows how status tracking turns scattered requests into a visible queue. The second is the operational system you already run the business on: your CRM, invoicing and scheduling.
If a change request touches data, such as a new field on a client record, a new invoice rule or a new report, the workflow should connect to that system. Three of our other guides help here:
- Role-based access control explains how to set permissions so only approvers can mark a change as approved.
- The six-phase data migration plan is useful when a change moves data between systems.
- The CRM implementation timeline shows how project gates keep scope changes visible during a rollout.
Our perspective: keep the workflow inside the system you already use
Most small businesses we meet in Surrey and Metro Vancouver don't have a change request problem. They have a scattered-tools problem. The request arrives by email, gets discussed in chat, is priced in a spreadsheet, and gets billed from a separate invoicing tool. Nobody can say what was approved, so everyone argues from memory.
Our view is that a change workflow works best when it sits next to the data it changes. If the request, the approval, the schedule and the invoice all live behind one login, the audit trail builds itself. That is what we design: custom software around your own processes, with CRM, invoicing, scheduling, reporting and workflow automation connected, and with you owning the code and no lock-in.
We also practise what we recommend. Our projects are fixed-price with regular milestones, so a change to scope is written down, priced and approved before work starts. Our clients tell us they typically recover 5 to 15 hours of administrative work a week once repetitive handoffs are automated. We'd rather you start with the simple seven-step version in this article and automate it once it is stable, because a messy process that is automated is still a messy process.
Harry Gill
Want your change workflow built into one system?
If requests, approvals and invoices currently live in different tools, we can build a single system around the way your team already works, with local support in Surrey and Metro Vancouver. Start with our AI workflow automation service to see how approvals, notifications and status tracking can run automatically, or look at custom software if you want the whole operation connected.
If you are still deciding whether to build or buy, our comparison of custom software versus off-the-shelf sets out the trade-offs, and our automation roadmap for Canadian SMEs shows where to begin.
FAQ
What is a change request in software development?
It is a formal request to alter something already agreed, such as a feature, a screen, an integration or a deadline. It is logged, assessed for its effect on scope, schedule, cost and risk, and then approved, rejected or deferred. Only approved changes enter the plan.
What are the five steps of change control?
The common sequence is initiate, evaluate impact, review and approve (or reject or defer), implement, then monitor and close after verification. Our seven-step version splits logging and scheduling out as their own steps, because those are where small teams most often lose track.
Do small businesses need a change control board?
Usually not. For smaller projects, one approver can replace a committee, provided the decision and the reason go into the change register. Set approval thresholds in advance, for example by cost or days of effort, and escalate only what exceeds them.
How often should we review the change log?
Nova Scotia's guideline has the project manager and service provider review the log weekly, and the sponsor monthly. A weekly ten-minute check works for most small teams. Look at what is outstanding, what is deferred and what is overdue.
Sources
- NAIT change management procedure
- APM: What is change control?
- University of Calgary Change Management Standard
- ProjectManager.com: Change request guide
- University of Waterloo: Project change request
- Nova Scotia Integrated Change Control Guideline
- University of Ottawa IT change management
- NC State ITSM change management guide
- University of Waterloo: Change management tools and templates
- Feature request process