Ad hoc projects are disruptive and distract your team from their planned work. They’re often urgent and bypass usual project planning, monitoring, and tracking processes.
But if ad hoc projects are consistently allowed to fly under the radar, they can undermine well-planned portfolios and mask wider issues in an organization.
It’s time to start tracking how long ad hoc requests take AND the chaos they leave in their wake. So your organization can reclaim control of unexpected projects and reduce the risk of reactivity.
Here’s how to deal with ad hoc projects in practice - to minimize the risk they pose in themselves, to other projects, and to your wider business.
Ad hoc projects are projects that aren’t planned and don’t appear in your work plan. They’re unexpected projects that crop up, demand attention, disrupt your best-laid plans, and leave you picking up the pieces afterward.
They might be a result of someone else’s poor planning - this is the most frustrating kind because they’re completely avoidable 😠 Or they might arise from something out of anyone’s control - which is much more forgivable.
One example of an ad hoc project could be if a new cyber threat emerges and a client asks your IT business to urgently patch a security vulnerability.
Or perhaps there’s been a PR disaster and your agency has to drop everything to fight fires for your client.
Either way, your planned work needs to take a back seat while you deal with this more pressing matter.
Ad hoc projects usually come with an urgent - sometimes unrealistic - timeframe for completion. This causes pressure to skip usual processes. If someone says ‘I need this yesterday’, it’s probably an ad hoc project.
As a PM, you’ll have proactively planned your team’s work and be managing it for maximum efficiency. Then along comes an ad hoc project that leaves you reacting, reeling, and really not in control.
Ad hoc projects often bypass normal controls because they’re perceived to be too urgent - or too minor - to go through due diligence. But - be warned - ‘off the books’ can turn into ‘off the rails’.
Ad hoc projects often involve a single team. This is because an ad hoc project is more likely to be approved when it has ‘limited’ impact rather than widespread - cross-functional - implications.
Ad hoc projects are usually time-limited, not long-term. A project is more likely to be waved through proper processes if it’s perceived as something ‘quick’ that a team can ‘fit in’ easily.
The problem with ad hoc projects is that they’re rogue. They exist outside your usual controls and project management processes. And this introduces risk on a lot of different levels - some that are clear to see, others that lurk below the surface.
Firstly, there’s the not-insignificant issue of the impact of ad hoc projects on your team and time. We’re guessing your team’s workload is planned to perfection and your resources are working at optimal capacity. There’s no slack to accommodate ad hoc tasks. This means - when unexpected projects land - they demand reallocation of resources from planned projects. And that causes disruption and delay to your current work - which can impact client satisfaction. That in itself should be a felony.
But that’s not the only problem with ad hoc projects. Because ad hoc projects often fly under the radar - neither planned nor tracked - your team’s input into them can go unnoticed. Your team’s productivity and progress against known workload could be seriously undermined. And if people don’t know about the ad hoc work you’re dealing with, that could reflect badly on your super-hardworking team.
Also, because they’re off the books - dodging due diligence - ad hoc projects are more likely to go off the rails. Without time to understand objectives, properly plan and budget, assess risks, and monitor delivery, they could easily end up taking more time and money than they should.
There’s also the bigger picture of what ad hoc projects mean for the business overall. If some projects aren’t being properly logged and tracked, your senior managers are making decisions in the dark. They could be making poorly informed decisions around capacity management, capability building, and recruitment.
And finally, there’s the question of why ad hoc projects are arising at all. If your team - or others - are being hammered by poor planning elsewhere in the organization, this needs to be noted and addressed. If your organization isn’t logging and tracking ad hoc projects, it can’t get to the root cause. This means they keep coming - and causing chaos - which is bad for business.
In an ideal world, you’d be able to reject ad hoc projects outright and refuse anything that doesn’t come through a centralized planning process (more on this later). But we’re realists. There’s always going to be something that bypasses proper processes because it’s too urgent - or the client or manager is too important - to say no to.
In these circumstances, you need a compromise. A way to action ad hoc projects quickly but without giving up all of your usual project controls. This approach will ensure your existing projects - and client outcomes - aren’t sacrificed on the alter of urgency or ego.
Here are four steps to keep control of ad hoc projects - and bonus advice on how to prevent them from happening in the first place.
Ad hoc projects sometimes come with a “They say ‘Jump’. You say ‘How high?’” mentality. If an unexpected project arrives via a senior manager or VIP client, it’s tempting to just give in and go with it.
But simply accepting ad hoc requests isn’t good for anyone - as you’ll have seen in the section above. So get used to CURB-ing people’s enthusiasm for ad hoc projects before you start them.
CURB is an acronym of our own devising 😇 A pre-flight check for unplanned projects. By addressing these four questions, you’ll know whether an ad hoc project actually needs to go ahead. And you’ll get the information you need to create - at least a basic - project plan.
How complex is the project? Are the requirements known, understood, and realistic? Are the expectations of the client or senior manager achievable? (Plus is there a budget attached? And what teams/resources need to be involved?)
Is the project REALLY urgent? Or does the originator just THINK it is? Have they assessed the urgency/priority level compared to other projects, based on the impact they deliver for the business? Ask ‘Why this? And why now?’
If you do prioritize this ad hoc project, what are the risks? Not just the risks for the ad hoc project itself - in terms of project weaknesses and vulnerabilities - but the other projects that it will disrupt and delay. See how to use scenario planning (below) to understand the impact.
What are the benefits this ad hoc project will bring to the business? For example, if it’s for a big client - and means retaining their custom - it may be worth bumping lower value projects in its favor.
Once you’ve performed this initial assessment, you’ll be in a better position to accept - or challenge - the ad hoc project.
This step is all about understanding the impact of an ad hoc request on the other projects in your portfolio. You might perform this as part of your CURB process to pushback against a request - or as a standalone activity if you know resistance is futile.
This is where using resource planning software is helpful - it just makes everything so much quicker and easier. We’ll explain what to do using Runn - but you’ll hopefully have similar functionality if you’re using a different app too.
In Runn, you can use the ‘tentative projects’ functionality to visualize the impact of an unconfirmed project on other work. This lets you understand the implications of an ad hoc project on your team’s workload and decide whether it's actually feasible.
You can also experiment with different scenarios so that - if you do need to reallocate resources or adjust other projects - you can find the least disruptive way to do it. [We’re big on scenario planning - discover more about the benefits and how to do it.]
In Runn, simply set up a new project and select ‘Tentative’ in the project status dropdown. Set up the basic project parameters and see the project appear in your Project Planner overview. From here, you’ll be able to toggle projects on and off to get a bird’s eye view of the impact on resource capacity, availability, and utilization.
Switch to the People Planner and you’ll be able to see the same information at an individual resource level, understanding the impact of different projects and combos on individuals within your team. For example, are they full to capacity? How many hours do they have to spare? It’s color-coded so you can spot the highest capacity at a glance.
You can also look at group utilization, to see how project combos impact different types of resource, such as designers or developers. This is helpful if you’re on the cusp of needing to recruit new resources.
By using tentative projects and scenario planning in Runn, you can:
Read more about visualizing tentative projects using Runn
Once the ad hoc project is confirmed, you need to plan the project and schedule resources. To minimize disruption to your other projects, it’s important to assign resources strategically rather than bending to the ‘drop everything’ mentality.
You need to consider the best people for the work, mindful of the other projects in hand. There’s no point pulling your best developer off another project to work on this one just because it’s urgent - or because they’re the only person free at the moment. Assess which project brings the most benefit to the business and assign/reassign resources accordingly. [Read more about what factors affect how to allocate resources to projects.]
In Runn, allocating and reallocating resources is ridiculously simple.
One mistake project businesses make with ad hoc requests is failing to track them. Ad hoc projects are often accompanied by an air of ‘It’ll not take long’ or a ‘Favour for a friend’ mentality. This means they’re not always subject to the same scrutiny as ‘proper’ projects. This is a big mistake.
You need to track the time spent on ad hoc projects just like any other. This helps you monitor your budget, manage your resources, and stay on schedule. But it also records the time your team has had to divert to unplanned work. This is stuff that senior managers need to know. Why?
Tracking ad hoc projects also gives you more data for when the next unexpected request arrives. For example, if an ad hoc project was supposed to be a quick fix but turned into an epic time-sink, this is useful information for next time.
You should make sure that - once they’re in your program of work - ad hoc projects are monitored and reported on like any other. Always finish with a ‘wash up’ meeting to discuss what went right, what went wrong, and what could be improved.
If your team is perpetually plagued by ad hoc projects, it could be time to take a stand. OK, there’ll always be an emergency you can’t prepare for. But if ad hoc projects are a result of poor planning elsewhere in the organization, it needs to stop for everyone’s sake.
Once you’ve got into the habit of logging and tracking ad hoc projects, you’ll have a better case to take to senior management. You’ll be able to show exactly how much time ad hoc projects eat up - and show their impact on planned workload, capacity, and resources. Not only will you be able to argue to end the tyranny of ad hoc projects, but you’ll also be able to lobby for more staff if there’s a clear gap in existing resources.
Once management is onboard, ideally you need a centralized project request process that everyone has to follow - whether they’re sales or the CEO. This provides a way for all projects to be assessed against certain criteria, to determine their priority and value to the business.
Project requests should complete a standard form that captures project deliverables, likely resource requirements, proposed timeframe, value to the business, etc. And a central team should assess and prioritize them based on their relative merits. This transparency is much better for the business than projects being able to jump the queue without any scrutiny.
If you’re ready to reclaim control of ad hoc projects - and reduce the risk of reactivity - start your free trial of Runn resource planning software today.
How do you know whether your project schedule is ahead or behind? One way is to calculate Schedule Variance (SV). Here's everything you need to know.
Too much work, not enough staff? Your service business might be understaffed. Here's how to deal with understaffing before it takes its toll on your operations.