Select Page


Managing Across the Globe: Define Clear, System-Based Milestones (#1 in the series Tips to Managing Across the Globe)
By 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’s one of my tips to making them successful.

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.

This original article can be found at:

Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It!’Your Guide to Modern Pragmatic Project Management’. She is the coauthor of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. And, Johanna is a host and session leader at the Amplifying Your Effectiveness (AYE) conference ( You can see Johanna’s other writings at

Recommended PM App

Recommended PM App