14
.
11
.
2023
1
.
04
.
2019
Project Management

Common communication issues in project management

Michał Krochecki
Chief Operations Officer

You hear all the time that Visuality is a full-stack software house. But what does that really mean?

In layman terms, it means that we are capable of giving you the full-service regarding your software. So it's not only the coding of the back-end and front-end but also UX/UI design, business analysis, fully-comprehensive workshops and complex project management. The latter is probably the most important thing in software development (after writing quality code of course and wrapping it up in a nice shell), as it makes the process smooth, organized and, most importantly for the client, cost-effective.

Regardless of the type of your business or the country of its origin, as a CEO, COO, product manager or else, you won't have all the time in the world to control the backlog and look after the development team. Developers, no matter how experienced, need to know what to deliver and do that on time. That's why we offer you services of trained professionals that have vast know-how about the development. It's all for you, so you could worry less and just observe the results.

We do our best, but even the best professionals encounter challenges throughout the process. Communication is one of them. I asked our PMs what common issues they have, how they fight them and what they advise our clients.

Q: Please identify major problems in communication with the client

Mateusz: Main issues I see, is low precision of the requirements regarding the features. Another thing is a small time window when the client can share the business vision of the application, especially when the backlog is packed. Also limited tech-knowledge of the client and his difficulty in understanding the complexity of the specific solutions.

Wiktor: For me it's low precision of the requirements regarding the features, very vague explanations of how things work. It's often embodied with sending over designs with no explanations how certain elements are expected to work. It's often in someone else's head or designer, but it's all up to us to ask those questions and indicate contradictory things in the design.

A common issue I have is also not using agreed formats of requirementswhich makes us wonder what did client mean by that. For example, user flow description is not consistent with the agreed format.

Krystian: In my view, agreement on a common glossary is essential. Having the common language, that ensures that both sides understand the things the same way, allows us to follow communication plan agreed during the workshop and help you (Product Owner) communicate with your dedicated engineering team effectively.


Q: Which one is the most painful for you?

Mateusz: For me, the most problematic is the situation when I don't have a detailed backlog ready per each sprint. Due to such issue, the team has no concrete tasks. I'm responsible for such state in the team. At the same time I have limited power to make the decisions on my own, therefore the whole situation creates a vicious circle. Such situation compromises the full delivery of the sprint.

Wiktor: What Mateusz wrote above is 100% true.

Krystian: No timely feedback from Product Owner or imprecise one.


Q: From your experience, how the lack of information and poor communication affects the team as a whole?

Mateusz: Engineers like to feel that they have control and that there's a clear goal. When that's not on the table, because of the poor communication or lack of details, it creates personal frustration that may affect the morale and reduce the mutual trust between developers and the client.

Wiktor: From my perspective, the goal is most important. The developers need to know what is expected from them and what kind of business goal we'd like to achieve, so whenever there is a technical obstacle, they can find a workaround.

Krystian: Project is a team play thus cooperation is the essence. With no information or lack of details, we are slow and less efficient.


Q: What is problematic and hard for the client from your perspective?

Mateusz: From my experience, the most difficult thing for the client is to dedicate time to work on the large volume of tasks. If the client is not consequent in his actions, it creates the overload of the things he needs to prepare and/or accept for the sprint. It often leads to frustration. Another thing is that the client usually cannot force himself to think like a developer. He cuts corners because he knows the system really well.

In the initial stages of the development when the developers don't know the system by heart it creates a situation when the tasks are not fully described and further refinement is needed which consumes time and effort on both sides.

Wiktor: Sometimes clients have difficulty with delivering consequently the "material". It's against agile and against principles of the project management itself as it creates periods of intense work or periods with a very limited scope of work.

Thinking in "sprints" is a challenge. Next 10 mendays is what matters.

Krystian: Client has difficulties with communicating the essence of the business that's behind the application. Product owner forgets that the developers and project manager not necessarily have vast knowledge about the business that they do. It is important for the client to omit jargon as sometimes it is not fully understandable by the team.


Q: Why should there be a single point of contact on both sides?

Mateusz: It's not about one person on each side, but it's about one common place where the communication happens and the records are kept. For that, we need clear rules and roles (responsibilities). Example: When a task/issue appears it is clear for both sides who takes care of it. In Visuality we like to have a first point of contact for random issues/operational tasks --- a dedicated person that we can address in communication, even if that person takes it further and comes back with an answer. Of course, all depends on the situation and team structure of our client. We are flexible, however as I said, we need to establish clear rules for both sides at the beginning. Priorities and requirements need to be communicated unanimously. Imagine a situation when there are 3 co-founders and each one tells us another thing. Suffice to say, it creates a lack of efficiency and frustration on both sides.

Wiktor:

There are three levels of communication: daily basis communication --- something that happens real time, quick questions and quick tickets. The second level is mid-level communication regarding the backlog. It shall happen in Jira or other software dedicated for that. Third level --- emails and calls which are dedicated for more important things. Mixing these levels or using only one creates chaos and will negatively affect the development. Using wrong channels forces the team to dedicate time to put everything in the right order. And as we all know --- time is money and nobody wants to waste any of them.

Krystian:

Single point of contact is good but not always needed. In bigger-size projects, when you need to handle the communication with multiple people, it's good to have a person who will facilitate/streamline the communication. That's one of Pm's duty.


Q: What happens when there is a lack of roadmap in a project?

Mateusz: When there is no roadmap it is hard to create goals, maintain motivation and health of the team. When you don't have a clear plan, you don't know what you need and want to achieve, you just work for works sake. Our developers engage themselves in the project, they feel personal satisfaction when they're part of something bigger.

Wiktor: When there is no roadmap client can't prioritize the tasks. No matter how effective our team is, client in such state will not observe that we are moving forward.

Krystian: It's pretty simple --- client will waste his money.


Q: How do you fight bad communication?

Mateusz: Most often I show our perspective and indicate the benefits of good communication and clear planning. I extrapolate different scenarios for the client and show the consequences of the bad habits in communication and processes.

Wiktor: I present the financial consequences of not using good habits.

Krystian: First, I do my best to find the cause (perhaps there is a room for process improvement) and then I try to help. Providing templates and examples is a nice technique that I use.


Q: Could you give some examples of frequent problems that were caused by a lack of communication?

Mateusz: Before I showed you some examples and I'd like to share some thoughts about the reasons. Most of the problems arise in the area where dynamic, and simultaneously important changes happen. Another issue is that there's a rush, so cutting corners may happen too. Using a language not adapted to the interlocutor (business-wise to the developer, technical-wise to the client) is also problematic. Such an approach creates misunderstandings and leads to frustration.

Let me share some examples.\ - Vaguely described, not prioritised tasks in the backlog.\ - Changing priorities in the middle of work,\ - updating requirements during testing,\ - using private channel to communicate requirements or priorities --- that creates siloses of knowledge while all stakeholders should have opportunity to be on the same page.

Wiktor: The biggest problem is the management of expectations. When the client doesn't communicate them early and in an efficient way, the delivered estimation per task/module/feature are different than expected by the client. It can cause conflicts between the client and the team and internal conflict between the stakeholders.

Krystian: Mateusz and Wiktor hit the spot!


Q: People often question the necessity of having a PM in the project. What would you say to that?

Mateusz: Most importantly, a PM is a person that takes care of the productivity. I'm on site daily so I can really look after the process. I detect and predict issues which gives me the ability to solve the problems before they appear. I know the team really well --- I know what strengths and weaknesses they have and I know what motivates and demotivates them.

Wiktor: A PM is kind of an interpreter. He speaks the language of the client and the developers, therefore he provides better and efficient communication. Engineers need clear tasks to work and a PM is in charge of making sure they get them together with a long-term vision. If the developer would be in charge of organizing meetings and getting requirements it would take definitely more time than is necessary when there is a PM.

Krystian: Sometimes the PM is not necessary (when the project is micro-size) , however, given the projects that we have at Visuality, this role is an essential part of any cooperation. A good Project Manager won't only send you the reports on-time but will also be strategy-oriented, understand & creates awareness about the financial aspects, follow your industry and focus on people together with processes.


Q: Does the project management help in quality control?

Mateusz: PM helps in testing the features. He often has a vast knowledge of the UX, therefore he can suggest the right solutions from the user's perspective. All that results in boosting the quality of the application.

Wiktor: It is not our main responsibility but sometimes it happens naturally.

Krystian: PM focuses on the quality of the process. Good process = good quality.


Q: What good habits should a project manager maintain in communication?

Mateusz: It is very important to stick to the dates of the meetings.Postponing is not a good thing. A PM should inform regularly about the sprint status and chances of delivering 100% of the sprint. Taking care of the daily standups is also a big thing because thanks to that the client is fully aware of the current tasks that the developers have and their status.

Wiktor: Using plain English, layman terms, clearly addressing the right people in communication. Scheduling the meetings in advance.

Krystian: That's a very broad subject. What you can (and should expect) will actually vary depending on the project itself.


Q: What advice would you give to the product owners?

Mateusz: I would suggest keeping the PM always informed about every single decision and plan as it helps us to see the bigger picture. I advise treating the team as partners. As I said before, developers like to feel needed and to see the result of their work. Simply keep us always in the loop!

Wiktor: Shortcomings on all sides can be recalculated to a cost (money). The better the communication the more efficiently everything goes and everything is more cost-efficient.

Krystian: Think long-term, prepare a product roadmap, and share it with us. When planning, think mainly about the value you plan to give to your users and leave the technology part to the professionals.


Summary:

Project manager is a one-man-band that has many different skills and responsibilities regardless of the type of application he takes care of. He needs to follow strict rules to make sure that the highest quality standards are maintained, the development team is motivated and happy, sprint deliveries are smooth and our clients are satisfied. Thanks to his role the client will be well informed about the progress and able to plan ahead. It's not an easy job, sometimes stressful but it's also very satisfying. Visuality's project managers like to observe the effects of their work and treat clients' successes like their own. If you are working with us or planning to hire us soon remember about all the precious advice they gave in this interview. After all, you will be gaining benefits from it, your software will thrive and you will have more time to focus on other areas of your business.

Michał Krochecki
Chief Operations Officer

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

Recap of Friendly.rb 2024 conference

Insights and Inspiration from Friendly.rb: A Ruby Conference Recap

02
.
10
.
2024
Kaja Witek
Conferences
Ruby on Rails

Covering indexes - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby on Rails
Postgresql
Backend
Ula Sołogub - SQL Injection in Ruby on Rails

The Deadly Sins in RoR security - SQL Injection

14
.
11
.
2023
Urszula Sołogub
Backend
Ruby on Rails
Software
Michal - Highlights from Ruby Unconf 2024

Highlights from Ruby Unconf 2024

14
.
11
.
2023
Michał Łęcicki
Conferences
Visuality
Cezary Kłos - Optimizing Cloud Infrastructure by $40 000 Annually

Optimizing Cloud Infrastructure by $40 000 Annually

14
.
11
.
2023
Cezary Kłos
Backend
Ruby on Rails

Smooth Concurrent Updates with Hotwire Stimulus

14
.
11
.
2023
Michał Łęcicki
Hotwire
Ruby on Rails
Software
Tutorial

Freelancers vs Software house

02
.
10
.
2024
Michał Krochecki
Visuality
Business

Table partitioning in Rails, part 2 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
Ruby on Rails

N+1 in Ruby on Rails

14
.
11
.
2023
Katarzyna Melon-Markowska
Ruby on Rails
Ruby
Backend

Turbo Streams and current user

29
.
11
.
2023
Mateusz Bilski
Hotwire
Ruby on Rails
Backend
Frontend

Showing progress of background jobs with Turbo

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Ruby
Hotwire
Frontend
Backend

Table partitioning in Rails, part 1 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend
Ruby on Rails

Table partitioning types - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend

Indexing partitioned table - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
SQL Views in Ruby on Rails

SQL views in Ruby on Rails

14
.
11
.
2023
Jan Grela
Backend
Ruby
Ruby on Rails
Postgresql
Design your bathroom in React

Design your bathroom in React

14
.
11
.
2023
Bartosz Bazański
Frontend
React
Lazy Attributes in Ruby - Krzysztof Wawer

Lazy attributes in Ruby

14
.
11
.
2023
Krzysztof Wawer
Ruby
Software

Exporting CSV files using COPY - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Ruby
Ruby on Rails
Michał Łęcicki - From Celluloid to Concurrent Ruby

From Celluloid to Concurrent Ruby: Practical Examples Of Multithreading Calls

14
.
11
.
2023
Michał Łęcicki
Backend
Ruby
Ruby on Rails
Software

Super Slide Me - Game Written in React

14
.
11
.
2023
Antoni Smoliński
Frontend
React
Jarek Kowalewski - ILIKE vs LIKE/LOWER - Postgres Stories

ILIKE vs LIKE/LOWER - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby
Ruby on Rails
Postgresql

A look back at Friendly.rb 2023

14
.
11
.
2023
Cezary Kłos
Conferences
Ruby

Debugging Rails - Ruby Junior Chronicles

14
.
11
.
2023
Piotr Witek
Ruby on Rails
Backend
Tutorial