The role of a Project Manager entails being involved in a project, literally, from start to finish. Starting with getting in touch with the client, carrying out estimations, defining the paperwork, then going through the delivery phase. One project may take a few weeks, another many months. There are many key moments during the project that can significantly impact the end result and mutual satisfaction – both of the client and our organization.
We cannot avoid making mistakes. However, we can minimize the risk of them occurring by identifying the most relevant design factors over which we have influence and, ultimately, managing such factors appropriately.
In this article, I have collected eight examples of common mistakes. The mistakes are easy to point out; what is important is how you can protect yourself from them. Therefore, I will provide you with examples showing how to avoid them effectively.
Most Common Project Management Mistakes and How to Avoid Them
The role of a Project Manager entails being involved in a project, literally, from start to finish. Starting with getting in touch with the client, carrying out estimations, defining the paperwork, then going through the delivery phase. One project may take a few weeks, another many months. There are many key moments during the project that can significantly impact the end result and mutual satisfaction – both of the client and our organization.
We cannot avoid making mistakes. However, we can minimize the risk of them occurring by identifying the most relevant design factors over which we have influence and, ultimately, managing such factors appropriately.
In this article, I have collected eight examples of common mistakes. The mistakes are easy to point out; what is important is how you can protect yourself from them. Therefore, I will provide you with examples showing how to avoid them effectively.
1. Improper task prioritization
A customer contacts you about a critical failure and you ignore the message because you are focused on fine-tuning an internal procedure for which there is no specific deadline for implementation? This is a bit of an extreme example, but it can well illustrate the wrong prioritization of tasks.
Remember that in the role of Project Manager, you need to prioritize not only your tasks, but also those assigned to your team. Understanding current needs and prioritizing tasks skillfully is an important ability that every Project Manager must possess.
ADVICE: Use the Einsehower Matrix or the MoSCoW Method. Both techniques will allow you to identify the important priorities that need to be addressed first, the ones that can wait, and what tasks should be delegated to others to do.
The Einsenhower Matrix is characterized by helping us to organize tasks according to the following four categories:
- Urgent important – immediate action required
- Important non-urgent – planned for later
- Urgent non-important – tasks to be delegated
- Not important non-urgent – tasks to be eliminated from our lives
Source: https://www.spica.com/blog/the-eisenhower-matrix
The MoSCoW Method, on the other hand, allows us to reach an understanding between stakeholders in a project about what needs to be done, what issues are prioritized, who is responsible for completing a task and what business benefit it brings.
It stands for four groups of priorities in which we categorize the tasks to be done:
M – Must have – a necessary requirement that the final solution must meet. It is assumed that the requirements in this category should make up a maximum of 60% of the Sprint tasks to be completed.
S – Should have – a requirement that should be included in the final solution. Requirements from this category should make up another 20% of the tasks.
C – Could have – an additional requirement that is desirable but not necessary. As with the previous category, the number of tasks in this group should reach 20%.
W – Won't have – a requirement that, with the general agreement of all stakeholders, will not be implemented at this stage of the work, but may be considered in the future. Requirements in this category are not included in the Sprint work.
Source: https://www.techtarget.com/searchsoftwarequality/definition/MoSCoW-method
2. Changing the work scope – promising too much
Will we add this functionality to the scope? Of course! Will we be able to do this as well? Definitely! It seems to me that this was not in the original scope of work, so yes, we will add it too!
Sound familiar? All the above behaviors are an easy way to achieve project failure. They result in an increased scope of work, a lack of control over project duration and a floating budget.
Every change, even the smallest one, must be consulted with the team and the project sponsor (not to mention the other stakeholders). It is irrelevant whether the project is a cascade project or perhaps run in agile methodologies.
ADVICE: In a cascade project, introduce a 'Change Log' to track the number and size of changes that have been made at the request of stakeholder or because of the need to change the direction of the work. In an agile project (and this is the only type of project we do at Polcode) scope changes are inevitable – but that doesn't mean you can ignore them. Constantly monitor the impact of the change on the set objective. It is important that all stakeholders accept the change and understand its reason and purpose.
3. Missing or inaccurate planning
I recently came across a statistic. It says that 39% of projects fail because of inadequate or no planning at all. 39%! Any Project Manager seeing this figure should immediately go back to their project and check again how the work was planned in it.
A significant problem with planning is, as in the previous points, the lack of involvement of other members in the planning process or the inexperience of the planners. Remember, it is not a bad thing to ask additional, third-party people to review the prepared plan. We cannot anticipate every situation, think through every scenario. Advice from a bystander who has been involved in a similar event in the past can be crucial.
One of the tasks to be carried out is so big that no one can categorize it? Break it down into smaller parts! This simple technique will allow you to identify the steps that need to be taken to achieve the goal and allow everyone involved to understand what needs to be done to make the finished solution happen (rather than just being written down on paper).
ADVICE: Plan with the whole team, don't hesitate to ask for help, confront the results of your planning with outsiders.
4. Communication, or lack of it?
A Project Manager's job is all about communication. You communicate with the team. You communicate with the client. You communicate with your manager. You communicate with your service provider. You coordinate business meetings, workshops, Sprint-related meetings. Your whole working life revolves around communication, meetings, speaking up. You have to speak a lot. A LOT.
And if you have to speak so much, you should probably also try to make sense. Be specific. Take care of the quality of your speech. Speak in such a way that others can understand you. Inspire others to do the same.
I can't imagine a Project Manager who is afraid to speak. Who speaks in a way that is ambiguous. However, I know that there are such cases as well.
Remember, it is up to the Project Manager what information gets through to the client, the team or the stakeholder. The quality of the information communicated must be of the highest standard. Regardless of the circumstances and the recipient of the message.
ADVICE: Some people are born with it, others learn it. Whether you have always been able to communicate or are just learning it, you need to acquire this ability. Immediately.
5. Lack of defined project risks
Source: https://conceptboard.com/blog/risk-matrix-template/
The subject of risks is often, unfortunately, ignored by novice Project Managers. Sometimes, driven by their positive attitude, we forget to assess the current state of the problem or project. It is very important to develop the ability to point out all the risks that may prevent the safe delivery of a finished solution that is in line with the objective set for the team.
With the experience of coordinating projects, it comes naturally to coolly assess all the 'pros' and 'cons' that you and the team are concerned about. Remember, the whole project team should be involved in identifying and assessing risks. What is invisible to you may be an insurmountable barrier to others.
ADVICE: Use the Risk Matrix, which will allow you to determine the level and severity of risks, identify corrective actions for a given risk, and make it easier to take further steps. Remember that opportunities are in opposition to risks! They are worth keeping in mind. Project stakeholders will greatly appreciate the project team's contribution to the development of the project or product by identifying positive opportunities that can be implemented in the future.
6. No budget tracking
The project has been running for three months. It still has two weeks to go. The work is going well, everyone is happy with the results.
The project sponsor calls you. He asks how much of the budget has been used for the work up to this point.
You check. You get the chills. You get hot. With trembling hands, you check the columns in the table. Yes, you were not wrong. You are 40% over budget. How is that possible? What do we do next? How do we explain this to the sponsor? After all, we still have to deliver 20% of the scope!
Sounds familiar? I sincerely hope not and you only know stories like this from tales. However, such a situation unfortunately often occurs in the world of projects. Regardless of the industry, regardless of team sizes, regardless of the chosen methodology.
ADVICE: For this reason, it is crucial to keep an eye on the burned budget and collide reports with the project sponsor. Make the end or beginning of the week your day to take time to examine the financial health of the project. Use Burndown Charts. What if you notice that we are getting dangerously close to the limit of our financial capacity? The next point answers this question.
7. No escalation of the problem
Yes, I know what you're thinking. I am a Project Manager. I am the person responsible for the project. I will deal with the problem myself. I will not harass my superiors or stakeholders. After all, I cannot come across as incompetent or being in this position by chance.
Nothing could be further from the truth.
Escalating a problem to the stakeholders or superiors is not a sign of weakness. On the contrary, it is a sign of maturity. It is a sign that we are watching over the project, watching over the team, watching over and taking responsibility for delivering the finished solution to which we have committed. Clients and organizations have tools they can use to get the project back on track. However, they will only use them when they KNOW there is a problem.
Remember, however, that you are the person responsible for the project. Evaluate, discuss, weigh up the problem, and only then proceed to escalate and expand the group of people involved in solving it. Not every problem requires escalation. But every problem that requires escalation must be escalated.
ADVICE: Do not wait! Escalate! Neglected problems tend to expand their murderous scope and negatively affect the next steps in the project. Avoid problems like the plague. Escalate!
8. Making decisions too quickly or fear in making them
I once heard that a Project Manager is not a decision maker. I could not believe those words! I was reminded of dozens of situations in which one or more people, in a live meeting, online or in a project chat room, were waiting anxiously for me to make a decision. Do we continue with the work? What direction are we heading in then? Where do we get the materials from? Is this task within the scope of the current work?
Some of the most essential qualities and abilities of any Project Manager are calmness and a cool head. Do you need to make a decision? Think through whether you have all the necessary information to make it. Sometimes making a decision will require additional information. Sometimes you will need to dig into the subject. Many times you will step out of your comfort zone.
ADVICE: There is no rush. In most cases, a decision does not need to be a split-second one. Give yourself time to analyze the problem and choose the best option. Do not be afraid to consult with people more experienced than you! And finally: do not let fate or a coin toss decide – or, worst of all, do not run away from the problem. Solving it is on your shoulders.
On-demand webinar: Moving Forward From Legacy Systems
We’ll walk you through how to think about an upgrade, refactor, or migration project to your codebase. By the end of this webinar, you’ll have a step-by-step plan to move away from the legacy system.
Latest blog posts
Ready to talk about your project?
Tell us more
Fill out a quick form describing your needs. You can always add details later on and we’ll reply within a day!
Strategic Planning
We go through recommended tools, technologies and frameworks that best fit the challenges you face.
Workshop Kickoff
Once we arrange the formalities, you can meet your Polcode team members and we’ll begin developing your next project.