Going Abroad--Part II

[article]

code and even brainstorming ideas are now a challenge. Even more challenging is the work of the project manager. How do you report the real progress on a project that is so decentralized and divided?

Similar issues arise for risk management and resource allocation in scheduling when things are not experienced firsthand. When isolated from the project team, how do you report progress and achievements to your peers? In such situations, you are dependent on other's guesstimates and opinions.

As a German living and teaching in the United States, I've noticed the culture and work ethic is defined through the values this country was built upon. I see this in discussing ideas proactively, promotions for good work by a team, and financially benefiting from that good work. It impresses me how fast Americans build new work relationships to form a team and how fast those ties are collaborated with the spirit to win. The courage to make things better is honored by the society.

Your partner offshore might have a different culture and work ethic--defined by hierarchy and top-down communication, executing orders rather than inventing things. It will cost your project to promote team spirit overseas so that all participants can identify themselves with the product.

Be prepared for ongoing interpersonal communication. The easy part is to draft a requirements document and ship it offshore. The hard part is to get what you want, which is not necessarily what you drafted in your first version of the requirements document. There will be change requests and renegotiation of scope and the project management for those requirements. To forecast local developments, project managers need to meet the team in the same way the business analysts need to communicate business requirements. To do this, the onshore team needs to go offshore in the same way the offshore team needs to come onshore periodically. Travel costs and time need to be incorporated into the pricing model on both shores. For larger endeavors, representatives of each partner communicate, collect, and request information from their shore. This go-to point of contact also can act as the funnel to the offshore team when pieces of the project are outsourced even further.

Be prepared for more detailed standards, guidelines, and procedures. If you expect that Java code will be written following a particular format, you will need to be specific about it. Casual internal reviews onshore that were just fine for internal development efforts are not sufficient for offshore development.

In the third and final part of this series, I'll provide you with guidelines to implement a different shore model, the smart-shore approach.

Click Here to Read Taking Off to the Smart Shore Part 1 of 3

Click Here to Read Smart Shore Part 3 of 3

About the author

Jochen Krebs's picture Jochen Krebs

Jochen "Joe" Krebs, www.jochenkrebs.com,  is a method engineer within the Rational Brand for IBM. He develops content for the Rational Unified Process, OpenUP, and other agile software engineering processes. Prior to his current role he was responsible for successful enablement of Rational products and services for clients in the financial sector. Before joining IBM Rational he worked as an instructor and senior consultant with a focus on project management, requirements management, software engineering processes, and object-oriented technologies using Smalltalk and Java. He holds his MSc in computing for commerce and industry at the Open University.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!