Work in Project Management long enough, and eventually you will come across everything - this will include having a Project you were working on cancelled. This can be a difficult process because we are often personally invested in Projects, and seeing all that hard work being seemingly be in vein can be difficult. In this article series I give some considerations to cancelling projects, discussing if it should be done, why it should be and how.

Firstly, today I will look at the question "Should Projects ever be cancelled?" Quite simply: Yes. The alternative is to suggest that all Projects, no matter how warped, off-track or irrelevant they have become, should be permitted to go on indefinitely. That clearly doesn’t make sense, so we need to accept the hard truth that cancelling a project is sometimes the correct decision. However, rather than seeing it as a purely negative activity, I suggest that cancelling Projects should actually be seen as a sign of strength. There is always the temptation to continue to throw good money after bad, to keep plugging away at something for just a bit longer, work a bit harder etc. But to have the courage to go against this and make the decision to end the project is tough – but such is the nature of leadership. It requires the ability to emotionally disconnect from the project and look at the big picture, consider the facts at hand and make a clear decision.

So whose responsibility is this decision? Well this will depend on the organisational structure, but essentially the Project sponsor, sponsoring group or body; this may be the Programme Manager, a Project Sponsor or a Project Board. If this isn’t clear within your organisation then this potentially points at bigger problems, and even hints at how the project may have found itself in this position in the first place. The Project Manager themselves shouldn’t make the decision, instead they may identify that they don’t think the project will meet its desired goals, and communicate this to the higher decision making body for review.

So, why would a Project be cancelled? In my view it can one of two main reasons: It’s not the right project any more, or the project isn’t being done right. In the next articles in this series I will look at each of these in turn - stay tuned! In the team time, have you ever worked on a Project that has been cancelled - or even had to decide to cancel one yourself?

Stay Healthy! Project Health Check - projecthealthcheck.org

PRINCE2 is a popular UK Project Management methodology, that continues to gain traction in other locations around the world. Now managed by Axelos, it is part of a comprehensive and integrated best practice suite along side other methodologies such as Management of Risk (M_o_R) and Managing  Successful Programmes (MSP). As such, is provides as alternative to the Project Management Institute's (PMI) A Guide to a Project Management Body of Knowledge (PMBOK), and it's Project Management Professional Qualification (PMP). Since the author holds both the PMP and PRINCE2 Practitioner Certification , it can sometimes be insightful to compare and contrast the two approaches to see what stands out in both.

The author always thought of the PRINCE2 "Themes" to be equivalent to the PBMOK "Knowledge Areas"; a specific sub-disciple of Project Management that was important throughout the lifecycle; for example they both have "Risk" and "Quality" in common. Then there is the PRINCE2 "Processes", equivalent to the PMBOK "Process Groups" - essentially the flow of phases throughout the Project Life cycle. They are both broadly like any good book or film, in that they have a beginning, a middle and an end - with of course a bit more complication along the way. But PRINCE2 has a third component: "Principles". I don't think PMBOK really has an equivalent, so I think PRINCE2 has an edge here; but what actually is a "Principle"? Without turning to the dictionary, I would instinctively think of then crudely like a "guiding beacon". They aren't detailed processes or procedures, they aren't step-by-step plans or rigorous methods. Instead they are are simple but critical focus points which must then permeate everything else we do in Project Management, something that we strive both toward. Why are they useful? Simple: because once you've got your PMP or PRINCE2 exam in the bag, that old textbook is transition into phase 2 of it's lifecyle: dust collector. You'll apply these methodologies competently of course, but you'll soon forget what precisely is actually in section 7.3.6.1 of the PRINCE2 handbook. But Principles are different; short and simple, if you forget all of the other detail and just focus on remembering them I don't think you'll then go far wrong

Ok Project Health Check you've got my attention, maybe these Principles could be useful in my Project. Tell me about them! Well this is just an initial insight, with our intention to focus on them in future articles - exploring our perspective and add some real life experiences along the way.

PRINCE2 Principles

1. Continued business justification
2. Learning from experience
3. Defining roles and responsibilities
4. Manage by stages
5. Manage by exception
6. Focus on products
7. Tailor to suit the Project Environment

What are your thoughts on these Principles, do you agree with them and can you think how they have played a role during your own Projects? Also, do you think anything is missing? Let us know your thoughts in the comments below!

Stay Healthy! Project Health Check - projecthealthcheck.org

Agile is a methodology which is getting more and more traction in the IT industry, to the point where the word is agile is thrown around out of context and with incorrect capitalisation. There are many variants, but a feature now common to many is the idea of a daily Scrum meeting to manage the work. In our experience, how this meeting is planned and executed will set the tone for the entire project, and how effectively they embrace the true Agile approach. Will it be truely Agile, or just "Agile", or even Watergile?

We've seen it done well, but also sometimes sickeningly badly - and made our own errors along the way. Here are our top tips for effective Scrum meetings:

1. Scheduling: The Scrum should be at a set time every day without fail, early enough in the morning to set the tone for the day but late enough to ensure everyone is consistently in the office in time! I suggest around 9:30 - 10:00 is ideal.
2. Timings: I suggest the Scrum should be 15 minutes in duration maximum top, short and sharp - any longer and you are just waffling. It should start on time precisely - be obtuse if needed to ensure this happens. If you're missing people, or they are having a chat then just start without them or over them - it might cause some angst for the first couple of meetings but team members will soon get the message. One problem is that many team members have poor time keeping - in fact it is our personal bugbear. Invite someone for a meeting at 09:30, and rather than be there ready, they will nonchalantly meander around to the meeting at 09:33 without a care in the world. To combat this we suggest that the meeting invite in calendars is scheduled for  a twenty minute period such as 09:30 - 09:50, but the meeting starts at earnest at 09:35 sharp. Use the first 5 minutes as buffer and for the obligatory morning salutations. Get a high quality visible wall clock, set it right and make sure everyone knows that is the master time clock - then there are no excuses! 
3. Sprint Burndown: The Sprint Burndown is essentially your status report on the Sprint, it tells you as Project Manager as well as senior managers who take an interest, how the Spring is progressing. Have the Sprint Burndown on a screen for all to see when they assemble during the buffer time; this will help foster the mindset that it is a team effort and the entire team is responsible for that progress. 
4. Stand Up: I'll be honest and say we didn't when I used to attend scrums, but I regret it. We always sat down and got nice and comfortable - then the meeting dragged on for half an hour. By physically standing up, it encourages brevity from participants.
5. Agenda - Each scrum team member provides an update on 3 things during the Scrum: what they did yesterday, what they will be doing today, what is blocking their progress. As PM you should be particularly interested to the blockers, catch the team members off-line after the Scrum to see if you can help remove those obstacles.
6. No Discussions - The team updates shouldn't morph into a discussions, if someone responds to someone or asks a question then the Scrum Master should start a visible egg timer in front of everyone with a 30 second time limit. As soon as that limit is reached you move on to the next update; discussions should take place immediately after the Scrum between the interested parties only, to stop wasting other people's time.
7. No External Input - Only the project team can contribute, that is those completing Story Points and contributing towards Spring Velocity. As PM this may mean that you don't contribute and are not allowed to talk! It depends how you translate the traditional PM role into Agile - in our experience the Scrum Master was typically more of a technical lead role, but PMs sometimes are Scrum Masters and we have done it before. But definitely no senior managers or external stakeholder interrogating the team or asking questions - shut them up and kick them out! If that means you as PM needs to take heat to protect the team: so be it.

Do you disagree with any of these, or would you suggest any others? Let us know your thoughts in the comments below!

Stay Healthy! - Project Health Check projecthealthcheck.org

We’ve said it before and we’ll say it again, Project Managers (PMs) live and die by the Plan. The entire purpose of the Start-up Phase of a Project is to produce a comprehensive Plan for the Project; consisting of an integrated Performance Measurement Baseline (Time, Cost, Scope) and an associated Project Management Plan to monitor and control it. Once the planning is complete, the Project shifts into the main Execution phase which will form the vast bulk of the timeline. The Project should then be reporting its status regularly to senior management via a Status Report, as part of its overarching Governance arrangement. So far so good; but when an organisation is orchestrating its status reporting process, what does it need to consider?

We’ve recently been involved in a review and update to the Project status reporting and governance structure for a major organisation with circa 150 Projects live projects at any one time. When you have that many Projects, the Project status reporting process needs to be effective and efficient to ensure the Organisation can “see the wood for the trees” – where does it need to focus its limited time and resources? Below we’ll outline up some basic high level considerations which we consider to be important; look on for more details on some of these points in future articles.

1. Management by Exception: This PRINCE2 Principle is extremely valuable as the starting point; the Project shouldn’t need to tell management about every single thing that it has done. The Project Plan was agreed and the Project now tracks to it; why waste time and effort restating what’s in the plan? The truth is senior management aren’t really bothered, or at least they shouldn’t be.
2. RAG: Red – Amber – Green. Very common terminology in the UK (“Amber” is the middle light on our traffic lights) you can call it Red – Yellow – Green if you prefer. This simple rating approach is pretty universal, and helps to implement step 1. A Green status means the Project is on-plan: management don’t waste your time asking any more questions. Amber status means the Project is a little bit off track, so keep an eye on us to make sure we’re ok. A Red status means we’re up a creek without a paddle – help! When you are dealing with a very large number of projects, RAG states help management see pain areas at a glance and then focus their attention accordingly.
3. Milestones: I’m not a fan of status reports with “Achievements this week” and “Planned for next week” – do they really want to know every task we’ve done and are planning to do? I have a very big schedule… But Project Milestones are different; high visibility key dates, they are typically tied to contractual requirements and financial payments. Reporting progress against these, or any risk to them, helps to give an appropriate view on progress without worrying about minor variations against individual tasks. Ideally, organisations should define as part of their standards a common set of milestones to be adopted by all Project to ensure consistent nomenclature and reporting.
4. Sub-Factors influencing Status: Reporting an overall RAG status is good, but in reality a Project’s Status is influenced by many factors. Effective reporting should ensure a Project report status against a standard set of sub-factors, which then collectively inform the overall Project status. These sub-factors may be different between organisations and industries, but should be common within the organisation, supported by an associated set of clear definitions. A good place to start when considering potential sub-factors is the Performance Measurement Baseline – the triple constraint of Scope/Cost/Time; how are we performing against these? What about the client relationship? If they don’t think the Projects going well then it doesn’t matter what you think. Risk is another factor; it’s nice if the Project is going to plan, but if there a lot of very severe risks stacked up that may impact at any time then the Project has the potential to go off course at any minute. There are many others of course: legal, commercial, safety, security, solution – the list goes on. Pick some, define them, stick to them.
5. Go-To-Green Plan: We’ve agreed the importance of the plan above, and if the Project Status is Amber or Red then clearly we are off-plan. What we need then is a plan to get back on plan – sometimes known as a Go-To-Green plan, or Corrective Action. If the Project is Amber or Red, management want to know that you have it in hand, and the GTG plan shows this. They will want to review it of course to ensure it is credible, and understand if they need to support it in any way – approving a Change Request to scope, making a priority call on key resources etc. In the worst case you may not be able to produce a GTG plan, in which case management will want to know when you will have one; a Plan for a Plan perhaps, or a Go To Amber plan.  
6. Reporting System Independence: The truth is that no one likes their Project to be Red, and understandably so – all you get is heat from senior management. The problem here is that sometimes PMs will keep on reporting Green when they should be reporting Amber or Red. This means that rather than getting the focus and support to fix their Project, the Project performance continues to slip until they are totally unrecoverable and yet another Project fails entirely. To counter this, Organisations need to foster an environment where being Red is not a negative; instead PMs get genuine support. Additionally, Organisations need to establish a reporting system what removes the ability to PMs to make potentially subjective and biased assessments of their Project’s status. Instead they should look to shift assessment of the key indices’ of Project performance out from their hands, and automate it based upon Project Performance Data. For example, cost performance data is collected by the PMO and the Cost Performance Index (CPI) is calculated and compared against defined Organisational standards to determine the Finance Status of the Projects – the PMs Judgement has nothing to do with it.

So there you go, some basic high level considerations for Status Reporting and Governance that we’ve used. What other considerations can you think of for designing Project Status Reporting processes? There are many other factors of course, and we may get on to them in the future!
​
Stay Healthy! Project Health Check - projecthealthcheck.org

Lean Six Sigma, a management buzzword that seems to persist and many don't understand. But what is it and how is it related to Project Management? Lean Six Sigma is an approach for Process Improvement Projects, combining many different conceptual tools depending on the situation. Essentially Lean Six Sigma is a fusion of two ideas: "Lean" and "Six Sigma":

Lean
Lean is a approach that seeks to eliminate Waste during a production process; it originated in Japan on the production lines of Toyota. It tries to make a process as efficient as possible, to reduce excessive costs and time - meaning the customer get the product they want faster and cheaper, the company improves their margin. It identifies seven categories of Waste which should be investigated and eliminated (though others have since been suggested):

1. Overproduction - It puts more pressure on the production process and reduces flexibility to change production
2. Waiting - Any time delay adds has a knock on effect on the final time to delivery
3. Transporting - Moving stuff costs time and money and provides no return
4. Over Processing - Gold plating additional features which aren't being requested don't provide a return
5. Inventory - Undesired costs to create and store products
6. Motion - Needless movement add time to processes
7. Defects - Obvious issues that need fixing

Lean will often start by interrogating the Process and conducting Value Stream Mapping and producing Value-Add Maps/Charts to show in detail what value every step in the process brings. It then used changes call Kaizen to fix these; small incremental changes that generate quick wins, made repeatedly to improve the overall process

Six Sigma
Six Sigma looks to improve the quality of the output of a process by reducing the variation of the output; it was introduced at Motorola in 1986 and resulted in $16 billion of savings. The term sigma comes from the statistical concept of standard deviation of the normal distribution; if points are normally scattered about a mean then one sigma is defined such that it would capture 68% of data points, 2 sigma would capture 95%, 3 sigma 99.7% etc. Six Sigma has a strong statistical focus, and defined in purely statistical terms a Six Sigma process is one in which 99.99966% of all opportunities to produce some feature of a part are statistically expected to be free of defects.

Six Sigma uses a lifecycle called DMAIC, that has five distinct phases each consisting of an array of tools that can be employed - depending on the nature of the project:

• Define - What are you actually trying to do? Define the Problem, the associated Goals, who in involved, the key measures and the rough timescales
• Measure - Quantitatively what is the current performance? Define a measurement plan and associated operational definitions, and check the quality of your measurement systems
• Analyse - Interrogate the data with statistical techniques to understand the process and it's performance. Understand weaknesses and root causes.
• Improve - Identify potential solutions, plan and implement them
• Control - Monitor implemented changes to confirm they have the desired effect

A Lean Six Sigma project can be a really effective way of delivering Process Improvement Projects - a distinct methodology from PRINCE2 or PMBOK. Alternatively, if you are managing mainstream project using either of these methodologies, you could then run a LSS Project using DMAIC on the across the Project processes themselves e.g. your demand management process, testing processes etc.

What are your experiences of Lean Six Sigma and DMAIC, good and bad? Let us know in the Comments!

Stay Healthy! Project Health Check - projecthealthcheck.org

Risk Management is one of the well established fundamentals of Project Management. Whatever system or tool you use, the basics of rating risks with some degree of severity and impact is well understood, and then doing something to stop it (because they usually are threats). But I have a challenge for you: look back over your last Project and consider - how many of the issues that occurred along the way were from impacted Risks that were identified on your Risk Log? I predict very few of them. I contend that we are typically very weak at one critical part of Risk Management: Risk Identification. And if you don't identify the potential risk in the first place then there is no way you can manage it - despite any fancy risk processes and tools you may have! This is where we can deploy one very effective process - the Risk Identification Workshop.

The Risk Identification Workshop is carried out during Project Planning, and is essentially a risk brainstorming session to try to identify everything and anything that may impact the Project. It is a proactive exercise to try to identify risk, rather than more typical passive identification mechanisms we see - for example something happens to pop up during estimating or requirements development and is added to the Risk Log. Its purpose isn't to develop detailed descriptions, evaluations or response plans to risks - merely to get first sight of them and get them on the radar.

Risk Identification Workshops work best when all key stakeholders are engaged, and can hopefully attend in a face to face session. Established Risk Prompt Lists can be used, which list a variety of key categories of consideration to the Project. This is essentially applying Lessons Learned to the Project, as historically these categories have been identified as having been sources of Project. Workshop attendees then throw out thoughts and ideas against each category in a positive collaborative environment, brainstorming anything that could later manifest as a risk. This works best with the prompts written on a marker board and post-it notes stuck on with ideas. Then the Project Manager or PMO team member can start to scribe them so they can be analysed and evaluated as a later date - not as part of this session.

Typical Prompt Lists may include:

SWOT
A simple classic - what are we good at and succeeded at in the past, what are we bad at and have failed at in the past?

• Strengths
• Weaknesses
• Opportunities
• Threats

PESTLE
This is typically used as Programme or Portfolio level to look at Strategic influences on the future work programme:

• Political
• Environmental
• Socio-Cultural
• Technological
• Legal
• Environmental

Our Project Risk Workshop Template contains these Prompt Lists and others, and allows you to record potential risks identified in your workshops - check it out in our store now! Have you ever used a Risk Identification Workshop in the past, and how did it work for you?

Stay Healthy! Project Health Check - projecthealthcheck.org

Lag and Lead time in also a concept in these logical relationship. Lag represents a time delay following task 1 before task 2 initiates, such as waiting for paint to try before fitting the wall lights. Lead is essentially negative lag, for example you could start fitting wall lights on one wall before all of the other walls paint has dried.

We've seen people make the mistake of thinking that by logging Dependencies in the logic of the schedule, that's them covered. But the problem with this is that a big schedule may have thousands of tasks and thousands of dependencies - how do you "see the wood for the trees"? You tend to find that, although there are many Dependencies on a Project, there are only a few key Dependencies. It's not worth making a special effort to track pretty mundane day-to-day dependencies which we take for granted, but these key Dependencies are critical to your Project's success - and so warrant special attention.

You can think of these key Dependencies in terms of a "Give-Get" relationship; either you are Giving or you are Getting. Typically it will be a key delivery from a 3rd party or supplier, or a key milestone date you have to deliver something to the client. In this case you should use a Dependencies Log to track them; this will make sure you maintain visibility of them and are able to more easily monitor them. An alternative is to recognise Dependencies as a source of Risk on your Project, which they certainly are; any "Gets" which you are waiting for from outside of the Project are not under your direct control. So you may chose to scan Dependencies to identify Risks that you need to log and manage, or you may actually integrate your Dependency Management into your Risk Management Tool/Process entirely.

What experiences do you manage Dependencies on your Project? And if you need a Project Dependency Log Template we have you covered in our template store!

Stay Healthy! Project Health Check - projecthealthcheck.org

This is a new one for us - Book Reviews! Continued learning and development is important not just for Project Managers, but for practitioners in any field; this development needs to be a combination of new in-the-field experiences, and the theoretical grounding it is based upon. This particular book is the "Project Management Pocketbook", by Keith Posner and Mike Applegarth, and stands out on my Project Management Bookshelf both physically and conceptually.

Physically: my first impressions are that this is a tiny little book, with 110 pages but less than 15x11cm in a landscape-type format- about 1/3 of the height of a normal piece of paper, and 2/3 the width. It's clear this isn't mean to be a Project Management tomb, unlike most of the other books on my shelf. Which is where the conceptual difference comes in: most of my books tend to be the official textbook of various certifications and methods. Frustratingly many of them are now out of date versions! But I think that is one of the positives of this book; it isn't linked to a particular methodology or system, and its basic concepts are timeless. Its clear it doesn't set out to be a definitive end-to-end Project Management book, but instead little hints and tips each one to a small page. I think perhaps this will mean that mean that rather than having yet another book gathering dust on a shelf, you are much more likely to dip in and take 30 seconds to read a page - so you'll more likely get some benefit from it compared to "just another textbook".

The Contents breaks the book down into What is a Project, Scoping, Planning, Implementing, Evaluating the Project and also working with People. The last section is especially useful as it moves us away from thinking about the Project Lifecycle and reminds us of our role as a Leader in the Project as well as a manager. The other phases don't correspond directly to any Phase names I've seen in any Project Management methodology, but are universally understandable. As to the content, it's a bit of a random bunch consisting of various simple techniques and ideas - for example SWOT Analysis, PERT Diagrams, Project Reporting etc. Some of the acronyms were new to me such as "the 5 C's of decision making" and "SQUID", but that didn't make them any less useful - actual it was more because it would have been pointless if it was recycling the same old material.

All in all, not a bad book - I'm pretty sure I could do better, but who has the time? Let us know your opinions in the comments below.

Stay Healthy! Project Health Check - projecthealthcheck.org

 When you're starting a new project, you of course identify staffing requirements as part of your estimating. You start to "put bums on seats" as you ramp up the project towards the Execution phase and on-board your project team. You hopefully even have a Team Management Plan that describes how you manage the team; how you on-board, train, mentor and recognise staff. You do all of that and think "phew! That's another job done!" But unfortunately that isn't always the case because there may unfortunately be staff turnover during the Project's lifetime.

Staff may come and go during the Project for a number of reasons: sickness, personal issues, reassignment to other priorities by higher mangers or as is often the case, by leaving the company to pursue opportunities elsewhere. Losing staff partway through a project is always tricky as you lose not only the individuals general expertise, but also their specific insider knowledge of your Project, client or technology. This presents a Risk to the Project that you need to mitigate as much as possible, and the best way to do that is via having a robust Knowledge Transfer Process.

Knowledge Transfer (KT) is where an Outgoing team member passes what they know to an Incoming team members. It should ideally be supported by a standard Knowledge Transfer Plan Template to ensure consistency of KT - and we will be launching such a template soon so keep an eye out! The KT should then follow a consistent repeatable Process; we outline a 5 Phase Knowledge Transfer Process below which you can use on your Projects:

1. Plan Knowledge Transfer
The object of this phase is to produce a comprehensice Knowledge Transfer Plan that will detail precisely what information will be transferred and when, covering all aspects of KT. As we start, there is an assumption that the incoming resource has been identified as is ready to onboard into the organisation - any delay in this reduces the KT window, and increases the risk of the loss of expertise. Using an existing KT Plan Template your organisation should have, the first task is to understand the time constraints that will affect the KT.

By understanding when the Outgoing resource leaves, when the Incoming resource can start, and their relative working hours you can then get an appreciation of the size of the KT window. From here, a time analysis should be completed using a "Working Backwards" method to break the time down into the next 3 phases we outline below (KT Sessions, Shadowing, Reverse Shadowing). The KT window may often range anything from 2 weeks to 3 months, but could be outside of these bounds in extreme circumstances.

​Then, every aspect of the role should be identified and factored into the KT Plan, with  sessions for each across the KT Sessions, Shadowing and Reverse Shadowing phases. Many roles include tasks with a degree of periodicity, usually weekly or monthly, such as a weekly status report or attending a monthly programme board. These should be factored into planning give at least one experience of each in the Shadowing and Reverse Shadowing phases if possible. 

2. Execute KT Sessions
Each discrete area of knowledge identified should have a planned session to review. There should be some sort of documented work instruction, which may potentially be a step-by-step procedure for more transactional work. The session should use this work instruction to define inputs, activity, outputs as well as what tools & assets are used. Here is where more mature organisations win out: if standard processes and tools are defined universally in the organisation then they benefit from this being a lot quicker and easier. But immature organisations, where everything is bespoke and where teams operate in silos, suffer the consequences of this being a lot more time consuming. Be warned!

3. Execute Shadowing
So the new resource now knows the basics of the role, now they need to watch it in action to see how it plays out for real. They should shadow the Outgoing resource when they complete these tasks so they can start to understand how the theory is applied.

4. Execute Reverse Shadowing
It's now time for the new team member to get hands on and try the work in anger. Only by doing can they really get familiar with the role, and others involved in their activities understand who they are and that they are the point of contact going forward. Be it producing the report or chairing the meeting, they now take the lead. The Outgoing resource is still in the background to shepherd the Incoming resource to make sure errors are identified and corrected, but there involvement should steadily reduce throughout this phase.

5. Complete Knowledge Transfer
By the end of the Reverse Shadowing phase, the new staff member should be as well prepared as possible to take on the new role. You should now have a good appreciation on how competent and capable they will be compared to the outgoing resource, but obviously it will still take some time in role before they reach their full potential. Use this final step to identify any specific remaining shortcomings or Risks that you need to be aware of as the new resource moves to independently operate their new role, and Implement risk mitigation actions to try to prevent those shortcomings from impacting the project. Ideally, the outgoing resource will still be available for the occasional query for some time to come just in case, a form of extended Reverse Shadowing-lite; but this can't always be relied on.

What have your experiences of Knowledge Transfer been like in Projects? And don't forget to keep an eye out for out KT Plan Template that will be launching soon!

Stay Healthy! Project Health Check - projecthealthcheck.org

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