專案執行過程最為人詬病的問題,就是用戶或sponsor持續追加需求,導致範疇不斷變更、膨脹。變更的原因有很多,最常見的情況是專案初期PM就無法明確定義範疇,也沒有讓團隊成員、用戶及sponsor都充分理解專案執行的邊界在哪裡,當邊界模糊,對於新增的需求自然也缺乏約束力,無法排除在專案之外。
在《專案管理知識體系指南》(PMBOK® Guide, A Guide to the Project Management Body of Knowledge)中,雖然有定義專案初始階段的任務,包含確認專案範疇、展開WBS...等,但如何有效界定範疇、用何種圖表來呈現,就需要靠PM自己想辦法。為了讓團隊成員及相關利害關係人都能理解專案範疇,我自己習慣使用UML中的Use Case Diagram加上流程圖的形式來輔助說明。UML是一種軟體開發的統一塑模語言(Unified Modeling Language),用來為即將開發的系統進行塑模分析,簡單來說,就是在開發前建立一個模型概念,以統一的圖文規則來表述系統架構、功能等。而Use Case Diagram是其中一種圖形工具,從高層次的角度辨識系統所應提供的功能,在圖形的繪製上,通常會有Actor(通常為某個角色,例如系統的使用者)、Use Case(使用案例,或可想像為操作行為、或者執行的功能),以及兩者之間的關聯,其中Actor和Use Case之間常為一對多關係。
舉一個簡單的例子來說明,假設專案要開發一套進出貨管理系統,那麼我們必須先釐清使用者有哪些,以及他們個別會如何進行操作。簡單的關係圖如下,業務建立訂單後,分別由撿貨員進行備料,再由送貨員遞送給客戶,其中訂單必須經過主管簽核才能正式成立,亦即一份完整的訂單包含了主管核准的動作,因此在圖形上使用虛線箭頭加上《include》標示,代表他們的關聯。每個專案、系統的情況不同,在拆解關係時務必以使用者為出發點,列出他們與系統、產品之間的互動關係即可,不須太過著墨細節,畢竟這個階段還未進入流程的分析。
當主要的關係釐清之後,接著便可從圖中找出隸屬專案範疇的部分,有時候專案必須仰賴其他系統的功能作為輔助,例如案例中的簽核流程可與公司原有的機制串接,此時便可將其排除在範疇之外,繪製出如下的關係圖。
當然,大部分的專案絕不會像範例一樣有如此簡單的關聯,且定義太過模糊也無法有效匡列範疇,因此PM必須與團隊成員一同檢視Use Case,從不同面向進行拆解,歸納出完整的關係圖。例如訂單成立後,是否需與銷用管理系統有資料的往來? 財務或經管單位是否需針對銷售金額或成果進行檢視? 這些都必須透過提問、訪談,逐步彙整而成。在匡列範疇的同時,也等於是對專案做整體評估,對後續展開WBS有極大的幫助。
為了確保盤點周詳,我通常會將Use Case Diagram當作初階範疇定義,接著再以系統的角度繪製流程圖,並將不同系統的功能或操作行為以色塊區隔,產出如下圖所示的結果。圖中我將簽核、用印歸納至合約管理系統內,並將備料過程拆解成「有庫存」、「缺貨」兩條動線,其中「向其他門市調貨」的動作,必須與相關單位確認配合方式,因此用不同的顏色來標示,作為日後討論的重點(可能會被移除在專案範疇外)。
當要對利害關係人說明專案內容時,可以著重在「進出貨管理系統」匡列的範圍內,對團隊成員則可聚焦在「與合約管理系統之間的串接點」,這是因為範疇內的任務通常掌握度較高,但與外部系統的關聯或處理不當,很可能會導致專案範疇膨脹(例如原定要與合約系統串接的項目,因為架構不符規範,必須要自行開發)。也就是說,初期流程圖所定義的,只是團隊們「期望」的範疇,它的邊界尚有模糊地帶需要進一步釐清,等到相關利害關係人都充分理解這張圖所匡列的範圍之後,才能算是真正定義完成,可以避免日後衍生的爭議。
當專案越複雜,就越需要明確定義用戶、專案範疇,以及外部系統之間的關係,日後才能辨識新需求是否屬於專案原本的範疇內。雖然這些做法無法保證專案不須變更,但可以作為開發排序的參考,越接近專案範疇核心,表示有越高的機率優先處理,當預計變更的項目有一致的評估標準,才不會讓用戶及sponsor衍生錯誤的期待,或者讓團隊成員陷入左右為難的窘境。
<文章發表於專案管理生活思維,請勿任意轉載>