Posted on

Why shitty projects rock?

Numerous case studies have demonstrated that if projects start to experience issues it happens towards the end of the project life-cycle – close to delivery. Obviously this is the worst possible timing for the project to go off track – everyone are expecting outcomes and they are getting problems instead. Sometimes it is decided that the best way to resolve issues is to bring a new PM that will reorganize and lead the project in a more efficient way. Overtaking a project is probably one of the most difficult ways of getting a project assigned. Often you are stepping into a half-baked solution, being perceived as an intruder that is going to turn the world upside down, sometimes not trusted and not welcomed. However I like to look at failing projects as like a rare opportunity, that can bring a lot of benefits to you and the organization.

 Why overtaking a failing project can be beneficial?

  • It’s an opportunity for the organization to learn on mistakes. Document the learning’s and share with key people
  • Quick (sometimes extreme) learning curve. When you overtake a project to save it usually quite few things are already going wrong. In most of the cases you will have little time and resources to bring it back on track  – challenging but often doable.
  • Gives you exposure. If you overtake “a sinking ship” you are perceived almost as James Bond who is going to save the world from its inevitable dramatic end. You have a chance to create a good impression that will be your capital for future
  • Quite often you are in position to demand additional resources, money, time as bringing in a new PM often is being perceived as a new opening for the project. This is not always the case even for newly starting projects where often budgets are cut and timeline squeezed from the very beginning.

First steps after overtaking the project

  • Stop (if possible) and evaluate. Verify the current state of the project. Understand at what stage the project is, what has been delivered, what’s still pending. Understand the products, their status, budget and timeline. If the previous PM is still available – take the handover.
  • Analyze existing documentation
  • Talk with key stakeholders. That goes for both project team and business –  understand who are you dealing with. Create a stakeholder matrix, where you will understand who has the biggest interest in the project, who’s powerful and who you just need to keep informed.
  • Understand key issues and risks. Not just the ones noted in existing RAID log – but also those that will surface from the conversations with stakeholders.
  • Provide a recommendation whether the project should be continued. This might be a very difficult task to do but sometimes recommending discontinuation of the project might be the best what you can do.
  • If you think the project should continue, provide a recovery plan. Set out, document and communicate your proposed way of delivering (including approach, timeline, budget, resourcing and risks and issues).

Do’s and don’ts

  • Don’t play the blame game. Do not discredit previous PM, don’t blame people who are not with the company anymore. Cut out the past and move on.
  • Respect what has been delivered, done so far but be critical about it.
  • Don’t be afraid to say “NO”. When taking over a project you might be pushed into some already made decisions and way of doing things. Don’t continue previous approaches, governance etc. if you fundamentally disagree with them, but where possible don’t change routines that can give the team at least a minimum of stability.
  • Build trust and relationships with the project team and stakeholders. Recognize that the Team might be in a challenging situation but clearly set your expectation on how you want to run the project.

To overtake a project you need to have a thick skin and quite a few years of experience under your belt. You will be blamed for decisions that were not yours, you will have to defend things that you disagree with and haven’t been done under your jurisdiction, you will have to convince people to let go things that have been already agreed and approved and get them to go a different path. You will feel frustrated, angry and powerless at times, but if you will succeed  this  project will be your biggest achievement and learning that’s highly likely to boost your career and experience to the next level.

Posted on

The art of escalating

Although majority of Project Managers understand the need and mechanism of escalations, they rarely get it right. Some escalate all over the place all the time, some sit on an escalation for too long, others think they can rule the world and deliver projects with no one’s help. There are different reasons why PM’s may not feel comfortable with escalating but one is for sure, there are situations in which escalations are unavoidable. Make sure you plan the project in a way that when the shit hits the fan you have all you need to effectively escalate.

The fear of escalating

  • A conviction of being a bad PM. There is a perception that escalation might be perceived as an outcome of PM’s incompetency. That we’ve missed something, planned it wrong, didn’t thought through well enough.
  • Ego problem. Deliver or die. Escalation is being perceived as a sign of weakness and lack of control. 
  • No clear escalation paths. We don’t know who can help, make decisions and the project roles are not clear.
  • Preference to “sit on it”. Some have hopes that with time the problem will solve itself. Maybe… but what if it grows, enlarges the impact and blows up in your (and company’s) face at one point?
  • Juniority. Being a junior PM or a newbie in the company may bring a level of uncertainty on when and how to escalate. In this case it’s good to get guidance from other PM’s who went through this process. However… I would always go with your gut feel.
  • Making enemies. Escalation can create enemies – that’s true. Some people take escalations personally. Unavoidable but manageable via sticking to data and facts rather than opinions.

Prepare yourself for a proper escalation

  • Take care of your stakeholders. Your stakeholders, if properly involved and informed across the full duration of the project, shouldn’t be surprised with your escalation.
  • Understand and set! your tolerances. I have an impression that in modern world of control, reporting and high pressure on delivery we have forgotten about project tolerances. A level of freedom (and trust!) for Project Manager to navigate via issues in creative way. An allowance for a percentage of tolerance can give Project Manager and Project Team a level of comfort and flexibility that if applied can make them more effective. However watch out for using tolerance as a method of avoiding escalation. If the project goes out of hand, you will need more than a tolerance to bring it back on track.
  • Build proper governance. Put in place a strong governance. Document actions, decisions, issues and risks, have regular meetings with the team and stakeholders (incl. Steering Committee). Well maintained RAID log will provide good data points that can support your escalation.

How to escalate?

  • Limit the audience. Escalate only to those who really need to see it. Don’t involve those that don’t have to be involved. Too big audience may blur the picture
  • Stick to facts. Don’t share opinions, general statements, assumptions. Share hard facts, data, numbers, events, impact, money. Take emotions out of your message. If possible avoid names. Remain professional at all times.
  • Set the scene. Remember that not everyone you escalate have the same level of details you do. Set the scene, give background, give some history, put events in sequence. This will allow stakeholders to better understand where are you coming from and how the project came to this place.
  • Expose the impact. Nothing speaks better to the stakeholders than the vision of a potential damage made to their business. Assess the potential or already materialized impact of the problem. Quantify where possible.
  • Give a helping hand. Show how it can be fixed (if fixable), avoided, mitigated. Propose set of actions and next steps that can bring the project to a stability.
  • Ask for help. Outline exactly what you need, ask for decisions, actions, follow up on them.
  • Appreciate the help. Something we usually forget about. If your escalation was successful make sure the stakeholders know about it. Appreciate their help and value they brought in by bringing the project back on track. If the escalation failed, remember to go through it as part of project’s lessons learned.

Machine generated alternative text: Risk Issue Example Event Impact assessment Proposed set of actions Executive ask Decisions required
Formulating escalation

When to escalate?

We usually say ‘in a timely manner’, but what does that exactly mean? It means that you have used up all potential ways forward (in your control) to address the issue (so it’s not too early) however there is still possibility to manage the situation at higher organizational levels (so it’s not too late to act). Sometimes it’s difficult to find that right moment, if so, look at impact that the problem may have on the project, business,
organization and what can be the consequences of not escalating.

What if escalation fails?

  • Try level up
  • Try horizontal escalation
  • Try to take it via informal conversations
  • Suggest re-scoping/re-planning/resetting the project
  • If every route fails, don’t be afraid to suggest pulling the plug on the project

Summary:

Escalating
is difficult, some say it’s an art and science in one. It’s difficult because it’s an official statement of something going off track and requiring fixing. However by not escalating, you lose the opportunity to fix issues, change the course of the actions and save the project from failure. Also be ready for someone challenging your escalation. Get your ducks in a row, understand the data you have and the one you are missing. Usually you don’t have only one shot – escalation can be a longer process, but you do need to do it right from the outset, otherwise you may lose credibility. Lastly, control what you can and let others control what’s out of your hand.

Be brave – escalate!