如何確定專案的工作需求(轉)

如何確定專案的工作需求
如果把專案範圍比作一個橄欖球，那麼球內的充氣量便是專案的實際工作需求。儘管五磅的氣體和二十磅的氣體充起橄欖球的外形是一樣的，但不同的充氣量會影響著橄欖球本身的彈性，從而影響整個賽事的結果。專案管理同樣是這個道理。不同的工作需求同樣會影響專案的結果。如果僅僅建立專案範圍而沒有建立範圍內的工作需求，同樣會影響專案所需的資源、時間、功能、質量，更直接影響服務的價格，從而導致專案的全面失敗。

必須事先確定工作需求

當我們和客戶進行洽談時，大多時候是以專案範圍來定義交付。但實際情況是，很多專案儘管好像明確地建立了範圍，但在專案程式中還是面對客戶相當大的變更要求。因為儘管專案範圍是不可變的，但其中隱含的工作需求卻並沒有明文規定在合約中。這種情況下，我們怎樣才能使專案得以順利完成呢？

我常以美國的橄欖球來比喻專案範圍，從附圖中能清楚地感受到問題所在：從正面看橄欖球是橢圓形的，但從側面去看它又變成了圓形。從不同的角度來觀察橄欖球的形狀，所得到的結論是不一樣。這個橄欖球的外皮便是我們所謂的專案範圍。客戶對範圍的定義與整合商對範圍的定義往往有很多不一樣的地方，這是因為雙方審視範圍的角度不一樣所導致的。

橄欖球的外形是專案的範圍，那麼球內的充氣量便是專案的實際工作需求，五磅的氣體可以把橄欖球的外形支撐起來，同樣二十磅的氣體也不會改變橄欖球的外形，但五磅的氣體和二十磅的氣體相差四倍，不同的充氣量影響橄欖球本身的彈性，影響整個賽事的結果。專案範圍內的工作需求也同樣地影響專案的結果，建立了專案的範圍而沒有建立範圍內的工作需求，同樣會影響專案所需的資源，時間，功能和質量，更直接影響服務的價格，導致專案的全面失敗。以範圍來進行交付，在過程中又如何能夠避免範圍的變動呢？

如何在合約中確立工作需求

大部分IT專案缺乏支援文件，縱然擁有商業案例（Business Case）或其他相關文件，也不能很明確地把專案所需的工作涵蓋起來，只能建立專案的周邊，對專案的實際工作量缺乏描述，這很容易導致專案過程中所產生的變動。

為解決這個和問題，國際上已於上世紀80年代末期開始採用“工作陳述”（Statements of Work或簡稱SOW）來固定範圍，同時放棄範圍定義（Scope Definition）的應用。因為IT專案有別於其他基建專案的地方在於基建專案有其他附屬文件來支援範圍定義，比如在基建專案的專案範圍中，一般都有諸如專案的有關設計圖則、用料標準等等明文規定，讓範圍能夠非常明確地涵蓋基本的工作需求。而IT專案的專案範圍中往往沒有這樣的定義。

在上一節“如何建立專案範圍”的講座中，我們談到以商業效益來確認功能需求，再利用功能需求來建立專案範圍。而在範圍確認後，我們緊跟著必需建立詳細的工作需求和專案計劃，否則專案的工作便像橄欖球內的充氣量一般，可以按照客戶的要求隨意變動。

工作需求和專案計劃基本上是利用工作架構分解法（Work Breakdown Structure）建立。明確的工作陳述（SOW）讓渠道商或服務商瞭解本身的服務承諾，有效地建立專案的成本，降低專案過程中所產生的變動。這些工作陳述應該在銷售過程中建立，成為服務合約的內容一部分。萬一合約中只有專案範圍定義，那麼交付小組必須在交付初期建立有關的專案工作陳述，避免交付期間所產生的爭議。

利用WBS技巧建立工作需求

IT業內人士多未能把握WBS的實際應用技巧。而有如工作量估算，錯誤的工作細節將對專案計劃不利。利用“圖二”加以簡單說明：每一個專案都有不同的交付物，而每一件交付物需要經過不同的里程碑才能夠產生，同時每一個里程碑也需要經過不同的階段才能夠達到里程的目標。每一個階段需要經過不同的步驟去完成，而每一個步驟需要進行不同的工作。

每一個步驟需要完成一系列工作才能進行第二步驟，直至同一階段的步驟完成才開始第二階段，而直至全部階段完成後才能到達一個里程碑。有些里程碑內的工作可以同期進行，但有些里程碑內的工作得等另一個里程碑完成後才能夠開始。到最終完成全部的里程碑內的工作後才能夠交付專案中的某一件交付物。

利用WBS技巧來建立交付組合架構，為每一件交付物建立本身的工作需求，可以讓我們很明確地說明每一件交付物所包含的工作。這個交付組合架構更可以讓我們在同一時間為專案建立有關的工作計劃。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21224/，如需轉載，請註明出處，否則將追究法律責任。