Common Project manager’s mistakes

Alex Morgunov

Alex Morgunov

Project Lead

Common Project manager’s mistakes

If you are interested in Project manager’s work, you should know that PM is not only responsible and reliable person, but also it should always be somebody who can manage people’s work correctly in every team. Imagine a vehicle. It’s not working without somebody who had a key – just like with a team. From the one hand, PM should understand how to find the right people and how to make their work together with the most convenient for everybody, so they will able to work as a team in projects. From the other hand, PM’s work has to include the comprehensive knowledge of the process: all risks, communication with a client, the best way to solve the problems. So let’s analyze some common PM’s mistakes:

 

 

1.  Not specifying customer’s requirements and do every project yourself. Not sending screenshots/mockup to the client for affirmation.

 

You’re working as hard as possible but a customer is still not satisfied with the result. You are told that it’s completely not a result that he wants.

You can do everything correctly, take advice from experienced specialists, but it’s still the most important thing – to get a confirmation from a client if it meets their expectations. If this button/text is what they want.

In case you hesitate whether you understand the task correctly, it’s better to ask/reformulate questions, make a video, paint a mockup, send screenshots.

Life example: the project

We were sent the psd files for layout, the HTML coder made the task in their own way without agreeing with the customer. As a result, estimate for 80 hours has become an estimate for 101,5 hours + 60 hours for correcting mistakes, because the customer has seen the result in a different way (e.g. paragraphs, text alignment, etc.)

 

2. Overestimating your possibilities.

 

Imagine the situation when a developers gets a task, they need to estimate. In this case, you’d better not to hope that they will analyze it deeply. Such as identifying all possible variants, understand all risks, give you the correct number of hours for realization and predict it constantly. But we know from our experience, that a developer spends 15-30 minutes and makes an estimate very optimistic (we’ve already known a solution and nothing is broken during the process).

But there’s ALWAYS everything broken, the right solution is not made immediately, and The Project Manager has to take into consideration all of the risks. Because it’s your responsibility to explain everything to a client, not a developer’s one.

It’s important to remember that every single developer’s estimate has to have its own time for risks.

Timeline Project

We confirmed an estimate for 100 hours (fixed cost), but we made it much later and sent to a customer in 260 hours because we hadn’t taken extra time for complicated logic. As a result, as soon as we’ve deployed a new feature, the previous one was broken.

It was our mistake: we didn’t study the area firstly, not considered the complicated architecture of the project and the way of it’s realization.

 

3. Not filling the Daily stand-ups. There’s no need in any specific retrospective; it’s only wasting your time. If you have any problems, the developer will come.

 

Daily stand-ups always allow you to find out the problems in a project or in a team as soon as possible to identify the most important tasks. With the help of it, you will always know what is done, what problems and plans your team has; and the most convenient thing are that you will see the whole picture, not the details of each member’s work.

 

4. Keeping silence about your problems as well as not understanding the problem.

 

If you don’t say anything about the problem, it doesn’t mean that you don’t have one. It’s always the cheapest and easiest way to fix something straight away than to fail it all. If you fail, do it quickly!

It’s a good thing when the developers and customers say straightly about the problems but it’s not always like this. That’s why the main thing if the developer’s job has become worse or the customer’s attitude has changed, the Project Manager has to find out the reason.

 

5. No checking how much time the developer spends with a task. Developers are responsible people and can fill the reports themselves.

 

The developers have always got involved with the code that’s why they need to be reminded to fill the report every time, to write how much time they’ve already worked and how much time it has taken to do the task.

If it isn’t done in time, it will be difficult to remember such details in 2-3 weeks.

LiveVoice Project

The developers’ requirement was to check how much time it has taken to do the task in Toggle and send all these reports to the customer for affirmation. There wasn’t too much attention for these reports to be filled. But after the regular reports’ affirmation and customer’s payment for the task, a developer came to me and said that he forgot to put 50 worked hours in it. All reports have already been confirmed, the check was filled and sent to the client, our enterprise must pay this itself.

The solution: Now all developers fill their reports every week and the PM’s responsibility is to remind them not to forget about it.

 

In conclusion, the best way to solve the problem with minimal damage is to analyze the working flow in advance and understand ones as quickly as possible.

Join our Newsletter