想像這個畫面:您正因專案和交付項目而忙碌萬分,突然之間,接獲跨職能的專案關係人請求增加額外的交付項目。您並未真正針對該項目進行規劃,但因為夠簡單可以完成,所以您同意了。接著,幾天之後又來了一封電子郵件。突然間,您的專案不再進度正常,而是延誤且不甚成功。
您經歷的正是範疇潛變—而這可能發生在我們大部分人身上。在本文中,您將瞭解您需要知道範疇潛變相關成因,以及如何加以預防的所有知識。
在專案管理中,專案範疇是專案中需求和交付項目的綱要。通常會在專案規畫流程初期將範疇定義好,且在您的專案計劃、藍圖或簡介中應涵蓋此內容。當請求和交付項目會超出預先設定的專案範疇,就會發生範疇潛變。
當您建立範疇管理計劃,您就是在自己 (專案經理) 與所有專案關係人之間形成共通的理解基礎。若不建立專案範疇,可能導致資訊不一致及誤解。沒有定義好的專案範疇,您就無法清楚定義、預先核准控制事項,決定哪些應該、而哪些又不應該包含在您的專案交付項目中。
有時候,範疇潛變可能無傷大雅——可能只是多一兩個交付項目,儘管麻煩但不對專案造成重大改變及影響。但嚴重的範疇潛變則可能拖垮專案,使專案無法成功,因為它會干擾您應投入在專案目標的注意力。將時間花費在這些新增的請求和交付項目,就表示時間無法運用於專案真正的目標上,而且也可能導致過勞或工作過度。
有鑑於此,若要預防範疇潛變,您首先必須有清楚定義的專案範疇。令人欣慰的是,定義專案範疇並不如您可能想像的那般困難。多數時候,專案範疇是寫下您已在其他稍早專案文件建立之參數 (例如您的專案簡介) 的一種方法。
若要識別並建立您的專案範疇,請依循這五個步驟進行:
從「為什麼」開始。為什麼您和團隊要執行此專案?您希望達成什麼目標?明白自己想要達成的目標規模和範疇,有助您定義專案範疇。
納入您的專案目標。 您的專案目標和專案範疇彼此緊密連結。專案目標定義了專案設定的目標,因而必須符合並落入專案範疇之中。
寫下您的專案範疇。 請記得,這部分不需要很冗長。專案範疇只是讓您清楚概略列出專案交付項目,以及這些交付項目如何與專案目標相關的地方。也可儘量利用項目符號。
審查您的專案範疇。 確認自己取得專案關係人的認可,且所有人對專案交付項目、目標和範疇均有一致的共識。
必要時應進行調整。 若您在第四步驟中並未達成一致共識,應花點時間重寫您的專案範疇。進行最終確認潛,請將文件再次呈現給專案關係人審閱,確保他們認可。
沒人想看到自己的專案失敗或對原來的目標失焦。以下是範疇潛變最常見的成因,以及您可以如何加以預防。
這可能是顯而易見的一個,但卻可能重複發生。若沒有專案範疇,您就沒有清楚的方法向參與的所有人就專案範疇達成共識,並加以溝通。此外,若您與外部團隊或代理商合作,當專案關係人試圖新增元素到您的專案時,您也沒有可參考的工作說明書 (SOW)或文件。
務必在專案之初就建立並定義專案範疇。不妨將它新增至專案計劃或其他早期文件中。如此一來,您所有早期專案文件中就會涵蓋專案範疇的基準。
閱讀:如何建立一個可讓您進展順利的專案計劃有了專案範疇後,您還必須向外分享。若您未有效 (在專案初期) 分送該文件,專案關係人就無法始終獲得最新更新資訊。儘管您已花了時間建立專案範疇,若不是每個人都知道它的存在,您仍可能因資訊不一致或甚至專案失敗而獲得慘痛的結果。
務必將專案範疇納入所有初期專案文件,例如專案計劃或專案簡介。如此一來,所有人均可存取專案範疇說明書,進而可以在專案開始前就先解決任何資訊不一致的問題。
說到底,您是因為以特定交付事物為目標,才執行此專案。那些成果和資產就是您的專案目標。
當您擁有清楚的專案目標,專案團隊就能輕易深入洞察哪些任務是 (而哪些不是) 對專案最終成功有所貢獻的。這樣一來,您就能將精神和精力專注於高生產力、高優先順序的工作。相反地,若您沒有清楚的專案目標,團隊成員就可能不知道哪些工作要優先進行,而且最後他們可能會執行一些對專案目標沒有貢獻的任務。
專案目標不清的範例: 改善公司部落格,以便呈現我們讀者喜愛的故事。
專案目標清楚的範例: 在 Q1 設計五種不同類型的部落格,包括但不限於客戶故事、提示、新產品特色、團隊聚焦以及思維領導。緊密地監控各個新部落格貼文的互動情況,以便決定未來幾季要持續聚焦的前三個種類。
閱讀:如何撰寫高效的專案目標 (附帶範例)好吧,或許您的專案目標很清楚,但若這些目標不是您團隊實際可以在一定時間內 (且在您專案範疇內) 達成的,那麼您的專案就不可避免地會失敗或遭遇範疇潛變。
務必確認自己能在時間範圍內、用您團隊的資源達成目標。將您的專案目標拿來與範疇和專案排程相互對照比較,以確認您最終可成功實現專案。若您未在專案之初就確認專案目標和專案範疇的一致性,那麼幾乎不可能管理範疇潛變的問題。
閱讀:IT 專案管理:經理及其團隊指南若每個人都想掌舵,真的很難讓專案朝對的方向前進。若沒有清楚的專案所有者 (即專案經理),您的工作就可能變得混亂,而範疇也可能變得含混不清。
儘管專案有各個不同的專案關係人和協作者,請確認每個團隊都有一位專案主管,且由他直接負責推動工作的進展。若要增加其他專案角色,不妨建立 RACI 矩陣。RACI 意指專案管理的四個主要角色:
執行者。 此為推動專案的人員,做大部分實際的決策。
核准者。 有時您可能需要一位或一群專案關係人的核准。例如,舉幾個例子來說,核准者可能會設定預算、目標或基調。
指導者。 身為指導者的專案關係人是您可能會匯報進度,聽取其意見、深入見解或指引的人。執行者和核准者這兩個角色有最終決定權,而指導者的角色則通常是該領域裡的專家。
知悉者。 此為需要知道您專案的任何人。知悉者這個角色可能包括您的專案團隊、跨職能專案關係人或高階領導主管。
即使有清楚定義的角色,您仍需要制定有效的變更管控流程。變更管控是變更重要或基本專案元素 (包括專案範疇) 的流程。別讓專案關係人逕自進行變更,而要透過變更管控流程實施一套規則和限制,從而引導所有專案變更。通常這會包含讓團隊成員或專案關係人提交變更請求、由專案經理和其他重要的專案關係人審查,以及再由系統判斷是否接受、拒絕或延遲這些變更的流程。
變更管控流程至關重要,因為這可讓您重拾對專案的掌控,同時又允許在絕對必要時容納新增新請求的彈性。有了變更管控流程,專案細節可能會改變。但若真的改變了,您可以確定改變是基於對的原因。
客戶回饋是面向客戶工作 (例如新產品或行銷活動) 的關鍵。但若您不主動收集回饋,可能會在進度後期才取得客戶回饋,而完全改變了專案的初衷、範疇、時間軸或目標。這樣的轉向可能包括改變您已在執行中的項目,或再徹底重頭開發新功能和新需求。
您是常人,而您的客戶也是。最後一刻的變更的確會發生,事實上,您對此能做的僅止於此了。有時您會需要變更專案的一大部分元素,而您可能無法事先做點什麼來阻止這一切的發生。
減少這件事發生機會的最佳方式,就是儘早取得大量的客戶回饋。定期向使用者收集回饋,並積極收集客戶回饋。如需更多提示,請試用我們免費的使用者研究範本。
好吧,您的專案已經開始進行了,而您對範疇潛變感到憂心:那現在該怎麼辦?
若覺得範疇潛變發生了,您可以做以下幾件事:
重新提出專案範疇。 若專案關係人催促新的交付項目,請提醒他們專案範疇以及哪些包含在內、哪些不包含在內。希望這樣有助整個專案團隊就專案的需求重新達成一致的認知。
若這麼做無效,請試著使用變更管控流程。請讓請求者透過您設置的變更管控流程提交請求。接著,與您的專案關係人一起審查這些請求並決定是否值得為該請求變更專案範疇。
若範疇改變已被接受,不妨重新安排另一項交付項目的優先順序。您是否可延遲任何事項,或整個予以刪除,以便為這項新的工作挪出空間?
若無法重新安排目前已計畫工作的優先順序,請看一下專案資源。使用您的資源管理計劃來查看是否有任何您可使用的資源,來協助達成專案目標。
為了辦到這一切 (獲得並維持您專案範疇、目標和計劃的明晰度),請使用 Asana 這類的工作管理工具。您可藉由 Asana 管理整個工作流程,把它與整個專案團隊分享,好讓所有人有一致的共識。
有些人可能會說:「欸,範疇潛變本來就會發生。」但其實不儘然一定如此。若有清楚的專案範疇,可檢視的專案計劃,以及易於使用的工作管理解決方案,您就能達成專案目標,而無須超出專案範疇之外。
準備好開始使用工作管理工具了嗎?請深入瞭解 Asana。