In the world of high technology and tight deadlines, Agile methodologies have become a true salvation for project managers. But how to maintain flexibility and efficiency when working with teams spread all over the world and clients with different cultural backgrounds?
Aleksei Chernega, senior project manager at Magora Systems, shares his experience in managing international projects and discusses the key skills needed for project managers in the era of artificial intelligence.
Agile without borders: how to adapt to cultural and regulatory differences
The Agile approach is all about the ability to adapt to change. When working with teams from the USA, Germany, and the UAE, differences in expectations, approval speeds, and regulatory constraints become critical.
For example, in a project with a German client from the logistics industry, we were already at the MVP development stage when the client made a significant change – the need for a route optimization module based on user behavior. This potentially meant a complete overhaul of the architecture and a risk of a 3-4 week delay. In this situation, an Agile approach was applied at a strategic level:
- CR workshop with the client: visualization of the impact of changes on the budget and timelines.
- Alternative solutions: preparing two options: including a module with the transfer of part of the control panel functions to a future release or phased implementation.
- Backlog and roadmap adjustment: collaborative adjustment with the team without losing key functionality.
As a result, the project was completed with a slight delay of two weeks, the client received the necessary business function, and trust was maintained. This situation reaffirmed that Agile flexibility is about managing expectations and transparency, especially when working with cultures where accuracy and structure matter a lot (like in Germany), as opposed to the more ‘rapid’ markets of the Middle East and North Africa.
Tools for intercultural interaction: creating a unified information space
When working with distributed teams, tools become a common language for interaction. The product manager’s task is to ensure that both developers from London, testers from Tbilisi, and designers from the Middle East and North Africa have a good understanding of the processes and documentation.
For this, I recommend:
- Create a universal structure in Notion or Confluence: divide the information by roles (developer, designer, product manager, customer success specialist).
- In Jira, bring out the visible client and internal technical tasks: reducing information noise and the number of misunderstandings.
- Add a page with instructions: describe the rules for using the tools with task templates, user stories, and feature requests.
- Format all work documents in English, with visual elements and Loom videos: consider different styles of information perception.
At the same time, resistance is inevitable. For example, when we implemented Notion as the main wiki system for the project, some experienced developers were attached to Google Docs or local documents. I decided to demonstrate the value — I gathered feedback, created a 10-minute introductory guide, and showed how it was possible to reduce the time spent searching for information by 40-50%. Two weeks later, everyone transitioned to the new environment and started using the templates. The key is to make the tool useful and understandable for everyone.
Dialogue with the management: how to persuade the client to reconsider priorities
When top management demands changes that could lead to missed deadlines, it’s important to discuss the consequences and possible scenarios. It’s not enough to simply say ‘it’s impossible’; you need to present possible options. In one project for a logistics company in Germany, the client requested the integration of a route optimization algorithm at the stage of an already planned MVP. This meant potential cost overruns, changes to the architecture, and the risk of missing deadlines.
What I did:
Conducted a workshop with key stakeholders, distributing the consequences across scenarios:
- Implementation now means postponing deadlines by 3-4 weeks, reworking the dashboard.
- We are moving it to the release after the MVP – the deadline remains the same, but we are adding a slot for the task with a buffer.
- Mini version now + expansion later – a compromise option.
Supported with calculations: delivery time, cost of delay, and impact on final KPIs.
The following arguments were triggered:
- “Your main metric is time to market. Scenario 3 allows you to show investors results on time — and at the same time, not lose a feature.”
- “This is not a refusal. This is flexible planning.”
- “Maintaining user trust is more important than releasing everything at once.”
In the end, the client chose a combined scenario, the project was completed on time, and the team gained a credit of trust. Senior executives do not want to hear ‘no’, they need to understand the risks and control the situation.
MVP: value above all
In complex B2B projects, an MVP is not a “minimum viable product” but a basic business unit capable of proving the value of the product.
For instance, in the case mentioned above, specifically in a logistics project with a German client, our goal was to automate route planning for a large distribution company. To set priorities, the team:
- Worked using impact maps and user stories: we figured out what would be used in the first week after launch.
- We sorted by value and cost: we focused on one key task: routes + basic analytics.
- Everything that did not interfere with the first delivery of value was moved to the backlog.
Indicators of MVP viability:
- % of successfully created routes (baseline indicator = 80%);
- time to form 1 route (no more than 20 seconds);
- driver engagement (through internal tracker);
- CSAT from the logistics team (goal – 4.0+ on a 5-point scale).
The client was explained: “MVP is like the first flight: if it has safely transported passengers, it means the product works,” “Integrations that are not critical on day one take resources away from the core route. It’s better to provide a stable route first than an overloaded product,” “If we can’t test the core functionality with real users, everything else will be irrelevant.”
As a result, the MVP was approved, launched with minimal technical debt, and after the release, the team quickly added additional modules.
Scaling: stress test on trust
An increase in NPS to 9.2 out of 10 is the result not only of development quality but also of managing expectations, especially when making changes to the project.
A change in the project’s scope is a stress test for trust. Clients are not afraid of changes; they are afraid of unpredictability. My task is to make the change process as transparent and controlled as possible.
To achieve this, I have implemented the following practice:
- CR board in Notion or Jira: recording all client requests with indication of status and estimated completion times.
- Influence map: each change is accompanied by a description of its impact on timelines, budget, and dependencies.
- Time reserve: up to 20% of time is allocated in the technical assignment for making changes.
The transparency of change management directly affects customer loyalty. If within 2-3 business days the customer receives a clear plan and options for action, the likelihood that they will give a high score in NPS is 30% higher. Feedback is collected through CSAT surveys after each release, NPS surveys quarterly, and individual interviews with clients.
Clients often note: ‘You give us a choice and do not delay decisions.’ Predictability of changes and open discussions of risks become factors of loyalty.
Hybrid methodologies: adaptation to reality
Agile is a tool, not a religion. In some projects, pure Scrum starts to work against efficiency, especially under strict regulation, external approval cycles, or a large number of third-party contractors.
A transition to hybrid models occurs when the frontend or backend is tied to a third-party team with a fixed schedule, there are stages that cannot be executed iteratively (for example, integration with APIs of government bodies), or business requirements are approved by external legal or financial departments.
We had a project for a financial platform from the EU, where the client side was developed using Scrum, and the backend integration was done via Waterfall. We implemented a hybrid model: frontend — short sprints, demos, reviews. Backend — milestones with clear documentation, signing, and regular synchronizations. Everything was combined into a single roadmap with notes indicating where iterations occurred and where phases were.
As a result, it was possible to avoid “breaks” between sprints and integration deliveries, and the team understood where to demonstrate flexibility and where it was better not to touch the architecture. The team was explained that hybrid is not a rejection of Agile, but a mature adaptation to the realities of the project: “We are not sacrificing flexibility; we are directing it where it is needed. A project is not a template; it is an ecosystem. And our task is not dogma, but a result.”
Risk management: culture, laws, and time zones
A multicultural project is not just about different languages, but also about different styles of decision-making, responsibility, and attitude towards risks. It is important to realize this as early as possible. I take the following factors into account:
- Time zones: work in overlapping “windows of availability”. Key daily and overview meetings take place from 11:00 to 15:00 European time.
- Legislation: at the data collection stage, a compliance mapping is created (especially in projects related to personal data, medical, or financial data – GDPR, HIPAA, ISO).
- Culture and hierarchy: cultural briefings are held within the team.
Often underestimated risks include:
- “Invisible hierarchy” with the client: agreement with the product manager, and then a “turn” of the decision in favor of a silent stakeholder.
- Misunderstanding of local holidays and traditions: for example, Ramadan or local holidays in Eastern Europe.
- Asynchronicity in decision-making: part of the team works in Agile, while another part follows Waterfall documentation.
In one project for a fintech startup from the UAE, the backend team was located in Egypt, the frontend in London, and the design team in Moscow. The Egyptian team did not ask clarifying questions so as not to ‘show weakness’ in front of the client. As a result, two sprints were spent on ‘unnecessary’ development.
Solution:
- Before each implementation, we introduced a format of clarifying questions and answers;
- We conducted personal conversations, explaining that ‘to clarify is a responsibility, not a weakness’;
- We added mini-documents with questions that ‘can and should’ be asked.
In two weeks, the level of engagement increased, and the number of revisions decreased by half.
Soft skills: empathy, communication, and trust
When you work with a distributed team from several countries in different time zones, the technical task is not the most difficult. The most important thing is communication, which is built on clarity, trust, and rhythm.
Critical interpersonal communication skills:
- The ability to “switch” between roles: transforming technical, design, and commercial languages into a unified language of priorities, risks, and solutions.
- Speech frameworks: using phrases aimed at identifying key needs and setting priorities.
- Open formulations, without pressure: identifying the reasons for delays and finding solutions without escalating tension.
There was a case when a designer from London was creating the UI according to British standards, while a developer from Eastern Europe complained that it was “too unconventional, the frontend can’t be assembled without hacks.” A passive conflict began in the comments. I had a brief call with each of them, after which I organized a 15-minute “between the lines” session where each explained why they needed a particular solution. After that, we collectively chose a compromise solution — the UI was adapted, and the developers saved time.
Regular informal meetings, public recognition of achievements, and visualization of progress are important for maintaining engagement in distributed teams.
Integration with Legacy: acknowledge the existence of limitations
Integrating with legacy systems is almost always a walk on thin ice, especially in international projects, where ‘touching the old’ can mean dependence on outdated APIs or lack of documentation.
To minimize risks, it is important:
- Technical discovery prior to launch: the stage of reverse engineering or API mapping.
- Sandbox model: test harness, even if partially emulated, if production cannot be touched.
- Failure and rollback scenarios: a prepared rollback plan in case of failure.
- Clear division of responsibilities: documented and agreed information about the areas of responsibility of the legacy system and the team.
As part of one project (B2B platform for logistics in the EU), we integrated with an internal warehouse accounting system developed in 2008, without up-to-date documentation and on an old version of the SOAP API. During the integration, requests to the API would “hang” for 4-6 seconds, and under high traffic, timeouts occurred, and the documentation did not match the actual behavior of the methods.
To get out of the situation, we involved the client’s technical specialist to manually restore part of the logic, separated the frontend and integration components (with the creation of a mock API), implemented an intermediary layer for data caching and error handling. At the same time, the whole team was working under the Scrum methodology, but a waterfall model with a phased approach and manual control was introduced for integration.
Legacy is not a technical problem, but a management issue. If you acknowledge the presence of constraints, they can be incorporated into the plan. If you ignore them, they will return as bugs and missed deadlines. My rule: do not automate chaos until you understand how it is structured.
PM of the future: AI and empathy
With the development of artificial intelligence and low-code platforms, many routine tasks in project management are being automated. The role of the project manager is changing: from a ‘task manager,’ they are becoming an architect of interaction and solutions.
In the future, the PM needs to:
- Sense-making: the ability to structure chaos and highlight the essence.
- Skills in facilitation and trust-based interaction: conducting sessions with clients and the team.
- AI literacy: understanding where AI helps and where it harms.
- Metaposition: the ability to see a dynamic system of interests in a project.
I see that the role of the project manager is rapidly transforming even now. We are moving from a ‘task manager’ to an architect of interaction and solutions. And this is just the beginning. Currently, I am using GitHub Copilot, GPT, and LLM agents to sort tickets, create documentation, and draft plans. This saves 3-5 hours a week.
The project manager of the future is not someone who simply ‘keeps an eye on deadlines.’ They are the link between speed, meaning, and empathy. AI will replace processes. But trust, intuition, and the ability to negotiate in conditions of uncertainty will remain with us for a long time.
In conclusion, I would like to emphasize that managing international projects is a complex and multifaceted process that requires project managers not only to have technical knowledge and mastery of tools but also to possess well-developed soft skills, the ability to adapt to cultural differences, and to find common ground with teams spread across the globe. It is precisely these qualities — from the ability to foresee risks and react flexibly to changes to the capacity to build trusting relationships and communicate effectively — that enable project managers to avoid getting bogged down in routine and to successfully handle international tasks.
In the era of rapid development of artificial intelligence, when routine tasks are being automated, the role of the project manager becomes even more important and responsible. From the ability to use AI to improve process efficiency to the capacity to see the living people and their needs behind the numbers and graphs — it is these skills that will define the success of the product manager of the future.
A project manager is an architect of interaction and solutions, capable of creating value for the client and inspiring the team to achieve common goals. And remember that even the most modern tools cannot replace empathy, intuition, and the ability to negotiate in conditions of uncertainty, as it is these qualities that allow for building long-term and trusting relationships, which are the foundation of any successful project.
