Even the best project managers can get derailed by ad hoc projects đ Donât let other peopleâs poor planning disrupt your best-laid plans. Hereâs how to deal with ad hoc projects in practice.
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?Â
Because:
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.Â
