No project goes exactly to plan. What matters is how quickly you notice when something is off, and whether you have a way of responding that doesn't depend on someone sounding the alarm in a Friday status call.
A supplier misses a deadline by a week. Your lead developer gets pulled onto a client emergency. A phase that was quoted at 40 hours has burned through 65 and still isn't finished. Any one of these is manageable on its own. Leave them all unchecked for a month and you're looking at a project that's over budget, behind schedule, and heading for a difficult conversation with the client.
Corrective action is a structured way of responding. You identify what's gone wrong, figure out why, agree on what needs to change, and follow through. Nothing complicated about the concept. The hard part is doing it consistently, across every project, before small issues turn into expensive ones.
At Magnetic, we build professional services automation software that agencies and consulting firms use to run projects from pipeline to invoice. We see how firms handle project problems every day, and the firms that recover well from setbacks almost always have two things in common: current data and a repeatable process for acting on it.
This guide walks through the corrective action process, the situations that should trigger it, worked examples from real project types, and practical habits for keeping projects on course.
Corrective action is what you do when there's a gap between the plan and what's actually happening on a project.
That could be a missed milestone, a budget running ahead of the work, tasks sitting untouched for no obvious reason, or deliverables that need to be redone. The specifics vary. Corrective action is about working out why the gap appeared and making changes to close it.
It's the last step in project monitoring and control: plan the work, do the work, track the work, and adjust when the numbers don't match. Most firms are reasonable at the first three. The fourth is where things break down, because it requires someone to notice the problem, own it, and act. That's hard to do when your project data is spread across timesheets, spreadsheets, and resource allocation tools that don't talk to each other.
Corrective action matters most during execution and monitoring, once tasks are underway and you're tracking progress against the plan.
That's when gaps start showing up. A task takes three days longer than the estimate. A cost line hits 80% of budget with 40% of the work still to go. Someone on your team is booked at 120% across three projects and none of them are moving fast enough. Most of the time, these things get mentioned in a stand-up, half-addressed, and then forgotten about until they cause a bigger problem.
Good reporting, clear resource management, and honest team communication help you catch these problems while they're still cheap to fix. Without those things, you find out when the project closes and someone asks why the margin evaporated.
Some situations almost always need a response. If you've been managing projects for more than a year, most of these will be familiar.
Timeline slippage. One phase takes longer than planned and pushes everything downstream. Often this is the first thing you notice, but it's rarely the actual problem. The actual problem is usually resource or scope.
Cost overruns. Spending is outpacing progress. According to KPMG's Global Construction Survey, 69% of projects experience cost overruns. The most common cause is scope changes that never got formally approved.
Resource strain. The same people are carrying too much. In a 50-person consulting firm running 8 active projects, it doesn't take much for one overbooked senior consultant to become the bottleneck across three different engagements. If capacity planning isn't connected to project assignments, you won't see it until everything slows down.
Scope creep. Extra work gets added without anyone adjusting the budget or the timeline. SPI Research data shows that over-servicing costs the average services firm 10–20% of project revenue, and most of the time nobody realises it's happening until the project wraps up.
Quality issues. Work doesn't meet the standard and needs to be redone. The rework costs time and money, obviously, but the bigger problem is usually the knock-on delay to everything that was waiting for that deliverable.
Communication gaps. People lose track of priorities, dependencies don't get flagged, and status updates dry up. This doesn't usually cause problems on its own, but it makes every other problem worse.
Most of these start small. A day behind here, a few hundred pounds over there. The problem is that nobody treats them as urgent until they've already compounded into something much harder to fix.
Having a repeatable process means you don't reinvent the response every time something goes wrong. It also takes the personal sting out of it. When there's a defined process, raising a problem feels less like blame and more like following the playbook.
Many teams skip this. A problem gets discussed informally, someone does a workaround, and it's never recorded. Then the same problem turns up again two weeks later.
Formal identification starts with data. Time tracking shows a 40-hour estimate has already used 35 hours with a lot of work remaining. A budget dashboard shows 85% of the money gone with 60% of deliverables complete. A status report flags a task that's been "in progress" for twice as long as planned.
Seeing these numbers on Monday gives you options. Seeing them on Friday, after the client has already asked what's going on, does not.
Before you decide what to do, understand what actually went wrong.
Was the estimate too optimistic from the start? Did the plan miss a dependency? Is one person carrying too much work across too many projects? Did the client add work that nobody logged as a scope change?
The root cause determines the right response. A bad estimate needs a plan adjustment. Scope creep needs a conversation with the client. An overloaded team member needs work reallocated to someone with capacity.
Get this wrong and you'll end up extending a deadline when the real issue was that your senior developer is stretched across four projects. The deadline will slip again next month for exactly the same reason.
Once you understand the cause, pick the response that fits. Some options:
A two-day slip on a six-month project probably needs a minor adjustment, not a full replanning exercise. Save the big interventions for actual emergencies.
Tell the team and stakeholders what's changing and why before you implement.
This is also when you reset expectations. If the schedule has changed, say so explicitly. "We're moving the milestone by a week to protect quality" is a conversation you can have on your terms. "We missed the deadline, sorry" is a conversation someone else forces on you.
Make the change and then watch what actually happens over the next week or two.
If you moved tasks to a different team member, check whether they're coping with the extra load after a few days. If you adjusted the timeline, look at whether the downstream milestones still work. Project management tools that update in real time help here because weekly status meetings are always showing you last week's picture. By Friday, the numbers may already be wrong again.
These are based on patterns we see across firms that use Magnetic. The names and numbers are made up. The dynamics are things we see regularly.
A 35-person consulting firm is running a six-month systems implementation. Three months in, a review of the workload view shows that one senior consultant is booked at 140% capacity across this project and two others.
Tasks on the implementation are taking 30% longer than estimated. The client has started asking why things are slowing down.
Root cause: The senior consultant was assigned to this project before the other two were confirmed. When the new projects started, nobody went back and checked the total workload.
Corrective action: Move 20 hours of work to a mid-level consultant with available capacity. Adjust the sprint plan to account for the difference in experience on specialised tasks. Flag the overallocation to the PMO so it gets picked up earlier next time.
Outcome: The delay is limited to one week instead of snowballing across the remaining three months.
A marketing agency runs an £8,000/month retainer for a financial services client. Looking at the numbers, actual costs have exceeded the retainer value for three consecutive months. Total overrun: £7,200. That's nearly a full month of free work.
Root cause: The client has been adding small things to the scope: an extra round of revisions, a new landing page, a few extra social posts. Each one seemed minor, so nobody flagged it. None of the additions were tracked against the retainer budget.
Corrective action: Pull a report of all time logged against the retainer versus the agreed scope. Show the client the numbers and propose two options: increase the retainer to match the actual workload, or define a hard boundary on what's included with extras billed separately. Set up tracking so new requests are logged against the retainer balance going forward.
Outcome: The client agrees to a scope adjustment. The agency recovers its margin and has a system for catching this next time.
An architecture firm is managing a 14-month commercial fit-out. Phase 2 (detailed design) has overrun by three weeks. Phase 3 (construction documentation) hasn't started yet, and the overall completion date is at risk.
Root cause: The structural engineers sent their feedback late, which forced a partial redesign of two floor plates. The dependency on structural sign-off wasn't in the original schedule.
Corrective action: Run Phase 3's structural and MEP documentation in parallel instead of sequentially. Hire a contract drafter for four weeks to handle the extra volume. Adjust the Phase 3 completion date by one week (recovering two of the three lost weeks) and tell the client about the revised timeline now.
Outcome: The project absorbs most of the delay. The client hears about the one-week change early, with a clear explanation and a plan already in place.
Most writing about corrective action frames it as "getting back on track." That framing misses the financial side entirely.
For services firms that bill by the hour (agencies, consultancies, engineering firms), every hour of unplanned rework or overallocation comes directly out of the margin. If a project manager doesn't catch a 20% overrun on a £50,000 project, that's £10,000 of work delivered for free. Nobody invoices for it, nobody planned for it, and it only shows up when someone reviews the margin at project close.
Firms that run corrective action as a regular operational habit (not a crisis response) usually recover from project problems in days instead of weeks. They flag resource pressure before anyone burns out, keep stakeholders informed when plans change, and build more accurate estimates over time because past corrections feed into future planning.
Exonic Solutions, a software consultancy, reported an 80% improvement in project-level tracking after moving to an integrated system. Without that kind of information quality, corrective action is just guesswork with a process wrapped around it.
Corrective action is only as good as the information behind it. If your project data lives in spreadsheets that get updated once a week, every decision you make is based on numbers that might already be wrong.
Four things to look for:
Professional Services Automation platforms put project planning, time tracking, resource management, and financial reporting into a single system. Instead of assembling the picture from three different tools, the data is already connected.
Magnetic is a professional services automation platform built for agencies, consulting firms, and engineering companies with 25 to 100 people. It connects project management, resource allocation, time tracking, and financial reporting in one system, which means the data you need for corrective action is already in one place.
The features that matter most for corrective action:
Magnetic also handles the financial side of corrective action. Because cost estimates, purchase orders, and invoicing are in the same system as project delivery, a budget overrun flagged in the budget spend view can be traced all the way through to the specific tasks and timesheets that caused it. That level of detail is what makes root cause analysis practical instead of theoretical.
Exonic Solutions, a software consultancy, replaced multiple disconnected systems with Magnetic and saw a 45% reduction in admin time alongside an 80% improvement in project tracking. Chapu Chartered Accountants, a 60-person firm, implemented Magnetic in one week and reported a 70% efficiency improvement. Magnetic offers a 14-day free trial with no credit card required, and pricing starts at £9 per user per month.
Most PMO leaders and operations managers understand corrective action fine. The problem is getting every project manager in the organisation to do it the same way.
When each team has its own approach, reporting becomes unreliable and lessons from past projects don't transfer. If you're starting from scratch, here's a workable structure:
There's a cultural side to this as well. If people feel like raising a problem means admitting failure, they'll sit on issues until they can't be hidden any more. You want a culture where someone saying "this project is 15% over budget" in week three is treated as useful information, not as a performance issue.
Waiting too long. By far the most common problem. Someone notices a task is behind, but assumes it'll sort itself out. It almost never does.
Fixing the symptom and ignoring the cause. Extending a deadline without understanding why the project fell behind means the same thing will happen in the next phase.
Changing the plan without telling anyone. If you adjust the timeline or move work around without informing stakeholders, you create confusion and lose trust. Even when the change is clearly the right call.
Overreacting. A one-day slip on a non-critical task doesn't need a full replanning session. If the response takes more effort than the problem warranted, you've created a new problem.
Working from old information. If your last status update was a week ago, the picture may have changed since then. Any connected project management system that shows live data will serve you better than a spreadsheet that gets updated on Fridays.
This guide was written by the team at Magnetic. Magnetic is a professional services automation platform used by agencies, consulting firms, and engineering companies to manage projects, resources, and finances in one system.
.svg){kind=small}
Corrective action in project management is the process of identifying a gap between the project plan and actual performance, determining the root cause, and making changes to bring the project back on track. The PMBOK Guide defines it as a documented change implemented to realign project performance with the management plan. Common triggers include missed milestones, budget overruns, resource overallocation, scope creep, and quality issues requiring rework.
Corrective action responds to problems that have already happened on a project. Preventive action addresses risks before they materialise by identifying potential issues early and putting safeguards in place. For example, reassigning work after a team member becomes overloaded is corrective action. Building buffer time into the schedule for high-risk phases is preventive action. Both are part of project monitoring and control, and effective project management requires both.
The five steps are: (1) identify the deviation from the plan using project data such as budget-to-actuals, time tracked versus estimated, and resource utilisation; (2) analyse the root cause to understand why the gap appeared; (3) decide on the appropriate response, which could include adjusting deadlines, reallocating resources, or renegotiating scope; (4) align stakeholders by communicating what is changing and why; (5) implement the change and monitor whether it is working over the following days and weeks.
As soon as you can see a measurable gap between the plan and what is actually happening. Specific triggers include a task exceeding its estimate by more than 20%, a project hitting 80% of budget with less than 70% of work complete, or a team member booked above 100% capacity across multiple projects. A 5% deviation caught in week one might need a 30-minute conversation. The same issue left until week six could require a full project replanning exercise and a difficult conversation with the client.
The project manager usually leads the corrective action process, with input from team members, stakeholders, and sometimes the client. In larger organisations, the PMO (Project Management Office) typically sets the thresholds and process (for example, "flag any task that exceeds its estimate by more than 20%"), while individual project managers handle the day-to-day decisions about how to respond.
Corrective action depends on having current project data: timelines, budgets, resource allocation, time tracked, and task progress. Professional Services Automation (PSA) platforms like Magnetic connect all of this in one system, so project managers can see budget-to-actuals, resource utilisation, and schedule progress without cross-referencing multiple spreadsheets. Generic project management tools like Asana or Monday.com handle task tracking but typically don't connect to financial data, which limits their usefulness for budget-related corrective action.
Magnetic is an all-in-one workflow management platform designed and built for professional services firms.
.svg)
