Urgent requests: it seems like most requests we get are. I took over a role recently, and rather than a detailed Knowledge Transfer plan covering many topics over a number of weeks, it basically took half an hour. "Most of what I do is respond to urgent requests". Well then, I thought, there's your problem.

Urgent Requests literally hold us hostage for our time, and we never have any warning they are coming. "The Tyranny of the Urgent" is a phrase that neatly describes this ever present effect, which can not only be detrimental to our Project delivery, but the stress it induces has a detrimental effect on us as human beings And yet the more we react to these unplanned activities, the more we are on the back foot - the more we are reactive. Sometimes called "Context Switching", it has been shown that any shift of attention to a new task ends up costing us a lot of time in trying to re-focus. That gives us less the less to get on the front foot and shape the reality of the projects we work on. It's a downward spiral that you need to fight your way out of fast. But how?

First, we need to understand the root cause of these urgent requests. which I broadly categorise into two:

1. Someone doesn't have the information they need when they need it - this is about Communication
2. There is an issue that requires you to resolve it - this is about Issue Management & Escalations

I suggest a five-stage approach to better manage these urgent requests:

   (1) Do your basic Project Planning right
We all know the Project Management textbooks, and often cast them aside once we've passed the relevant exam. But don't, because doing the basics right in any discipline will set you up for success. Do you have a Communications Management Plan, does it reflect reality and has it been widely reviewed and agreed to? This is how you plan your communications, so if someone has an urgent request for information then something must have been missed during communications planning - fix it. But robust planning in general will set up the project for success; things like engaged stakeholders, managed risks and a realistic Performance Measurement Baseline will reduce the likelihood of issues appearing in the first place. Skip these basics and you are only setting yourself up to be on the back foot for the rest of the Project; the Project Manager should dictate how the project will play out, not vice versa.

   (2) Define an Issue Escalation Process
In point 1 we attempted to avoid urgent issues and escalations in the first place by proper planning. If that doesn't work then we need to put in place a process to manage these. This takes these ad-hoc uncontrolled requests that may be coming in from many directions, and funnels them into a standard process where we can impose order upon them. Define escalation routes for different types of issues e.g technical, financial etc. You can use a Communications Plan or an Issue Management Plan for this; but make sure you define it somewhere and then communicate it effectively - be it via email, apresentation or even desktop tri-folds.

   (3) Reduce your exposure
In step 2 we defined an escalation process, in step 3 we make sure it is adhered to. Despite best intentions, it can be easy in the pressure of the moment for individuals to skip the defined escalation routes - especially if they can see you right there. There are times you need to reduce your exposure to these rogue escalations by physically or digitally making yourself unavailable. Work remotely if you need to complete an isolated major task (e.g. writing a key part of the plan), mark yourself as busy or do not disturb on instant messenger tools, hot desk in different parts of the office such as empty meeting rooms. It can feel like you are avoiding responsibility, but in reality most problems can be resolved without your interaction. So while you do still need to be reachable in some way for appropriate escalations, this will free you up to focus on running the Project properly.

  (4) Delegate
Now and again a urgent request will rightfully come your way, perhaps a customer escalation for example. But this still doesn't mean you need to drop what you are doing to personally resolve it; you are Accountable for making sure it is resolved, not necessarily Responsible (think RACI). A Project Manager is a leader, so use your team by delegating and overseeing this request to the most relevant staff member, or to the staff member who has availabilty or isn't on the critical path at the moment.

   (5) Learn
So a genuine urgent request came you way, and you managed to resolve it - good. Now try to learn from this: understand the root cause of this urgent request and take Preventative Action to stop it happening again, otherwise you are doomed to repeat it. Was it an urgent request for some project status information from higher management? Then look to see if you can include them on the distribution of status reports you already produce, or alternatively understand what information they need that you don't already produce - then amend the Status Report to capture this. Ask yourself the question "how should have this been taken care of by our normally processes such that this urgent request never happened?" - try to make sure this is the last time you will get an urgent request of this nature. But while you are doing this, think Lean - avoid adding more unplanned work by reusing exist activities as much as possible.

Let us know in the comments below how many urgent requests you get on your Projects, and how you handle them. And check out our articles on Project Lessons Learned and our Lessons Learned Log Template if you want to effectively implement point (5) above.

Stay Healthy! Project Health Check - projecthealthcheck.org

Project Risk Logs are pretty well institutionalised, and we mentioned them in our last blog post. But what about Issue Logs? We've heard Issues defined as an impacted risk, an unknown question that needs answering, or just a general spanner in the works that will cause you to go off-plan.

In our experience, Project Issues pop up so thick and fast that most never even get documented. Clunky Issue tools just aren't agile enough: I recall one which required a lengthy check-out from a Config Management tool, two minutes to load, a pile of error messages to click past, then around twenty fields to complete - before starting the check in process. People just weren't interested, and just didn't bother. But it meant that during the End-of-Project Review it didn't look like there had been any problems along the way as none were documented! This had a double impact of meaning Lessons Learned couldn't be carried out to improve in future, and when questions were asked after it was all over about why the Project was inevitably late or over-budget that all the issues had been forgotten. Cue scraping about through old emails from two years previous from whichever project survivors there were.

We've considered the use of a simple whiteboard for Issues - certainly more user-friendly and will better focus attention in a single office location. But for multi-location delivery this won't work, and we still don't solve the problem of recording issues for future analysis. Other times I've seen Issue Logs emailed to everyone every day (auto-delete?)

A simplified electronic log on a share is most suitable in our experience, with minimal fields to capture the basic Issue information for action and recollection. Check out our own Project Issue Log Template that is available now! What methods have you used to log Issues and maintain focus on them on your Projects?

Stay Healthy! Project Health Check - projecthealthcheck.org