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).
6 thoughts on “Collection Of My Favourite Project Manager’s Fails”
As a ‘no formal training’ type of PM, I think I’ve made all of these and more. And more, and more and more again. I am looking at a $50k mistake at the moment, and there is no way round it, and yet I am also sitting on an on-schedule project $3million under budget. I think I might survive. The net sum of mistakes vs wins is what counts. Of course if you get handed a project when all possible wins have already been assumed in the price, you’re screwed from the start. Loved the article, PM’s that fail repeatedly are the most successful ones, because they pick themselves up, improve what they do and become more successful in the future.
Thank you for your comment! I like PMs who know about their errors and admit them much more than the “always winning” guys.
My list of fails is much longer than the one I mentioned here, including tech decisions, planning errors, poor risk management, etc. This time I wanted to focus on the “behaviour” related errors.
PMs seem to me like magicians who try to control the chaos 🙂 So errors are inevitable. Sometimes they save us from even bigger mistakes, so failing early can be welcomed.
> Of course if you get handed a project when all possible wins have already been assumed in the price, you’re screwed from the start.
I felt the same in 80% of the projects. Until I started taking part in sales process(had chance to change our approach). They always try to take into account the “best case scenario”. Have you ever seen the best case scenario in life? It can be worst case or disaster case, but not the best one. But all our competitors assume the best case scenario (and cut 20% on top of that to win the deal), so how you can get the business not doing that? Development companies are preparing the personal hell for themselves 🙂
I am fortunate that I get to write most of the proposals, and when I am choosing contractors, I rarely buy on price alone. I generally work in large organisations, and the cardinal sins are going overbudget, the project not delivering, or not delivering on time. So budgets, timelines and specs get padded, and because I am ‘the expert’ people rarely challenge me too hard, or I can tell them horror stories about why they’re wrong. What they don’t realise is I have become good at selling risk-avoidance.
I get the impression when ordering custom software that the buyers have already factored in large contingencies when selecting contractors, because they know they can’t spec out what their stakeholders want. Also, they know what the stakeholders want this morning will be different after lunch, so they plan in advance to have plenty of fat in the change-order budget to cover these known issues, and the vendors are betting that they can make their profit from these.
The strangest business behaviours I have ever seen are always around IT projects. It’s like people think code is magic and if they wish hard enough Tinkerbell will appear and children everywhere will be safe.
I did enjoy your post however I was anticipating some actual failure stories not behavioral issues of PMs but definitely interesting none the less. My go to question when interviewing PMs is to ask for the biggest project failure. I had one PM (had 10 years experience listed on her resume) tell me she’s never had a project fail…I of course voted against her hire! You state that you never want to be a PM again, what is your current role?
Honestly stumbled at first with your use of ‘smth’ hadn’t seen that in any chat windows or social media and I am not thaaat old 🙂