Problem communication in project management practices

Problem communication in project management practices can create unpleasant problems, delays in project progress and dissatisfied clients. Let’s look at a common and common mistake made by project managers.

To understand where the problem is and what were the reasons for the previous project manager to write this angry speech, I will try to make a brief analysis of each step that he has affected. I will try to give some guidance and outline the good practices that the company follows.

Perhaps the clients were pleased with the project work not only because the project did not move as they had imagined, but also because they did not have much clarity as to how the project was developing. Very often, problems with clients come from insufficient and incorrect communication with them. Some project managers prefer to write emails instead of talking to the client in person. Written communication is a great solution for short messages. Still, it should not be used simply because it is more convenient or because it saves the inconvenience of a difficult conversation. Many misunderstandings and misunderstandings are born because we have not taken the time to identify touchpoints with our customers and prepare them for what is to come.

Different perceptions between clients and the entire development team, even if the clients are technically illiterate, the project manager is expected to present the understanding of his team in a way that is correctly understood by the clients – using diagrams, pictures, layouts, sample design, so everyone can have a clear idea of ​​when something is done. Read more about the function of the project manager.

The client should be involved in all the development and meetings, so he will not be neglected.

Face-to-face communication builds trust, enables us to make sure that we are in the same position. Through direct communication with the client, we will easily feel the disagreement and the origin of the conflict. We can have quick feedback, it is easier to win the customer’s support on important issues, we will understand the other party’s point of view, we will feel how to communicate with the client the easiest.

In my opinion, in addition to a lack of communication and incorrect information, it also makes the customer feel dissatisfied. We must be able to properly evaluate how we will present to the client the progress or delay of the project.

The problem with dissatisfied customers, in my opinion, will be primarily resolved by paying attention to communication with them. It is essential at every stage of the project to know what the client is expecting, where we are from our initial expectations, and whether changes are needed.

A significant part of communicating with the customer is accuracy. If we are committed to responding or reporting within a certain timeframe, that deadline must be met, even if the result is negative or disappointing for them. Otherwise, the client starts to lose trust in us, and this leads to various problems and misunderstandings.

Projects need a good plan

For a good start to the project, it must have a clear plan in place when starting it. This is good practice that the company follows. However, only a good plan is not enough to successfully work on the project. The implementation of the plan must be monitored both within its planned time and quality and budget. Each stage must be completed on time and with a product that meets the client’s expectations for that stage.

There can be many different reasons for lagging behind the project plan – poor planning of the time, insufficient understanding of the requirements for what we are doing, insufficient work on the project, poor and inefficient work, lack of control. And there may also be problems in the project process that we did not anticipate that would take some of the time and budget is foreseen for other activities. To create a good project plan a decent project management education or training course may be needed,

Delaying the project management plan should be discussed.

Delaying the plan should also be discussed with the client in the right way, and once explained to him, his adverse reaction will not be as severe – transparency in relationships and work is essential.

If the timing has not been well planned or we find that it is not enough for the reasons that have arisen, then we can try to plan it again within the project, or contact the client and discuss how we move forward. If deemed necessary, we may include more project staff if this can happen within the budget.

It is advisable to seek feedback during the various stages of the project daily and at the end of each stage. The daily meetings should be brief, concise, but also keep us up to date – what we have done, what lies ahead, whether there are obstacles. It should also allow people, the projected time to work on the project, to work and test quietly to the final stage.

If there is a problem with the quality of work, it must be solved with the help of a functional manager who monitors not only the progress but also the quality of the work, through feedback from the testers, and if the project director is also required if there is any such. The decisions, in this case, can be different – training, team rockets, crunching team members, new team members. Meetings with developers are good practices in the work of the previous project manager. However, these meetings should also be brief and clarify uncertainties and should not be too long to work. In these meetings, it is good to be able to determine whether those who work on the project are enough.
Further, in the statement of this former employee, I can see that he felt that the company felt that he gave priority to communicate with developers over that of clients.

As I noted in the beginning, customer communication is crucial, but communication with developers is essential to the project. One should not be at the expense of the other. This applied to both Scrum and Waterfall project management. Period.

Developers are an essential part of successful project execution.

One of the mistakes in communicating with people who have to work on different parts of the project is that too much, and too much information is provided. In order not to confuse the people who work they need to know precisely what they need to do, we need to give them just the right amount of communication and nothing more. Our goal in communication is to communicate effectively and efficiently, but not regularly and without taking the time to complete the project.

For developers, communicating with them, and understanding their tasks, we can seek the help of a functional manager.

As far as clients and their contact staff are concerned, it might be a good idea to have a meeting. If there is a reason for delaying the project on their part, it is a good idea to seek, together with the responsible persons on their part, a solution that, to some extent, satisfies both parties. I do not think that being extreme in the speeches will help us in this direction. We should better look for facts and arguments to support our thesis that their employees caused the delay. And then we have a solution to solve the problem.

In some projects, even when both employees and the company conscientiously fulfill all their duties and follow all instructions strictly, the project still does not go. In my opinion, you can revisit the project plan, think about the methodology, responsible persons and employees involved in the project, check whether there was no discrepancy in the initial negotiations (sales team may have misled the client by in some way he was left with the wrong impression). Sometimes changing the methodology, or adding steps that are part of company practices that have proven effective, helps. It is not necessary to blindly follow the steps of any of the popular methodologies we have chosen to design the project. If this is considered useful, we can model the methodology in a way that we believe will be effective for our particular project. Each project is unique in itself, and the framework used can be modified for the needs of the project.

It would be a good idea to evaluate the effectiveness of employees, including developers, with the help of a functional manager. This will allow you to decide whether to replace or downgrade programmers, or whether you need to look for a solution in another direction, such as insufficient project work or lack of clarity in instructions. Get feedback from other executives, clients, other colleagues the dev team has worked with so we can have a clear picture of the developer team’s attitude and professionalism.

Conversations with clients, a thorough review of the project plan, and performance evaluation so far will allow us to assess whether the client and his project are difficult from a project management perspective. Even if it is so difficult, you can find an effective way to get on with it – a bigger budget, a bigger team, more time.

In addition to the steps described above, in my opinion, it is also good to seek feedback on the project and the project staff. In this way, we will have the opportunity to confirm or deny any of our conclusions, opinions and opinions.

Evaluate project communication

Another critical point, in my opinion, is to evaluate project communication. By this, I mean the communication and transmission of information from and to – managers, employees, programmers, testers, customers, and other interested parties. Success is teamwork. For a team to work well in one direction and for one purpose, it must properly understand the direction, steps, and purpose.

It is also important to have some kind of project manager reporting – reports, charts, something that can relatively measure project effectiveness:

  • For one iteration, how much work is done.
  • How the team moves in time.
  • How does the absence of people from the team affect the overall project work (if one becomes ill, leave, etc.)?
  • How the team handles the budget.

Leave a comment

Your email address will not be published. Required fields are marked *