TL;DR: An Integrated Product Team (IPT) is a cross-functional group. If everyone on the team has the same background, that’s a functional or discipline team. There’s a difference.
Designing a system requires cross-functional integration. After all, a pile of airplane components does not an airplane make; intentional integration of those components is required to get off the ground. Even more care is required to meet various stakeholder needs and lifecycle support goals.
The Systems Engineering Vee model suggests this integration happens sequentially: each functional discipline (e.g. mechanical, software, etc.) is allocated requirements for their portions, they design and develop, and then the various parts are integrated. There’s an emphasis on systems engineering rigor, finger-crossing that all the parts work when fit together, and rework when they inevitably don’t.
The Vee is a useful theoretical model, but from a practical perspective, cross-functional collaboration is more the norm. The amount and formality of this collaboration depends on the size of the program and the execution framework. For example, Agile approaches demand formally-defined cross-functional teams. Small projects with just a handful of people in each discipline may not need any formal system as they naturally work together closely.
One large-scale, formal approach is called Integrated Product and Process Development (IPPD). The core of IPPD is the concept of Integrated Product Development Teams (IPDTs). There is a hierarchy of IPDT types, as shown in the excerpt from the INCOSE SE Handbook to the right. From this, you can see how the IPDT structure mirrors the system hierarchy.
IPPD matured in the mid-1990s. The DoD recognized the value of IPPD for solving its own acquisition challenges and decided to adopt it. Since 1995, program managers for large DoD acquisitions have been required to utilize integrated product teams (IPTs) to provide development, review, and oversight of the acquisition process1.
Similar to IPDTs, there is a hierarchy of IPTs: Overarching (OIPT), Working-level (WIPT), and Program-level (PIPTs). From the figure to the right, it should be clear how the IPT structure is modeled on the IPDT structure, but for higher-level acquisition issues rather than product design and engineering.
The purpose of both IPTs and IPDTs is the same: bring together representatives from multiple organizations and/or functional areas to facilitate cross-discipline collaboration. There is a great deal of variation depending on the team’s charter. Some teams meet occasionally to answer strategic questions, some meet regularly to address program or design challenges, and some work closely together on a daily basis to design a component. Regardless, all IPTs and IPDTs must have a clear focus which requires cross-functional effort.
Over the past decade or so, industry has been more frequently using the term IPT in favor of IPDT. This isn’t necessarily a problem, though there is some benefit to distinguishing between customer and contractor roles.
What is worrying is the trend of using “IPT” to mean simply “team”. For example, “Mechanical IPT”. A team made up of only people in a single discipline cannot be cross-functional by definition. Calling that group an IPT makes the term IPT meaningless and makes it harder for projects to implement a true IPDT/IPT structure.
Why has this happened? I have no idea. One theory floated by a coworker is that projects were comfortable operating in functional silos. Some well-meaning corporate policymaker implemented IPTs and so these teams adopted the moniker in order to comply. They became IPTs in name only and that approach has persisted and become accepted in many places. A similar trend is happening today with Agile teams.
IPPD, including IDPT/IPT, is a proven and practical approach for many large projects. But, its effectiveness is hindered when the terms are used incorrectly. Please, be explicit with how teams are defined and chartered and use the most accurate terms to describe them.
Have you seen IPDTs or IPTs used particularly effectively or ineffectively? Do you prefer a different approach to cross-functional collaboration? Share your thoughts in the comments below!
Footnotes: