領導 Leadership > 領導力
feature picture
2

專案牽一髮動全身!貫穿五大流程,整合所有專案活動

經理人編輯部
2009-09-01
分享
收藏
已完成
已取消

專案要成功,需要專案經理(PM,project manager)的縝密規畫、徹底執行與嚴密控管,以求在交期、品質與成本間取得最佳平衡。

專案管理不僅需要縝密的規劃,更需要整合各知識領域與流程的全面掌控。《經理人》推出的線上課程「從觀念到實踐一次學會|專案管理 15 堂課」,以結構化的教學設計,帶領專案經理深度學習如何兼顧交期、品質與成本,協助專案順利推進並達成目標。

要做好這件事,專案經理必須融合專案管理各知識領域的知識,應用在五大流程中,對每件事「為什麼要做」「該做什麼」「要怎麼做」有通盤了解,才能確保所有工作都能做到位、不出錯。

專案牽一髮動全身,不可視為獨立事件

這項「協調專案各項活動」的任務,在專案管理稱之為「專案整合管理」(Project Integration Management),也就是藉由釐清專案管理與執行的架構、說明各項管理活動之間的關係,協調各個不同的知識領域,將專案管理五大流程及其各項子流程結合起來,成為一整個連續而緊密的系統,以達成專案目標,並滿足專案利害關係人的需求。它是專案經理能否成功管理專案的第一道門檻,也是決定專案成敗的關鍵。

專案整合管理之所以如此重要,是因為一項專案在實際執行時,各項活動與流程都不可能獨立於他者之外,必定會彼此影響與牽連。專案經理若未能以「整合全局」的心態主事,只將各項工作視為「獨立事件」來思考與管理,很容易便會忽略許多隱藏性的問題,導致計畫在進入執行階段時,必須不斷地修正,甚至是決策難以落實的情形。

舉例來說,在一個資料庫系統的建置專案中,若打算增加資料庫的容量,絕不是增加硬體預算,多買兩顆硬碟就可以打發,還必須考量硬體相容性、程式改寫、預算排擠等問題;而這些工作便牽涉了成本、時程、風險等不同專案知識領域的內容。

因此,在擬定、甚或變更任何計畫之前,專案經理都要以整體的視野,確認各項活動的影響範圍,利用如「實獲值管理」(Earn Value Management)等工具,掌握對專案品質影響甚鉅的範圍、成本和時間這三大要素,做好通盤考量,以做出最佳決策。

貫穿五大流程,整合所有專案活動

相對於專案管理的其他知識領域,整合管理由於必須「整合專案所有內容」,因此其工作顯得非常龐大複雜。根據國際專案管理學會(PMI,Project Management Institute)的定義,專案整合管理依照專案的 5 個流程,主要包含以下 6 項工作:

起始階段:1. 發展專案章程(Develop Project Charter)

「專案章程」指的是「核准此一專案,並授予專案經理合法分配與運用組織資源的權力,來達成專案目標」的正式文件。「發展專案章程」就是將專案的需求與目標,「文件化」為合約、專案工作說明書等,再經由專案發起人認可,專案經理便可獲得向組織其他部門取得資源的合法性,正式啟動專案。

規畫階段:2. 發展專案管理計畫書(Develop Project Management Plan)

「專案管理計畫書」是用以定義專案該如何執行、監控與結案的說明文件。在制訂過程中,專案經理必須對必要的各項活動進行定義與整合,並協調各項子計畫,例如範圍管理、時間管理、成本管理、風險管理等等,使之成為完整且可執行的專案管理母計畫。

執行階段:3. 指導及管理專案執行(Direct and Manage Project Execution)

「指導及管理專案執行」是指,由專案經理和團隊成員負責執行專案管理計畫,完成各項專案工作。在過程中,專案經理除了必須帶領團隊成員,漸次產出具體的產品或服務,還必須評估專案執行的績效,製作工作績效資訊表。此外,若遇到無法順利執行專案或發生作業問題,專案經理亦可提出變更請求,或進行糾正措施。

監控階段:4. 監控專案工作(Monitor and Control Project Work)

專案團隊在執行計畫的整個過程中,必須進行持續性的監控,以了解專案執行的績效,其行動可分為「預防」和「改善」兩部分:針對潛在問題,採取有效的預防措施;若發現錯誤已發生,則必須採取適當的補救措施。

5. 執行整體變更控制(Perform Integrated Change Control)

在實務上,幾乎沒有一個專案能夠百分之百按照原訂計畫進行,為因應變化,專案計畫會需要進行許多「變更」。然而,每做一次計畫變更,都會影響到日後的成本估算、活動順序、行程日期、資源需求及風險控管的決策,因此專案經理必須以整體的角度,對「變更」進行控制、確認與紀錄。

結案階段:6. 專案結案(Close Project or Phase)

「專案結案」在程序上,可大致劃分為以下兩者:

  • 「外部的」合約結案程序:著重在如何依合約結案,透過驗收專案文件,與顧客或發起人協調互動,共同驗收專案成果
  • 「內部的」行政結案程序:專注於組織內部的專案紀錄,藉由各種結案文件與資料檔案,進行組織的專案知識管理。

簡而言之,由於專案是一連串環環相扣的活動,所以專案經理必須透過整合管理,來確認專案的架構,說明工作關係,辨識、定義、結合、統一與協調專案管理的各個流程與活動,從而有效分配有限的資源,協調促成專案的各項工作,確保所有流程都能緊密結合,有效達成專案目標。

領導 Leadership > 團隊管理
feature picture
3

如何將敏捷精神導入團隊?滿足這個「意圖」,專案成員更加自動自發

整理.撰文 周頌宜
2022-04-18
分享
收藏
已完成
已取消

「如果一間公司自身的研究無法讓產品持續升級,其他公司就會取而代之。」破壞式創新大師克雷頓.克里斯汀生(Clayton Christensen)在《創新的兩難》提到,求新求變才是適應市場、不被淘汰的法則。

快速修正、調整產品,視變化為常態,也是敏捷管理的精髓。《學會專案管理 12 堂課》指出,敏捷團隊的最高宗旨就是在最短的時間內,開發出可用的半成品或成品,讓客戶試用後,根據回饋意見,重新製作出符合客戶要求的最適產品。

快速回應變化、持續優化成果是敏捷管理的核心精神,而實現這一目標,需要結合專業的管理方法與工具。《經理人》推出的「從觀念到實踐一次學會|專案管理 15 堂課」線上課程,深入解析如何在短時間內完成迭代開發,並讓團隊在變化中穩步推進,實現最佳成果。

延伸閱讀:敏捷開發不只是專案管理法,而是整個組織的變革!拆解 7 大變革要素

專案負責人聚焦「該做什麼」,敏捷大師協助「怎麼做」

台灣敏捷協會理事長張昀煒分析,在工業化時代,標準化、量產的工作模式,只須由專案負責人規畫步驟,每個人負責單一任務,各司其職就能完成工作。

但是,隨著專案複雜程度提高,再加上教育普及,員工希望工作不只是餬口飯吃,不只是做主管交派的工作,而是追求成就感與自我實現。因此,如今的專案管理強調團隊有沒有自主性,能不能主動解決問題、達成目標,發揮敏捷的精神。

張昀煒表示,實務來說,專案負責人的職責是對外與客戶溝通、交付團隊任務、掌握工作進度、控管成本與風險。想要打造敏捷專案團隊,還需要一個敏捷大師,也稱作敏捷教練,由第三人協助,避免產生上對下的關係,喪失團隊自主的意義。

《SCRUM 敏捷產品管理》解釋,專案負責人和敏捷大師的功用相輔相成,前者聚焦「該做什麼」(what),打造正確的產品或服務;後者重視「怎麼做」(how),運用正確的方式實施敏捷。

台灣敏捷協會理事林裕丞補充,當敏捷組織漸趨完善,專案負責人調派任務的功能就會被稀釋,因為專案如何執行、做多久都由團隊自行決定。這時,專案負責人好比老船長,具有通訊、運輸、氣象等專業知識,隨時站在船上制高點,觀察天象、潮汐、海浪,引導船員完成任務,並在預定的時間內抵達目的地。

也就是說,無論團隊是否配置敏捷大師,專案負責人都應該運用敏捷精神,將自己視為一個整合者、溝通者、協調者。

國際專案管理學會理事長高治中說明,不是每個專案都必須有敏捷大師,關鍵在於運用管理手法,如授權、信任團隊等作為,讓專案團隊形成一個自主管理的組織。

團隊介於 5~9 人,分工明確、溝通效率高

如何將敏捷精神落實到團隊?《Agile 成功法則》建議,建立人數介於 5~9 人的團隊,原因是依據米勒定律(Miller's Law),人腦的短期記憶能夠同時保有、立即使用的資訊約 5~9 個,共事成員保持在這個數量,就能清楚知道彼此的工作狀況。當人數少於 5 人,成員可能身兼多職;當人數大於 9 人,溝通的複雜度提升、頻率降低,甚至形成派系、敵對關係,都是敏捷管理的阻礙。

至於組織的形式,《學會專案管理 12 堂課》認為折衷型的矩陣式組織(matrix organization),較能夠在維持日常工作的同時,完成專案任務。平時,人員依照各自的專長歸屬功能性部門,如行銷部、會計部等,一旦設立專案目標,從各部門中挑選適任的成員組成臨時團隊,結束後回歸各部門。

在矩陣式組織之下,根據專案負責人指派形式的不同,細分為3類。

1. 弱矩陣: 指沒有專責的專案負責人,由各部門推派協調員,共同掌握專案進度。適合小型、短期,已有操作經驗的專案。

2. 平衡式矩陣: 最常見的專案組織,由較資深的員工擔任專案負責人,負責專案的成敗,成員除了聽從原部門主管的指揮外,也要接受專案負責人的調度。

3. 強矩陣: 公司有專責專案管理部門,擁有多位受過專業訓練的專案負責人。當新專案成立,由此部門派出專案負責人,延攬其他不同功能部門的同仁。依據專案種類、時間、人力等差異,運用相對應的組織類型,完成預定目標。

負責人掌控團隊目標的同時,協助成員實現個人需求

除了團隊模式,成員投入度也是達成敏捷組織的關鍵。《我懂了!專案管理》強調,只有在人員的個人需求獲得滿足時,他們才能傾注全力完成任務。因此,成員不只要具備完成工作的特定技能,像是撰寫文案、開發程式等,更重要的是參與這項專案,可以獲得成就感。

多數時候,成員都會有自己的隱藏意圖(hidden agendas),也就是不想讓他人知道的目標,可能是得到升遷機會、培養新技能、增加經驗等。

專案負責人要想辦法獲取成員的信賴,除了關心工作上遇到的困難,也要觀察員工的心情,適時給予鼓勵及協助;一方面嘗試達成團隊目標,也要協助他們完成個人目標。

另外,多授權團隊做決定,也能提高員工投入度。《敏捷專案管理基礎知識與應用實務》提到,專案負責人必須從傳統的命令和控制(command and control)領導模式,也就是由主管下達指令、分工與監控,轉換成僕人式領導(servant leadership),任務不再只由專案負責人規畫,而是團隊共同討論、合作。

張昀煒舉例,就像做一本雜誌,其中有很多細節任務,包括企畫題目、約訪、採訪、寫稿等,不是由總編輯告訴大家要做什麼,而是由記者發想,依照個人經驗找答案,這就是給予成員空間。

延伸閱讀:授權給員工,他卻覺得工作變多了... 主管「放手」的幅度怎麼拿捏?

多問問題、少講答案,引導成員思考解方

僕人式領導者的最重要技能就是傾聽,只問問題而不講答案,藉由詢問,引導人員思考解決方案,讓團隊做決定。這樣做的好處不只是訓練成員解決問題,還能減少衝突、促進理解。

具體的提問方式包括:「你有什麼建議?」「這聽起來蠻合理的,你要不要先試試看,有問題我們再進一步討論。」「你認為我們還有哪些地方沒有符合目標?」

另一個方法是情境式領導(situational leadership),《Agile 成功法則》解釋,專案負責人針對「已發生」的情況給予建議。舉例來說,如果團隊在開發過程中做出超出能力的承諾,專案負責人不直接介入導正,而是在可容錯的範圍內,等成員自己發現問題,設想不貳過的方法。假設發生第二次同樣的錯誤,再採取更直接的行動或指導。

「不要告訴別人怎麼做,說出你的目標,人們的創造力會讓你驚訝。」美國二戰著名陸軍將軍喬治.巴頓(George Patton)堅信,不用為團隊樹立嚴格的規定,或逼迫他們執行特定的戰法,只要引導他們理解問題,並鞭策他們設想能力所及的最佳解方,就能激發團隊的潛能。

能自行執行任務、管理流程,才算敏捷團隊
經理人
相關文章
管理 Management > 產品與專案
feature picture
4

客戶需求模糊不清,團隊無所適從?釐清 3 個不同層次要求,讓專案逆轉勝

整理.撰文 劉燿瑜
2022-04-19
分享
收藏
已完成
已取消

蘋果創辦人史蒂夫.賈伯斯(Steve Jobs)曾說:「如果只靠客戶主動告訴我,他們需要什麼,以此打造產品,等到產品完成時,客戶又會改要其他東西了。」

賈伯斯這句話點出了專案管理中的一個核心挑戰:需求往往難以具體化,但需求的釐清與落實,卻是專案成功的基石。專案經理需要一套結構化的框架,幫助團隊在不確定中找到明確方向。《經理人》推出線上課程「從觀念到實踐一次學會|專案管理 15 堂課」,提供專案管理全流程的實務應用,讓專案管理更有條理,面對挑戰也更加從容。

賈伯斯認為,客戶反覆無常,因為多數人並不真正清楚自己需要什麼,而這也可能成為專案團隊最大的惡夢。舉例來說,客戶或許會這樣描述自己的需求:「我想做一款年輕人喜歡的飲料。」

為何鎖定年輕人?為什麼選擇飲料這個產品?《SCRUM 敏捷產品管理》一書指出,這些可能都是客戶無法一開始就釐清的核心問題,而需求愈模糊,客戶對專案的要求也愈容易更動。

《我懂了!專案管理》將這種情形稱為「無頭雞專案」,意即專案像是被剁頭的雞隻,不知道方向、胡亂衝刺,直到力氣耗盡、血流不止才倒地斃命。書中指出,很多數專案的失敗都源自在初始階段時,沒有釐清客戶做專案的目的、建立對專案的正確願景。

延伸閱讀:RFM 模型怎麼用?將客戶價值分 8 種,挖出你的「黃金級」顧客

不要接到需求就開規格,釐清深層想法再提方案

因此,主動問清楚客戶需求,是專案邁向成功的第一步。《完全圖解計畫力》作者、專案管理顧問芝本秀德指出,想在初次討論時,就摸清客戶真實需求,建議使用「抽象階梯」方法,將客戶提出的要求,由上往下分為需求、規格、指示 3 種層次。

階梯頂端的需求指的是「為何要做」、規格是「用何種手段滿足需求」,作業則是落實規格的詳細執行計畫、行動步驟。舉例來說,當對方請你規畫某間門市的宣傳活動時,先別急著制定活動計畫書,因為規畫宣傳活動,只達到抽象階梯中的規格層次,而擬定執行活動的計畫書,則屬於指示層次。

企業想辦宣傳活動,背後一定有個更深層的需求,可能是為了行銷新產品或提升品牌知名度。專案團隊必須掌握到需求層次,才能找到更能滿足客戶需求的方法,像與社群網紅聯名、舉辦貴賓限定的座談會,宣傳效果可能都比辦門市活動更能提升品牌知名度。

芝本指出,多數客戶之所以只提得出規格層次的要求,是因為上層的需求較為抽象,規格則相較好表達。像前述的門市活動,就比提升品牌知名度更好理解。芝本秀德認為,透過 4 個連續問題,能讓客戶更具體描繪抽象需求、協助對方從規格,推導至需求層次:「發生什麼狀況?」「這個狀況對我而言的問題是什麼?」「該用什麼方法解決這個問題?」「為什麼要用這個方法解決?」

若以前述例子解釋,「發生什麼狀況?」可能是品牌知名度不如同業,「對客戶而言的問題」則是銷售動能低落,因此客戶想到的解決方法是辦門市活動,此時專案團隊可用「為什麼要用此方法解決?」來確認客戶原先開出的規格跟需求間的適配性。

「電梯行銷」簡潔陳述專案願景,確立共識仍須測試、修正

在掌握客戶的真實需求後,《敏捷專案管理基礎知識與應用實務》一書建議專案團隊可用電梯行銷術,簡單複述客戶期待的解決方案,凝聚雙方對專案的共識、建立共同願景。

電梯行銷術是透過以下 6 句話、在坐一趟電梯的時間內,簡潔向客戶陳述該專案、產品如何滿足、解決需求:

1.「該專案是為某人/某事(目標客群、欲處理的問題)而做。」
2.「因為他們想要⋯⋯/造成⋯⋯問題。」
3.「所以提出 XXX 這個產品/解決方案。」
4.「這個產品/解決方案,提供⋯⋯等功能。」
5.「不像其他產品/解決方案,有⋯⋯缺點。」
6.「此產品/解決方案有對手沒有的特色。」

《SCRUM 敏捷產品管理》提醒,在凝聚專案或產品願景的同時,請謹記少即是多的原則,報告的專案特性、功能盡量濃縮在 6 點內,才能凝聚、激發客戶對這些功能的興趣。

《產品專案管理全書》指出,即便雙方對專案有穩固願景,但在落地、執行的過程中,仍可能因消費者行為改變、市場趨勢等外在因素,需要改變執行方向,才能抵達雙方原本預期的目的地。

產品陽春也無妨,用核心功能測試市場

《SCRUM 敏捷產品管理》建議透過打造最小可行性產品(MVP,minimum viable product),縮短專案執行期間、產品開發時間,提早讓產品進入市場,好頻繁測試、取得客戶與市場的回饋,這樣一來,如果客戶的需求更動,產品也能盡早修正,所冒風險與損失的成本都相對較低。

《精實創業》作者、知名創投顧問艾瑞克.萊斯(Eric Ries)指出,有時最小可行性產品甚至不用做出實際原型,也能測試產品符不符合客戶期待。像是在個人雲端共享服務 Dropbox,2008 年首度問世時,僅以 3 分鐘的影片向市場介紹、模擬產品功能,一夕間吸引7萬多名用戶排隊預訂。

但如果專案目標並非面向消費者市場的產品,也沒有消費、使用者回饋當作評價,專案團隊該如何替最小可行性產品,設定成功標準?《專案管理:玩一場從不確定到確定的遊戲》一書提醒,專案團隊在設定目標時應謹記「數字+時間」原則。

無論設定任何指標,例如專案要提升產品多少良率,或替組織省下多少材料成本,都得加上期限。例如良率提升 5 個百分點是要在一年內還是一季內?如果太晚達到成效,就失去執行的意義。且在原指標上,設定更細緻的時間期限,例如專案內容是 3 個月內替某產品減少 20% 材料成本,拆分成每周該達到的進度,也有助隨時確認執行方向是否落後目標。

延伸閱讀:誤解了 OKR,領導者只會愈用愈痛苦!你搞懂真正的精髓了嗎?

打點利害關係人,避免各方意見干擾執行

即便與客戶、團隊溝通好目標,但後續執行卻常遇到供應商或贊助商等利害關係人的意見加入,造成專案需求不斷增加。《學會專案管理的 12 堂課》指出,有這樣的狀況是因為組織內各部門的利益不一致。舉例來說,一項避免水庫淤積,而興建攔砂壩的專案,水利局會想要用最划算的成本興建完成,但當地村長,則會希望攔砂壩上頭增建行人陸橋、涼亭,當地居民才不會覺得工程破壞景觀,於是專案很容易因為多方干擾,需求膨脹,浪費許多資源。

此時除了透過利害關係人矩陣,平衡為達原本專案目標,需維繫的權力關係外,還可透過「目標與關鍵結果」(OKR,objectives and key results)的方式對標,讓專案不因閒雜人等的要求偏離計畫。

《產品專案管理全書》舉例,如果是一項設計 App 的專案,用戶體驗團隊在乎介面互動功能、工程部門則在乎程式編碼夠不夠安全,以避免駭客攻擊。這時專案領導者應聚集不同部門,溝通專案的頂層目標(objectives)為何,將原本各自在乎的指標,整合成從大目標拆分下來的關鍵結果(key results),協調不同職級、部門的利益。

 如何顧及各方利害關係人,讓專案順利推行?
經理人
相關文章
管理 Management > 產品與專案
feature picture
5

專案經理救進度的 3 項基本功:詳拆任務、精算時程、收斂待辦

採訪.撰文 高士閔
2022-04-19
分享
收藏
已完成
已取消

「專案唯一不變的,就是它一定會變更!」台灣IBM 諮詢資深專案經理林憲哲解釋,客戶需求講不清楚、上周交辦的任務,下周又要改變,對於專案經理來說,這些都是家常便飯,他半開玩笑說「哪天不用更改,會感覺專案不正常。」

需求變更與進度管理是專案過程中常見的挑戰,一旦計畫出現偏差,往往會讓團隊陷入疲於奔命的狀態,甚至影響最終成果。《經理人》推出線上課程「從觀念到實踐一次學會|專案管理 15 堂課」,結合實務技巧,幫助團隊掌握任務拆解、時程規劃等關鍵方法,化解不確定性,讓專案推進更有條理。

對於專案經理而言,一切都按計畫走是理想。因為,一旦發生意外,同仁可能為了趕上進度,草草做完,日後又要修改,陷入惡性循環;或者,需求增加太多,只能強迫團隊處理,最終導致專案失敗。

專案之所以會有各種意外,有 2 個主要原因。第一種是不清楚「必須完成什麼」;第二種是錯估時程。以打掃為例,第一種就是隨興地看到什麼收什麼,摺了衣服,倒了垃圾,才發現沒有掃廁所。第二種就是,以為一個上午可以收得完,結果花了 3 天。

延伸閱讀:時程一拖再拖,專案經理好焦慮!7 大工具改善延宕問題,高效完成好產品

善用工作分解結構,拆成待辦事項

如果單憑感覺、經驗列出待辦事項,很容易遺漏、忽略。《我懂了!專案管理》建議,可以採用工作分解結構(WBS,work breakdown structure),常見的方式有幾種:

以交付項目拆解:用「自行車開發專案」為例,想生產一台自行車,你必須擁有車體、變速系統、煞車、輪胎等零件,它們就形成第一層任務(別人要交付給你的項目)。之後,可以再往下細分,像是車體可分為車架、坐墊、踏板、車把。

以次專案拆解:如果專案規模龐大,每一項子任務彼此關聯性小,可以先分成「次專案」,再往下拆分。比如「高速鐵路」專案,可以先拆分成為車站站體、鐵軌工程、車體建置、營運系統等。下一層再根據地區細分,譬如「車站站體」可以分為台北、桃園、新竹。

以產品生命周期拆分:又稱流程分解結構(PBS,process breakdown structure),簡單來說,就是根據時間先後,依序排出任務。像是「軟體開發」專案,必須先「蒐集需求」,再進行「系統分析和設計」,之後才能「撰寫程式」「測試上線」。

工作分解沒有規定一定要拆成幾層或幾項,《學會專案管理的 12 堂課》提醒,原則上愈細緻,愈不會有誤解,但展開本身也要花時間,專案經理須從中權衡。《SCRUM 敏捷產品管理》指出,分解完項目,最好與團隊成員討論,確認工作量可行。

需求明確的專案,細分項目後再加總時間

至於時程估算,《學會專案管理的 12 堂課》建議 2 種方式,一是由上而下估算(top-down estimating):如果公司曾做過類似專案,就可以根據它來推估時程。假設業界標準是一個人工作一個月(人月)能開發 16 個功能點,今天接到一軟體開發專案,根據過去的資料大約有 1600 功能點。專案時程就是 100(1600 / 16)人月,如果公司願意投入 5 位工程師,專案就能在 20 個月(100 / 5)完成。

之後,再根據 WBS 拆分的任務,估算每項任務的時間。比如「軟體開發專案(時間占比)」分為收集需求(15%)、系統設計(30%)、開發測試(50%)、安裝上線(5%),每項任務所需時間就很清楚,像是開發測試需要 10 個月。

由上而下估算,既快速又省成本,卻很粗略,由下而上估算(bottom-up estimating)優劣勢正好相反,估算精確,也比較花時間。簡單來說,就是利用 WBS 細分工作之後,算每項工作要花多少時間,再加總。以「收集需求」為例,可以分成問卷設計、蒐集問卷、文書處理、分析結果、撰寫報告等步驟,耗時都是 0.5 人時,加總是 2.5 個月。

林憲哲提醒,以上方式,只適合需求固定,變化不大的專案,像是建立人資系統;如果需求不明,比如數位轉型,由於市場還沒有先例,就得用「用戶故事點數」估算時程,比如以 T 恤尺寸(XS、S、M、L、XL)為任務難度分級。

《敏捷專案管理基礎知識與應用實務》指出,由於需求不清楚,估算誤差很大,所以估算時程最好用相對大小,像是用「費氏數列(即1、1、2、3、5、8、13、21…)」估算點數,由於每一個數字都是前 2 個數字的加總,代表距離愈遠的案子愈困難。例如,要爬到 4 棟樓的頂樓,要花多少時間?由於不確定建築的高度、老舊程度,以及自己的體力,因此把第 1 棟的分數假設為 1,第 2 棟是 3(1+2),第 3 棟是 5(2+3),第 4 棟是 8(3+5),時間愈靠後,分數愈高,難度愈高。

4 面向評估待辦清單,避免任務無限累加

如果出現意料之外的任務該怎麼辦?台灣敏捷協會理事林裕丞建議,採用「待辦清單」來管理專案需求,清單愈上方的任務愈重要,要先做;新增需求如果離主要目標太遠,就會安排在清單下方,最後可能會發現不做也沒差。

《SCRUM 敏捷產品管理》指出,可以從 4 個面向:價值、不確定性與風險、可發布性,以及相依關係,來建立待辦清單。

價值:該任務是不是產品上市的必要項目?不包含該項目,是否仍能達成預期效益?例如,蘋果(Apple)第一代手機訴求:流暢介面、行動上網和行動音樂,一上市就廣受歡迎。但你知道,一代蘋果是不能複製貼上的嗎?你不知道,因為這個功能沒那麼重要,所以可以列在產品清單最底部,甚至完全捨棄。

不確定性與風險、可發布性:專案的風險愈高,失敗機率愈大。風險代表不確定性,不確定性源自知識不足。因此,不確定性愈高的專案,優先度愈高,因為愈早做,就能愈早獲得新知識。Google 的第一版新聞應用,開發團隊不確定該按照日期或地點篩選新聞,最後乾脆都不做,先測試再說,結果有 300 人要求日期篩選,只有 3 人要求增添地點,答案自己浮現。

相依關係:簡而言之,就是任務與任務之間互有關聯。《學會專案管理的 12 堂課》建議,排定優先順序時,要注意 3 種關係,分別是前後關係(FS,finish to start),像是「粉刷壁面」完才能「貼壁紙」;同時進行(SS,start to start),比如「吃早餐」和「看新聞」;同時完成(FF,finish to finish),例如「每周運動 3 天」和「進行網球訓練」。

延伸閱讀:專案管理工具推薦!善用「視覺化」溝通,跟客戶、團隊不再雞同鴨講

《SCRUM 敏捷產品管理》提醒,如果 2 個任務屬於先後或同時,可以考慮用不同方式分割。比如說,「身為使用者,我想寫文字訊息」和「身為使用者,我得寫 email。由於兩者都涉及文字處理,先處理哪一項,都能提升後一項的工作效率。不過,更好的方式是結合成「身為使用者,我想要輸入文字。」

總結來說,需求明確、固定,就套用 WBS,並由下往上計算時程;需求模糊、變動,就列出待辦清單,以用戶故事點數估算工作量。傳統專案管理和敏捷專案,並不是互斥的關係,清楚自己要什麼,它們就是互補的工具。

限制「正在進行的工作數量」,避免時程延宕
經理人
相關文章
管理 Management > 產品與專案
feature picture
1

專案管理|怎麼規劃管理專案?圖解專案管理5步驟與工具

經理人編輯部
2025-03-06
分享
收藏
已完成
已取消

專案管理怎麼做、會經歷哪些流程?為了方便控管專案,專案經理會將專案分隔為數個階段(phase),當一個階段完成,交付出成果或產出具體文件之後,接著就會轉入下一階段。

專案管理的每個步驟,從起始到結束,都需要系統性的計畫與工具的支援,才能提高執行效率與成功率。《經理人》推出線上課程「從觀念到實踐一次學會|專案管理 15 堂課」不僅深入剖析這 5 大步驟的實務操作,還搭配實用工具與案例,幫助專案經理有條理地完成專案管理工作,全面提升掌控全局的能力。

所謂「專案生命周期」,指的是就從專案的開始到結束過程中,必經的數個階段。根據《專案管理知識體指南》,專案管理可劃分為 5 個流程,分別是起始、規畫、執行、監控和結束(結案)。

延伸閱讀:圖解:敏捷 vs. 傳統專案管理差在哪?哪類專案不適合敏捷?

專案管理流程、重點圖解!5 步驟,一次看懂專案管理怎麼做

1. 專案管理|起始階段:定義問題,並辨識專案利害關係人

專案管理 起始階段
楊婷宇/製圖

專案管理起始階段主要工作是定義問題,並針對問題發展出解決方案和專案章程,以及辨識出與專案相關的利害關係者(stakeholder;例如,顧客、供應商、贊助者、職能經理等),使專案順利進行。在這個階段,由於有賴專案經理的居中協調,使大家達成共識,因此較著重於整合管理及溝通管理這兩類知識。

延伸閱讀:敏捷管理專有名詞|Scrum、PO、每日立會是什麼?怎麼做?

2. 專案管理|規畫階段:思考完成專案所需做的事

專案管理 規劃階段
楊婷宇/製圖

待問題釐清、專案的目標也明確訂定出來,之後便要進行縝密的規畫,釐清專案「要做些什麼」「誰負責做」「該如何做」「什麼時候完成」「需要耗費哪些成本」「需要供應哪些資源」,以及如何預防及減輕風險。

一般而言,專案管理在定義和規畫階段,通常要投入最多心力,因為計畫得愈周詳,活動切割得愈細緻,顧全的層面愈多,進展到執行和追蹤階段時,就會更加順暢、有效率,進而協助專案目標順利達成。

3. 專案管理|執行階段:整合各方訊息,輔助專案推行

專案管理 執行階段
楊婷宇/製圖

在專案管理執行階段,專案經理的主要任務是,運用溝通管理知識,了解及掌握專案利害關係者的需求與期望;運用人資管理知識,建立並發展自己的專案團隊;以及運用採購和品質管理知識,輔助專案的推行。至於整合管理知識,在此階段則旨在指導和管理專案的執行。

4. 專案管理|監控階段:隨時隨地檢視專案是否符合計畫

專案管理 監控階段
楊婷宇/製圖

專案管理監控階段雖然是專案管理 5 流程的第 4 個階段,但其實監控的角色,就如同監察院是獨立於行政體系之外,職責是在過程中不斷監督及控制各個流程是否均符合原先計畫。一旦發現有偏差,就必須立即採取必要措施,將流程導回正軌;但是若已無法還原,也要做出修正或彌補,以因應新變數加入之後所產生的影響。

5. 專案管理|結束階段:將經驗文字化,供後續的專案參考

專案管理 結束階段
楊婷宇/製圖

當專案進行到最後結束階段時,專案經理除了運用採購管理知識,針對專案中所採購產品或服務進行「合約結案」(驗收賣方完成的工作及交付成果,是否符合專案的需求與標準)及稽核審查工作之外,這個階段的重點更在於,以整合管理知識,將團隊成員在「專案各個階段結束/整個專案結束」之後,所學到的成功及失敗經驗,轉化成文件化記錄下來,做為日後其他專案的參考及借鏡。

專案管理、專案規劃必備工具!以「專案規畫圖」區隔 4 大問題

專案是解決問題、創造新事物的過程,不管是長達數個月的婚禮籌備,到國家級的基礎建設都屬於專案的範圍。根據美國專案管理協會(Project Management Institute)的專案人才就業市場報告指出,專案型工作人數從 2017 年 6600 萬人預計到 2027 年將增為 8800 萬人;全球專案創造的經濟活動價值亦從 2013 年 12 兆美元(約台幣 360 兆)增加到 2027 年的 20 兆美元(約台幣 600 兆)。而專案管理絕不只是一群人定時開會、制定時程和填寫財務表單而已,它真正目的在於幫助人們把好點子落地實踐

專案管理學會前董事會主席、《專案管理革命》作者安東尼奧.尼托—羅德里格茲(Antonio Nieto-Rodriguez)參與過富通銀行併購荷蘭銀行的專案,由於意識到組織經常忽視專案管理,他研究無數成功和失敗的專案,把專案管理的知識統整成一套工具「專案規畫圖」(Project Canvas),可區分成 4 大問題:

專案規畫圖重點 1. why:為何啟動專案?

釐清執行專案的理由、目標、是否足夠鼓舞人心。像是波音公司的「波音 777 專案」,希望設計出人類史上最先進的飛機,可以省油 20%,並提高波音的市占率。

專案規畫圖重點 2. who:誰該參與專案?

許多組織中的專案負責人身上掛了數十個專案,因此,必須確保專案取得必要人力。像是 iPhone 的「紫色計畫」,賈伯斯投入 4 成時間,並招募最優秀的工程師、程式設計師和產品設計師,全職投入約兩年半時間。

專案規畫圖重點 3. what、how&when:專案內容為何?

在什麼時間、如何執行?討論專案內容中的時程、風險、品質、成本、利害關係人、人力資源和採購等面向,足以影響專案 50% 的成敗。

專案規畫圖重點 4. where:在哪裡執行專案?

最後,檢視公司文化與組織結構,確保專案優先順序以提高成功機率。

執行專案,要檢視專案內、徹底控管風險

執行專案時,先釐清啟動原因,確保誰要為專案成敗負責,還有專案的優先順序。以下拆解「專案規畫圖」(Project Canvas)中對專案成果影響程度高達 5 成的「專案內容」,幫你提早偵測可能的風險,從中快速修正。

檢視專案內容,徹底控管風險:確認範圍與時程
經理人月刊 第 183 期
檢視專案內容,徹底控管風險:掌控成本、品質、採購
經理人月刊 第 183 期
檢視專案內容,徹底控管風險:進行風險管理
經理人月刊 第 183 期
檢視專案內容,徹底控管風險:爭取利害關係人支持
經理人月刊 第 183 期

本篇不提供合作夥伴轉載使用

資料來源 / 《專案管理革命》,遠見天下文化出版、《專案管理知識體指南》

相關文章
會員專區

使用會員功能前,請先登入

  • 台灣首款對話式 AI 職場教練,一次提升領導力
  • 會員專享每日運勢、名人金句抽籤
  • 收藏文章、追蹤作者,享受個人化學習頁面
  • 定向學習!20 大關鍵字,開放自選、訂閱
  • 解鎖下載專區!10+ 會員專刊一次載
追蹤我們