乍看之下，似乎是顧問公司「時間掌控」不當，然而細看合約，赫然發現其中一條寫道：「乙方（顧問公司）在專案過程中，需幫助甲方（IT公司）完善其人力資源管理體系。
……未盡事宜，雙方協商解決。」
試想，企業的人力資源管理體系豈有所謂「完善」之日？
以此做為專案的任務之一，幾乎在簽下合約那一刻起，就注定專案將永無止境。
所以，在這個例子裡，不是顧問公司時間管理有問題，而是專案「範疇的界定」不夠明確。
無法排除不必要流程，工作就做不完
根據《專案管理知識體指南》（PMBOKR Guide）的定義，以專案內涵而言，「範疇」一詞意指：
1.產品範疇（product scope）：一項產品、服務或結果所具備的特色和功能；以及／或者
2.專案範疇（project scope）：為了完成並交付一項具有特定特色與功能的產品、服務或結果，所需執行的工作。
至於專案範疇管理（project scope management）則旨在確保專案涵蓋了「成功完成專案所需的全部流程」，而且沒有一個流程是不必要存在的。
換言之，範疇管理就是在定義及控制：哪些工作應該納入專案，哪些工作又不該納入。
《我懂了！專案管理》一書指出，範疇管理是專案管理最基礎的工作，在了解所有利害關係人的需求之後，清楚地界定專案應執行的範疇（工作內容），是完成專案的重要關鍵。
界定專案範疇之所以如此重要，主要是因為：在必須達成專案目標的前提之下，如果無法決定哪些工作該做、哪些工作應該排除，將會造成工作內容無止境地延伸。
甚至，誠如山東大學專案管理研究所所長丁榮貴在《專案思維與管理關鍵》所說：「在進行專案管理範疇定義時，確定專案『不做什麼』，比確定專案『做什麼』更為重要。」
哈佛大學教授理查‧海克曼（Richard Hackman）在《領導團隊》（Leading Teams）一書中則強調，「方向不明確或極度抽象，都會浪費成員的時間。
此外，成員對實際上應該做的事，如果難以達成共識，將會令他們陷入衝突。」
至於如何落實範疇管理，《專案管理知識體指南》提出了5個流程，分別是：
1.蒐集需求（collect requirement）：定義及記錄利害關係人的需求，以符合專案目標；
2.定義範疇（define scope）：對專案與產品做出詳盡描述，包括準備一份完整的「專案範疇聲明」（project scope statement；即詳述專案的「交付標的」，以及用來產出「交付標的」所需完成的工作）；
3.建立工作分解結構（create WBS）：將專案的「交付標的」與專案工作，細分為更小、更容易管理的組成要素；
4.驗證範疇（verify scope）：專案的「交付標的」，獲得客戶或專案贊助人的正式接受；
5.控制範疇（control scope）：監視專案與產品範疇的現況，並且「管理範疇基準」（scope baseline；包括專案範疇聲明、WBS及WBA說明表）的變更。
把流程拆解到「可控制」的程度
由上可知，製作工作分解結構（WBS，Work Breakdown Structure）是範疇管理的一大重點。
《專案管理立即上手》一書指出，在專案的生命周期中，WBS扮演了舉足輕重的角色，相當於是把整個專案固定在一起的設備。
唯有在製作完成WBS之後，才能進行專案工作時間的規畫、資源的分配、成本的評估，並呈現出工作的範疇。
因此，WBS可說是一種圖像式工具，以便讓利害關係人能夠全盤地檢視專案工作，藉此確認是否有遺漏之處，掌握目前的進度。
英文諺語「你無法一口吃掉一頭大象」（You can not eat an elephant one bite），在某種程度上，還頗能傳達WBS的主要精神。
要注意的是，實際參與專案作業的人員，一定要參與WBS的建立。
通常是由專案的幾個核心人士先訂定WBS的上層部分，其他小組成員再接續其下的部分，最後再做整合。
前面曾提到，建立WBS是將專案工作細分為更小、更容易管理的單位，但究竟要細分到什麼程度？
一般原則是，精細到你可以正確地估算「細項作業」的時間和成本，或是所耗的時間單位小到等於排進度的時間單位。
舉例來說，如果你排的是每日進度，那麼就要把作業劃分到一天能夠完成的範圍；如果你要的是每小時的時程，那就要把作業細分到以小時計的範圍。
許多企業最常見的做法，是將工作分解到1～2人可以負責的範圍，以達到可管理的目標。
計畫愈周詳，範疇愈不會失控
雖然專案範疇管理是為了定義和控制「專案的範疇」，然而專案管理者在執行專案的過程中，難免會有所改變，加入許多細部的計畫外工作，導致專案範疇不斷擴大，出現無法控制的變更，亦即所謂的專案「範疇潛變」（scope creep；或譯為「範疇蔓延」）。
《專案管理聖經》一書作者詹姆斯‧路易斯（James Lewis），針對專案範疇之所以會潛變（或蔓延），提出了3個主要原因：
1.在原始的計畫中，因為疏忽而未把範疇列入。
2.在專案進行期間，才得知某項技術上的問題，可能必須進行變更；又或者是直到進入執行階段，才發現了在規畫階段還無法得知的工作。
3.在整個專案生命周期期間，環境局勢不斷地變遷，為了保持競爭力，因而必須變更專案內容。
《專案管理知識體指南》指出，當專案範疇發生變更時，也可應用「控制範疇」這項流程，而且必須與其他控制流程做整合。由此可見，即使變更是不可避免的，但還是必須「採用某種形式的變更控制流程」。
如同路易斯在《專案管理聖經》一書中所說，只要在開始規畫專案時，能夠更縝密周詳，就可避免第一種狀況；至於第二種或第三種狀況，儘管看似很難事先避免，但是在確定要變更範疇之前，也務必要確保所有利害關係人，尤其是客戶，都已同意專案範疇變更，也都明確知道變更將會造成何種衝擊。
>>
更多精采內容，請見經理人月刊9月號 
留言列表
留言列表
{{ article.title }}
{{ article.title }}
