The US DoD has had the concept of the Integrated Product Team (IPT) for a couple of decades. If you search "Crosstalk, the journal of defense software engineering", you'll find zillions of articles that reference the IPT.
And, if you search www.dau.mil, you'll also find a wealth of material. As the agile folks go about with multi-functional and persistent teams, they'll find that's an idea that was mature in DoD before the agilists were organized.
Here's few important points about integrated product teams (taken from training materials produced by Space and Naval Warfare Systems Command (SPAWAR) San Diego Systems Center):
- IPTs are cross-functional teams that are formed for the specific purpose of delivering a product for an internal or external customer
- IPT’s implement the IPPD Process. DoD defines Integrated Product and Process Development (IPPD) as “A management process that integrates all activities from product concept through production/field support, using a multifunctional team, to simultaneously optimize the product and its manufacturing and sustainment processes to meet cost and performance objectives.”
That's all well and good, but here's where their power comes from (and agilists will be sympathetic to this list)
- (Team) must have vision or objective defined, including level of authority
- Team should be multidisciplinary
- Members must have both mutual and individual accountability
- (Team) must have a decision-making process defined
- Team members empowered to make decisions
- Cost, schedule, and performance parameters pre-defined for the team
- OIPTs (Overarching IPT)
- acquisition oversight - IIPTs (Integrating IPT)
- coordinates WIPT efforts and covers all topics not otherwise assigned to another IPT - WIPT (Working level IPT)
- focuses on a particular topic - Program IPTs
- provides for program execution
The first step was to determine the IPTs. The program manager and his functional chiefs decided which major products or components needed direct management by an IPT.You've probably got enough to get started.
Next they took the necessary time to carefully craft a charter for each IPT. The charter had to be specific, not at high level, not vague or timid. It had to contain milestones, outcomes, or specific objectives.
The charter had to state the IPT’s authority and the next level of reporting for the IPT. The program manager and his chiefs named in the charter an IPT lead whose responsibilities were stated, which did not include any functional responsibilities. Finally the charter was signed by the program manager. Each charter was eventually posted in the IPT’s team area
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog
