If they're not carefully managed, however, distributed engineering projects can fail in ways you never imagined. That's why it's important to carefully plan your projects, follow best practices in software development, and set up and monitor key metrics to make sure projects stay on track.

Here are some potential pitfalls--and steps to avoid them--so your next project doesn't end up buggy, behind schedule, and over budget.

It's not my fault
A contract is not necessarily a contract. In the United States, we like to think that contracts are legally binding, but in some countries, what's more important is what the other party thinks they've agreed to. Even if you're on sound legal footing, you probably can't afford the time and expense of a courtroom fight. It's better to make sure you and your partners truly understand what each other is doing.

The act of drawing up a contract nevertheless provides a good opportunity to set expectations about the project. Bring physical examples of the work you're doing and also of related work other partners have produced for you in the past. You may also want to ask your partners to show examples of work they've done for other customers. This is a great way to ensure everybody knows what's being done and what's expected of them.

Define your terms and whether you're using U.S. or metric measurements. There are no industry-standard terms in a world marketplace and any misunderstanding can delay your project. You should also specify when you need the work translated into English.

Watch the legal language. Legalese, while common in the United States, may be viewed as unfriendly overseas and sets the wrong tone for your partnership. Strive for a friendly tone in your documents and avoid exclusionary language. Ensure it's a win-win deal. Try to anticipate problems and talk with your partner at this early stage about what could be done should they arise.

Keep it cordial
It's better to be humble than to be right. While we expect some criticism of our work from time to time, in some cultures, any criticism is viewed as a monumental failure. Even if you're right and your partner is wrong, it's almost always better for everyone if you let your partner save face.

One key way to do this is to make suggestions. Don't tell them, "This is how it's going to be done." Rather, make a suggestion and ask them if it would be a good idea. If they're not doing something you thought they agreed to do, treat the work as if it were a new request, even if it's in the contract.

And if you have a problem with the work, start with the engineers directly responsible, not with their boss. Let them decide to take the problem to their boss if it needs to go to that level. Immediately running to their superiors is a sure-fire way to damage any relationship you had with those engineers, and it may ultimately cost them their jobs.

When visiting overseas partners, be aware of local customs. Remember your manners. Not all cultures are as informal as we are in the U.S. Also, be aware of local gift-giving traditions. Such customs are more common than you might think. I was surprised when my hosts in India greeted me with red roses and gave me a pearl necklace, a product for which their city is locally famous.

Also be aware of local biases. If they aren't used to dealing with women (in my case) in positions of authority, realize there's nothing you can do in the moment to change a cultural bias. Behave in a way that maintains your dignity, but doesn't cause others discomfort.

Wanted: software engineers
Just as it can be difficult to get projects accomplished in the U.S. between Thanksgiving and New Year's, holidays and unusual compensation systems in other countries can make it difficult to find help when you need it. Holidays are easy to overlook, especially when you have partners in several different countries. In any given month there's a chance one of your partners will be on holiday, affecting the work of other teams. Given that all engineering is schedule- and dependency-based, it's imperative to develop inclusive timelines that take into account requested time off.

Determining the impact of a holiday means more effort than just looking at your calendar. You need to understand the significance of the holiday and how much vacation time people take around it. Chinese New Year is a six-day holiday, and the celebration starts weeks before it begins. Much of France takes off for the entire month of August.

It's not just holidays you need to consider, either. In Taiwan, a unique system for paying annual bonuses can make it difficult to gear up for projects. Workers there get one-seventh of their annual salary at the end of the year as a bonus, but only if they've stayed with the company the whole year. This practice creates a de facto "hiring season;" the majority of hiring occurs immediately after the bonuses are paid out. And there's always the risk employees could be lured away by other firms at that time. Any Taiwanese project requires significant advance planning.

Before doing business anywhere or launching a major project, it's wise to check with U.S. trade offices or with your foreign bank (many banks provide international business advisors). You should also specify specific dates for deadlines. "Tomorrow" means in a few days in Europe; it generally means sometime next week in South America. You may also want to set up your contracts so you spread out your payments, paying only when certain milestones are reached.

Don't assume anything
We all do business differently. You can't assume things are done in the rest of the world as they are in the U.S.

We were surprised, for example, when a development partner didn't have access to an oscilloscope, a standard piece of test equipment in the U.S. Another project was delayed because it was initially prepared with a Japanese version of a software-development tool provided to engineers who don't speak Japanese. We'd only specified that the final output be in English; we didn't think to ask for it to be built with English-language tools.

Think outside of your normal experiences and ask questions even if you think you know the answer. It's helpful to think "outside" of the way things work in the U.S. and to figure out solutions before the work begins.

Pay close attention to what is being said. While your remote employees or partners may speak perfect English, it's very difficult to pick up on nuances in speech. You need to figure out what really is being said (or not said). Video conferencing can aid in communication as can translators.

Surprise!
There's nothing worse than reaching the end of your development cycle and realizing your product is lacking features or quality. Some partners may not be forthcoming with status information, positive or negative. Others may have grown up in a culture where it's shameful to answer "no" to any request, regardless of how unprepared they are.

To prevent yourself from getting caught off guard, it's important to set structured status reporting practices with meaningful benchmarks before the work begins and to track them often to make sure the project doesn't go astray. You need to be able to measure quantitatively, at any point in time, how the project is going. Set up metric-driven status reporting: percent complete, hours to completion, earned value and defect counts, all at a component or task level. The numbers won't lie. Whether or not you speak English, if the number of hours is significantly over budget at a particular milestone, you immediately know you'll need to make adjustments.

If a mistake is made early in development, it's easily compounded if teams around the world build on top of the error. That can be devastating if you don't discover the problem until the final stage of development. As a preventive measure, you may want to consider using a "gated development" technique. This process involves calling on your extended team at certain "gates" within the development process, to test their pieces together. These gates can help you uncover incompatibilities and engineering issues. And, if you do discover a problem, don't let the project move forward until the teams agree on how to solve it. The more complicated the project, the more gates you'll need, but six to nine gates generally works well.

Managing a distributed engineering project can be challenging--but rewarding, too. Managed well, you can save money, expand your capacity, and open your product to new markets. Just as we sometimes like to buy American, people in other countries like to buy from companies that benefit their own economy. Spreading your production around the world brings you closer to your customers, wherever they may be.

Carey Butler has spent her 25-year career in the software engineering and professional services industries. Carey is responsible for BSQUARE's Professional Engineering Services division. She can be reached at careyb@bsquare.com.

Reader Response

Thank you very much for interesting article. For me coming from Eastern Europe and being on a position of subcontracted, it is very interesting to know how things appear from other side.

- Armands Valdmanis
Temporarius
Riga, Latvia