The Perils and Opportunities of Multi-site Product Development
Lessons learned from multi-cultural, dispersed product development teams
(In this article the term “dispersed” is used to denote teams who are scattered around the world, but working on a single development program. Other terms used include “virtual teams”, “distributed teams”, and even “global teams”.)
Developing new products in far-away countries is a model that’s here to stay, and it will become a preferred method for new product development in many organizations. The global nature of today’s business requirements it, and there are several compelling reasons for companies to adopt a multi-site approach to product development:
- Obtaining cost-effective resources
- Establishing a local presence in a particular country or required to by local laws and tax structure in order to tap a new market
- Accessing talent, technology or competencies not available in your home country
- Acquisition of a foreign company
- Outsourcing development to extend your current capabilities
Regrettably, we find that, most organizations today are still using the co-located development approach of old, where engineering, marketing and manufacturing were co-located in the same building or the same industrial park. Specifically, the new product development processes, organizational structures dating back to co-location, leadership models not in tune with multi-culture environments.
We’ve traveled around the world working with companies to solve the challenges of developing new products when the development team is scattered over multiple sites. Over the years we have learned many lessons when working with development teams that are separated by distance, culture and language.
The Challenges
Some companies make the wrong assumption that engineering is the same the world over, while this is true at the technical level, it does not mean that engineers are the same. The approach that engineers take to solve a problem, think about innovation, and communicate with their peers varies around the world and is heavily influenced by two critical factors, their native culture and the engineering schools they attended. In Europe for example, engineers are taught to develop incremental innovation, while in the U.S. the intent is to always strive for the “home run” breakthrough. Both approaches are correct and both deliver value. The problem occurs when the two are combined without the proper effort to create alignment.
Not surprisingly, communication across distance, language and culture is the most frequent challenge we encounter. From the simple e-mails full of typos, poor grammar, slang (see appendix “B” for more on slangs) and seriously cryptic. To an MRD (Marketing Requirements Document) written for a co-located audience where engineering only needs to walk across the hallway to get clarity from marketing. To business plans written from the perspective of a free market, capitalist model. The concept of capitalism varies around the world, so does the thirst for profits, particularly in the product development ranks.
Another challenge is the poor use of technology (see Appendix “A” for more on the use of technology), while it has enabled multi-site product development to an unprecedented scale, it has also created barriers to communication. Let’s not forget that there is still the need for human beings to communicate, add to that different cultural backgrounds and different languages and you have a communication “firewall”.
Some organizations believe that if they purchase a software application for collaboration or enable video conferencing the challenges will disappear, not likely without a parallel effort to improve communication skills, cultural sensitivity
The base line
We always start our engagements by asking our customers to think of all the challenges they face developing products is a co-located framework. For example unclear customer requirements, conflict between engineering and marketing, lack of strategic alignment across the organization, ineffective product pipeline, etc. Then, we encourage our customers to visualize all these problems and add distance, language and culture to the equation. This little exercise always creates a vivid picture of the challenge at hand. For example, if your MRD is insufficient for your local engineering team, why would it be “good enough” for a group of engineers in Shanghai, who attended a Chinese engineering school, speak a very different language and have the values of an ancient culture.
Six Suggestions for Improvement
Multi-site product development represents a sizeable opportunity to grow a company profitably, in many cases is essential to manage the growth of your company. Many corporations have found it profitable to develop products around the world; many more will see the opportunity and wills start tapping these new sources of profits.
Historically, multi-site development is not new; it has been going on since the start of the industrial age. What is different in the 21st century is how prevalent it has become, and how fast it is taking place. Technology and the end of the cold war have enabled unprecedented speed towards a global market place.
Multi-site product development is not daunting nor is it reserved for large multi-national companies. It does take a change in your product development model to account for differences in distance, language and culture. Plus the realization that technology alone cannot bridge this gap.
#1 Assess your current situation
Start by evaluating or reviewing your product development maturity level[1], i.e., the ability of your current organization to deliver new products on time. For example, are your MRD’s clear and sufficient to enable your R&D organization to create innovative products, faster than your competitors? Is your marketing organization capable of obtaining clear customer requirements on a consistent basis? Is your rate of innovation “up to par”; that is, are you creating innovation that your customers value? And are you doing it faster than your competitors. Do you manage your product development projects effectively?
Once your have assess your current product development maturity level, set about fixing the most pressing problems by re-engineering your new product development processes, enabling your marketing organization to obtain and use customer requirements consistently, etc.
#1 Use technology wisely
Do not assume that a new software application on collaboration or a new video conferencing set up will solve all your communication problems. The most important “glue” that holds a team together to deliver measurable results is the interpersonal communication amongst all the team members. Technology can only enable part of this exchange, culture, language and organizational structures make up the rest.
Let’s not forget that in business, a team is a group of people who are committed to a common purpose, and trust each other. Clarity in communication happens when there is trust, respect and the alignment around a single purpose. Plus, the understanding of the differences in language and culture. Technology bridges the “distance” dimension of communication.
#2 Leadership over management
We have a simple contrast we use to address leadership. “You can manage a process, but you must lead people”, in short, we make the assumption that “managing” people is close to impossible. This is even more evident when the definitions of management and leadership vary around the world.
The role of leadership is critical, but the definition of leadership varies around the world. Here is where cultural sensitivity plays a very important role. The manifestations of a leader in the U.S. are different than those in China or Germany.
#3 Outsourcing does not mean “out of mind”
Some companies make the incorrect assumption that once they have hired an outsource organization the need for close interaction and supervision is no longer required, on the contrary it takes considerable energy to work with your vendor to communicate your expectations of quality, speed, and most of all for you to represent your customers to your vendor.
The same can be said for product development programs, companies are indeed outsourcing development to third parties around the world. We advise our customers to create a robust framework to ensure full collaboration with your design vendor. All the rules and challenges about distance, culture and language also apply to outsourced development.
Having someone simply monitor the contract agreement between you and your vendor is not enough. We suggest the formation of a Core Team made up of a senior person from engineering, one from marketing, Quality and Manufacturing. The make up of this Core Team will vary by companies, but it is critical to go beyond managing the contract. The members of the Core Team must have the experience, skills and time to immerse themselves in the challenge. Considerable involvement by the senior Executives of the company is also required, and not just when there is a breakdown.
Another recommendations we often make, is to develop, document and consistently manage a risk plan on your relationship with your vendor. This is about how your company and your vendor work – beyond technical issues. A Risk Management Plan will surface potential failures in your relationship and allow you to prevent a breakdown.
#4 It all starts at the top
The Executives and other leaders of the organization must be the first to adopt the sensitivity to distance, language and culture and become the role models of the new behavior. They also need to set up a simple set of metrics to asses the progress towards multi-site product development, and finally they must reward the right behavior by identifying and recognizing role models.
#5 The critical initiation of your development program
Considerable effort and focus must be placed at the very start of your new development program. In our experience, this is an area often neglected by product development organizations, even when the team is co-located. Imagine the problems when you add distance, culture and language. The start of any development program is critical to building your team and enabling them to develop trust. Thus, spending several days doing a “kick-off” meeting is time well spent, and an investment that will provide a high return later in your project.
The “fuzzy-front-end[2]” of a development program is that phase at the very start of the project where there is much confusion. For example, the development team is not fully identified yet, the objectives are not clear, budget is not set and the schedule is in flux, roles and responsibilities are not even identified let alone communicated – to name a few. Incidentally, every project has a “fuzzy-front-end” no exceptions! It is a natural phase of project management; thus, it is best to take full advantage of it.
One strategy that we have used very effectively is “go slow to go fast”, the idea that the initiation of the project is the most critical phase and consequently much time and effort should be spent. We have found that with a strong foundation through “kick off meetings”, increased communication and team building at the beginning of the development program, considerable velocity is achieved, and “false stars” are avoided.
We always advise our clients to hold a “kick-off” meeting with as many members of the team as possible. This is an area where one cannot afford to be “penny wise, and pound foolish[3]“ by trying to hold the cost of travel and lodging down. Money spend to clear the “fuzzy-front-end” has considerable returns later in the project through increased velocity of development, said another way, the cost of not dealing with the “fuzzy-front-end” will cause delays due to poor communication, friction in the team, and lack of alignment with the technical and business objectives of your development program.
Our recipe of the extended “kick-off” meeting include a complete review of the objectives of the new product, both business and technical with ample time to discussion and dialog amongst the team members, remember a PowerPoint presentation is woefully insufficient to create alignment or even clarity.
Further we spend considerable time in dialog (discussion) on the customer requirements, and understanding what the customers of the new product “value”.
We also add time for the team members to interact at the personal level, for example extended coffee breaks, evening activities and even some “free time” for networking.
#6 Address the common multi-site development maladies
When distance, culture and language are involved, we have identified a series of common maladies, and over time we have helped our customers either prevents them or put in place corrective action.
Breakdown of communication due to language and culture
As the pressures of the development program increase it puts a strain in the ability of the team to communicate with clarity and objectivity. This is aggravated by distance, language and culture.
Conflict between the local management structure and the “head office”
Local sites have their own set of pressures, priorities and in many cases business objectives. Try as they may, corporation constantly face this type of turmoil yet the problem persists. There are development programs where this conflict creates delays and even the risk of failure.
Conclusion
Multi-site product development is indeed not a mystery; it is a mature and proven approach to increase profitability and growth. There are steps that must be taken in order to tap the potential, as with any strategic initiative in your company, this one will take several years to fully implement, will require a change in the way your company develops new products, and will tenacity and commitment on your part.
[1] Maturity Curves have been developed for product development including software. These models look at the level of competency of a particular organization, as opposed to an individual within that organization. The model assigns different levels of “maturity” the higher the competency.
[2] “Fuzzy-front-end” is a term that started in the development of new techniques, over time it has come to represent that start of development programs where there is insufficient information and confusion is prevalent. Every project has a fuzzy-front-end; your task is to exit this phase rapidly without sacrificing clarity, and alignment in your team.
[3] “Penny wise and pound foolish” is a refrain (idiom) used to denote being careful with very small amounts of money but foolish about missing the larger mission.
Tags: collaboration, cultural differences, global business, global teams, international, leadership, multi site R&D, Multi-site product development, outsourcing, product development, R&D, virtual teams
You can comment below, or link to this permanent URL from your own site.