Project Management Antipatterns

We all think that we are unique. Even when we make mistakes – they are unique. But it seems we are so predictable, that people already studied and classified all our epic fails – past and future ones. So it is very useful sometimes to read about the issues others suffered and compare yourself to the persons described – you definitely find something common. Project managers are not exceptions – you may think you are a smart project manager, but still you can follow some of the well known anti-patterns. I tried to collect the most common ones – which I built myself or observed in action. I found they fancy names on the internet and now I am prepared to use them in my speech, so I would look as smart as the developers talking about their architectural patterns.

Death By Planning

Beginner PMs usually think that you can control almost everything (thanks God they agree they can’t control floods and meteors). But project plans they create are the same distance from the reality as the person who claims to control weather. Although planning is an essential part of building quality software keep in mind they should be “just enough”. Keep short term plans as close to the actual implementation of your software as possible, while keeping long term plans as flexible as possible.

Just remember the last time your tried to keep up to date one-year project Gantt diagram…

Black hole planning

Is close to the Death by planning, but is mostly about creating the “ideal” plan, not taking into account even the risks you can identify very easily. You assume developers are coding 8 hours a day? You forgot the holidays, vacations? You are not taking into account your team members are shared between the several projects? You forgot, that the newly formed team can’t start working with the full productivity from day 1? A new developer joining a team start performing like an old one after studying the project for 1 day? Hmm, we are in trouble…

If you look through some of the project plans – you would easily see the black hole closer to the the deadline.

Throw it over the wall

It’s my favourite one. Often you have different tech departments in the company – QAs, developers, managers. So you, as a manager, get people “assigned” to your project, while they still report to their boss in the department.

The best role-play in such a company structure is “The problem is not on our side”. When developers “resolve” the task and just throw it over the wall to the QA. And the winner is who keeps the task on their side for smaller amount of time. “I have done my part”, “I can’t access the server” and the killer-strategy “It works on my machine!”.

“We have no time!”

This is my favourite too (be honest, they are all my favourite).

When the PM can’t manage priorities he looks more like the fireman – solving the issues when they rise and 100% of time devote to the urgent tasks. There is no time for defining the goals, strategy, planning and making the processes more effective.

Problems continue appearing, there are more and more of them – no matter how hard the PM works – he would be flooded with them.

Among the signs of this anti pattern are: email titles with a lot of exclamation marks and ASAP/Urgent, all the tasks in the bug tracking system are of the top priority. The work is performed under the pressure of the deadlines, usually unreasonable. There is no time for refactoring, architecture and documentation. “What are you talking about, there is no time to think even!”

Witch-hunting

PM is the one one who causes the most damage to the project because of his anti professionalism? No worries, just blame someone and lead the punishment war against him! Some of the PMs are so good in this process that once they found themselves the only person left in the project team.
I think that the PM is always in charge of the outcome of the project. Yes, you can’t control that, but you are in charge.

Seagull Manager

That type of the manager can’t be ignored by you – if you have seen him even one time you won’t forget him. As if you are in his kill zone – he won’t miss. This type of managers if very loud – they come to your place, raise alarms, point out all the issues,  put red flags, provide negative feedback, then leave others to clean up the mess.

Their greatest secret is that they usually have a little knowledge of the things they are talking about.

“Seagull managers fly in, make a lot of noise, dump on everyone, and then fly out.”

“Leadership And The One Minute Manager” by Ken Blanchard

The signs of the seagull manager:

• mass emails about the critical issues, even if they are really minors or there is the slight risk of the issue. As we usually have a lot of issues – they always get a chance to say “I warned you about that!” (with a c-level manager in CC).
• late night calls on very-very-very critical bug
• they are always named among the people who saved the whole thing
• all talk, no action
• when they leave your room – you feel totally exhausted, as if it was a tornado or tsunami
• manager is highly detached from the team
• ‘What is the status? What are you doing?” are his favorite questions.

Time frames manipulation

I have heard that from many managers – “If you tell them the real date they will work till that date, not an hour less! I am sure even that they fail the deadline. So tell them the deadline is a week earlier!”. Or “Cut the estimation, as they won’t hurry up it they are not pushed!”

Seems like a fair idea. But what about trust? How many times you can play that way with developers? They will know all your tricks in a months! What you’ll do next? Why not to make the simplest things – plan according to the estimation provided by the people who will do the work? Why we need to adjust and trick?

Tighten the purse strings

We all know you can’t buy a plane at the price of a bike. But our clients usually want to cut here and there and somehow be the winners in this lottery and get the plane.

PM does not help them in reducing scope (“That is not possible with them!”), but starts reducing there things. Usually the first would be reduced – autotesting, development practices, conventions, communication (!), analysis, even team size. PMs instead of showing the truth make themselves believe that somehow they can squeeze into the budget. It never ends successfully…

Developers are not working as much as they can

Resources are not used with the full potential. Yep. From the wide range of options to eliminate waste PMs often choose to work on the “effectiveness” of the developers. As it is so hard to “measure” the developer’s work – there is a huge potential for the “improvement” in this field. Ideal thing to show how hardworking manager you are.

Buzzword Mania

I hear the word “Agile” so often during the day that I become sick before even the lunch time. And no one knows what they mean! Managers usually use the world as the “markers” of being the part of the “management circle”. When you hear them – you understand that you talk to the manager. Managers likes hiding their lack of knowledge behind the words.

“This is mission critical, so we need to thing outside of the box and work towards the win-win solution, using the agile methodologies.” Sounds familiar?

Delegation without Authority

There is no better way to fail the tasks, initiatives and bring the morale level to 0 than to practice the ineffective delegation.
Managers often make the mistake of expecting people to explicitly have the same authority as they have when they delegate some of the tasks.  And they they got something like “I thought I wasn’t allowed to call the CEO” in response to the question why the task was not done. You can even say the person that there will be others reporting to them. Wow, he has authority now! Wait a minute, these people have their own bosses in their departments, other projects and tasks. Something is wrong here… Also managers can play with making the person in change but setting the low priorities for the tasks. In a month they call the person in change to their room and ask “Why it is not still done???”.

Emails driven communication

When I joined one of the companies I worked for the new colleague PM volunteered to help me during my first days. He explained me the processes and guided through the new projects. He also put me in the CC in his emails which were connected with my projects. I was shocked to see how he was communicating with developers and designers in emails. He sent them an email about the task, set the deadline there. And waited. Even if there were no response. Some of his developers even stopper reading emails and when he finally had a meeting with them to ask why they haven’t finished the task they asked “What task? I am not reading my emails!”

Also I have seen PMs writing emails as the “evidence” that they made some certain actions (you always can pool the email later and say – “I wrote him about that! That is not my fault he did nothing.”)