© 2005 Johanna Rothman.
So you’re managing people and projects around the world. It’s not easy, and it seems to be the norm these days. I’ve worked with global projects for the past 15 years, and here are three of my tips to making them successful.
Define Clear, System-Based Milestones
One of the biggest problems with global projects is knowing who depends on what piece. Sometimes pieces of the system are interrelated, without the project manager understanding how. If you and your project team define clear handoffs that are based on pieces of the system under development, you have a much better chance of knowing if you’re all on schedule or not.
Too often, I see major milestones such as “Requirements Complete” or the ubiquitous “Code Complete.” I don’t think I’ve ever seen a project that met a “Requirements Complete” milestone, but I have seen projects where the requirements could be baselined, or where the most important requirements were defined enough to continue the project’s work.
Since I tend to work in more Agile ways (even on global projects), I rarely define a milestone such as “Requirements Complete.” Instead, I have milestones such as “Initial Requirements for such-and-such scenario (or user type) Defined.”
Sometimes, I forgo requirements-based milestone, especially if the project teams are implementing by feature. In that case, I’ll define milestones, such as “Feature 1 Complete.” Once we have any features complete, system testing can start, even if it’s not much of the system.
The value to implementing by feature is that as the project manager, I learn very early in the project if people are having trouble. If it takes longer than we expected to implement (or test) Feature 1, I have to review the rest of the schedule to see what I want to discuss with the project team.
You can still use milestones that say “Code Complete” or “Features Complete” — as long as you define what “complete” means. Since that generally means listing all the features, I prefer to create more milestones that reflect the done-ness of each feature as we proceed.
But no matter how you do it, make sure you have milestone in your project schedule that reflect how and when each group makes process on the system. That way if you’ve organized the architecture or the features by geographical area, you and the project team will still understand the current project state.
Clarify Each Handoff’s Meaning
In general, I dislike milestones that say “Complete” without defining what complete means. I’ve noticed that even when I ask developers to unit test their code, some developers think that unit testing means their code compiles. And, I’ve noticed that when I used to ask testers to “bang on” a piece of software, they thought as long as they tested the obvious things, that was good enough. Since I expect a variety of testing, I can’t just say “Testing Complete” as a milestone with discussing the types of testing I’m expecting.
When I create a schedule with a global project team, I tend to list the milestone criteria along with the milestones. For example, when I say “Feature 1 Complete,” I’ll attach criteria that might look like this:
- Feature 1 code compiles without warning on all platforms
- Feature 1 unit tests checked in and run (If I’m managing a team who’s using test-driven development, I’ll omit this criterion)
- Feature 1 smoke test checked into smoke test area
- Feature 1 checked in and built. Smoke test runs successfully
It’s clear from this list that the project team (and I) won’t say that Feature 1 Complete is done unless all the code is checked in and works, as well has having some unit tests and smoke tests to verify the feature works.
If you’re managing a small, collocated team, you could talk to the developers and gain their agreement to criteria like these. But the larger the team, and the more geographically distributed the team, the more specific agreements you and the project team require to know the true project state.
But by far, the most critical action a manager or project manager can take with global development is to develop trust among all the teams. A couple of years ago, I consulted to a project that had teams in several European countries, and several countries across Asia. In all, there were teams in seven countries.
Senior management was concerned about the costs of development. So they created a competition. Project teams that met specific milestones early would receive small bonuses and keep their jobs. That’s right, the “losers” in the schedule game would forfeit their livelihoods.
Every single project team met every milestone. Of course, the project didn’t work at all. But each person met his or her milestones, no matter how ridiculous the schedule was. The cost of development increased by several orders of magnitude. And the blaming across the organization continues to this day.
Without trust among the distributed teams, the project cannot succeed. Even without senior management who (unintentionally) created a project monster, the distributed teams need to know that they are all equal partners in the project, and that they all need to work together for the good of the organization. The project manager (and any other managers) can do this by building trust with the teams and among the teams.
It’s Not Easy
Managing across time zones is not easy. But it’s part of how we work now, and will probably remain a part of how we work for a long time. It’s worth adapting your current management practices to make the most of it.
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.