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.

Don’t Use Basecamp

Hi, I’m Zacharias Beckman, President of Hyrax International. Managing a multinational team can be really challenging. You have to make sure that each team, around the globe, is coordinating their efforts. That means overcoming the communication problems between them, tracking task dependency from one team to the other, and staying on top of projects — so that one team doesn’t get held up waiting for another one. So, the real challenge is figuring out to stay on top of each team and how do you make sure that all of their activities are coordinated well.

Get The Right Toolbox

Part of the answer is making sure that you have the right tools for the job. A good project management tool is going to help coordinate team activities and tasks around the globe. With the wrong tools in place, project teams suffer. They don’t have good communication, they don’t understand what the other team is doing, and task dependencies — the handoff of activities from one team to the other team — is not coordinated well. You end up with project chaos.

And when you’ve got team members that are separated by 8 or 10 or more hours in a day, this can derail the entire project for more than a day at a time.

We have two “go-to” tools that we use all the time very successfully. And we also have one that is a project nemesis. The one that we don’t like is Basecamp. We tell our customers, “Never use Basecamp.” The thing with Basecamp is, it’s super easy to use. You can sign up and start using it, literally, in a few minutes. People who don’t like process love Basecamp, because there is no process. You just put your tasks in. It’s easy, it’s unstructured, you can attach documents, and it all goes into Basecamp — and it kind of vanishes into Basecamp. That’s the problem, Basecamp doesn’t drive the process. We need tools that drive the process.

Driving The Process

A great project management tool is going to remind people of what they need to be working on, it’s going to track the interdependencies between tasks, and it’s going to make sure that someone doesn’t get hung up waiting on somebody else. This is particularly important for multinational teams where communication is already an issue. We need tools that will fill that gap and work hard to coordinate these teams, because they are already distributed, they are already having a hard time coordinating.

For small companies we recommend Teamwork PM. Teamwork PM is a good step towards an enterprise grade project management tool but it doesn’t have a lot of overhead. Your team can be using it in no time at all. It does coordinate tasks really well between team members, and it tracks dependencies, and it notifies team members of what they need to be working on. Which is one of the key ingredients to success.

For mid-sized and large teams, we recommend Atlassian Jira. It’s an enterprise grade solution. It’s completely customizable workflow system means that you can build out really elaborate, powerful processes to support your team and to support your entire organization. Jira can be customized to go all the way from requirements management and development through to customer support and care.

There are lot of great tools out there, Teamwork PM and Jira are two of them. But the most important thing to remember when selecting your project management tool — make sure it drives the process, make sure that the Project Manager is going to be able to easily get the information they need out of the systems so that they can stay on top of the project — before problems start to crop up.

Be sure to check our website. On this blog post we’ve listed a number of other project management tools that we have used in the past in addition to Atlassian Jira and Teamwork PM.

Our Project Manager’s Toolbox

Here are a few of the project management platforms that we feel are worth taking a look at. We couldn’t recommend Atlassian JIRA (for mid- to large-size organizations) and Teamwork PM (for small-size organizations) more highly, but they clearly aren’t the only solutions on the block. We track close to fifty different project management tools — these are the ones that have risen to the top, in our opinion.

  1. Atlassian — JIRA, Confluence, ServiceDesk for a complete enterprise solution
  2. Genius Project — Traditional, full cycle portfolio and project management platform
  3. Herogami — Agile development with Kanban
  4. Jama Software — Full lifecycle project management
  5. Liquid Planner — Traditional team and project planning
  6. Rally Software — Agile project management platform
  7. Teamwork PM — Full featured, easy to deploy task and project management

How Do I Communicate With My Overseas Team?

When it comes to delegating work, how can you communicate tasks to your overseas team, and know those tasks will be handled reliably? Communicating with your overseas partner or your outsourced vendor can be a lot more complicated then you might think.

Communicating with your overseas partner or your outsourced vendor can be a lot more complicated then you would think. Yes, sure, it’s fine to pick up the phone and send an email — and actually you should do that a lot. It’s extremely valuable to build those strong relationships and to maintain a lot of communication with your overseas partner. But, its easy to make mistakes when you assume that they are going to be communicating with you in exactly the same way.

Assumptions And How We Communicate

So, for example, we have had clients that would pick up a phone and call their Chinese or their Indian partner to brainstorm about ideas. But, because of misunderstandings between the two parties and between power distance and saving face, the partner over in China, or in India, might take that brainstorming session to be a directive to get to work on something. And so they throw everything else out and the schedule goes out with it — and they start working on something new. And month’s later, you’re surprised — what the heck happened? Why are they working on that? We were just talking about a fun idea we had.

Communicate Assignments Without Misunderstandings

So, how do you avoid misunderstandings like that? Well, one of the most important things you can do is make sure that you have a procedure or a system in place to manage tasks, and assignments, and responsibilities between your teams. There are a number of systems that we’ve used with our clients. Some of them are pretty simple. Basecamp is very popular. We actually don’t recommend Basecamp. It’s not too hard to get lost in Basecamp and much like sending a phone message or an email, people can start pointing fingers, saying, “Oh, I thought you had that task,” “No I had that task.” Also, base camp doesn’t have a great audit trail. Instead we tend to recommend more advanced systems that provide better audit trails, better assignment tracking, and permission and workflow systems.

Salesforce, if you are in a sales organization, actually does a great job of assigning tasks to different people, keeping track of records, who made a call, who didn’t, where is that customer support ticket. If you’re in a more technical discipline, then tools like Rally and Atlassian’s JIRA products are excellent project management tools. They can also be used for customer service management, ticket management or even call tracking because they are very customizable. Especially JIRA which has a very powerful workflow management system that you can customize to do whatever you want. But the best thing with all of these tools — Salesforce, Rally, JIRA and host of other ones — they work over the world wide web, they work on mobile phones, and they all have excellent audit trails, so you can see what has happened, who was assigned the task, and why did they give it to somebody else… And they also make it very easy to expose all of this information to anybody that wants to see it.

So, our number one recommendation, when we are talking about how do you get a hold of your team whose overseas, you can get a hold of them on the phone and with email. But you shouldn’t use those methods to communicate tasks or assignments or new requirements. Those things, if its official, it needs to go into a system. And everybody needs to understand that the system is what dictates who is working on what. That way when your team in China receives a call from the CEO saying, “Hey, what about this great idea?” — well, they’ll understand that if it wasn’t assigned to them in the system, they’re not supposed to start working on it.

Why we can’t just burndown everything

Prashad is the project manager for a new product. After reviewing the project scope, Prashad’s team gives it an initial estimate of about three to four months to complete, which is good enough for management. The project kicks off, and using Scrum along with a little bit of project management, the project gets underway. The first month goes quickly, there is great progress, and everyone loves what they see. But in the second month, things start to slow down — so, Prashad adds more resources to the project to compensate. But by the third month, there are real problems and it looks like the project will be late. Prashad adds even more resources. Now the team is almost double the original size. He adds a lot more quality assurance and testing support for the team, too, because a lot of problems are cropping up. The team cranks away, and they finish the project in the fifth month, and claim “success” because they almost hit the deadline (it was, after all, just an “estimate“).

But what about all those additional resources? Is it really success if the project cost twice as much as originally estimated? The problem is, that cost was never formally stated. It was never tracked as a metric, so the fact that the project went horribly over budget is quietly swept under the rug — at least this time. There are plenty of cases where the budget isn’t there, or the resources aren’t there, or the product just can’t ship late.

So, if so many projects are missing their mark, what’s causing the problem?

The fallacy of so called Agile methods

According to studies conducted by KPMG, as much as 70% of projects fail to meet their goals. In this case, “goals” mean quality, schedule, and function (or a combination of those). Clearly, being able to accurately estimate a project’s delivery date is important. Without knowing when a project is done, you can’t predict cost, plan business operations, or dovetail releases with marketing, training, and customer service.

Agile methods like Extreme Programming and Scrum make promises that, in my opinion, they can’t keep. For well over a decade we’ve seen an increasing trend in project failures, and a large number of those failures are the result of “unending projects.” Projects that go on and on, continuing to deliver improvement but slowly creeping over budget and never reaching an end state. Part of the problem is the lack of formal estimation and metrics.

Both Scrum and Extreme Programming dodge the entire issue of project life cycle estimation. They focus on the near term, providing estimates for the next one or two sprints. This works great if you don’t have budget or time constraints, but in the real world that’s rarely the case.

Burndown just doesn’t work

Most Agile methods don’t explicitly define how you estimate progress, but the most common method is burndown — the measurement of completed effort against the planned sprint goals. This is fine for a quick-and-dirty project but as a strategy it utterly fails to pinpoint problems with budget and timeline. For anything larger than a few months effort, it doesn’t do the job.

And the problem is, few of today’s engineers seem to be getting the formal education and training needed to use proper estimation methods.

There are better solutions than burndown

Earned Value Management, or EVM, is nearing it’s 40th year of practice. Throughout this 40 year history, EVM has repeatedly evolved to meet new demands as technology and innovation made new leaps forward. It’s a proven method for measuring progress and it’s been proven time and again.

Of the dozen or so software engineers I spoke with about this article, none of them had even heard of EVM.

Earned Value Management, as well as a variation known as Performance Based Earned Value® (PBEV), are my favorite choices for estimating a project. The PBEV approach provides an incredibly robust method for measuring progress and staying on top of your project. It’s only marginally more difficult than other techniques of measurement. And most project managers are already capturing the metrics needed to make it work.

PBEV is an improvement over Earned Value Management Systems’ (EVMS) national standard. It supplements EVM with guidelines for the integration of project cost, schedule, and technical performance — thus created a comprehensive and highly accurate method for measuring true progress in a project. The key here is integration of effort with schedule and performance.

Had Prashad been using PBEV, he would have had a very different experience. The early estimates would have been more accurate, since PBEV estimates the entire project. It would have measured not only resources and cost, but also the actual performance — the rate at which work is being done. Had the project gone off track, Prashad would have known much more quickly, and would have had a more precise picture of how to correct the project’s course.

There will definitely be situations in which PBEV is not warranted, and a skilled project manager will need to know when to use other methods, and why. EVMS, for instance, addresses only the quantity of work completed, ignoring cost and schedule metrics. The implication here is that a quick burndown or EVMS-based evaluation of a project might look A-OK, when in fact the only reason it’s on track is because resources are being thrown at it — and costs are skyrocketing.

Burndown versus critical path thinking

Burndown is a very simple method for estimating work effort over a short term. It explicitly avoids timeline, cost and performance metrics. That’s fine for projects that are not constrained by time, budget, or resources. The problem is, burndown is used as a defacto standard too often, on the promise that using an Agile method will deliver a project faster or cheaper than its alternatives. I don’t disagree on this front. Agile methods generally are faster and cheaper — but the question is, faster and cheaper than what?

Most business need to be concerned with time, money, and staffing. Projects that have those constraints need to think about the critical path — the sum of all activities to reach the end of the project. Having a solid understanding of the fundamentals of critical path management is important to managing any project schedule. Depending on the nature of your project, you may be able to rely on casual effort estimates — or, you may be required to carefully identify, analyze, and attack critical paths to shorten your project lifecycle and stay within stringent guidelines. Without understanding the principles, and knowing where to turn for more information, neither is possible.

I’ll revisit the topic of PBEV in a future article and provide more depth into how it can be applied to a project. If you’re eager for more information, check out Performance-Based Earned Value®, Paul J. Solomon, Ralph R. Young, IEEE Computer Society, Wiley Interscience, 2007.

What you won’t get out of your certification

When it comes to project management certification, there’s no doubt quite a few options available. The real question is, do you know what you’re getting with a shiny new certification (such as PMI’s PMP, or IPMA’s Level A through D)?

Certification programs are more about demonstrating your competency than about learning how to manage. Consider this: PMP and IPMA certification takes you through a process guide and an examination that you can easily enough prepare for in a few weeks. The process guide itself is a valuable reference, a great way to organize all the possible areas of knowledge in a project — but it’s just that. A process guide is largely a checklist, giving you a tool to make sure all the right pieces of a project are in motion.

The other part of the certification process is the exercise of documenting your experience, as a project manager, and having the certifying organization vet your experience (although the vetting process is often cursory). It’s supposed to show the world that you have a certain level of project management competence. It is explicitly not going to teach you that competency. The real theory behind PMP certification is that by achieving it, you have demonstrated relevant competency as a project management professional. There’s a good bit of debate regarding the value of this certification: How well does the PMI do in vetting experience? Is there any qualitative distinction in the evaluation? I’ve seen a few terrible managers get their PMP by documenting their management of projects that were miserable failures.

For the most part, deciding whether a candidate’s PMP or IPMA certification (or lack thereof) is valuable lies with the employer. For the individual, I always recommend learning the bodies of knowledge, so long as you are fully aware of what you’re getting. Here are a few of the things that either program won’t prepare you for:

  1. Project management is more about management, and less about process. Most of the certification programs out there tend to emphasize the latter, the process, and spend little time on the “soft and fuzzy” bits: People. The fact is, this is where you’ll succeed or fail. It often comes down to how good you are at picking up on subtle (and not so subtle) cues between team members, sponsors, and stakeholders. There is no certification program in the world that will teach you how to be a great manager — that requires experience, more than anything else (but if you have a degree from a top management school it’s bound to help).
  2. The rosy project you just inherited is actually completely out of touch with reality. More often than not businesses will commit to a project that can’t be met (often establishing budgets and schedules in the process). Studies by Standish and KPMG bear this out, pointing at 70% of projects failing to meet cost, schedule, and quality goals.
  3. Identifying all the right pieces of a project is just the beginning. For example, knowing who the stakeholders are (an important step in the PMBOK) is the easy part. You’ll spend far more time motivating them, coordinating their schedules, dealing with stakeholders that want your project to fail (or just don’t care about it), responding to impossible demands, and figuring out what everyone’s secret agenda is all about.
  4. You’ll need to be good at managing other people’s anger and frustration. Part of being a strong manager is knowing how to evaluate the project dynamics, and then make the right decision. Most of the time, you won’t find a rosy world where everyone agrees about what has to be done. You’ll be stepping inside someone else’s world, and messing with it. You’ll have to tell people to do things they don’t agree with, or don’t want to do. You’ll have to step in and change everything, and people don’t like change.
  5. Your certification didn’t warn you about some of the important bits. There is no such thing as a comprehensive process guide or methodology that gives you all the answers. Some guides are really good in some areas, and horrible in others. The PMBOK, for example, spends precious little time talking about quality assurance and risk management — so little, in fact, that without turning elsewhere you won’t have any idea what these two things are, how important they are, or what to do about them.
  6. You are actually not ready to manage a large scale project simply because you’ve earned your PMP/IPMA/PRINCE2 certification. These certification programs document your past experience, and your basic knowledge of the relevant process guides. Unfortunately, splashy advertising sells certification, so I’m sure we’ll keep seeing claims such as “everything you need to manage complex projects!” It’s a lie.

Deciding whether obtaining a certification is worthwhile or not is a personal decision. I definitely recommend learning the reference material — and after all, if you learn the PMBOK, it’s not much more work to get a PMP certification. Just be honest with yourself about what it means. Being a good project manager means having the experience to guide an organization toward success, not just recite the process guide. I always recommend starting small and finding out what your personal aptitude for management is.

Your key to success as a project manager is going to hinge on your ability to listen to others, learn from others, and always be open and ready to support your team. You’ll need to turn to other people and other sources of information. Be humble, never let obstacles derail you, and make sure your team knows they can rely on you for support. These are the things you don’t find in the process guides.

The good (and bad) about Project Management School

I’m frequently asked what I think of certifications such as the Project Management Institute’s PMP, or its other programs. Generally I’ll say that programs such as these (including those offered by IPMA, and the UK’s PRINCE2) are valuable tools to know. They represent bodies of knowledge that any project manager should be aware of. In fact, I’ll go so far as to say that any project manager that is serious about their career should be well versed in more than one body of knowledge, able to recite the encyclopedia of information offered, and above all, be aware that neither will teach you to be a good project manager.

There’s a host of information you won’t get in school (not even from a top tier management school, let alone a certification program you can cram for in less than two weeks). And that leads me to the value of the certification itself. Here I’ll generally weigh in saying “it’s up to you.” If you feel going through the certification process will be a helpful learning experience, then by all means do it. On the other hand, getting the certification will neither teach you to be a good project manager, nor will it have a great impact on your career.

It’s important to realize that the Project Management Institute (or PMI) is not a standards body. PMI is a for-profit company that sells several products, and those products are all essentially based in the PMBOK (for example, you can seek certification as a Project Management Professional, or PMP, through PMI’s certification process). This imposes a couple of limitations on the concept of the PMBOK being a robust standard:

  1. Successful standards bodies are international in nature, and the best of them are completely unbiased — something that usually requires forming a body that is not motivated by profit attached to its own products. PMI is, ultimately, concerned with corporate profitability, and this has led to some debate regarding whether the PMBOK has evolved first-and-foremost as a leading project management standard or as a product that PMI can easily sell.
  2. PMI tends to be very insular in its thinking. By this I mean that it does not extensively rely on third party standards — quite the opposite, in fact. The PMBOK is almost exclusively a self-contained work. It does not reference the 50 years of decision management theory that constitute strong risk management practices. Nor does it reference other standards, such as the ISO’s work on quality management. This, naturally, tends to keep people more involved in the PMI’s products, as opposed to moving into other standards.
  3. The PMBOK standard is unquestionably a solid reference volume with extensive project management knowledge — however, it also has startling weaknesses. For example, it’s coverage of risk management and quality management is largely negligent, and it’s strong focus on technical knowledge completely ignores the human factors addressed by methods such as Kanban.

The PMI’s Project Management Body of Knowledge (PMBOK) represents a strong reference guide, and one that I turn to when appropriate as a process guide — but its very strength as a reference text also makes it a poor companion for someone looking for a comprehensive project management methodology. It lacks the practical, hands-on information needed to apply much of the knowledge it presents.

That tends to mean that novice project managers turn to the PMBOK far too often, hoping that it will solve management problems (it won’t). Experienced project managers recognize that it’s a process guide, and nothing more — which means it’s a provides a great checklist to make sure all the right pieces are being executed, but it does little to tell you how to execute those pieces. That comes from experience. The experience of managing people, learning how teams work together (and often don’t work together), how to motivate and communicate, and how to see problems coming before they hit you.

The bottom line is simply this: No school, and especially not one offering a short certification program, can teach you to be a good manager. That’s what project management is all about — it’s not the technical process, more often than not, but the personal factors and the management skills that make or break a project. So yes, get familiar with all the standards, bodies of knowledge, and process guides you can. Learn what you can from each, and use that knowledge as a reference when deciding how your project will be run. But don’t ever assume that this encyclopedia of knowledge has taught you how to manage successfully. That’s going to take management training and experience — more the latter than the former, in my opinion. A lot of it, most likely.

Managing with blinders on

Most managers today have blinders on when it comes to solving the problems of complex projects: They are lost among the trees, and can’t see the forest for what it really is. In a recent discussion in the popular Project Management forum of LinkedIn, one moderator posted the question, “what is the most common mistakes of project managers?”

During the ensuing discourse respondents from around the world posted not less than 18 different answers to this question.

Among the responses were answers such as “having poor stakeholder involvement,” “not enough project planning,” “poorly documented requirements,” “the budget being too small or poorly estimated,” and “the [project] goal is not consistent.” To be sure, many of these 18 answers are highly relevant to the success of a project — and yet, every single answer was wrong. None of the 18 responses identified the single, most common mistake of project managers.

In fact, each answer emphasizes the root of the problem: Too many project managers are focused on the day-to-day problems of the project and have lost sight of their overall strategy. They are thinking tactically, putting out fires, rather than strategically — making sure the fires never happen in the first place.

Take, for example, a few of the more common issues raised in this discussion:

  1. Poor stakeholder involvement. Let’s assume for a minute that we have a solution to this problem — perhaps, for example, a project manager has correctly identified all the stakeholders, put together a great communication plan to keep the stakeholders informed, and succeeds in building a collaborative environment with the stakeholders “at the table” on a regular basis. If this solves the problem of stakeholder involvement, does it actually save most of the projects that go off the rails?
  2. The budget was too small. Again, let’s assume that the right process was used to estimate the project from the start, and that the project manager uses a solid method for measuring performance, cost, and schedule (say, Performance Based Earned Value). Certainly, budget overrun is a common problem, but would this actually solve most project problems?
  3. Poorly documented requirements. In my experience, every requirement is poorly documented to start with — so, let’s assume that the right approach is taken to turn poor requirements into great requirements. Quality assurance is involved early, a full-circle approach ties requirements to work product to acceptance, excellent change management is used, and stakeholders provide a final consensus. Will producing great requirements really save more projects than any other strategy?

The list, of course, goes on quite a long ways — and that’s the point. The list is long, and every single item raised is a valid concern for project managers. But with 18 different root causes on the table, could any one of them really make that much difference is the overall landscape?

These are all tactical solutions to specific project problems. So what’s the big picture? What is the one thing that would actually make the biggest difference, that would actually address many, perhaps even most of these 18 different issues?

Let’s take another look at KPMG’s survey of 252 organizations, and their subsequent findings. According to the study, inadequate project management implementation constitutes 32% of project failures, lack of communication constitutes 20%, and unfamiliarity with scope and complexity constitutes 17%. Taken together, 69% of project failures ultimately trace back to poorly implemented project management practices. What this means is simple: Project managers need to step back from the tactical, day-to-day fire fighting, and take a more strategic view. Adopting the right project management strategy will address most of the problems at hand.

How so? Let’s reconsider those first three project issues above.

  1. Poor stakeholder involvement. A thorough project plan, adopted out of an appropriate project management methodology that is fit for the purpose, will place the right emphasis on stakeholder involvement. It will also provide the right tactical tools make sure stakeholders are involved, and appropriate measures should stakeholder involvement begin to fail.
  2. Budget problems. A correctly selected project management methodology will put the right emphasis on budget analysis, and will provide the right tools to stay on top of the budget. The project manager may need to look outside his or her own skill set to manage to those requirements — but the methodology will establish the goals, the tools, and the metrics from which deviation triggers a red flag.
  3. Poor requirements. The right project management plan will include appropriate methods, probably mandated as part of a technical requirements standard, for developing strong requirements. The plans will include adequate validation and verification of requirements — possibly through strong quality assurance measures. Again, all of these tactical solutions will become part of the project and solve the overarching problem.

So, the root cause of project failure — in fact, of 69% of project failures, according to KPMG’s study — is failing at the strategic level to identify and implement appropriate project management practices.

This means choosing the right standards and methodologies for the project. For instance, if tight quality and budget is a concern, more rigorous controls in this regard are needed. That probably means shunning simple methodologies such as lightweight, agile methods in favor of something that uses more ceremony and process (such as that defined in the PMBOK® and other classical project management approaches). It also means sticking to your guns and making sure the methodology is applied. Showing the methodology to the team and putting it on a bookshelf won’t cut it. Application is the key, and that means recognizing that the standards, practices, and procedures are there for a reason — don’t take shortcuts, because doing so means introducing risks to your project’s health.

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.

Successfully applying lessons learned

In theory, capturing lessons learned at the end of a project sounds like a great idea. Who wouldn’t want to reflect on what was done right, what could be done better, and then apply those lessons to the next project? In practice, though, it is sometimes a different story. It may be a lack of time, resources, interest, or follow-through that causes lessons learned to fall by the wayside. Or, even if they are captured they may not necessarily be implemented. So what makes successful application of lessons learned possible?

Probably the most important factor to me is accessibility. Actually capturing lessons learned is relatively easy (as long as it’s embraced by project and team leadership). Problems, issues, ideas are still fresh in people’s minds so voicing them is not the problem. Management needs to recognize this and embrace the idea that some time needs to be invested in capturing lessons learned — and not just at the end of the project, but throughout its lifecycle. In my experience, this is pretty easy to achieve.

It’s returning to the information and using it in the future where most organizations fail to follow through. 

Having a system in place that makes sure the lessons learned knowledge base is consulted and used in the future is critical. My favorite approach is a well structured, collaborative, wiki-like system. For example, Atlassian’s Confluence has proven great in the past. It offers an open information repository that anyone can contribute to. It’s rich in terms of media integration, and it has version control and sufficient security to ensure that nothing gets lost. 

But most important, the system needs to provide a ready reference library. That means an excellent search capability and well thought out keyword or classification systems. Project managers and leads need to know they can consult the knowledge base, quickly find relevant lessons learned, and apply them to their current project. 

This also means capturing a lot of information. The tool is only useful if it really has a significant knowledge base. Lessons learned need to encompass the positive as well as the negative. Project performance statistics need to be in there. Specific development problems and solutions. Having a cross-reference to your support system or ticketing system is a great idea, because the team can look up generalities and then link directly to hands-on end results from past projects. 

Building the right kind of system is critical. Think about building a reference library. What does it take to feed the library, and what does it take to make it easy to access?