如果把項目范圍比作一個橄欖球,那么球內的充氣量便是項目的實際工作需求。盡管五磅的氣體和二十磅的氣體充起橄欖球的外形是一樣的,但不同的充氣量會影響著橄欖球本身的彈性,從而影響整個賽事的結果。項目管理同樣是這個道理。不同的工作需求同樣會影響項目的結果。如果僅僅建立項目范圍而沒有建立范圍內的工作需求,同樣會影響項目所需的資源、時間、功能、質量,更直接影響服務的價格,從而導致項目的全面失敗。
必須事先確定工作需求
當我們和客戶進行洽談時,大多時候是以項目范圍來定義交付。但實際情況是,很多項目盡管好像明確地建立了范圍,但在項目進程中還是面對客戶相當大的變更要求。因為盡管項目范圍是不可變的,但其中隱含的工作需求卻并沒有明文規定在合約中。這種情況下,我們怎樣才能使項目得以順利完成呢?
我常以美國的橄欖球來比喻項目范圍,從附圖中能清楚地感受到問題所在:從正面看橄欖球是橢圓形的,但從側面去看它又變成了圓形。從不同的角度來觀察橄欖球的形狀,所得到的結論是不一樣。這個橄欖球的外皮便是我們所謂的項目范圍??蛻魧Ψ秶亩x與集成商對范圍的定義往往有很多不一樣的地方,這是因為雙方審視范圍的角度不一樣所導致的。
橄欖球的外形是項目的范圍,那么球內的充氣量便是項目的實際工作需求,五磅的氣體可以把橄欖球的外形支撐起來,同樣二十磅的氣體也不會改變橄欖球的外形,但五磅的氣體和二十磅的氣體相差四倍,不同的充氣量影響橄欖球本身的彈性,影響整個賽事的結果。項目范圍內的工作需求也同樣地影響項目的結果,建立了項目的范圍而沒有建立范圍內的工作需求,同樣會影響項目所需的資源,時間,功能和質量,更直接影響服務的價格,導致項目的全面失敗。以范圍來進行交付,在過程中又如何能夠避免范圍的變動呢?
如何在合約中確立工作需求
大部分 IT 項目缺乏支持文檔,縱然擁有商業案例( Business Case )或其他相關文檔,也不能很明確地把項目所需的工作涵蓋起來,只能建立項目的周邊,對項目的實際工作量缺乏描述,這很容易導致項目過程中所產生的變動。
為解決這個和問題,國際上已于上世紀 80 年代末期開始采用“工作陳述”( Statements of Work 或簡稱 SOW )來固定范圍,同時放棄范圍定義( Scope Definition )的應用。因為 IT 項目有別于其他基建項目的地方在于基建項目有其他附屬文檔來支持范圍定義,比如在基建項目的項目范圍中,一般都有諸如項目的有關設計圖則、用料標準等等明文規定,讓范圍能夠非常明確地涵蓋基本的工作需求。而 IT 項目的項目范圍中往往沒有這樣的定義。
在上一節“如何建立項目范圍”的講座中,我們談到以商業效益來確認功能需求,再利用功能需求來建立項目范圍。而在范圍確認后,我們緊跟著必需建立詳細的工作需求和項目計劃,否則項目的工作便像橄欖球內的充氣量一般,可以按照客戶的要求隨意變動。
工作需求和項目計劃基本上是利用工作架構分解法( Work Breakdown Structure )建立。明確的工作陳述( SOW )讓渠道商或服務商了解本身的服務承諾,有效地建立項目的成本,降低項目過程中所產生的變動。這些工作陳述應該在銷售過程中建立,成為服務合約的內容一部分。萬一合約中只有項目范圍定義,那么交付小組必須在交付初期建立有關的項目工作陳述,避免交付期間所產生的爭議。
利用 WBS 技巧建立工作需求
IT 業內人士多未能把握 WBS 的實際應用技巧。而有如工作量估算,錯誤的工作細節將對項目計劃不利。利用“圖二”加以簡單說明:每一個項目都有不同的交付物,而每一件交付物需要經過不同的里程碑才能夠產生,同時每一個里程碑也需要經過不同的階段才能夠達到里程的目標。每一個階段需要經過不同的步驟去完成,而每一個步驟需要進行不同的工作。
每一個步驟需要完成一系列工作才能進行第二步驟,直至同一階段的步驟完成才開始第二階段,而直至全部階段完成后才能到達一個里程碑。有些里程碑內的工作可以同期進行,但有些里程碑內的工作得等另一個里程碑完成后才能夠開始。到最終完成全部的里程碑內的工作后才能夠交付項目中的某一件交付物。
利用 WBS 技巧來建立交付組合架構,為每一件交付物建立本身的工作需求,可以讓我們很明確地說明每一件交付物所包含的工作。這個交付組合架構更可以讓我們在同一時間為項目建立有關的工作計劃。
原文轉自:http://www.anti-gravitydesign.com