Top Tips For Managing IT Projects That Combine Offshore-U.S. Workers

Managing projects across geographic lines and cultures is becoming more complex as companies expand their workforce options. Project teams can span multiple countries as companies choose offshore resource pools.

Each country and organization has their own set of rules and assumptions for they way they work, and it’s up to the PM to help the team understand that and provide those guidelines back to the team.

Here are some tips for managing IT projects that combine offshore and U.S. workers:

Culture. Depending on the country, there will be a social order within the workplace that should be respected and followed. Do your best to understand that prior to your first engagement with any member of that team. It will definitely set the standard for your working relationship going forward. If you are able to exhibit that knowledge, new teams will appreciate your understanding of how their team works.

Standards. Set clear expectations for team communications and work. In the kickoff meeting, provide a set of standards you expect the team to follow. Provide examples, templates and other documentation to enable the team to be successful with the requirements.

Flexibility. Depending on location, workers may be up to 12 hours ahead. Be sensitive to this. While the expectation can be that they flex to a U.S. workday, it may not be feasible because of transportation and other limitations. Be sure to understand those limitations before placing expectations on the team abroad.

Resource allocations. Define the resource allocations needed. Some companies will float your resources depending on the demand for the day. It’s always good to ensure the resources you are leveraging are consistent on your project. This will provide continuity and context for your team going forward. Play special attention to this as you manage the budget and the work. It’s not something that may show up immediately, but it can impact your code quality.

Types of resources. What types of teams are you using? Are they testing teams, code teams or is everything off shore? That will impact your overall project plan: schedule, budget and management style.

Image: Business Woman Drawing Social Network from Bigstock

Comments

  1. BY John Peter says:

    I am an American working with Indian offshore team. Your tip come very handy.
    Thanks – JP

  2. BY jalstadt says:

    This sounds like management directive instead of team directive.

    Software teams according to Agile are to promote the directive. The PM should be engaged in this and encouraging the team to act as a whole. The software team should be setting the dates for delivery and management is ideally to respect this, and to work with the team to determine the features that are the most important to meet the date. The PM is to work with the team to identify feature prioritization and identify possible gaps the team might have missed and ask velocity questions to the team (like you performed last year on this, why do you expect it to take so long this time around). This could help the team better plan.

    It is best to let offshore teams manage themselves via scrum and keep the US team working on a specific software component while the offshore team works on another software component. Of course the software architect should provide oversight into the design. It is not best to have offshore teams clearly tied together with US team members as this could lead to a lot of refactor, redesign and constant integration (can be avoided to allow the team to do feature work).

    Often times I find PMs like to involve every team member in meetings with offshore teams. This isn’t really necessary and takes a toll on personal family life. This can easily be avoided.

    It would be best for stakeholders to meet the offshore team in person and the offshore team members or US team members to meet each other via video or in person. This allows people to get face time with one another.

    Resource allocations are best made with input from both the architect and other team members feedback. It is best to put resources that work well with one another and junior resources that could be mentored/paired with senior resources to learn the process. Get rid of the resources that do not like pair programming (they hurt your team more than help).

  3. BY tj3 says:

    I think the phrase ‘Offshore-U.S. Workers’ is key here.

    Aside from points mentioned or posted by others, working with folks who speak the same language makes a big difference in how smoothly things can go.

    In my case, English was the common denominator at places I worked at. Doing a con-call, video call or whatever, usually goes fine as long as they have had enough practice using English.

    When not, it can be a nightmare. Since we have minimal control over the environment being provided by the powers that be, one has to backtrack within the walls and see how things can be reworked or rerouted to get the job done.

    So, the more people the offshore site has that speaks your language, the better and ideal. Just my 2 cents.

  4. BY Daiva says:

    From the offshore stand point I would like to highlight the two main key factors in my opinion as setting expectation and flexibility.
    Clarity on expectation is of profound importance, offshore teams work like an army with power in skill the PM has to rudder the boat well. Yes the factors on translating on what was “meant” in a discussion even though the same language is spoken has also proved to be a definitive driver.
    Flexibility in work time is another big one. Most offshore teams feel the onsite is not sensitive to their work timings, never try to post something on them at the end of their day or shift unless its a show stopper.
    What works is a strong offshore co-ordinator with an onsite face, he can get things done for the PM.

Post a Comment

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>