Product development team members are often focused on the component level, but understanding the whole system is a challenge. Forming cross-disciplinary integrated product teams can provide support for large and small efforts in either agile or traditional development, helping teams achieve total system lifecycle expertise.
Product development seems to be going at an ever-quickening pace. Managers are pushed to get products to market faster and cheaper, stressing existing traditional models for software and systems development. As a side effect, engineering teams typically focus on trades to meet competitive and market demands. In this fast-paced environment, this introduction can occur without a thorough understanding of how these trades may cause some unforeseen downstream impact in the form of reduced capability, higher maintenance cost, or general liability.
Successful product development is becoming more challenging. It is increasingly important that total system lifecycle expertise, in addition to that of the development team (i.e., the programming team), be considered early in the product lifecycle.
There is help available. With the employment of cross-functional integrated product teams (IPTs), there is a focus shift from pure technology to one that also includes production, marketing, sales, deployment, and support.
What Is an Integrated Product Team?
Thanks to a 1995 Secretary of Defense directive, the adoption of IPTs within the Department of Defense (DoD) has been the favored approach for systems and software acquisition. An IPT is defined as a multidisciplinary group of people who are collectively responsible for delivering a defined product or process.
The value provided by IPTs in support of product acquisition is recognized widely within the DoD. However, additional benefits from the employment of an IPT approach can be realized if similar types of integrated cross-functional teams are used to support product development activities.
IPTs, supported by various subject matter experts, can be used throughout the product development lifecycle. These are teams of individuals who represent different areas of expertise with the joint goal of producing the best product. The same type of cross-functional expertise that is leveraged to support product acquisition activities can be applied to the development of system and software products. Some examples of where to best leverage these efforts include the support of requirements reviews, use case reviews, work package inspections, and development and integration test and deployment planning. IPTs should be employed to help define and manage the technical baseline, promote a systems-level view of product development, determine technical performance, and manage risk.
Benefits to Product Development
Early involvement of marketing and program management, manufacturing, material, test, quality, and product support personnel in the development of any software or systems product provides a multifunctional perspective. It facilitates the development of requirements and the design of the product and reduces production problems. Early and ongoing engagement of all stakeholders also results in each participant investing greater ownership and becoming more committed to the development of the product. This improves the chance of a successful delivery—a product delivered on schedule and within budget.
Coordination and communication are critical to any successful product development effort. Organizational silos and inefficient information flow are often cited as contributors to product development failure. IPTs break down information silos and enforce coordination and communication to ensure that all critical input is received and can be used to support agile and traditional lifecycle development. The creation of multidisciplinary IPTs can provide real benefit to small and large development efforts by ensuring that individuals with the correct systems and software expertise are involved early—and remain involved—in the lifecycle of the product.
Setting Up a Product Development IPT
For any cross-functional team to be successful, each member should be empowered and the IPT should have senior leadership support. One way to do this is to formally charter the IPT so that all ground rules and participant responsibilities are defined and understood from the start. An effective charter should describe the purpose of the IPT and include a brief overview of the software project, including all stakeholders and responsible management. A charter should also have a description of the meetings; specifics should include the frequency, roles of participants, typical agenda, and subsequent distribution of information.
The IPT should be set up so that each member is an equal participant. However, as shown in figure 1, inclusion of senior management oversight when critical decisions are made (e.g., changing requirements, altering system design, moving the schedule, and changing the budget) should be detailed in the IPT charter.
The goal of any cross-functional IPT is that members be kept informed regarding any changes to product requirements or design, targeted fielding environment, development progress, and product-related financials. The product manager will continue to communicate across the organization, but the team members carry some of the responsibility.
This cross-functional support also increases organizational awareness and alignment. In addition to representing their areas of expertise, each IPT member should communicate information from the team to their primary group and act as a source of product information back to their teams.
Helpful Resources for Team Formation
Great sources are available that can help enable effective cross-functional product development teams. I recommend the IEEE Standard 1220-2005, for application and management of the systems engineering process; the DoD’s Rules of the Road: A Guide for Leading Successful Integrated Product Teams; and guidance supporting the DevOps concept for product development.
IEEE Standard 1220-2005 provides a description of the goals of IPTs:
The interdisciplinary tasks, which are required throughout a system’s life cycle to transform customer needs, requirements, and constraints into a system solution, are defined. In addition, the requirements for the systems engineering process and its application throughout the product life cycle are specified. The focus of this standard is on engineering activities necessary to guide product development while ensuring that the product is properly designed to make it affordable to produce, own, operate, maintain, and eventually to dispose of, without undue risk to health or the environment.
The DoD guide provides best practices in support of IPT implementation as applied to the acquisition of systems and software. Many of the principles can be transferred to product development, and the guide provides good information on chartering a team, as well as an example formal charter.
DevOps principles embrace an expansion of agile practices that, instead of bounding at code check-in, include systems and operations. DevOps supports a cross-functional, commercial approach to software and systems product development through an understanding of the domain in which the software is being written.
These sources of information can provide help in building effective multidisciplinary teams to support your small and large development efforts. It is important to remember that no one solution works for every project. Do the research, understand your environment—its strengths and weaknesses, and see what aspects of cross-functional IPT deployment might work best in your product development environment.