Crusades in Large-Scale Projects… And How to Avoid a Brawl in Latvia

Source: Äri-IT Autumn 2019

Authors: Marek Maido, Marketing Manager at BCS Itera, and Kristina Ilves, Head of Quality and Methodology at BCS Itera

Just as every family has its own customs and traditions, so too do companies have their internal culture and rules (or lack thereof). Add national cultural peculiarities to the equation, and you have the perfect recipe for a full-blown battle.

A multi-stakeholder software project places high demands on both the client and the implementers. Things get especially interesting when the client has multiple interest groups involved, such as parent and subsidiary companies in different countries. How do you ensure one hand knows what the other is doing—and agrees with it? How can you prevent conflicts in both the solution and the relationships? And how do you untangle them before a Gordian knot forms?

Rule 1: Who Manages the Project and How

Everything starts with the right methodology and a solid project plan. International project management methodologies weren’t invented for nothing. Beyond the fact that they help you systematically reach your goals, they first and foremost provide a common set of rules and a communication framework for all parties.

A couple of tips:

1. On more complex projects, one party must be the main contractor responsible for monitoring, coordinating, and supervising all activities, deadlines, and quality. In other words, they are authorized to lead. At BCS Itera, we’ve seen firsthand the old truth that a project is only as successful as its weakest link. In large-scale projects, all parties can be held up by one participant, as subsequent activities depend on their work being completed. If one development partner can’t or won’t stick to the agreed-upon development rules, deadlines, and quality, it’s the main contractor’s duty to step in and, if necessary, pause the project. It’s crucial to find out why agreements are not being followed: is it an incompetent partner who needs to be replaced, or were the expectations unrealistic?
2. For the leading partner, it’s essential that they are familiar with business software implementation and methodologies and have experience managing similar projects. Ideally, the leading partner is the one who plays a central role in creating the overall solution.

Note: The client should never be in the leading role. Experience shows they usually lack the time, as well as the technical and methodological knowledge, to handle complex issues.

Rule 2: Communication

Even before the project begins, you must agree on roles and communication rules. As with any project, the success of a multi-stakeholder project depends equally on the client and the implementers. Are the participants dedicated, professional, following the shared rules, and actively collaborating? If something is lacking, conflicts are quick to arise. Often, those responsible don’t look in the mirror to understand and fix the root causes of the problems; instead, they focus on the consequences—the tip of the iceberg. In our culture, direct communication is highly valued, so you shouldn’t be afraid to say things as they are.

A couple of tips:

1. Agree on communication tools and milestones. It’s not enough to agree to be open, friendly, and talk. Projects need “meeting points” or milestones, specific communication channels and chains, and agreements on when and to whom to report. All parties must report on their achievements and the status of their work. This is ensured through weekly project meetings, memos, status reports, the project plan, and so on.
2. When problems arise, inform all parties immediately, clearly, and loudly. In our daily work, we often see a back-and-forth email exchange between a couple of people for weeks, or phone calls, while the decision-makers and the client know nothing about it. When major obstacles or problems appear, you must convene all parties, including the client-side decision-makers, and agree on who will do what, when, and how it will affect the project’s progress.

Rule 3: Estonians, Latvians, Lithuanians

In pan-Baltic projects, the client’s internal communication is often a challenge, as the cultures in these countries are surprisingly different. The problem usually stems from two things: first, the head office in Estonia often informs its “apple-tree neighbors” (subsidiaries, departments, affiliates) at the last minute; second, the parties often have different understandings of what, why, when, and how something needs to be done. In the worst case, a guerrilla or civil war starts, which halts the project and creates tensions.

How do you find common ground and an optimal approach when the group, a subsidiary, and a sub-subsidiary have different understandings of the solution? If the goal is a profitable solution, not just blindly following an order from above, the only way is through negotiation!

A couple of tips:

1. Start the project with a party in Latvia or Lithuania (or both). This might seem like an odd suggestion, but many problems are solved at the party table before they even begin. The message is that we are not going against each other; we are going into battle together.
2. Agree at the very beginning of the project on what, why, when, and how you will do things. This is where you should definitely involve the leading implementation partner, who can help explain the wins, present the work plan, and identify the expectations of the company’s leaders. The partner should generally have experience in how and what to communicate.
3. The client’s management must have the courage to make decisions. Every company knows best what its management rules and decision-making chain are, but it’s very common for top management to be unwilling or afraid to make a final decision. This “democracy” can last for years, with the leaders of the southern subsidiaries “rebelling” against the changes.

Today’s projects have become much more complex because of cultural and functional differences, and a large number of people must be able to collaborate—to work as a team. At the same time, every organization has a unique culture. It’s important to understand that in most cases, culture isn’t completely right or wrong—it just is what it is. The cultural component and understanding are especially critical when you go more than 500 km away.

Therefore, project management, experience, and shared rules are critical success factors in more complex projects.