Here's a fact: in local government, nobody manages a single project. If you do, something's wrong with your capacity planning. By month three of my first council role, I had three roads projects, one shared path, and half-responsibility for a drainage upgrade. By year three, I was carrying eight to twelve active projects at any given time, with varying levels of intensity. It's not unusual—it's the default state.
The challenge isn't managing one project well. The challenge is keeping eight on track when they're all hitting pressures simultaneously, when money's being held up for one because budget's transferred to another, when two contractors want SR certification on the same day, and when your director is asking why the roads program is three weeks behind. That's the reality. This is how you survive it.
Why Multiple Projects Are the Default in Local Government
Councils don't have the budget to hire project managers exclusively. They hire engineers and expect them to deliver multiple assets. You get funded from different budget lines: capital, general, grant funding. When one funding source has money and another doesn't, you're told to accelerate Project A and defer Project B. Your personal capacity doesn't change—your workload does.
Contractors also manage this. They don't have crews sitting idle. One crew finishes a road and starts a path three weeks later. The same site manager oversees four or five council projects. If you're not organized, your site manager isn't either—and that's when corners get cut.
The only way to handle this sustainably is to build systems that don't depend entirely on you remembering everything.
The Key System: Programme Boards and Weekly Reviews
I use a simple programme board—nothing fancy, just a shared spreadsheet that lists every active project with current status. Each project gets: delivery status (not started, design, construction active, practical completion, closed), budget remaining, schedule status (on track, at risk, behind), next critical date, and issues/actions.
That board gets updated every Friday based on the week's site visits, contractor reports, and budget spend. It takes 30 minutes to maintain. It shows your director exactly where things stand without them having to ask. And it forces you to actually think about each project weekly instead of reacting to crises.
The weekly review meeting is equally important. You, your director, any stakeholders who care, and (if your council's organized enough) the contractor team leads. Thirty minutes. Each project gets two minutes. Status, next week's critical activities, any blockers. Nothing gets decided in that meeting—it's a status sync and an early warning system. If a project's going to slip, you know it before it actually does.
This system works because it's predictable and low-effort. If you tried to run eight individual project status meetings, you'd spend all your time in meetings. This gives visibility without the overhead.
Prioritization When Two Projects Hit Crises Simultaneously
This will happen. Two contractors will have issues at the same time. You can't be in two places at once. How do you choose?
Your decision framework should be: safety first, then schedule risk, then cost impact.
If Project A has an OHS issue—someone did something unsafe, or conditions changed unexpectedly—you go there first, even if Project B is a bigger budget item. OHS issues can cause injuries, liability, and shutdown orders. Nothing else matters until it's handled.
If both projects have OHS issues (unlikely, but possible), you assess which one poses immediate risk. If they're equal, you go to the one with more workers, because the exposure is greater.
If there are no safety issues, you prioritize by schedule impact. Which issue, if not resolved, will cause more delay? If Project A is near completion and an issue delays it one week, versus Project B which is early and has three weeks buffer, you go to A. Loss of schedule at the end of a project is more costly than schedule loss at the beginning.
If both are equally schedule-critical, you look at financial impact. Which one has more contract value? Which one has more budget exposure?
I learned this the hard way. Early in my career, I made decisions based on which project I cared about more, or which contractor was more likable. That led to real projects suffering. A decision framework removes ego and politics. You make the call because the logic is clear, and you can explain it to anyone.
The Documentation Discipline That Keeps You Sane
With multiple projects, you can't rely on memory. You need to document not just for disputes, but for your own sanity.
For each project, maintain: daily site logs, contractor progress reports, budget tracking, schedule updates, and a decision log. Not books—just structured records. A site log is a few lines: date, weather, activities observed, any issues, who was on site, next week's plan. Takes five minutes if you're there already.
Budget tracking is critical when you're juggling eight projects. You need to know, at any moment, how much of each project's budget has been spent, how much is committed (via certified claims waiting for council approval), and how much is free. When a project overruns and the director asks if you can move money from another project, you either can (because Project B has 15% spare) or you can't (because every dollar is allocated). You'll know in 30 seconds if you've been tracking it.
The schedule update doesn't need to be fancy. For each project, track: the critical path milestone, its current status, what could slip it further, and what's your contingency if it does. Again, five minutes per project, ten minutes total if you're efficient.
The decision log is the one most people skip and most regret skipping. Whenever you make a decision—approved a variation, rejected a claim, issued a direction—you record it: date, decision, reasoning, who it affects. When someone asks six months later, "Why did we approve that?", you can tell them. When a dispute happens, you have a record of your thinking, not just your outcome.
Managing Contractor Relationships Across Multiple Sites
When you're managing multiple sites and a contractor has crews on two or three of them, you need consistency. The same contractor shouldn't experience different expectations depending on which of their sites you're on.
I have a standard set of requirements for all sites I manage: how they report, how they handle claims, how site meetings work, what OHS documentation I expect, how variations are processed. It's documented in a project induction pack. New contractors get it on day one. Returning contractors already know it.
This does two things. First, it sets expectations clearly—no surprises, no "I thought you wanted X but you actually wanted Y." Second, it's fair. Every contractor gets the same standards, so there's no perception of favoritism. If Contractor A thinks you're harder on them than Contractor B, you can show them your standards are identical.
This approach also makes your life easier. You're not deciding site-by-site how to handle things. You follow your standards. That frees mental load for the actual problem-solving.
Budget Tracking When Money Moves Between Projects
Council budgets are rarely static. A project will underspend. Another will overspend. You'll get asked if you can transfer the spare. You need to be able to say yes or no based on facts, not guesses.
I track budget in three categories for each project:
- Spent: Payments already made to contractors.
- Certified: Claims approved by SR, waiting for council payment. This money's allocated but not yet out the door.
- Free: Unallocated remaining budget.
When a project overshoots, you're often moving money from free budget in another project. If you've been tracking this, you know if it's available. If you haven't, you'll guess, and sometimes you'll be wrong, and you'll create a budget crisis that your director blames on you.
Update your budget tracking whenever you certify a claim or learn about a major cost change. Monthly is the minimum. For active projects, I do it weekly. It's 10 minutes well spent.
Managing Stakeholder Fatigue and Keeping Momentum
When you're managing multiple projects, stakeholders get tired. A council has limited capacity for change. If you're asking residents to accept three road closures, diverted traffic, and three different construction sites simultaneously, they get fatigued. They complain more, they're less cooperative, they create political pressure.
You manage this by staggering projects when you can. If Project A can start in March and Project B in May, do that rather than both in March. The same residents experience less disruption, and your contractor pool isn't as stretched.
You also manage it through communication. When a project's about to start, you tell residents: why it matters, how long it'll take, what to expect, who to contact if something goes wrong. You don't oversell or promise things you can't deliver, but you explain the purpose. People tolerate inconvenience more easily when they understand why it's necessary.
Finally, you keep political stakeholders in the loop. Your councillors, your director, your mayor—they need to hear about progress regularly. Not weekly, but monthly at least. A five-minute update that says "Project A is on track, completion expected June; Project B is two weeks ahead of schedule" costs nothing and prevents the situation where a councillor finds out your project is delayed by hearing a resident complaint, not by hearing from you.
Practical Frameworks That Prevent Chaos
The Traffic Light System
Each project is green (on track), amber (at risk but manageable), or red (escalation needed). You use this in your programme board. Green projects get monitored. Amber projects get active management. Red projects get director involvement. You're not micro-managing all eight projects—you're managing the ones that need it.
The Biweekly Site Visit Rotation
With eight projects, you can't visit every site every week. You visit critical projects weekly, others fortnightly. You schedule it in advance so contractors know when you're coming. This is predictable for them and for you—no scrambling to fit visits in.
The Critical Milestone Calendar
Each project has 3–5 critical dates: practical completion, payment date, handover, major deliverable dates. You keep a master calendar. Two weeks before each critical date, you check in with the contractor and your director. Are we on track? What could derail it? What do we need from council? This prevents surprises.
The Monthly One-Pager
Each month, create a one-page summary for your director: all projects listed, status color-coded, budget position, schedule position, and one sentence on each project's biggest risk. Your director can understand your portfolio in three minutes. They're not surprised by bad news because you've flagged it early.
My Personal Approach
I don't try to carry all eight projects in my head. I carry the systems. I know where to find the information, I update it regularly, and I use it to make decisions. When my director asks a question, I have an answer within minutes, not days. When a contractor asks about their budget or schedule, I know it. That confidence—grounded in actual data, not guesswork—is what makes multiple projects manageable.
I also don't pretend to be everywhere. Contractors know I can't visit every site every week. They appreciate that I'm organized enough to make my site visits count. I walk the site with a purpose: check specific quality issues, review OHS practices, understand progress. I'm not there to oversee every moment.
And I protect my own sanity. Multiple projects aren't sustainable if you're reacting constantly. You have to be proactive. That means your Friday programme board update, your weekly status meeting, your monthly director brief. Those systems take five to ten hours a month and give you control over everything else.
The engineers who struggle with multiple projects usually aren't struggling with the projects themselves. They're struggling because they have no system. They're keeping track mentally. They're reacting to crises instead of preventing them. They're duplicating effort because they've documented something three times and forgotten they did it.
Build the systems first. Then multiple projects become manageable. Then you can focus on doing good engineering instead of just surviving your workload.