Stand with Ukraine
There are multiple factors that affect the success of the project delivery on time and on budget. First comes proper communication with the client and the team at all stages of the project life cycle and, as a result, agreements and their observance. The second is the availability of sufficient information at the input of the project as well as clearly set team goals. The others include a competent assessment of the project, determination of deadlines for implementation, and the qualifications of the direct performers like the Project Manager.
Project Managers have different levels of experience and knowledge, different backgrounds, and different approaches to achieving a single goal — a successful delivery on time and on a budget for the client's satisfaction. 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 can be distributed to the one who is relatively less busy at the moment than his colleagues.
Meanwhile, the choice of the manager of each specific project is practically the choice of the ship's captain who should 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 specifics, 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:
- 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 and 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 successful acceptance and transfer, organize the assessment process terms and complexity of the project, and discuss all the information with the client. But let us consider a situation where the company is a little more numerous, and you do not need to go all this way on your own as 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, and a request to form a team for the project), and then it was high time to attract a project manager. Thus, it's when you begin to fulfill the responsibility that 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 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, or with whom you can simultaneously discuss and synchronize the information available at the input. Ask for the transfer of knowledge to be documented.
It could be a Google Docx 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 principle “there are projects, but no resources; there are resources, but no worthy projects.” And it is always like this. You simply need to work with this.
When planning the timing of the project, we also plan the workload 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
Being integrated into the project, you got to know the client, talk to him, find out what you needed, 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 the reflection of the goal that the customer laid in it is doubtful in this case.
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 for different team members to think in the same direction and complete tasks with the final project goal in mind.
4. Lack of intermediate control points on a long project
The team has been assembled, everyone has been familiarized with the goal and requirements, and 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 good, simple, and understandable 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, the greater the chance to quickly return him/her to the general course of the project.
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. Moreover, it should 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. 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 then 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.
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 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 each task. The use of the RACI matrix is recommended, so you can read more about it. Remember, the Project Manager is not responsible for 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 is responsible for the written code and 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, and 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. If that is the case, then the scope of his responsibility is slightly higher, but even here he does not cover 100% of the work on the project. Everyone has their 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 RegisterForm, 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. But 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 do not 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, this list 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 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. Good luck!
