Read an Excerpt
Chapter 1: Introduction
Much has been written on the subject of productivity. We all want to produce a high quality product for our customers and do it faster and less expensively than our competitors. But what is high quality in today's world and how does it relate to productivity? Historically, inside many organizations, productivity has been viewed as a counting game. That is, productivity has been associated with the number of "widgets" one can produce in an hour.
With productivity improvement in mind, recent years have found many organizations working diligently to establish stable and repeatable internal engineering processes. In many of these organizations the thinking has been that a repeatable internal process will hold a key to future productivity. Despite this longheld belief, in today's world the path to real productivity requires a close reexamination; for example, what good will increasing your widget-per-hour count do when your competitor already owns the product your customer wants?
Inside today's downsized and consolidated organizations the rules of the productivity game are changing. Organizations that yesterday stood successfully and alone are now taking a closer look at the products they produce along with their relationships with external organizations. In the process, many of them are recognizing that the speed which solutions require no longer affords them the opportunity to look solely inside for all their answers.
As a result, inside today's successful organizations real productivity is no longer viewed as just a number. These organizations are finding new and creative ways to turn traditional rivals into close, workingcollaborative teammates.
Why Do Many Collaborative Ventures Fail?
This book focuses on a new way to construct advanced technology software intensive systems that fit our rapidly changing external environment. In particular, it emphasizes the issues involving projects that are integrating existing products, along with new development through the utilization of engineering personnel with diverse skills, knowledge, and backgrounds.
Research done by Booz-Allen indicates that many collaborative efforts fail because of a combination of four reasons:
- Cultural incompatibility
- Leadership struggles
- Lack of trust
- Inbred notions of competition
Based on our experience with a number of collaborative engineering ventures that took place in the 1990s and early twenty-first century, we view this list as one of symptoms. The real reason behind many collaborative failures rests in a failure to take timely and effective action to resolve the real underlying root causes of problems that are actually not as complex as imagined. Furthermore, by looking deeper into real collaborative experiences, these root causes can be identified, along with practical and affordable solutions.
Background
We first noticed the issues that became the subject of this book on a number of distributed development projects that shared a common set of characteristics. These projects occurred between 1994 and 1998. Initially we thought the material we were developing would only be relevant to projects that fit the same model. After being involved in a number of additional distributed projects (1998 to 2000) with differing characteristics, we concluded that the applicability of many of our observations was much broader than originally thought.
We do not recommend that our clients attempt to apply everything in this book to their virtual projects. This book can help if your project includes multiple sites and multiple companies with hundreds of people spread around the world. But it can also help much smaller organizations as they look for the most effective strategies to operate in the virtual world.
What Do We Mean by Virtual Collaboration?
When we began to study virtual projects in the mid 1990s we defined Virtual Collaboration to be
"Uniting critical skills to solve a problem without physical collocation."
Today there is a new kind of distributed development project emerging that has led us to a revised definition.
In most traditional subcontract relationships the prime contractor develops a formal specification for the subcontractor. This specification normally establishes detailed requirements of the product to be produced. Traditional subcontractors often accomplish the required work within their own facility, employing their own management personnel, support infrastructure, internal processes, and technical approach.
As long as the specification is met, the subcontractor is free to operate within his own facility as he desires using his own tools, methods, and supporting infrastructure. Using the broad definition above, this relationship between prime and subcontractor could be viewed as virtual collaboration.
The virtual projects that we emphasize in this book involve multiple organizations and multiple sites. However, the relationship between these organizations differs from traditional subcontract relationships.
In contrast to the traditional prime-sub relationship, the projects of interest to us are those utilizing virtual teams that operate more as a single integrated team employing some level (to be discussed) of common processes, support services, and technical strategies driven through a streamlined management chain. A key distinction of these virtual collaborative projects centers around the methodology employed.
Oftentimes insufficient time and knowledge exist at the start of a project to develop a comprehensive detailed specification before initiating engineering development activities. Furthermore, customers are looking for value added starting on day one of the project. In most new high-technology arenas few organizations have just the right set of off-the-shelf solutions to meet this need. In response to this market demand a new form of virtual collaboration is emerging which we define as...