Communication in an IT project: How long-term planning helps you stay on track with deadlines, tasks, and expectations

Why in an IT project it is not enough just to agree «at the start»

Author: Elizaveta Arsenyeva, Bulltech Project Manager

As a project manager, I have often encountered a situation where everything looks pretty calm at the start. There is a clear goal, there is a list of tasks, there is a team, there is a customer, everyone understands roughly what needs to be done. At this point, it often seems that the main thing has already happened: we have agreed, we have started, we are moving.

But in IT projects, the problem rarely appears immediately. It usually accumulates gradually. At first, they decided to «discuss one detail later,» then the restriction was not fixed, then the customer verbally said that «this could be added at the next stage,» then the team understood this as a separate task, and the business as part of the current volume. After a month, everyone seems to be talking about the same project, but everyone already has their own version of the result in their head.

And here it becomes clear that communication is not just phone calls and chat messages. This is a way to keep the project in one reality.ager, I have often encountered a situation where everything looks pretty calm at the start. There is a clear goal, there is a list of tasks, there is a team, there is a customer, everyone understands roughly what needs to be done. At this point, it often seems that the main thing has already happened: we have agreed, we have started, we are moving.

But in IT projects, the problem rarely appears immediately. It usually accumulates gradually. At first, they decided to «discuss one detail later,» then the restriction was not fixed, then the customer verbally said that «this could be added at the next stage,» then the team understood this as a separate task, and the business as part of the current volume. After a month, everyone seems to be talking about the same project, but everyone already has their own version of the result in their head.

And here it becomes clear that communication is not just phone calls and chat messages. This is a way to keep the project in one reality.

On one of the projects for the development of an online store, we encountered a fairly typical situation. The functionality was planned to be developed in stages: at the first meeting, the launch of the basic version was discussed, then possible improvements, and then ideas for future stages of development. Everything looked logical, but some of these ideas remained at the discussion level. We have not clearly defined what is included in the current stage of development, what is being transferred to the next one, and what remains only a hypothesis so far.

For the first few weeks, it created almost no problems. The team completed the tasks, the customer gave feedback, and the project moved according to plan. But over time, questions began to arise.: «Why is this feature not in the current version?», «We discussed this possibility,» «Since you are already making this section, can I add it right away?»

The most annoying thing in such situations is that no one has made an obvious mistake. The customer really remembered the discussion. The team really focused on the agreed amount of work. The manager did record key decisions, but did not clearly separate the current stage of development and plans for further development of the project.

In the end, the problem wasn’t the quality of communication. The problem was that the discussion did not turn into a long-term plan that was understandable to all participants with clearly defined stages of implementation.

Sometimes long-term planning is mistakenly perceived as something heavy and inflexible. It’s like if we’ve described the stages in advance, we can’t change anything anymore. That’s not how it works in IT. A good plan doesn’t have to nail a project to the wall. It should help us understand where we are now, where we are going next, and what decisions will affect the timing, budget, and team.

For me, long—term planning is not an attempt to guess everything a year in advance. This is a way to divide a project into clear horizons in advance: what we are doing now, what we are preparing for the next stage, what ideas we are keeping in reserve for now, and what decisions we need to return to later.

The PMI in the Pulse of the Profession 2025 report specifically highlights the importance of critical conversations with stakeholders, which help to find discrepancies in expectations in advance and adjust the course before the conflict becomes large. This is a very practical idea for a project manager: the sooner we talk about an inconvenient moment, the cheaper it is to fix it.

When working with a customer, it is important not just to answer questions, but to regularly bring everyone back to the big picture. Especially if the project is long, develops in stages, or depends on several teams.

I usually try to say not only «what we’re doing,» but also «what it means for the next steps.» For example, if a customer asks to add new mechanics to the current stage, it is important not just to say «yes» or «no». You need to explain what this will affect: timing, testing, design, integration, administrative dashboard, documentation, or future support.

At some point, I started using a more direct formulation.: «Let’s separate the idea from the task.» And it worked well. An idea may be correct, useful, and promising, but that doesn’t mean it automatically enters the current stage of development. First you need to describe it, evaluate it, understand the dependencies, and only then put it in the plan.

This approach reduces the number of contentious situations. The customer sees that his offer is not rejected, but carefully placed in the decision-making system. The team sees that the volume is not growing uncontrollably. The manager gets the opportunity to manage the project, and not just put out new introductory ones.

In a long project, it is impossible to keep all the agreements only in memory or correspondence. Especially if the discussions take place in different channels: meetings, chats, emails, comments in tasks, layouts, documents. Therefore, communication must leave a mark.

In practice, I try to capture a few things.:

1. what is included in the current stage of work;
2. what was discussed as an idea for the future;
3. what decisions have already been agreed upon and by whom;
4. What questions are still open?;
5. what changes affect the timing, cost, or volume?;
6. which topics should be revisited in the next step.

This is not bureaucracy for the sake of bureaucracy. This is a way to protect both the customer and the team. When the agreements are transparent, there is less room for the phrase «I thought we meant something else.»

Russian materials on communication management also agree on this logic: a communication plan describes channels, rules of interaction, and formats for transmitting information, and as the number of participants grows, it becomes difficult to maintain a unified understanding of the project without such a plan. Project management training materials also emphasize that communications affect the timing, quality, and cost of a project, which is why a communications plan is of strategic importance.

Most of the conflicts in the project do not arise because people want to argue. More often than not, they just understood the agreement differently.

The customer could hear: «it is possible to implement this.» The team meant, «It’s possible to implement this as a separate task.» The manager was thinking: «we will come back to this after the launch of the first stage.» Everyone seems to be right, but the conflict has already appeared.

A long-term plan helps to separate such things in advance. There is an ongoing development. There are upcoming improvements. There are ideas that need to be evaluated. There are tasks that depend on external integrations, content, legal approvals, or the willingness of another team. When this is seen on the same level, the conversation becomes calmer.

Instead of «why hasn’t this happened yet?» a more practical question appears: «do we want to move this to the current stage or leave it for the next one?» This is no longer an argument about who promised what. This is a management decision.

One of the most annoying mistakes a manager makes is waiting for the problem to become obvious to everyone. It seems that if we don’t talk about the risk yet, then maybe it will resolve itself. But this almost never happens in projects. A risk that has been kept quiet for two weeks usually becomes an urgent problem on a Friday night.

If I see that a new introduction might affect the plan, I try to say it right away. Not in a panic format, but calmly: «Now it looks like a volume change. We need to assess the impact on timing.» Or: «We can add this to the current stage, but then we need to choose what we transfer.» Or: «This idea is good, but there is not enough data for it, so it is better to put it into a separate task for elaboration.»

PMI noted in earlier materials that poor communication is one of the key factors in the failure of projects, and in unsuccessful projects it was a significant concomitant factor. The figure itself is not as important as the conclusion for practice: communication problems almost always become problems of timing, budget or quality.

The most effective approach is to speak not abstractly, but through consequences. The customer does not need a beautiful plan for the sake of a beautiful plan. It is important for him to understand how this helps the product.

Instead of saying, «we need to create a long-term roadmap,» it’s better to put it more simply: «Let’s break down the development of the project into stages in order to understand what tasks we are doing now, what we are preparing next, and what decisions may affect the timing.»

Instead of «we need to manage expectations,» it’s better to say, «We’ll fix what’s included in the current stage so that we don’t have to argue about whether it was part of the original agreement.»

Instead of «we have communication risks,» it is better to say: «Now some of the decisions are discussed verbally, so there is a risk to understand the scope differently. Let’s put this in writing.»

Such formulations sound simpler and more honest. They don’t create the feeling that the manager is complicating the process. On the contrary, it becomes clear that planning is necessary for the project to move more calmly.

Good communication does not guarantee that there will be no changes in the project. They will be there anyway. The customer can clarify the business goal, the team can find a technical limitation, and users can show that the scenario needs to be changed. This is a normal part of development.

But good communication helps you stay in control when changes appear. It makes the project more transparent: the team understands the priorities, the customer sees the consequences of decisions, the manager can highlight the risks in advance and suggest options.

For me, long—term planning is not a document that is done once and forgotten. This is a regular conversation about the future of the project. What are we doing now? What will be the next step? What decisions should be made in advance? Where do we have open questions? What can affect the timing?

If such questions are asked regularly, the project depends less on the memory of individuals and random chat messages. It becomes manageable.

In an IT project, you can’t agree once at the start and then just do the tasks. The longer a project lives, the more new introductions, clarifications, limitations, and ideas appear in it. If they are not connected to a common plan, the team and the customer gradually begin to move in different directions, even if they are trying to do everything well.

Therefore, communication and long-term planning must go together. Communication helps to notice discrepancies in expectations in time. Planning helps to turn these conversations into understandable decisions.

As a project manager, I see this not as a formality, but as a way to maintain normal relations within the project. When everyone understands what we are doing now, what we are leaving for the next stage, and why some ideas require separate evaluation, there is less tension and more trust.

And trust in a long-term IT project is sometimes more important than an ideal plan. Because the plan will change anyway. The main thing is that at the time of changes, the team and the customer continue to talk to each other in the same language.