≡ Menu
Pawel Brodzinski on Software Project Management

Don’t Look Back

When a team faces a problem I see quite often a tendency to look back to find who is guilty in triggering the issue. This attitude can be recognized by questions:

• Who did something?

• Why it wasn’t cross-checked by his supervisor?

• What was promised to a customer?

• Why didn’t they prepare an ass-cover?

• How you could allow that?

That’s all about the past. And most likely that’s all about witch hunting to find the one to blame and prove you are not the one.

As we’ve been learned by experience above process rarely brings a clear message. He failed. She misunderstood the task. They forgot to agree something. And even in those rare examples that kind of knowledge is most likely useless. Yes, this time PM sucked. So what? Are you happy now? We better go back to find the solution, then.

Anyway, usually you end up with some vague information pointing at misunderstanding between several persons, unexpected issue which popped up in the worst possible moment or a series of events which you can’t blame anyone for, yet they brought you to the placed where you are.

That’s all utterly useless and completely wrong.

First you lose time for witch hunting instead for spending it on looking for a solution. It’s like looking for arsonist instead of firefighting when you see fire all over the place. Very clever indeed. Second you teach your people not to take the risk and to minimize the chance to make the mistake and, as a consequence, to slow down their learning curve. With that attitude in extreme example you can end up with people refusing to do anything until very detailed specification is delivered (and yes, I worked with that kind person some time ago). While you can count time spent on useless activities (and accept it if that’s your will), impact on creativity, commitment and atmosphere in the team is both hard to measure and really painful.

Temptation to follow the witch hunting scenario is strong (several years ago you’d see me quite often in the role of an inquisitor), but really, you have better choices here. I usually try to focus everyone of fixing the situation (firefighting), leaving looking for a reason why it all went wrong (tracking arsonist) for later. That usually satisfies both those who can’t live without looking for ones to blame and those who remember about learning from own mistakes. Quite often when the pressure is taken off no one needs to witch hunt any more and you don’t have to point fingers on each other. The learning part you can make on post mortem sessions where the atmosphere is far from blame game.

Interesting thing is that even in environment focusing on today and tomorrow instead of yesterday I see so often people actually expecting they’ll be blamed for overrunning the schedule, wrong estimates, screwing up the task, bad weather or manager’s hangover. Maybe it lays so deep inside of us, we can’t fully resist?

in: personal development, project management

2 comments… add one

  • Headworx August 21, 2007, 10:53 pm

    Pawel, I think looking back has one very important aspects – taking lessons. Looking back at failures should always been taken by means of post mortem reviews. People have to understand (i) they failed (ii) why they failed and (iii) what to do to prevent future failures. Without looking back some may come to a conclusion that nothing really happened, there was no issue. Learning by mistakes is (paradox?) the most effective way of learning.

  • Pawel Brodzinski August 23, 2007, 7:12 am

    Yes, that’s the role of post mortem sessions (or however you call it). And yes, you should learn from mistakes and then looking back is unavoidable. I’ve mentioned about that in the post.

    The main point here is you should avoid doing that with no plan, when it’s all hot out there in the project. In that situation it usually ends in blame game instead of looking for lessons to learn.

Leave a Comment