PM's mistakes in the project implementation

management Jan 14, 2021
blog post image

There are multiple factors which affect the success of the project delivery on time and on budget, such as correct communication with the client and the team at all stages of the project life cycle and, as a result, agreements and their observance; the availability of sufficient information at the input of the project, as well as clearly set goals in front of the team; a competent assessment of the project and determination of deadlines for implementation, the qualifications of the direct performers as well as the project manager.

Project managers have different levels of experience and knowledge, have a different background and a different approach to project management and achieving a single goal - successful delivery on time, on budget, so that the client is satisfied and can work in it. Unfortunately, when a new project enters a company, it happens that the choice of a project manager is not always given due attention and the project is distributed to the one who at the moment is relatively less busy than his colleagues.

Meanwhile, the choice of the manager of each specific project is practically the choice of the captain of the ship, who must assemble and lead the team to the goal. Sometimes it happens that the strength of the selected manager is overestimated in relation to the incoming project and its scale, complexity or specificity, which may turn into a slippery slope towards a project failure. An inexperienced manager can make mistakes, which, depending on the scale and complexity of the project, can have significant aftermath - both financial and reputational.

I would like to highlight the most significant mistakes of a project manager, avoiding which, you will definitely become much closer to the successful delivery of all your projects:

  1. Acceptance of a project at the stage of its establishment without sufficient information

I used to work in two different companies where I looked for clients and projects on my own; where customers and projects were sought and found by colleagues from the sales department. In the first case, everything is clear - you, as a project manager, independently collect all the necessary information about the project: you identify the client’s need, highlight the purpose of the project, disassemble and articulate (if necessary, put down) the requirements for the project and the criteria for successful acceptance and transfer, organize the assessment process terms and complexity of the project and discuss all the information with the client, thereby establishing contact with him/her personally from the very beginning. Let us consider a situation where the company is a little more numerous, you do not need to go all this way on your own and the project is transferred to you by one of the sales managers. They have already communicated with the client for some time, probably managed to establish contact with him/her, carried out some preliminary work (such as transferring the project specification for evaluation, a request to form a team for the project) and then it was high time to attract a project manager, so that you begin to fulfill the responsibility which is inherent in your role in the project, which is to manage. The biggest mistake that a project manager can make at this stage is to agree to lead the project without knowing all the details that have been discussed before, however, perhaps not recorded anywhere in writing. Small but important nuances can slip away in the process of transferring information, and this in its turn can negatively affect the result of the work of the entire team and jeopardize customer satisfaction.

How to avoid it? Accept the project in the presence of all participants who have already familiarized themselves with the provided materials, who may have already given an assessment of the project, with which you can simultaneously discuss and synchronize the information available at the input, with which the project manager will subsequently have to work in more detail. Ask for the transfer of knowledge to be documented.

It could be a google-doc or a Confluence page - it does not matter. You only need to have a chance to return to the completed document and rely on it in the process of further work with the client and the team, and not seek answers to questions, verbally tugging at the sales manager, who, after transferring the project to you, immediately proceeds to search for the next one and is unlikely to keep in mind all the nuances.

2. Miscalculation of scheduling terms depending on the number of free performers in a sufficient number

Imagine an ideal world in which, as soon as a new project enters, the necessary performers in full force are absolutely not involved anywhere else, they just cool their heels before the immersion in the project headlong without any restrictions. Have you got the image in your head? Forget it. Because it never happens in real time. The sore point of many companies is the concept of “There are projects, but no resources, there are resources, but no worthy projects”. And it is always like this. You simply need to be able to juggle with this and to work with this.

This must be taken into account when planning the timing of the project, as well as when planning the load of one or another performer. An experienced project manager will never take exactly 3 business days for a task that the team has estimated in 24 hours. Since before the delivery of this task to the client, more time will surely pass by, given the considerable number of factors affecting the deadline. This is both the employment of this performer on a parallel project and the presence of the team of meetings that were not included in the assessment of the task, and the risks associated with the possibility of making an error during implementation and the need to correct what was done. And here the most difficult thing is to explain to the client later that the task estimated in 24 hours will not be ready tomorrow at the same time of day (in exactly 24 hours).

What is to be done? It is trivial to calculate all possible risks and lay them in, if not in the increase in the assessment hours (which, for a certain type of contract, will affect the cost depending on the number of hours set), then it is exactly the same on time. Well, if we explain it to the clients who do not think like us, in man-hours, that the estimate comparing man-hours and money is not equal to the number of light hours.

3. The final goal of the project is not communicated to the team

Now you have already been integrated into the project, you got to know the client, talked to him, found out what you needed, something important or interesting for you, and immediately prepare the development team with conditionally understandable tasks (for example, a user story) with the rating set in the tickets (for example, the team leader of the unit prepares your assessment). What do you think you will get? A group of people who perform tasks separately from each other, not understanding what the result in terms of a business product should be. As a consequence, the product may technically work correctly, but not reflect the goal that the customer laid in it.

What is to be done? Once you have figured out and understood the end goal - fix it in a public document and familiarize all the team members involved with it. This way you will get a clear, well-known reference point that will help different team members think in the same direction and complete tasks, keeping in mind the final goal to which everyone should work together to bring the project.

4. Lack of intermediate control points on a long project

The team has been assembled, everyone has been familiarized with the goal and requirements, the tasks have been “cut” and rushed to develop. Can you guess where you will end up? Not the fact that to the same cherished goal, voiced by everyone initially. No matter how beautiful, simple, and understandable in your opinion you conveyed the goal, this is not a guarantee that everyone understood it the same way. Therefore, the sooner you realize that someone has taken a wrong turn, does something wrong, understands you somehow wrong, the greater the chance to quickly return everyone to the general course of following.

What is to be done? Speak, mark, document and approve the milestones for which you will shoot the intermediate result of the team (both as a whole and its individual members). The checkpoint should be as clear as possible to all participants taking part in its reception and transmission, and should also be located at such a distance from the previous checkpoint so that, if something happens, the changes with the least amount of losses could be corrected or returned to the previous point.

5. Lack of control

If you have assigned the checkpoints, but do not control their observance, very soon the result of the team’s work will be incomprehensible to you, not familiar and uncontrollable. This should not be allowed. Since, in any case, you, as a manager, are the first contact person for the client, representing the company’s reputation and responsible for matching the project result with the customer’s expectations. Therefore, you should always match the client’s documented and approved wishes with what your team is doing. Lack of control over the situation and over the ongoing project will very quickly drag you to the point of no return, the cost of which may be too high.

What is to be done? Synchronize the documentation with the client in a timely manner, and synchronize the team on the subject of where we are all heading and where we will be in a step, in two and at the end of the path. Control should not be excessive, so as not to stifle the desire of team members to work and create, but it should not be too weak so that your comments, if any, are accepted, taken into account and corrected at the time.

6. Excessive control and attempts to do everything yourself

The flip side of control is the thought “if you want to do well, do it yourself”. A deliberately losing team management strategy in which all your work boils down to is finishing up and / or reworking someone else’s work instead of doing your own, supervising and guiding the team towards the correct (approved / agreed) result. With reasonable management and control, any person opens up and performs the work diligently and in a comfortable environment, sometimes with a touch of creativity, which allows him to increase overall satisfaction with what and with whom they are working , and to produce predictably positive results.

What is to be done? Guide, support, motivate, show the course and the goal that we must reach together. Leave the choice of methods and tools for achieving the goal at the discretion of the performers. Then you will see how talents are revealed, offering options for implementation and fresh interesting ideas that work for your own pleasure.

7. Unclear separation of duties

This error partially stems from the previous one - the desire to control everything and perform as many responsibilities as possible. If you do not fix the areas of responsibility from the very beginning and do not appoint those responsible for them, then almost certainly there will be one, if not more, person in the team who will wait for the completion of certain tasks / responsibilities from a teammate. For example, decomposition of tasks, creation of tickets for meetings, filling in project technical and non-technical documentation for the project and much more.

What is to be done? At the start of the project, create a document that is convenient for all team members, where you will record who is responsible for what, who does what. The use of the RACI matrix is ​​recommended, which you can read more about. Remember - the project manager is not responsible for everything, everything in the project! If you think so, please stop. Each team member has his own area of ​​responsibility, for which he will be responsible at each checkpoint. Engineer - for the written code and for completing the task in the provided assessment, team lead - for the quality of the code after review and the absence of errors, product manager or business analyst - for describing and communicating the business goal of the project to the team, project manager - for getting the result on time and on budget, as well as for customer satisfaction with cooperation with the company. It so happens that the deadlines have been disrupted, and the budget has already been increased, but the client is very pleased with the result, this is an excellent result for the team. Sometimes a project manager combines several roles, for example, a project manager, a product manager and a business analyst, then the scope of his responsibility is slightly higher, but even here he does not cover 100% of the work on the project. Each has its own area of ​​responsibility on the way to hitting the target.

8. Lack of maintenance of project documentation or its untimely updating

Competently and responsibly drafted and completed project documentation is a powerful tool in project management. It is needed by both the manager and the client, and also, of course, the team. The most important thing is an understandable clear structure of project documentation, accessibility to all participants, to whom it should and can be open, as well as its regular updating. Some of the most important documents of the project manager are: terms of reference (specification, SOW), register of stakeholders (Stakeholder Map), project schedule (Project Schedule), Meeting Notes (Kick off Meeting, planning Meeting, Stand-up Meeting, Retrospective), project responsibility matrix, Risk Register, change log (sometimes called Change Requests), weekly Project Status Report, documentation from testers (Test Plan, etc.) and others.

What is to be done? Surely your company has already approved methods as well as methods for maintaining project documentation. Do not be afraid to try and suggest something new - for example, software specifically for convenient planning and project management.

9. Hiding the problems arising in the course of the project

Anyone can make a mistake in the process. The main thing is to recognize the mistake in time and warn about it. Problems don’t get solved on their own. They continue to increase and if not eliminated early on, they will have a significant impact on the timing and budget of the project.

What is to be done? You need to learn how to fix errors and eliminate problems that arise. Problems should not be put on the back burner and ignored. If they noticed them on time and were able to redo the whole thing right away, it would be great, and it could be considered that no one was hurt. If the problem is not resolved on its own in a relatively quick time, it is vital to escalate the problem to the management. Perhaps something that you cannot solve on your own is a past situation for someone that still needs to be corrected without any serious consequences.

Summing up, I would like to say that everything mentioned above is not all the mistakes that may lie in wait for a project manager on his way, but getting acquainted, delving into their study and recommendations for prevention and trying to prevent at least some of them are already significant steps that bring you closer to the successful delivery of more than one of your projects.

Additionally, paste this code immediately after the opening tag: