IPMS（Integrated Project Management System），是一個為上海貝爾阿爾卡特某移動事業部門定制化開發的多系統集成項目管理系統，其目標是通過對該部門整個開發管理工具環境的集成來達到對項目的實時跟蹤和管理，以及數據的采集和度量。然而，一個客觀事實是，國內大量的中小型項目中的絕大多數都存在著需求不明確性的問題，伴隨而來的是大量需求變更所帶來的開發 風險。那么面對這樣的客觀事實，是否意味著 項目經理根本無法應對這樣的問題呢？真正優秀的項目經理又會如何挑戰需求不明確和需求變更所帶來的開發風險呢？
[案例背景]
背景描述1: 隨著阿爾卡特與朗訊科技的合并，該移動事業部門也將與原兩家公司的多個部門進行合并。合并后的新部門將采用全新的產品線定義，并實施新的項目管理流程。在這樣的情況下，以前的IPMS系統已經無法滿足該事業部門對項目的流程管理，IPMS系統三期開發勢在必行。
背景描述2: IPMS系統作為一個集成化的管理系統與眾多功能強大的軟件系統集成，其中包括ClearQuest，一個強大的事務狀態管理軟件。原先IPMS與ClearQuest通過一組ClearQuest軟件預先定義的API進行數據通訊。
[提出問題]
由于合并的時間過于倉促，以及部門之間的項目數據定義和管理流程的不同，導致IPMS三期開發的需求極不明確，整合后的新部門內部還在為部門的項目管理的流程定義和系統可能的功能修改爭論不休，在這樣的情況下，項目進展十分緩慢。
IPMS三期的第一個迭代中有這樣一個非功能性需求，即ClearQuest的版本升級，隨之而來的一個風險便是，伴隨著ClearQuest的版本升級，沒有人知道原版本中與IPMS數據通訊的API接口是否可以向下兼容。
[解決方案]
1．基于現實的問題，即該事業部門確實無法在很短的時間內協調和構思出統一的系統需求，以及部門希望盡快將部分功能使用起來的愿望，項目組采取了基于需求基線化管理的迭代開發。項目組采用了合適的開發步驟，首先基于目前的需求不穩定性項目組決定了以一個月為開發的迭代周期；然后在策劃期提取出一組客戶的高端需求，通過對需求的簡要分析和工作量估算，并依據一組參數（比如重要性，緊急程度和需求的穩定程度）規劃出一個月內（一次迭代期）的項目需求；對這些需求建立基線，一旦需求的基線確立，那么在這個迭代周期內的需求應該是穩定的；最后項目組在一個迭代周期內，通過依據 CMMI的流程對系統進行三期開發。
通過這樣的方式，能夠盡可能的降低需求不明確所帶來的開發風險，增強需求的可管理性，但是如果在迭代內部發生了需求的變更又該如何處理呢？
2．項目組通過對風險可能的發生時間點和閥值的控制，來管理風險的危機。
項目組首先識別出了ClearQuest升級后的API兼容性風險；同時，通過討論，項目組確定了這個風險可能轉化為問題的時間點，即一旦完成三期對項目注冊功能的修改后，必須在測試時確定IPMS中注冊的項目數據是否可以正確的被保存入ClearQuest中，我們可稱那個時間點為A時間點；當項目的開發活動快到達A時間點之前，項目組安排人力對新版本ClearQuest中的相同API進行了簡單的功能原型測試，測試結果表明確實存在兼容性問題；項目組立刻決定修改項目計劃，并在原先的風險預留的時間段內增加了對API兼容性問題的處理事務，從而解決了ClearQuest版本升級可能導致的系統無法正常注冊項目的重大問題，使得項目得以平穩開發。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
