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

There's lots of talking on Projects; too much really. And so little of value said. People lurch from meeting to meeting, telecon to telecon, wear out the carpet on their mobile phones. People proffer opinions, half baked viewpoints, analysis and hot air. Next time they do that, just stop them and ask "What's your data point?".

They won't know what you mean of course; but then it is a phrase we basically just made up. But it does cut to the crux of the matter: I don't want opinion or views, I want hard data. I don't want qualitative Analysis, I want Quantitative Analysis. The "data point" represents the precise measurement of a process to give true insight into its performance. Ideally a Project Manager would never have to write their own status report, the project tools would do this automatically based on the current actual performance data. Finance data provides financial performance; Schedule data provides Schedule performance. We can aim to remove the subjectivity, and report a true reflection of actual status. That status would then not only be clear and unambiguous, but the automation of reporting would be Lean process improvement to boot. Then we can get down to the important part of Project Management: running the plan, implementing Corrective Actions to get back on plan, and Preventative Actions to avoid going off plan in the first place. And as project managers, we live and die by the plan.

This transition from qualitative to quantitative reflects generally a move from a lower to a high maturity culture of project and programme management. Those familiar with the CMMI model of Process Improvement will recall the "Measurement and Analysis" Process Area; introduced as a level 2 maturity PA that is the basis for many other advancements (the rating is 1 low - 5 high, but there are no level 1 Process areas).

So how do we get there? Well we start by putting in place a Project Measurement Plan. "What?" you ask, "that's not in the PMBOK guide?!" True, though perhaps it could be said to be part of the Project Quality Plan. This Planning Product will define what you will measure on the project, when you will measure it, where it will be stored, and critically what the thresholds of performance are; outside the thresholds then it's time to act. It could even be a Programme umbrella document to ensure consistant standards across projects.

There's a lot more to it than that, of course. But collecting data is the first step on the road to high maturity. Go and look at what you are measuring on your project, and see where you have these measurements planned - if at all! And remember the question: "What's your data point?!"

Stay Healthy! Project Health Check - projecthealthcheck.org

We all make Assumptions every day, mostly without thinking about it. The reason we don't think about it is because we are so confident they are true; be it how something will turn out, what someone will do or what something is like. They are the bedrock of day to day life, and we just don't notice them.

Project Management is exactly the same; we make many Assumptions in planning our Project, things that we almost take for granted. But the difference is here we need to make a special effort to notice them, because Assumptions have a nasty habit of turning into Risks, which then may impact and turn into Issues. The flip side is that we can't and shouldn't devote a huge amount of time to managing Assumptions because it just isn't worth it - most of them are true, and his will just distract us from project delivery.

We suggest a two-step Process to Assumption Management:

1. Identify Assumptions. This is the proactive act of identifying those Assumptions that underpin your planning, those things you take for granted. They must be formally logged on a Project Assumptions Log, so they aren't lost in the midst of delivery and are available for further analysis if needed. This logging will capture only some basic information such as a title, owner, date identified and Category (Staff, Schedule etc). I suggest you exhaustively identify every Assumption possible - you can always close them later. Then, any proposal to a client or management for review should come with as many of these Assumptions bolted on as possible and appropriate; they too can validate them.
2. Monitor Assumptions. This then again pro-actively plans activity to validate the Assumption; that is to prove it is still "safe". This includes the date the next monitoring activity is planned, and results of previous monitoring activities. The frequency of monitoring can be tailored to the organisation, project or individual Assumption. But the successful planning and executing of this monitoring activity is key.

Notice here that we talk about "monitoring" in this Process and not about an "Action Planning". Risks have Action Plans, steps taken to actively manage the risk in some way; Assumptions do not warrant this action and hence are merely monitored. However the monitoring activity may identify that the Assumption has become "risky"; in this case the Assumption should be closed and a Project Risk raised (cross referenced back to the original Assumption for traceability)

We have our own Project Assumptions Log Template available in our Template Store, it is built around this process and has all of the fields needed to help improve your Assumption Management on your Project. Why not check it out now!

Stay Healthy! Project Health Check - projecthealthcheck.org

In our Precious Blog entry we reflected generally on Project Lessons Learned. Now let us spell out a structured Process that we suggest:

1. Plan Lessons Capture - Lessons Learned (L.L.) need to be pro-actively orchestrated by the Project Manager, they won't just happen by accident. A specific effort must be made in the same way as all other project activities. By "planning" we partly mean scheduling in the Project Schedule - arrange meeting in advance for the end of each project phase, plan an agenda item in your project meetings, arrange sprint retrospectives etc because if it's not in the calendar it won't happen. But "plan" may also mean putting in place the infrastructure for L.L. - a Lessons Learned Repository, perhaps a mailbox to receive suggestions, an obligation for team members to participate in L.L. in their Roles & Responsibilities etc. The Project Quality Plan is the best place to Outline the general approach to Lessons Learned.
2. Execute Lessons Capture - You planned in in step 1, now do it! If not, raise a Corrective Action like any other unplanned variance if the task is late.
3. Log Lesson - If it's not written down it doesn't exist. A centralised repository, using a standard format and taxonomy will be the bedrock of your Lessons Learned activities. But a bare bones description of a problem you had isn't a Lessons Learned; we need to analyse that  submission first, only then can we act.
4. Analyse Lesson - We need to flesh out the basic Lesson to understand what caused it, why it was a problem and how it could be avoided in future. To determine the true cause we may need to use Root Cause Analysis (RCA), and to decide on a way forward we may need to make a Decision (recorded on our Decisions Log) potentially employing Decision Analysis and Resolution techniques (DAR).
5. Implement Lesson Learned - Here we put in place the action plan developed in step 4. It may be part of the Project Plan, or part of the wider project environment (organisational policies, tools, procedures etc)
6. Monitor Lesson - We need to put in place a plan for verifying that the Lesson has truly become institutionalised. (a) What mechanism can be used for verifying it, such as a specific project metric during a specific governance forum (b) exactly when the monitoring should take place, and then (c) the precise results of the monitoring activity. We may conduct multiple verifications over an extended period of time before concluding that the Lesson truly has become institutionalised and closing our monitoring.

What Lessons Learned Processes have you used - or has it mostly been unstructured? Join in the discussion in the comments, and look at our own Project Lessons Learned Template that is available now!

Stay Healthy! Project Health Check - projecthealthcheck.org

During the Project Start-up and planning phase, projects will execute detailed planning processes to produce a Performance Measurement Baseline of Cost/Schedule/Scope and an associated Project Management Plan. The project schedule will then steer the project through the foggy waters of its lifecycle and eventually help it to find its way to delivery and closedown. But what about the planning phase itself when the schedule doesn't exist yet?

Here is where we need a Plan-For-A-Plan, and this is where having a process asset template can be a real help. In a simple tabular format it includes key steps to get the project through the planning phase, and can be tailored to organisation, industry or project type.

At a high level, we suggest it should include:

• Project Mandate/Business case
• Establishing Skeleton Plan-For-A-Plan
• Formal Project Registration
• Stakeholder identification and engagement
• Decision on Project Approach (both Project Lifecycle and Technical Solution)
• Production of Project Management Plan
• Initiate Requirements Definition /Refinement /Iteration Zero
• Production of Performance Measurement Baseline - Scope/Cost/Schedule Baseline (ensure aligned)
• Project Tooling setup
• Staffing engagement
• Procurement preparations
• Risk identification
• Planning Audit
• Formal agreement to Solution and Requirements
• Formal Management agreement to Baselined Plan/PID and approval to proceed/spend
• Project Governance established
• Formal Project Kickoff Meeting

We could add others, and of course this could be tailored to organisations, industry domains and project types - but we think this is a good overview. Do you have any suggestions of anything else that should form the Plan-For-A-Plan? Look out for our more detailed Project Plan-For-A-Plan Template that will be launching soon!

Stay Healthy! Project Health Check - projecthealthcheck.org

Here's the thing about Lessons Learned: you're not learning them. In our experience, most organisations at best identify them - but is anything actually learned? Is changed behaviour ingrained into the lifeblood of the organisation? We have our doubts.

A few reflections we have on Project Lessons Learned activities:

• Does your organisation have a Lessons Learned repository? If not then how do you hope to record and implement them?
• At project start-up, we suggest you conduct a Lessons Learned scanning exercise using key project parameters, search words etc on any Lessons Learned tools to identify any previous lessons of relevance. You could also interview key stakeholders with history in the organisation, read End of Project reports etc. You can then factor these into your plan from the outset.
• Lessons Learned isn't just an end-of-project activity. We should seek to learn lessons and improve during the project itself, leaving it to the end is a bit late! Add it as an agenda item to your project meeting, or schedule a review exercise at the end of each of each Phase. Agile Projects are typically successful here with their Sprint Retrospectives (but probably weaker on recording lessons - Agile Manifesto and all...)
• Use a structured approach to document, analyse and implement Lessons Learned, and make this standard across all Projects in your organisation
• Share the lessons learned as widely as possible!

See Part 2 of this Article Series where we will outline our suggested Project Lessons Learned Process to help bring this structure to your L.L. activities, and hopefully help keep your future projects on-track. Also check out our Project Lessons Learned Template that is available now! What approaches have you used for Lessons Learned in the past?

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