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:
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
0 Comments
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:
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:
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:
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:
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 |
Mission:To understand why do Projects Fail and what we need to do differently to stop it happening again. Archives
March 2018
Categories
All
|