Organizing Overseas Teams

Hi, I’m Zacharias Beckman, president of Hyrax International. When it comes to coordinating international projects, one of biggest challenges we hear about is staying on top of the project.

As an international project manager, you have to know how to stay organized, and you need to know what your team is doing. When you have several different teams, all spread around the world, that’s not always easy. You also need to make sure that one of your teams isn’t being held up, waiting on another team.

This is what Tanya ran into, at one of our clients. She had been managing a U.S.-based team. Her company had just bought a smaller firm in India, intending to set up a “follow the sun” strategy. With teams in the U.S. and India, they could move faster because one team would hand off work, at the end of the day, to their overseas counterparts.

But there was a problem. After a few months efficiency was falling, not improving. Tanya found that the teams were poorly coordinated, and more often than not one would end up waiting on the other one. Tanya needed to change her strategy to accommodate a global team. She had to refocus, and figure out how to get these teams collaborating smoothly despite a separation of over 10 hours.

She made two major changes, both of which focused on improving coordination.

She took a critical look at their project management system, and decided that it wasn’t up to the job. It had worked great when everyone was in one office. But now it had to deliver a new level of coordination. She needed something that could better drive the process, improve visibility to her management team, and show dependencies between team members. It was absolutely critical that everyone know, at any time, who was waiting on them. They also needed better requirements management, and better collaboration tools. Her new system gave them the tools, but it couldn’t solve the communication issues on its own.

Tanya also changed the team schedule, setting up short, collective meetings every day. To avoid burdening one team, she set a rotating schedule: meetings where held at 9am in the US twice a week, and 7pm twice a week, with no meeting on Friday. Team members had to join at least two meetings each week, but it was up to them to pick which ones.

Tanya’s changes showed almost immediate results. The teams became more coordinated, and situations where one team was held up waiting for another pretty much vanished.

In a multinational organization, it’s important to remember that remote teams can feel like they are in a vacuum, lacking communication or cut off. To compensate, a good manager has to be extra vigilant and put in good processes, and good tools, and also make sure that no one team becomes the favorite. Tanya spread the meetings out to share the burden of after hours meetings. By doing so, she also sent the message that both teams are equally important.

Dealing With Timezone Differences

Working in the global economy means spending lots of time connecting with clients and colleagues on the other side of the world. But multinational teams also face “multi-timezone” management problems. What seems like an obvious, potential problem can cause management nightmares for multinational leaders. Here are few tips on how to deal with time zone differences and build smoothly functioning, multinational teams.

Hi, I am Zacharias Beckman, president of Hyrax International, and today I want to talk about dealing with timezone differences. In my work, I’m frequently fixing problems with projects that have gone off the rails. That often means a lot of travel — going to international partners, finding out what’s wrong and fixing it. And when I’m traveling, then — that means being able to collaborate with my team, back here in the United States, is also a problem.

Timezone Challenges For Teams

Focus on finding a method for seamless communication, throughout your entire company, worldwide. You want your teams to break down barriers. You don’t want a team here to be thinking “Oh, I just cant call the other team because they are in different time zone, they’re half way around the world and I can’t bother them.” You do want them to pick up the phone and call or use Skype or whatever it is. The teams need to get to know each other. One way to do that is through co-location. Bring the foreign team home for a while. Or, send some of your team members there, so that you can build a tighter relationship.

But when co-location isn’t an option, you can turn to frequent short meetings — by phone, by Skype, it doesn’t matter. It’s the frequent contact that helps. It breaks down barriers so that the teams starts to operate as a single team, not as a bunch of different team separated by distance and culture. You don’t want your teams to feel distant, because then they are going to act distant.

The other thing you want to do is work on implementing collaboration tools that work really well with remotely located teams. So, project management systems that are easy to access, information radiators and easy to use communication tools. Plan your work days to overlap a little bit. It wont do to have your team in India working from 10 to 6pm and your team in the United States working from 9 to 5 because there is no overlap, there’s no communication. Instead adjust schedules a little bit on each side and try to have about an hour or so of overlap, so that your team can then have a daily or semi-daily stand up meeting. The idea is just to get everyone on the phone and in the virtual room together, so that they can find out what happened on the other side of the world and the they can ask the other team for what they need in order to move forward. The frequent contact and the direct connection is going to go a long way towards breaking down barriers between the team and making them more efficient.

But the meetings are short. They are just to touch base. They’re there for one team to let the other one know what happened and what they need so that they can move on and make progress, the next day.

Tackling the global project problem, part 2

In my last article on preparing for global project challenges, I addressed a few of the more soft skills oriented issues such as cultural differences and basic mismatches in business environments. For this second installment, I thought I’d share a few concrete ideas for tackling some of these issues — things that can make a real difference, and aren’t that hard to put into play. To keep on a theme, I’ll focus on strategies to tackle the common, core issue raised in my first article: communication and execution problems.

Recap: Face up to communication problems

Last month I pointed out that we have to deal with a lot more than language barriers with global projects. For example, in some cultures, speaking openly is not to be expected, in any setting. Furthermore, communication is often strongly augmented with non-verbal cues that simply don’t come across the telephone or email channels. The very method someone uses to communicate often carries an important message in and of itself — “reading between the lines” and picking up on the myriad of non-English, non-verbal hints is critical. It takes time and often a great deal of experience on an individual level.

Doing everything we can to remove ambiguity from project communications can be a huge help. One of the first things I generally want to take a close look at are the techniques and processes used to manage a project. Most of the time, they are not adequate for one reason: They weren’t designed to support a global, multi-cultural organization.

Tools do help

Let’s consider some of the common problems stemming from communications issues:

  1. Assignments don’t get handled correctly
  2. Nobody seems to know what’s going on
  3. There is no single place to go to find out how well (or how poorly) things are going
  4. Sometimes people don’t seem to be working effectively
  5. Things that aren’t important get attention, while things that are, don’t

These are problems that almost every organization has dealt with at some stage in its life. The typical global project almost always faces them, and often, fails to address the root cause, and then keeps right on stumbling over the problem. Making a few strategic changes to your process, and your tool set, can help dramatically.

Use the right tool for the job

I’ve seen many organizations use email inappropriately. Email is easy to fall back on as the main communication avenue when everyone isn’t in the same office building. For example, I’ve seen engineers jump in response to a new product idea from the CEO. This leads to circumventing the project management effort, often misdirects the lead engineer, and easily puts a project off-track. After all, what’s an engineer going to do — tell the CEO to go through channels and keep working on today’s mundane task, or jump on a new, exciting idea straight from the top?

Equally damaging is responding to every customer “fire drill” that comes up. Email invariably leads to rapid-fire emergency drills, often at a very high cost. Customer service sends an email to engineering, and engineering jumps to respond — in the process, putting current tasks on hold and upsetting schedules (not to mention the engineers themselves).

Stop using email for project communications, requirements, design and, above all, assignment of work. Email is a fantastic communication tool — but it’s not the right job for communicating work items on a project. It has a poor audit trail, as you never know who did or did not read it, emailed tasks cannot be prioritized or captured in a work management system, and at the end of the day, they’re just unreliable.

Instead of trying to stay on top of a dynamic, changing organization with email, use an appropriate work management system. There’s great news here: In today’s market there are fantastic systems available to handle requirements management, task management, project planning, customer communications, resources and more. In fact, probably the most daunting challenge is simply getting enough information to make an informed decision and choose the right tool. Cost is always a concern, but make sure adequate due diligence goes into analysis of the tools. Picking the wrong product can easily create problems. For instance, some tools may work well with your project management process, whereas others may not fit smoothly. In this latter case, people end up working outside the system — and that usually means sending emails to each other.

Use the right estimation methods

Also critically important in a global project context is taking a long, hard look at the techniques you follow for project estimation. Make sure that your estimation methods take into account the complexities of a global team — this means accounting for inefficient communication and dramatically variant resource cost.

Be wary of estimation methods that focus only on the short term. “Burndown” estimates that provide visibility into the next thirty days are a leading source of project overrun and schedule slippage. An appropriately planned global project needs to communicate the goals of the project throughout the team. This includes setting very real objectives and milestones. If the milestones are variable and tend only to establish goals in the short term these become the only measures of success for the team — in other words, hitting the thirty day goal means success, because other yardsticks have not been established.

Wildly variant resource costs must also be accounted for. It’s one thing when every engineer gets paid more-or-less the same salary. When facing a dynamic, global team where costs can vary by a factor of ten, cost overruns become a very real threat. Simple estimation methods such as burndown estimates neglect these issues on two fronts. First, they don’t establish an adequate project baseline, and second, they don’t measure resource cost and progress against the baseline.

Make sure that the estimation methodology you use is adequate to the project at hand. Keep “burndown” estimates confined to projects that are either free of cost constraints, or at least operating on reasonably small budgets — so that cost overruns won’t hurt the organization.

Pay close attention to metrics — and metrics tools

Metrics tend to be a sore point with many teams. Mostly, at least in my experience, this comes from the assumption that measuring and keeping on top of project status requires a lot of work, and requires capturing a lot of data that nobody wants to capture. This is just plain wrong.

The fact is, almost every organization I’ve worked with is already capturing the data they need. It just isn’t being used right. The basic information needed to estimate tasks and monitor progress of the project as a whole is usually already in the system — it’s just a matter of getting at the data and building the right kind of reports. For example, most popular project management tools that tout themselves as being “agile” tend not to bundle reports for EVM metrics, baseline comparison, and project cost overruns. This is certainly the case with Atlassian’s JIRA, an excellent product that I’ve frequently put to use on large scale projects. Fortunately, the data recorded by systems such as JIRA gives us everything we need to perform more advanced metrics analysis. We know the original task goals, it’s planned schedule and it’s actual schedule, and can derive planned cost. That’s all we need.

Staying on top of the metrics and measuring against original project baselines translates into a very tangible return: You know your project health at any point in time. You know if you are slipping the schedule, if project cost is increasing, if too many changes are being made, or if too many defects are being discovered. If you can’t answer these questions you aren’t on top of your project.

Prioritize and balance dynamically

Finally a note about traditional, static project planning. Project plans are out of date before the ink is dry. Make sure that your project management process and your tools take this into account. Whatever tool you are using, it needs to generate the supporting project artifacts for you — not the other way around. In other words, if you find yourself wondering “how can I keep this Microsoft Project file in-sync with the project,” you’re looking at the wrong end of the equation. Instead, your project tools should be constantly in-sync with the actual state of the project — and if you’re favorite view of the project happens to be a Gantt chart, then your project tool should spit out an accurate one at the click of a button. Let the computer do the number crunching and formatting. You need to concentrate on managing the project, the people, and the global organization challenges that your team faces on a daily basis.

Creating a truly collaborative, communicating team cannot be accomplished with tools alone. While the tips I’ve offered above are sure to help, they won’t address all of the challenges a global project team faces — but they will give you a starting point.

Tackling the global project problem

Launching a global project presents many problems that are completely foreign to most project leaders and managers. The global community offers an incredibly diverse landscape of culture, language, social interaction, and business preconceptions. In most situations this varying landscape leads to conflict or, at the very least, misunderstandings and miscommunication.

Each project reveals something new, sometimes subtle, sometimes much more obvious. While writing Outsourcing in the BRIC: Being successful in global projects with Brazil, Russia, India and China, understanding each situation and turning it into a tangible, applicable lesson was often a complicated exercise.

In this article, the first of several, I’ll present a few of the lessons learned — not necessarily the most prevalent or the most important, but lessons that I think most teams will run into pretty quickly and could derail you from the start.

Face up to communication problems

By far the most common, most glaring misstep U.S. employers make in foreign markets is to assume that people, by and large, aren’t that much different. It’s a mistake I’ve seen in almost every situation, whether the global team is Russian, Indian, Asian, or South American.

In the U.S. we have become very insular, expecting behavior from our workforce that simply doesn’t exist in other cultures. For example, we take for granted that employees will be outspoken and even downright vocal about anything they aren’t happy with. “The squeaky wheel gets the oil,” as the saying goes. But as it turns out, that saying doesn’t apply to many cultures. In fact, the global project manager needs to recognize that in some cultures, speaking out is not to be expected, in any setting. This has come up with almost every outsourcing effort I’ve managed throughout Asia: People will contribute extensively or not at all, depending on the culture.

One strategy to begin overcoming this problem is to initiate collaboration up-front. This can be a particularly effective tool for establishing peer relationships early in the game. While speaking out is not a given, it’s almost universally true that people open up to their peers before opening up to managers. Initiate your project with a two-day collaborative session to drive interactivity. Be sure to stage the session appropriately. It has to be at one location, the entire team should be present, and the environment should be tailored to create effective, collaborative conversations. Remember, it’s more about building the team than about making real progress on the project.

Be sure to continue facilitating collaboration once the exercise is over. If you don’t work to break down barriers constantly, they’ll crop up again — probably the day after your exercise ends. Make sure the team has the right tools to establish effective communication. Try to arrange team schedules that facilitate frequent communication. Develop an on-going staff rotation plan to make sure the team is constantly getting “refreshed,” and working together on a regular basis.

Beware differences in business fundamentals

Just as varied as individuals are the business environments. Consider, for example, the complexity of developing a product in a foreign market, with most of the team speaking a foreign language, with common business knowledge rooted in a foreign business environment. Many of the assumptions that we take for granted are simply missing, or interpreted differently in other countries.

Often a good starting point is to look for regulatory and risk management profiles that will identify potential differences of understanding. Compliance requirements are often taken for granted in one market and completely missing in another (think of COPPA, the Children’s Online Privacy Protection Act, a U.S. law that dictates certain standards for any system storing information related to a minor). Many such standards, laws, and policies exist and are well documented — particularly in Western nations — but are never explicitly communicated to foreign teams where such laws do not exist.

Another common problem: People who understand the technical aspects of a project, but not the application of the product itself, often work “blind” to project quality goals. For example, I once worked with a client developing a legal work product in the United States, but most of the work was performed in India. None of the Indian team members had a solid business or legal background, and even if they had, it would have been based on Indian business law. As a result, most of the team had only a vague idea of what the product would be used for, and none of them understand the target customer.

Be ready to reset perceptions

Depending on your market, your product, and your overall goals, don’t be surprised if there are a few false starts. Engaging a global partner is not something that will succeed or fail in less than 90 days. Having a short-term perspective and focusing on the tactical, rather than the strategic, will doom the effort to failure. Because of the multitude of barriers — from culture, to language, to geography — expect to take time to develop a lasting, successful relationship.

Likewise, when developing a product in the global marketplace, don’t be surprised if it’s necessary to restart the project once your client or partner really begins to articulate what they need. If the project was initiated in the U.S., its inception was probably isolated, initially developed in a silo. Assumptions regarding foreign markets, realistic business objectives, and misconceptions about global performance are likely to be re-examined.

Monitoring a global project is clearly much more complicated than a domestic project or one that runs entirely out of a single building. Make sure the right key performance indicators are being measured, and stay on top of them. Keep a careful eye on communication throughout it all. Once the gaps have been closed and a collaborative environment built, successful, frequent communication will drive creativity and results from foreign markets — while failing to have good communication will create isolated, poorly performing teams. Even though you operate as a global business, try to remember what it felt like when everyone was in the same building, and keep that feeling alive as much as possible.

Managing risk in global projects

I was recently asked what are the most relevant, pressing risks that affect global project management. Many come to mind but one stands out immediately: One of the most significant risks we identify is a globally disparate (geographically separated) team. Teams working in separate regions face tremendous challenges that a co-located team doesn’t have to think about. This is exacerbated when outsourcing, where conflicts in language, time, culture, and business environment all affect the organization.

Organizations facing these environmental issues need to put a considerable investment into mitigating the associated risks. This is essentially why the “promise of outsourcing” has been toned down over the past decade: Gone is the illusion that you can get solid work for 25 cents on the dollar. “Real” outsourcing costs tend to range anywhere from 70 cents on the dollar to $1.20 on the dollar (yes, outsourcing can often lead to higher costs — but sometimes it’s not just about cost, but geographic presence, distribution, foreign market penetration, etc.)

Language barriers pose some of the most difficult issues to work around. Being unable to easily communicate means poor communication becomes a barrier to the entire team. This can lead to misunderstood requirements, misinterpretation of directions, even a complete disconnect on whether a team is in trouble or doing fine. Ideally, open communication, information radiators, and visibility are central to successful projects. Any barriers increase risk, and that means increasing efforts to compensate. Closely related to language barriers are cultural barriers. A pretty obvious example is the straightforward U.S. business culture in regard to the respectful and tradition-rich Japanese culture. Even seemingly similar cultures pose barriers; for example, East Indian cultures and U.S. cultures don’t easily connect until interpersonal barriers have time to break down.

Business environment and common bias also contributes to the risk of disparate teams, especially those separated by business culture. For example, consider a client developing a legal work product solution in the U.S. market while using East Indian resources. The lack of a common business foundation can easily lead to a complete disconnect regarding assumed business objectives (in other words, the legal system is very different in the U.S. versus India, which means a lack of common understanding regarding some pretty basic business goals).

All of these issues can be mitigated with appropriate practices. The necessary measures will vary from one project or organization to another — there are a lot of variables at work, and that means every project has to be treated uniquely. The common thread is communication. Breaking down these barriers by using process, technology and culture is critical. The disparate team needs to become one team, working as a unit — and that usually means a significant investment in tools, strong processes and team-building exercises. I strongly advocate rotating team members across the organization or project as one example. This helps across the board: It breaks down communication and culture barriers, helps team members get to know one another, lets distant teams experience local culture, and helps to build a collaborative “whole team.”

Not a panacea, but trying: Comindwork is attractive

Management tools probably don’t bring to mind excitement and visions of “getting things done” the agile way. Nevertheless, it’s an important aspect of running any project — whether agile or not — and there are some tools, believe it or not, that are easy to use, hugely helpful in managing a project and sometimes even a little bit of fun.

One such tool is comindwork.com, a fabulously rich project management software as a service (SaaS) site. While not right for everyone or for every situation it’s definitely worth taking a look at.

Comindwork combines over 250 project management related capabilities under one roof, yet does it with a web interface that is, by and large, a breeze to use. Some of the strengths of the service include traditional project management tools, knowledge management, collaboration tools, information sharing and versioning, and both agile and traditional waterfall management tools (e.g.: think Gantt).

The entry point is easy, and that’s another strength for comindwork: A small team can get started for somewhere around $20 a month (for teams of 10 or fewer, it’s $1 per day that you actually use the service — if nobody logs in, it’s no charge). This offers up a wealth of really advanced tools at a fraction of the cost of most large scale management infrastructure. For companies that don’t have a system in place, it’s easy to give comindwork a spin.

Here are a few of the things I like about comindwork.

It all starts with the personal dashboard. I’m a huge believer in personal (meaning, customized and personally relevant) dashboards, especially if they follow the basic principle of “Getting Things Done” methodologies. Distraction is bad, focus is good:

201002041521.jpg

With the project dashboard, you can:

  1. Get a bird-view on all activities where you are involved, see who changed what and when
  2. See your nearest milestones
  3. Check team members’ status and mood
  4. Easily access detailed project-specific dashboards

It offers both traditional (meaning, typically, “large scale”) project management and agile management philosophies living under one roof. At first glance I was taken aback by any system that can claim to offer this mix of tools, but comindwork manages to pull it off. On the traditional side, there are Gantt charts and round-trip import and export of Microsoft Project files, not to mention a whole host of reporting capabilities. On the agile end of the spectrum, to-do lists, tasks and very easy time tracking support simple progress monitoring. Unfortunately, burndown charts have yet to make an appearance, although there’s enough information available that they may not be entirely necessary.

Knowledge management and collaboration are central to the product. Blogs, to-do lists, milestones and business wiki support which codify and share tacit knowledge are tightly integrated into the project. In fact, one of comindwork’s strengths is that so many services are so tightly integrated. For example, linked business wiki entries, tasks and time commitments can be shared and kept up-to-date, with progress being reflected in round-trip Gantt tracking in Project. Notifications of all activity take place automatically, sending out instant email messages or daily digests that summarize project activity.

One of the problems I’ve run into with customers that have no pre-existing system is simply keeping track of all the project artifacts and versions of each. With email flying everywhere, documents being authored, and half the team not knowing how to use source management repositories, how can you hope to keep track of every artifact the team produces? I like to implement a policy of “email doesn’t exist,” but this means you need a tool that’s going to support the policy.

In other words, if someone wants to get something done, it should be in a system, not flying around in email. The idea of half a dozen versions of a document living on everyone’s desktop is just unacceptable to me. Comindwork provides file versioning and drag-and-drop upload. This makes it possible to implement the “email doesn’t exist” policy, and comindwork does a great job of delivering an easy to use tool:

201002041446.jpg

Having a convenient and ubiquitous place to store project artifacts makes it easy for the team to share, manage, and collaborate. Comindwork put enough effort into the interface that it’s not painful:

  1. Create a convenient tree-structure of your documents
  2. Make common actions on a set of files (mass-delete, mass-move)
  3. Provide comments to any file version
  4. Versions are stored automatically whenever you upload a file with the same name. Check all revisions and easily revert if required
  5. Use drag & drop area for native multiple files upload

You can even email files directly to a folder in your comindwork project.

For more demanding projects, you can design custom workflows to support the security, policies and customer demands of the project. This is an essential tool in my mind. Any project management solution needs to be able to grow with the project. Custom workflow makes it possible:

201002041515.jpg

You can create graphical representation of your business process, modify the process with appropriate business rules and make sure your project is enforcing necessary policy:

  1. Define, control and track states and transitions in your business process
  2. Encourage process automation and standardization
  3. Break your business process into easy to follow step-by-step workflow diagram
  4. Reconfigure your business process as needed
  5. Clearly define your business process and avoid miscommunication and inconsistency

If you’ve been casting about looking for how to get project tracking off the ground, take the quick tour and see what you think. It’s not a panacea that will fit all project’s needs, but it is a very solid tool that’s been seeing a lot of success lately.

If you decide it’s not for you, take a look at Atlassian’s JIRA too. JIRA is by far my favorite project management tool, especially if you’re agile-oriented. It requires a bit more of an up-front investment to get off the ground (both in terms of deployment and financial cost), but in my opinion, it’s one of very few first-rate tools available today. I’ve been trying to finish a detailed article on JIRA for some time now, so check back in a bit.