Collection Of My Favourite Project Manager’s Fails

This time I would like to share my personal collection of manager’s errors which I have been made (at first I wanted to write “errors which I came across” pretending that other managers made them and I only witnessed these stupid errors)  for the last 7 years.

You solve the issue that does not exist or exists only for you

This is my favourite one. You come to the battlefield and find the issue. You think it is obvious for everyone, so you start acting without hesitation (as the PM you probably are the man of action). After some time you receive the negative feedback from your colleagues: “Everything was OK until you suddenly came and started fixing everything”. You are frustrated and feel betrayed. You think your colleagues are stupid bastards. But it is not the case.

The case is that managers find the problems where they don’t really exist. They tend to think some things can influence the work process while they really are irrelevant.
The most evident examples of that can be when manager tries to implement the dress code,  make the team sit in the office for exactly 8 hours, set the early working start time, fill detailed timesheets, etc. These are the simplest cases, when the “not the problem” fact is easy to identify. But there are a lot of cases when PM tries to fix some processes or takes part in some projects and do not consult with others whether they consider the same thing a problem or not.

The case is that PMs are prepared to see the risks everywhere – projects are really the black holes, so you are trained to make the max precautions and be ready to meet any unforeseen disasters. Once my colleagues asked me if I see the glass half empty or half full as a project manager. I answered, that “As a project manager I don’t see the glass of water half empty. I see it half empty and it is all the water we have left on Earth, and there is a crack in the glass, and the water is leaking and I am burning and you are burning and there is not enough water to put out a fire and WE’RE ALL GONNA DIE”.

So, the best approach will be to double-check before you start fixing. Probably, the only problem here is you.

Being too enthusiastic, assume others should be the same

Especially when you are a newbie to the project management. You are extremely energetic and know how to fix the world. You try to energize your team and…they look at you as if you are crazy. They are experienced developers. They already know that you can’t last long in a sprint mode. So you should keep the balance – sprints when needed and marathon pace at the other time.

Making focus on why this is the issue for you

As we all have the only option to explore the world – with the help and through our mind – we sometimes can’t differ our personality from the world or confuse our point of view with the “independent observer’s” point of view.

Just imagine project manager in the following situation: developer forgot to submit the timesheet and now you can’t send the monthly time report to the upper management on time. Next month you ask him not to forget to do this, but the problem repeats. You talk to him describing the problem you had: you could not send the report. But was it a problem for him? I doubt.

When we see the issue we automatically start finding the reasons why this is an issue from our point of view, how we surfer from it. But at the same time it can be not an issue for other employees.

You can say that if the person do not care about the issues of his manager he should be fired. But let’s be realistic – very rare you have so trustful relationship in the team that team member will follow any manager’s instructions, especially if they are not in their job description.

So, instead of communicating why this is an issue for you, try the toughest – find out why that is an issue for the person you are talking to. May be, if the report was not submitted in time your team won’t receive monthly bonuses?

Want to change everything immediately

One day your manager comes to the team and says “Now we should work according to the scrum”! He is very happy, he found the solution, how to fix EVERYTHING! (Remember the time when you was sitting with your team and discussing “it would be great if only…we can change the development processes.”)

The only question that manager can see in the people’s eye’s is not “When we can start?”. The question is “Why?”. “Why do we need it? Everything is working now!”.

The only working strategy here is to show the problem first, make sure everyone sees it and agrees it is a problem. You can even make it a bit worse to show better 🙂 Usually you don’t need to do anything specially – just wait a bit and smth definitely would fall and kill one or two of your colleagues. After that incident you can initiate the solution research. Try not to be the most active – the more you push, the more negative feedback you get in response.

Communicate the decisions incorrectly

Especially, if the decisions were made by the management above you.  The easiest thing would be to say “They are idiots, but they are bosses, so we should do A and B.” It can bring you +10 points of coolness this time(teams like when the manager thinks like them and becomes a “cool guy”), but it also cuts points from your achievement “protect the team”.

Assume that you know what other’s think

if you think you are talking to an idiot he probably thinks the same.

The biggest mistake is to assume that the other person understood you when you explained smth to him. Even when you double-checked, even when his responce 100% fits your expectations – you can’t be sure.

Numerous times I had the issues of this kind, especially with the new people in the team. And that is a common case in outsourcing companies, as you have a lot of projects and people in the team can change rather often. So until you understand his/her “level” of understanding you – keep an eye on all of that. I don’t want to say that people are stupid and don’t understand you, probable the opposite is correct, as you are the manager here.

When you think you are doing good thing, but the results are disastrous

When you customer comes to you and asks you to make smth important for them in addition to the scope you already have. Usually  with tough deadline -“it should be ready tomorrow”. Because THEY REALLY NEED IT.
Some PMs refuse, some try to do the impossible – persuade everyone to work overtime, during the weekend…And they deliver the build. Everyone feels relief – they did it! But it is to early to celebrate – you problems just begun.
When you succeed with the development task which seemed impossible to complete – it rises the expectations. Your clients start thinking that is ok, that was not the miracle. Probably, they think, you are not trying hard all other time?  Probably we should each time set tough deadlines and say “we really need it”?
Seems really strange – you did your best to help your client and now his opinion of you is worse than before.

Do not uncover the real cause of manager’s irritation

We often forget that the things you see as the problem are not usually the root, but the top of the problem tree.
Let’s imagine the following situation:
Manager complaints that the team members spent too much time browsing the internet/chatting/drinking coffee/playing ping pong. Solution? Obviously, restrict the internet access, implement daily reports of their work progress, estimation of the tasks in hours, timesheets, close ping pong room, etc. No.

Let’s go deeper. Is the playing ping pong a real problem? What if this team is delivering features on time, project budget is in good shape and your clients are happy? I bet you wound not have such thoughts about how developers spend their day.
Managers always try to fix the things they think they can fix easy( at least, they think so). If you think about fixing the development processes – it seems hard, almost impossible (let’s be honest), but restricting internet access – it’s easy.

---

I uncovered a really surprising thing – when I go deeper in uncovering the root cause of the problems which exist in our teams I find myself digging into a) company mission, values and b) recruiting process. It is so far from the business goals, finance reports, software deployment or meetings that I was never thinking of it as a root cause in the beginning. But seems that these things are underneath of all what is happening in the teams. If you get good fit people(I do not mean hardworking unicorns everyone would like to hire, just “good fit”) who share your vision and values – it somehow works. You do not need agile, you do not need any fancy methodology – it still somehow works).