首頁 專案管理
內化專案管理知識 在跨領域活化應用
2019/12/1 作家:專案經理雜誌
4162
文/徐文達, PMP

我自認是一個「不務正業」的人,學生時期主修氣象學,就業後先從氣象產品的應用,慢慢跨足到專案、產品的管理,歷經不同角色的變化。在跨領域的轉換過程中,專案管理知識扮演了很重要的角色,它讓我能夠從容掌握工作進展,並有效整合資源,就算是不甚熟悉的領域,也能夠維持不失控,爭取補足Domain Knowledge的時間。

從跨領域的關聯性切入
隨時練習專案管理
當決定從氣象產業轉換跑道成為專案經理,我深知要能活用管理知識,才是我可以和同業競爭的優勢,因此跨領域前的預先練習,就成了重要功課。首先,要找到專案管理知識在自己熟知領域裡的關聯性,從中去思考如何運用管理技能來處理?有沒有其他解決方案?或是它背後的原理是不是有共通點?

以氣象預報為例,要歷經初始資料分析、綜觀分析,最後才是預報決策,和專案管理有什麼關聯呢?

1.初始資料
在進行正式的預報之前,需先彙集最近的觀測數據,反映環境場的初始狀態。同理,在專案管理的世界,所謂初始資料,可能是人員技能分佈圖、材料設備價格,甚至是市場競業分析……等各種有助於理解現況的資訊。

2.綜觀分析
蒐集資訊的目的,在於藉由這些數據來分析現況,在氣象學中,稱為綜觀分析,所謂綜觀就是要站在一個完整的視野上,俯視全局,過程中還有一項重要的「尺度」概念,例如:當我們探討鋒面移動時,會忽略小尺度如建築物大小對氣流帶來的細微變化。若用在管理上,則類似抓大放小的概念。舉例來說,一個創新產品的重點在於快速測試市場反應,並找到對產品有決定性影響的價值,至於一些極細微的UI設計,雖然會對操作體驗有加減分效果,但在這階段或許可以降低一些要求,把資源挹注在更攸關成敗的事情上。

3.預報決策
有足夠的資訊,並且找到關鍵因子,便能針對特定項目進行預報,但預報仍有一定的不準確性,正因為如此,才需要配合日常的監控作業,隨時掌握變化。專案執行的過程中,同樣會遇到許多不可測的因素,所以規劃階段雖然已初步辨識了風險,並訂定可能的對策,但仍需要定時監控,反覆從各種徵兆中判讀風險的狀態並修正應變計畫,才能讓專案穩定維持在正軌。

簡單來說,專案的定義為「有表定的時間、工作範疇與預算,並且通常由一個團隊來運作、完成特定的產出」,因此,除了工作上的關聯,生活中也有許多專案管理的應用,例如:居家裝潢的準備與驗收、參與路跑的前置作業及訓練過程等,甚至從電視節目、電影中看到的情節,只要符合上述的某部分條件,都可以拿來做為練習標的。

跨領域的思維-如期如質之外的事
跨領域前的暖身練習,只是取得角色轉換的門票,真正的挑戰還是在於如何執行被賦予的任務。專案管理貴在如期如質,但Sponsor往往期待的是專案成效與延伸效益,所以PM更應該要從商業策略的角度釐清「為何而戰」,讓專案在「不鍍金」的前提下,發揮最大的價值。釐清為何而戰的好處,除了便於讓討論過程聚焦,也有助於團隊同仁自發性去努力達成專案目標,專案的成功機會自然就會提升,對PM來說只有利而無害。除此之外,藉由辨識方向的過程,可以看到更多市場上的資訊,同時培養對商務決策的敏感度,對於有心要轉換至產品經理的人來說,是一項非常重要的功課。

專案管理起始流程的首要任務是「確認範疇」,它不僅在釐清專案執行的邊界,某種程度來說,也是釐清為何而戰的關鍵步驟。我過去曾有失敗的經驗,當時負責一個集團內部的軟體建置案,專案本身的目標是建立一套供內部同仁使用的即時通訊App,但老闆背後的真正盤算,是希望藉由內部專案來建置可商業化的軟體架構。由於我自己和團隊成員未能充分理解專案目的,任務拆解的過程便朝著簡化的方向設計,包含使用Open source、建立彈性低的資料庫結構等,專案最後雖然「如期」完成,但它的「質」僅限於專案本身,並未達到老闆心目中的「值」。

那一次經驗之後,我開始對專案的範疇定義更加謹慎,並嘗試從不同的角度來審視專案目標,雖然有時會耗去不少時間,但透過不斷論證的過程,專案的目標就會更加明確,對後續的工作展開有非常大的幫助。

「Do the things right」 是PM所需具備的基本能力,也是執行力的展現,「Do the right things」則是一種思維與原則,是在動手做之前,PM要時時提醒自己去努力的方向。

跨領域的執行-掌握流程,事半功倍
專案經理和產品經理的英文簡稱都是PM,一個是Project Manager,一個是Product Manager,由於角色定位的關係,工作思維也會不太一樣,但在某些產業裡,兩種PM不一定有明顯的區分,至少在我的職涯歷程中,幾乎都是處在兩者並行的狀態。企業對人才的期許是多元的,不會因為你是專案經理就只求如期如質,而對產品經理來說,專案管理也是必備的知識之一。人本來就不是全能,有些人靠專案管理技巧彌補對產品的熟悉度,有些人則從產品規格去找問題的答案。

我過去經手的案子常以新功能開發為主,在釐清為何而戰、定義範疇之後,我會強迫自己短時間內勾勒第一版的WBS及時程表,雖然某些工作彼此有相依性,無法準確估算,但有了第一版後,至少對於後續的工作有初步的認知,才能辨識要將資源投入哪些關鍵任務,或者趁此時補強自己的Domain Knowledge。除此之外,初接手不熟悉的工作,不只PM本身,Sponsor可能也會有不安感,若能夠先提供初階的專案里程碑,也可以減緩來自Sponsor的關注壓力。

這套工作的基本邏輯,曾經讓我在短短4個月內,空降主導一個流程管理軟體的2.0版建置。如同前述氣象預報的流程,我先蒐集了大量1.0版本的相關資訊,做為改版規劃的「初始資料」,接著和主管及相關同仁討論改版的主要目的與方向-特別是商務面的考量,完成我的「綜觀分析」、釐清為何而戰。最後,再將這些資訊轉為具體化的工作包與時程,並且確保訂定的里程碑能有效呼應專案目標,如此一來就能向Sponsor進一步爭取更多的資源與時間。


跨領域的執行-
產品是持續不斷的小專案
釐清為何而戰、定義了範疇、也拆解了工作任務,另一個重要的工作是風險管理的運用。這裡所謂的風險管理,不單指「執行」過程的風險控管,一個產品的走向通常會歷經多面向的商務決策,每一個決定的背後,都有衍生的風險或放棄的機會成本,PM務必要將風險管理的層級往上提升到整個專案甚至整個產品。

新產品為了快速測試市場反應,有時會簡化UI設計,造成客戶操作體驗變得較差,這就是商務決策上的風險。以專案的角度來看,被捨棄的UI原本就不屬於專案範疇,但換個角度來思考,何不將它視為下一個專案? 產品開發過程有一個重要的PDCA循環(Plan、Do、Check、Action),每一次PDCA的運作,都可以視為一個專案的生命週期。專案本身在結束的階段,就對Lessons Learned有所著墨,狹義來說是將專案執行的經驗透過文件紀錄來保存,提供給其他專案參考,廣義來說,也可以用來闡述這一個專案還有哪些被捨棄而未執行的項目,是否值得下一個專案繼承?如此一來,產品便能拆解成數個延續的專案,對專案經理來說,執行上就相對容易了。

依據上述的邏輯,我的2.0版流程管理軟體實際上也可視為一個過渡專案。我和主管們釐清目標客戶的需求排序,將重要的、可快速改善的功能列入2.0版範疇,例如:自建表單欄位,並暫時捨棄外部檔案匯入的功能。對於專案本身而言,開發風險在於自建欄位的多元性,它必須藉由大量的客戶訪談來進行歸納,會耗去不少時間。但被捨棄於範疇外的檔案匯入功能,則可能造成部分客戶抱怨,是我們要面對的另一層風險,而這一層風險,若沒有事先被納入考量,就會造成後續銜接上的困難。於是我們在定義2.0版範疇的時候,就同時保留部分擴充性,讓自建欄位所無法完全滿足的需求,透過未來要開發的外部表單匯入來實現。

除此之外,源自於風險管理的精神,我習慣將重大決策的論證過程記錄下來,做為下一次爭議發生時的佐證資料,這個習慣也讓我無形中養成對商務策略的理解,同時也成為後續2.1、2.2版「為何而戰」的重要資訊。

當產品被拆分成數個專案,專案可獨立執行,同時彼此之間又保有強大關聯性。藉由這種專案拆解模式,不斷練習、改善,讓我對於產品規格有更深的認知,清楚了解每一個功能的存在原因,久而久之,也就更能勝任產品經理的職務。

檢視我自己的職涯發展,我將專案管理視為一種工作邏輯,而不侷限在專案經理的角色應用上,當內化了專案管理知識後,可以應用在許多不同的地方。一旦知識被活化應用,就如同程式語言內的物件一樣,任一管理技能都可以隨時被繼承使用,不論是策略分析、或跨足到不同領域,都能找到立足點去發揮,成為更有價值的工作者。

PM2.0 升級版專案經理

以往的專案經理只需要專心地執行專案,致力於完成專案即可。但時代轉變,產品以及客戶的需求變化速度快速,若是不拉高視野具備高階主管的思維...
PM2.0 升級版專案經理
專案經理雜誌
《專案經理》雜誌是華人最有影響力專案管理雜誌,宗旨為擴大專案管理應用傳播。
邀您一同為深耕專案管理努力,您的參與,相信能為您的產品/服務,擴展商機, 無形中,也為專案經理雜誌的永續經營注入契機。
您可能也喜歡這些文章