From the opening article of the series on the projects standards, you have learned:
- what projects standards are and what is their purpose;
- what is the approach to this topic in our organization;
- how the process of defining project standards looked like at SolDevelo.
The subject of this article is communication – one of the 6 areas of project management that we have standardized.
Communication is the key
There is no need to convince anyone that communication is the foundation of understanding, both in personal and professional life – and this applies strictly to project work as well. Research indicates that inadequate communication is one of the significant causes of project failures. Mistakes made in the initial stages usually result in numerous difficulties later in the project implementation.
The good news is that project work and the achievement of project goals can be improved by knowing effective ways to manage communication. It is important to take care of communication throughout the entire project life cycle: from the initiation phase through planning and implementation to the closing phase, taking care to reach out to all interested parties and to ensure a two-way flow of information.
In theoretical terms, Project Communications Management refers to the processes necessary to ensure the timely and proper development, distribution, collection, storage, finding of project-related information and its ultimate disposition.
Therefore, communication can be seen as a planned set of methods, tools, channels, but it should also be kept in mind that it is a competence, necessary for the project manager (being the central point of the communication network), as well as the whole team.
Communication rules RULEZ
The following list of rules is a summary of our team’s work in the field of project communication management, carried out in the first quarter of 2022.
List of all team’s meetings with schedule and short descriptions
The goal here is to explain the nature of the meeting a bit more closely than in the agenda. It includes the following information: what is the most important objective of the meeting, who should attend, and where are meeting minutes stored (if needed). Another point is to make it easy for visitors (stakeholders, program managers, etc.) to decide which meetings to attend. It is also a safety lock in case of any emergency, for example a team member losing access to their calendar or Google Calendar bugs.
List of communication channels
We keep track of all our points of contact. The main purpose here is to be able to quickly add new members to all existing places of discussion. It allows us to make sure that no one is left out. Having multiple options also helps to speed up the response when immediate action is needed. Besides, it is helpful if someone needs to use another device to share an emergency message with the rest of the team.
List of all project members on both sides – including client’s
The idea behind it is that projects may last for a long time and both teams’ (client’s and ours) structures are likely to change in the meantime. To avoid confusion and uncertainty about who should be contacted to discuss budget or tech debt, etc., we keep a list containing all team members with positions, e-mail addresses and responsibilities. It also includes coworkers from the client’s side – we act as we are all on the same team, working together as partners to successfully deliver the project.
Planned absences of team members
It is never a pleasant moment when you are the only person on the video call. We try hard to eliminate any surprises in the field of availability. Based on clients preferences, it might be a shared calendar or just a list of planned absences of particular team members. It allows us to properly count the team’s capacity for upcoming sprints and adjust the project roadmap accordingly.
It is agreed how the work will be accepted by the client
To make sure that everyone involved in the project is positive about how exactly the work is being accepted, we state it clearly in our communication rules document. A short description of the process is all we need. It may be even one sentence, if that is the case in the particular project. For example, in our project UAT, a status in Jira workflow is reserved for the client, and the work is considered accepted once the ticket passes through.
Continuous feedback is gathered from clients
We conduct regular feedback sessions to remember that the project is a living organism existing in the dynamic environment. The questions we ask ourselves are: what is the condition of the project, what should we do more, what should we do less, what are the opportunities for the project and how can we prepare for them. It helps us to adjust team structure if, for example, it turns out that we need to release the feature a month earlier than planned. General idea is basically to avoid surprises later in the project development. It is definitely better to learn bad news earlier and have time to brace ourselves!
Page with project brief is created on SolDevelo Confluence
The brief template we have adopted in SolDevelo is a collection of all our company standards. We treat it as a SPOT (Single Point Of Truth) for all basic project information. It also lets us monitor changes in project standards and measure how their levels of implementation affect the effectiveness of certain projects. Our brief consists of the following areas:
- General project description
- Communication rules
- Agile Project Management
- Project Metrics
- Quality Assurance
- Work plan
- Tech Stack
All presented above are SolDevelo’s essential components of efficient communication in the IT project. Current list is just the first version. Our Agile way of working makes it very likely that it will have next iterations of improvements. We will observe the condition of all projects and confront it with data of compliance with the standards, to find out which of them are the most impactful.