4.集成的項目管理
當項目的交付物由多個獨立的團隊產品化了，可以應用集成的項目管理（IPM）。集成項目管理的因素有很多，比如：
● 功能分布的團隊
● 地理位置分散的團隊
● 產品大小
● 多種技術
● 軟件外包
這些因素使得項目溝通變得分散，以至于產生了需要直接應用于軟件產品開發中的集成的需求。集成的需求越大，使用系統的和經過訓練的項目管理原則更重要。
4.1 集成項目管理的框架
在第3部分討論的過程模型形成了集成項目管理（IPM）的框架。在產品開發的啟動階段，許多功能組因許多工作特性而形成。但并不是所有的功能。例如，市場組的形成不同于開發組，但開發組可能會與產品支持組有所重疊。同時，應該有意識地努力來正式將團隊組織到已經定義好的框架中。在以上所討論的模型中，每一個組件是產品開發的一個子項目。每一個子項目都應該有明確定義的范圍、進度、資源和成本邊界。每一個子項目的項目經理對項目邊界負責。下圖表示項目體系結構如圖2
圖2 子項目的接口體系結構
產品經理由子項目經理輔助來負責產品管理。對于每個子項目，子項目經理（SPM）負責相應的團隊的管理。這并不是新概念，但是這里所指的是，為了有一個成功的產品管理，這個框架并沒有清晰地定義和組織，有許多實例都假定使用此結構，但是，團隊間在范圍、資源甚至成本方面都還實際上很模糊。
4.2 高級WBS
創建高級工作分解結構（WBS）是進行一個完整的集成項目的第一步。所選擇的結構影響如何管理項目。功能結構增加了接口的數目和復雜性。WBS的級別可以用以下方式來選擇：
● 產品開發中所涉及到的所有活動
● 可以給每一個活動分配一個或多個組
● 減少重疊
● 為每個子項目經理在子項目范圍內確定功能留有余地
如圖3所示可以給出一個責任分配矩陣
圖3責任分配矩陣的例子
4.3 管理接口
高級別的工作分解結構定義了子項目的范圍，自此，子項目的項目經理具有執行工作分解結構的任務的責任。每一個子項目與其它子項目都有獨立的接口。一個子項目中一個任務的輸出，形成另一個子項目中一個任務的輸入，這是接口（圖4）。例如，錯誤消息編號模式，是體系結構組的輸出，它又是形成更低一級設計的開發組的輸入。
