Practical examples

The 2 main challenges of managing a project 5.1 thousand miles distant

October 27, 2019

Recently I finished managing a project 5100 miles distant and all I can say is that I learned a lot. The team I managed directly had 9 people for some time and finished with 6. I’m sharing here two of the biggest challenges I faced during the project and how we overcame them.

1. Language

Part of the team, which lives in Porto Alegre, speaks Portuguese as their native language. We speak English as well, but it’s not the same as a native language. The rest of the team, speaking English, were 5.1 miles distant.

Portuguese is a broad language, and English is way more straight to the point. Also, culture and context make a difference. Using Portuguese, it’s natural to talk about a point without reaching the point itself (using passive voice). If you want to say no for something, you can say no without using the word “no”. This is one of the traps I fell inadvertently.

Sometimes I even realized a bit of an ego holding part of the team to ask questions. I could tell they were not 100% sure of what somebody told but they wouldn’t ask to make the information clearer. It’s something small, but all the points not understood 100% eventually had to be clarified and time was lost. Sometimes bad decisions were taken and rework was the consequence.

The language is a barrier. We cannot avoid it. Ideas and complex scenarios are tougher to explain.

2. Sense of lack of communication

During the project, I kept conducting regular ceremonies for communication, but I was always feeling a lack of communication. Sometimes I thought the team should have more autonomy to reach the client more often, without relying on me as a proxy (bad practice found here). We tried and started to improve. It did start to work from the 7th month on.

At the end of the project, we traveled to the client headquarters to validate the system faster than we were doing. This trip was crucial to creating a good relationship with the entire team. It decreased dependency on key stakeholders and it was easier to see each one’s potential.

What were the problems and how we overcame them

For practical activities, it’s hard to split the language and the lack of communication because they often seem to be the same. They are not. How did we overcome these two challenges were the most important part:

Language

Naturally, team skills in English improved. In just those few months of the project, it was not enough to have everybody’s English on the state of art. But we improved. The week we spent on the customer headquarters was also a divisor in terms of language. All the team got to understand better each other also considering the different cultures.

Communication

Status report

since we had a mix of waterfall and agile practices, the status reports were part of the plan. Few of them were sent. Many of them were missed. What makes me sad here is that they were missed. What makes me happy is that nobody missed them. They were just a group of information being discussed daily. Different formats of “status reports” could have been used. At the end of the project few short and summarised emails were used for the same intent. Both had the same impact.

Daily meetings

We started with daily meetings. They worked just in terms of high-level catch-up. The big mistake here was not having the business representatives on them. From the middle of the project on, the daily meetings were just a quick and superficial report of what people were doing. No one was actually taking care of the project using the daily meetings. From a business and practical standpoint, they could have stopped at some point and not much would have changed. Besides, they were important to create a team and a collaborative environment.

Emails

It’s unbelievable how easy it is to fall into the trap of sending an email and throwing an invisible package of things to solve to the other side of the wall. We made this mistake. And the team fixed it as soon as it realized the emails were actually creating friction instead of solving problems. We didn’t stop to send emails. But we stopped using them isolated and always had a quick catch up meeting parallels.

Bi-weekly demos

The demos happened always as planned. The good and bad part is that they created a lot of discussions about what was being delivered. They were bad because highlighted our lack of alignment in terms of business decisions many times. But they were also good because highlighted our lack of alignment in terms of business decisions many times. Then after the demos, the project used to have new turns to put the requirements back on trails.

By demand meetings

Every time we had meetings, we found solutions for the problems. No exceptions. Every time we got to talk, we solved problems. The meetings that started to happen after some business decisions lack of alignment were crucial for the project’s success. Here I’m talking about both long meetings to detail requirements and short meetings to synchronize small decisions.

I shared some of my key learnings in this project. I hope it helps you guys in similar scenarios to overcome your current project challenges.

You Might Also Like

No Comments

Leave a Reply