IT project management - team communication.

We don't have to tell anyone about the importance of communication at work. It's just important and you should stick to it. This fact is obvious, but the "quality" of this communication seems less obvious, and it is on it that the success of the company and its effectiveness depend in the long run. Communication is especially important in the case of engineering projects such as IT. The investor often has a lot of money to deliver the project within a certain time and (if it is a Fixed Time&Cost model) budget. The form and quality of communication between project stakeholders often depends on how the project will be run, when it will be completed, with what number of errors and what quality of the code. In a few sentences I will try to present the most "sensitive points" of communication in the project team creating software for the client.

1. First - tools.

An important element of all communication is the appropriate selection of project tools, such as tools for internal communication (e.g. Slack.com), tools for storing information about the project, graphic files, documentation, etc. (e.g. Basecamp.com), a code repository (e.g. Bitbucket.org) or the project management system itself with a Kanban board (e.g. Jira). However, the right tools are not enough. They must also be correctly completed, so that no person involved in the project does not have to bother the PM with such trivial matters as: "where do we cut the png for the andka?" or "give me access to the repo, write permission because I can't commit". Everything must be organized – documentation, graphics and other elements must be in properly labeled folders in a specific system. The repository with the code must be constantly updated, its backup copies should be created on an ongoing basis, and the board itself in Jira must be up-to-date and verified by the Project Manager on an ongoing basis. The internal communication tool is to be used to improve certain processes, e.g. ideas for faster software for a given algorithm or to increase project progress - it is by no means a cluster of internet memes.

2. Blocks.

Another element of exemplary communication is the elimination of the so-called bottlenecks, i.e. situations in which we cannot go further with the project because something or someone is blocking us. A typical bottleneck is often the client himself, who delays the design team, e.g. due to the failure to provide specific graphic elements to the application (when the design is the client's responsibility). Here, the project manager himself must show not only kindness (because the client pays us), but also firmness and decisiveness. A very common phenomenon are tasks marked in the project management system with the label "Blocked by API", which are nothing more than specific endpoints in the API and often the client should deliver them within a certain time. After all, software must also be tested, not only manually...

3. Tests and cooperation with the QA department.

Regarding the tests themselves and cooperation with testers, one could write for hours. This is where the greatest delays often occur, and most often through no fault of the programmers. Lack of good communication of their needs by the tester results in misunderstanding of these needs by the programmer, which may result in (at best) unnecessary "asking" what the author had in mind or (worse) incorrect implementation of the solution. The only way to avoid problems at this stage is to accurately and thoroughly describe the errors in the operation of the application and create appropriate tickets in the system, so that the programmer can start fixing bugs without any problems and asking unnecessary questions. Each error must have its detailed description containing the brand, phone model on which manual tests were performed, the system and its version, as well as other significant elements that help the programmer to diagnose and fix the error in the shortest possible time.

4. Customer awareness.

Another important element is to make the client aware of how important (if we are talking about project work on behalf of the client) he is in the entire software development process. IT projects are often very complicated and risky - usually large budgets are involved, so everyone should be up to the task, as well as the client - even though he is often an investor and puts money on the table. Here, the effort lies with a good and firm PM who, through effective pressure, will obtain the necessary information from the client in a short time, thus ensuring the continuity of work for his engineers. In addition, we must be aware that the client does not need to know programming or project management - in this case, it is the business's goal to properly explain that in such a situation, the client should entrust the care of the entire project to an experienced team that will lead the project (along with with its proper budgeting).

5. Daily stand-ups, weekly demo calls, scheduling sprints.

When managing a project based on the Agile/SCRUM methodology and wanting to eliminate situations that delay our project, we must pay special attention to the structure of work and its internal organization. And I do not mean the dispersion of the team, i.e. remote work - this is perfectly fine if other elements are properly structured. One of such elements are daily stand-ups, i.e. team meetings organized most often in the morning, after all project stakeholders have logged in. This is the moment when we summarize what was done yesterday or before the weekend, and what tasks await us today. The note from the meeting should be placed by the PM in the appropriate system, e.g. Basecamp, which will allow the client to track the progress of work and give the meetings a certain order. Weekly demo calls are meetings, usually organized in the form of video calls with the client, who follows the progress of the team's work on a regular basis, from week to week. An important element is also meetings on setting the sprint schedule - stages of project development, its subsequent milestones. Analytical knowledge and excellent knowledge of design assumptions are needed to prepare such a schedule.

The above 5 points are just the beginning of what happens to us in the project and affect communication, but based on my experience, I have listed the (in my opinion) most important ones. It is certain, however, that many project problems, companies failing to meet a specific budget (e.g. imperfect communication of the QA department with programmers) or deadlines (e.g. conflict with the client, change of project assumptions during a given sprint, lack of awareness of the client about potential threats) is often the reason for poor communication.

Finally, the last thought that came to my mind – communicating well does not mean talking/writing often. If no one asks questions, then everyone knows what to do. And this is probably the most effective communication.