Why you should have an onshore project manager

onshore project manager

What used to be a novel approach to software development has become the norm. Offshore developers have gotten good enough (and have remained cheap enough) that much of the software development ecosystem exists outside the confines of our continental borders. This makes a ton of sense, right? Great code is great code, regardless of where it hails from. So why not save a ton of money by using offshore development resources if you can deliver the same (or at least very similar) quality of project?

Ohhhhh if only it was that simple. There are a lot of givens in that comparison that, in the real world, are anything but given.

For one, you’re presupposing the offshore resources can deliver a product of the same or similar quality to what you’d use on shore. For another, you’re assuming that the cost to get there will be less (while the cost per developer hour will certainly be less going with offshore, if the quality isn’t the same from the jump, you may have to spend a lot more hours delivering the same work product… which eats into any cost savings you were hoping to generate while delaying roll out, which is a cost consideration all its own).

So how do you reap the benefits of an offshore development project while avoiding the pitfalls?

The onshore project manager

From our years working on both onshore and offshore development projects, the linchpin to a successful offshore project is based in a hybrid approach that prizes an onshore project manager. Most of the obstacles that trip up otherwise strong companies or strong ideas can be boiled down to the three C’s: Communication, coordination and collaboration. We think utilizing an onshore project manager can solve for any issues likely to develop within any of those C’s.


Offshore development firms almost always boast a high degree of English fluency; it’s been our experience they’re right! But there’s a difference in conversational fluency, or even technical fluency (e.g. coding languages, tech requirements, etc.) and true fluency. I’m not making a value judgement — I don’t speak another language, so I don’t have a leg to stand on here. What I am saying, though, is that the nuances and norms of American English are often trickier to navigate than many Americans can muster, much less folks who are speaking English as a second language. Furthermore, there’s an entire intricate dance between clients saying what they want and us sussing out what they actually want or need… then translating that into clear instructions for an audience of developers speaking English as a second language. It’s more delicate still to work through challenging conversations between client and developer (we can’t build that for this amount of money, this feature isn’t possible, etc.) without risk of souring the relationship.

These nuances in communication are almost always alleviated by an onshore project manager. They provide a single point of contact through which all requirements, feedback and assignments flow — in both directions. Developers know who to go to with questions and our clients know to whom they should direct feedback. Now, if you have a crap onshore project manager, you’re still going to have communication (and coordination and collaboration) problems… but that’s true of any position. If you hire good people, you’ll be rewarded with good work product. We’ve found that identifying gifted onshore project mangers can be the difference between smooth projects everyone is proud to have worked on… and the opposite.


When working on something complex like software development, it’s basically a given that coordination is going to be a challenge. Coordination in software development is always a challenge, but when you add the offshore element to the mix, it becomes infinitely more so. Which developer is working on what feature? For how many hours? Who is coordinating integration and QA for that? To whom do we direct feedback for the most recent version push?

Coordinating between so many moving parts can be a nightmare… then throw in 11-14 hours of time difference? That can leave you in a tight spot.

Again, we’d point you toward an onshore project manager. The single point of contact can organize and prioritize resources, and make sure all of that is communicated to all relevant stakeholders. Furthermore, if you have one person managing the time shift, you as a client don’t have to think through that or manage that yourself.


One of the points I made earlier was about the difference between what our clients say they want, and what they actually want. More often than not, our clients have a strong vision of what they want the final product to look like, feel like, and what it ought to do. The trickier part is elucidating the exact details of how you get the software to do whatever that is.

In our experience, a ton of offshore projects are bid out and delivered in a model of: client says, “this is exactly what I want, give me that.” So, your offshore development partner gives you exactly that, and not one single thing more. If you missed anything in your requirements document, or if you expect your development team to fill in any blanks, or if you want suggestions that could help with stability or usability, etc… you’re kinda outta luck. Part of what you get for the low price you’ve bargained is exactly what you asked for, with nothing else provided.

If your technical writing staff is absolute aces, then this might be all you need (or, for instance, if your project is pretty small and straightforward). If you can write a perfect requirement doc that encapsulates everything you want and need (with 100% certainty that nothing will change along the way, or you’ll get a new, fresh idea during development), then you’re in the clear.

But for the vast majority of us, that’s not super realistic. Things change along the way during software development all the time. Developers (at least those worth working with) have deep experience and expertise and might suggest a better or more elegant way to accomplish what you actually want, instead of just taking orders and delivering on them.

An onshore project manager can be a vital conduit through which requirements flow and ideas ebb. They can ensure you are indeed getting exactly what you want, but not confining you to a rigid set of documented requirements that might not fully encapsulate your vision. Establishing a truly collaborative relationship takes time and trust to establish, and working with a single point of contact in your onshore project manager can help fulfill that ideal.

In conclusion

Will an onshore project manager solve every problem in your offshore development project? Probably not. But from our experience, we’ve found having that singular, stateside point of contact with your development partner can head off a bevy of pitfalls. It’s why we recommend it to our clients, and it’s why we think you should implement it too.

    Leave a Reply

    Your email address will not be published. Required fields are marked*