[ieee 2005 ieee international engineering management conference, 2005. - st. john's, newfoundland &...
Post on 01-Mar-2017
Embed Size (px)
AbstractTechnology industry is a global industry. Cisco
routers are sold all over the world, serviced all over the world and developed by engineering teams spread across the globe.
Several organizations in the United States are developing products with development teams spread across timezones. Development teams in India, China, Russia and other low cost location allow the project manager to put more resources on the task. In several cases, the presence of an overseas components can turn a negative NPV project into positive NPV project.
In this paper I would like to enumerate learning from several telecommunications product development experiences. In most cases there were two main teams working on the project. One based in a low cost location and the other based in North America. Additionally, some members of the team worked from home offices and would commute to the main office only when asked to do so by the project manager.
The overseas team was always part of a dynamic overseas company which specialized in providing development resources for advanced telecommunication ventures. This distinction is important since we are dealing with established companies with mature processes and verifiable track record. This paper lists key lessons that can help better managing distributed projects.
I. INTRODUCTION HEN a new project is started, a project managers primary concern is to get the effort, funded and staffed.
Project staffing options range from single site in-house development to multi site development spread across numerous organizations. Multi site projects are also called distributed projects. A product developed across multiple sites is called a distributed product.
Several factors go into making a selection. This includes the skill set of the management team and engineering staff, prior experience with multi site development and comfort level with foreign cultures and work ethics. Once a decision is made to multi site the project, the project manager can employ one of three outsourcing models.
First model is termed Blackbox outsourcing; it implies a high level of independence for all sites and a low level of interactions between sites. On the other hand of the spectrum is Integrated outsourcing. This model results in a high level of interaction between sites and a low level of independence for each site. Third option is a combination of the two or a middle ground.
Every project manager aspires to deliver high quality product on time and under budget. If the development effort is
structured as a multi site effort than the team faces additional challenges that can derail the project. These challenges can be accentuated if one or more sites are in a different time zone. I have often referred to these extra challenges as distribution risk.
While there are no text book techniques to mitigate
distribution risk in every scenario, there are some guidelines that can help. The application of these guidelines is more art than science and it demands a high level of flexibility and emotional maturity in the management team.
In this paper, I have summarized some decision points which can help decide what kind of outsourcing model is suited for a project. I have also elaborated on techniques that can improve the quality of a distributed product.
II. PROJECT STRUCTURE: OUTSOURCING DECISIONS
A. First Decision: Integrated Outsourcing or Blackbox outsourcing. Technology projects typically have a hierarchy of engineers
reporting into one or more project managers. The work breakdown often is influenced by various high level architecture components that form the product.
Work breakdown and staffing is one of the first decisions that a project manager needs to make. If the project team is spread across multiple locations, a wrong step at this stage can guarantee failure at the end.
B. Introduction to Blackbox outsourcing. Let us consider a project with M locations. Project manager
is working with the core team at headquarters and the rest of the team is remote, spread out over M-1 locations.
In this project, high level product architecture breaks out the product into N components. A simple solution to the staffing quandary is to identify high level components that are complex, but are largely self-contained and have sparse yet well defined interfaces. Such components could be given to a remote team. The remote team would need to be set up as a project team with a strong team leader or project manager. Such a model is referred to as a Blackbox outsourcing model.
In this situation there is very little interaction between engineers on the remote team and those at headquarters, or between remote teams.
A good example of this approach is where an ancillary piece is spun off to a remote team. For example, on an ATM switch, if the Mibs are in place, the graphical user interface
Strategic Management of Distributed Technology Projects
Shantnu Sharma, Manager Research and Development, Ellacoya Networks
0-7803-9139-X/05/$20.00 2005 IEEE. 461
can be easily outsourced using Blackbox outsourcing. In Packetcable Multimedia, the SOAP interface on an existing Application Manager could be developed using this methodology.
This model has several advantages and disadvantages. These are discussed in detail here.
1) Simplicity: If the module developed at a remote site can be completed with little interaction with the core site, this is the recommended approach. There is an implicit assumption that the developed module is either a stand alone product or is very straight forward to integrate.
A telephony soft-switch that I was involved used a database. We decided to switch from an open source database to a commercial database. This was an excellent project for a dedicated, remote team. The interfaces were already in place and did not need to change. Remote team needed very little interaction with the core team. Integration was smooth as the interfaces were the same.
2) Side stepping communication issues: In Blackbox outsourcing, most communication flows between a point person on the remote side and a point person on the core team. This is simpler to achieve, particularly when compared with every one on the core team talking with everyone on the remote team(s).
3) Ability to scale up/down: If a new module has to be added to a project, in the Blackbox model, that might translate into adding a new development site. This can be accomplished by minimal disruptions of other sites. On the other hand, if a module is completed, the site responsible for it can be diverted to work on another component, with minimal disruption of the of core team.
This may seem like a strong advantage on paper. In reality it is never that simple, because most projects are a combination of Blackbox and Integrated Outsourcing.
4) Difficulty in transitioning sustaining work to low cost locations: In Blackbox outsourcing, teams are made on the basis of modules/protocols/products etc. Every team takes ownership of their particular segment.
It is quite likely that a team at a high cost location has sole ownership and domain expertise in a particular area of the product. After project completion, if the project manager wishes to transition sustaining/enhancement work from the high cost location to a lower cost location, she will run into trouble. Project team will feel threatened that their jobs are being transferred overseas. In many cases they will be justified in feeling vulnerable. Even when the original team is guaranteed work on a new project they may feel insecure if the old project is transferred. Even if they spend time training the remote team, it would be half hearted and may even be at the expense of the new project.
5) Skill set constraints: Sometimes when deadlines are looming, project managers are looking for exact skill set match. This is unfortunate since I am a big believer in hiring smart, high caliber engineers and training them. In Black box outsourcing all the vacancies for a module are in one location. It is possible that talent may be available in other locations where the project has a footprint, but such individuals cannot
be called upon to help. In my opinion this is a big drawback of the Blackbox outsourcing model, particularly in locations where the demand for engineers exceeds supply.
C. Integrated outsourcing. Unfortunately in many real world examples, several
practical limitations prevent Blackbox outsourcing from taking place. If a project wants to leverage the advantages of global sourcing than integrated outsourcing needs to be considered. In fact several projects are a combination of both models.
In this approach, local and remote teams are integrated as one team. Team members happen to be working at different locations. In the ATM switch example, the GUI team could be spread across 2 or more geographically disparate locations.
The biggest advantage and disadvantage of this approach is that the project manager and team have to confront and solve the communications issue. If the combined team cannot work as one cohesive team than the project will not survive. On the other hand, if the team can work as one cohesive unit, they will enjoy tremendous cost and strategic advantages.
Attached figure below summarizes some key differences between Integrated outsourcing and Blackbox outsourcing.
Fig. 1. Illustrating major differences between the two outsourcing models
The main challenge of the project leader is to transform a distributed team into one integrated virtual team. I have used the following techniques and have found them to be useful in several cases.
1) Leverage advances in telecommunications: Emai