In the age of continuous connectivity, many a web worker may feel a sense of wry irony in the fact that often, when we need answers on something, the person we need those answers from is uncontactable.
We all diligently plan ahead, so we allow plenty of time for our colleague to pull together the necessary input to our project. We go out of our way to establish some kind of understanding and rapport. We explain the timeframes and constraints of the project so they know where we’re coming from. And we try to make our follow-up requests as polite and professional as possible.
To no avail, sadly. As the deadline approaches, we find we’re still waiting on that input they promised three weeks ago. Are they avoiding us? Do they think that because we’re not on the other side of the partition that they can ignore our project? Are they using distance as an excuse to relegate our project to the bottom of their to-do list?
It can be a frustrating scenario. Resolving these kinds of problems certainly isn’t rocket science but, in the heat of the frustrating moment, it can be easy to act in haste, rather than in your usually impeccably professional manner. Well, that’s how it is for me, anyway. Here’s a little process I use to ensure that I handle this kind of annoyance appropriately.
Step 1: Call.
Forget email, text and IM. Just call your contact. If you can’t get onto them, leave a message. Speak to their PA. And try them later the same day, or the next day.
If they don’t get back to you within what you deem to be a reasonable timeframe, you’ll have to identify some other way to obtain the input you need. I usually do this around the time I first get the sense that my contact’s not going to deliver, just in case. It’s better to have a backup than nothing.
Step 2: Follow up.
Follow up your call with an email, IM or text. Explain what you need and, if you’re getting edgy about, or are already past, the delivery deadline, identify the steps you’ll take if you don’t hear from the person.
This step — advising the person of what you’ll do if you don’t hear from them — is essential. You must give the contact fair warning about the consequences of their inaction, and allow time for them to get back to you. Even if it’s just a call to admit they can’t deliver what they promised, it’s essential that you give your colleague that opportunity. If they don’t take it, that’s their choice — but you need to do the right thing.
Obviously, you may need to discuss your contingency plans with other team members in order to arrive at a suitable outcome for the project. In some cases, you may effectively need to pull rank — speak to someone higher up in the chain of command — to ensure you can have the task delegated to another individual, or simply to have pressure applied to your colleague from above.
Step 3: Deploy Plan B.
If the contact still hasn’t produced the work, or responded to you, it’s time to deploy Plan B: unleash the consequences you described in your follow-up message.
In my experience, tasks are very rarely re-delegated to another team member. Usually, my project timelines have been extended to allow the original delegate to complete the task or — gasp! — if I’m capable, I’m asked to pick up the slack and do it myself.
Regardless of what the contingency plan is, it’s courteous and professional to let your colleague know that you’ve decided to implement it. That way, you can avoid the potential for doubling up on work, since you both know where you stand, what the next steps are, and who’s taking responsibility for producing the input.
Contingency Planning Pays Off
The key point here for those working in a team is: don’t go it alone. It’s important in such circumstances to let your team members know early if you’re having trouble obtaining inputs from one person. This ensures you can do your contingency planning ahead of time, and that you feel supported in your efforts to do your job.
If you’re working alone, not in a team, and you can’t obtain an answer that you need — such as client approval to proceed on a new project — your contingency plans may include devising strategies to shift the potential project to the backburner without upsetting the client or undermining your income for the month, and sourcing a new client or project with which to replace this one.
This is the way I usually approach the issues of avoidance that seem to crop up in the world of web work. How do you handle such situations?