How to deal with Grey Swan event

In this post, I will be talking about one important role of project managers, and that is, what to do when things are not that great. But before that, let me tell you one little story. When I watch football penalty shootout on TV, I really don’t know who is going to score the goal, but I am very good in guessing who is going to miss it. When I see a player approaching the ball with his face telling you “I must not miss it”, I am pretty sure that the guy is going to miss the goal. Similary, if the eyes of the player who is taking the ball are telling you “I am going to score the goal”, most likely, the guy will make it.

Similar things happen in project management. I have seen too often project managers trying not to miss the ball, making project plan look like long distance excuse thing. In that fashion, as soon as things turn ugly, as they often do, the first task of such project managers would be to find an excuse. The strange thing though, this is the last thing people expect from you.

There is also another important thing you should remember. Higher you go in the hierarchy, people have less time for other people’s problems. Therefore, when your project is hit by a grey swan, think for the moment and come up with the following slides to your boss (this is one of few places where I believe slides are useful):

  1. Define the problem
  2. Explain the impact of the problem
  3. Give a plan of what you think should happen next
  4. List all dependencies of your proposal(s)
  5. Tell what you need from your boss to make it happen, if required
  6. Say what will happen if nothing happens
  7. Tell your preferred choice and explain why
  8. Give a date by which you need a decision

In my previous post, I talked about some of situations in which your project will certainly get in trouble. The last thing you need then is to get in panic, look for excuse and let other people manage your team and your project. Stay cool, prepare few scenarios and then knock at the door of your boss.

Now, it’s time to fix the team

Your job is not over yet – you have only defined your grey swan and don’t think that the problem will be resolved by itself. Now it is time for the next phase – get the job done. The first and the most important thing to remember now – you are on the stage like in Shakespeare play, and people will look at you. You need to stay calm and consistent in your messages. Your team needs that. There will be pressure building from various directions, but you must keep your team in isolation and let them do what you ask them to do.

And now, it is time to fix yourself. Everyone else is busy.

How to deal with pressure – or “Fake it Till You Make It” approach

Grey Swan events are usually remembered by the number of meetings, and no worry, if you have forgotten them, you will be reminded. There is only one thing you should do: go back to your first slides and stick to your message. Patience is the mother of all virtues. The most stress and frustrations in your job come from actions directed to things you can’t influence or from a feeling that things go too slowly. If your team needs a week to test the fix for concurrency bug, or if the rollback to the previous platform takes 2 weeks, this is what it takes. If that means coming every day to the same meeting and repeat the same message, so be it. “Fake it till you make it” is mantra I very often think of in these moments. Or as William James put it once:

“Act as if what you do makes a difference. It does.”

4 Replies to “How to deal with Grey Swan event”

  1. Was expecting this post for sometime and its as usual good one. I am not able to link the Project Managers with the “I’m not going to score the goal”. May be bit more explanation needed.

    1. From my experience, people who start from “not missing attitude” will always start from excuse and not from the contingency plan, once they get in trouble.
      What usually happens is that once people get a tricky issue, they approach it from “it’s not my fault” side, spending more effort covering their **s than looking for a solution. This way, they send a wrong message to the higher management, which then gets in panic too. Since guys who are higher in the organization are very often adrenalin driven, they will call for action and want to see the results – next day. So, the next thing you get is a chicken run.
      But you are right, I will try to re-write that part so it is more clear what I want to say with this story.

  2. Here come another request:
    “Fake it till you make it” : Here comes the same situation. My team says, they need 2 weeks to test this. But customer thinks, this is single line change and why you need to 2 weeks to make it. How will you convenience? Any tricks?? The answer for this question can be in separate post. This may be out of topic than agile, but much needed for people.(readers request)

    1. Now we are talking about two things I believe.
      One is about “Software craftsmanship” stuff http://manifesto.softwarecraftsmanship.org/ and the other one is about the trust.

      This is what Uncle Bob says about the first subject (more or less, this is my interpretation):
      If you go to a doctor and start challenging his diagnosis, you will be kicked out from the office. Reason? Well, you just made his day by questioning his knowledge and expertise, for which he has been working hard for decades.
      In our world, everyone can come to me and start “challenging” me. Reason?
      1. we have made too much crap in the past (and present)
      2. we have let too many people with no skills to enter in our profession
      3. so we let other professionals to treat software development as some kind of dumb activity.
      In one of my previous posts How we got screwed in the first place? (http://talk-agile.me/?p=99) I talked a little bit about this already.

      Another important aspect is trust. This is something different. This comes form the nature of the contracts, which are either fixed price or time and material. Again, I covered this a little bit in this post http://talk-agile.me/?p=289 . This is also the reason why I always prefer time and material contracts, if you want to go for good long term relations.

Leave a Reply