In my previous post I talked about how to deal with mistakes that I as a PM make. A sometimes more difficult situation, is dealing with mistakes others on your team (coworkers or customers) make. The general approach is the same as for your own mistakes, but must be handled with more delicacy.
Humans are complicated creatures and they each develop their own particular view of themselves and the world around them. When someone makes a mistake, a broad range of reactions can be observed. Some cannot admit to making a mistake and will react with denial and even push the blame to someone or something else. Others are mortified that they made a mistake and will punish themselves to the point of becoming unproductive or withdrawn. There are many other reactions that are exhibited besides these two, but I will not go into them at this point. Just suffice to say that most of them are bad in some way.
Talking about others mistakes in a public forum will amplify these reactions and usually result in defensiveness, arguments, name calling and sometimes hanging up on the call or storming from the room. All of these scenarios are bad for the team, bad for customer relations and bad for the project. However, anything in a project that affects scope, schedule or budget needs to be documented, analyzed and reported. How to do this with minimal impact to the inter-relations of the team mates and stakeholders is the meat of this post.
Let’s say the scenario is a data center move is scheduled for a weekend and all systems needed to be back up and fully tested by Monday 8 AM. While bringing the systems back online, problems were encountered where critical applications were unable to connect to their data sources. This results in the whole team working day and night, Saturday and Sunday and on into Monday. The problem is not resolved until 10 AM on Monday. It turned out that two mistakes were made in the network configuration having to do with a route statement and a firewall rule. A single person was responsible for the configuration of both items.
The crucial things to remember when reporting or discussing the mistake is to stick the facts and keep personalities out of it. In this case I would report in my status that “An incorrect configuration in the firewall rule was detected and corrected and a route statement adjusted to the correct route.” Note that no one was named as being at fault. This is as it should be. All humans make mistakes and there could be extenuating circumstances such as the person responsible could have been working for 24 hours straight when the mistakes were made.
The followup postmortem would concentrate on the nature of the failure and that it was human mistake and not that Joe fat fingered the commands. We would then move on to a quality control plan to provide some kind of check and balance for future actions.
The important points to keep in mind are:
- Stick to the facts
- Keep personalities out of the discussion
- Make no judgements
I would be interested in any comments or feedback you might have on this post. Please take advantage of the comments section below. Your email will not be used for anything beyond helping me combat spam.