跳至內容

專案管理三角形

本頁使用了標題或全文手工轉換
維基百科,自由的百科全書
專案管理三角形

專案管理三角形(Project Management Triangle)也稱為專案三角形是在項目管理上有關限制的模型。最早提出者不明,最晚在1950年代起就開始使用[1]。專案管理三角形是在以下內容中取捨:

  1. 專案工作的品質會受到專案預算、時程及專案範圍(特徵)所限制。
  2. 項目經理可以在各限制條件之間取捨。
  3. 一個限制條件中的調整多半會影響到其他的限制條件,有可能有些限制條件要妥協,或是犠牲品質。

例如,專案可以在增加預算或是縮小範圍的情形下加速完成。同樣的,加大專案範圍也需要對應增加預算或拉長時程。若減少預算,但專案範圍及時程都不調整,會讓專案的品質下降。

不過在實務上,有些專案限制上的取捨不一定可行。例如,在任務全滿的專案中投入金錢(及人力)可能無法加速專案,反而會讓專案慢下來[2]。而且在運作不良的專案中,可能無法在不影響品質的情形下調整預算、時間及專案範圍。

專案管理三角形常用來分析專案[3],不過專案管理三角形常會誤用,定義成功的專案是在事先規劃的預算及時程內,以合理的品質,發佈必要範圍的專案[4][5][6]。 專案管理三角形因為缺乏了有關利益相關者的影響[7]、學習[8]及使用者滿意度等有關成功的關鍵因素,因此不足以作為成功專案的模型[9]

簡介

[編輯]

時間的限制是指要完成專案中所有工作需要的時間,成本的限制是指可以用於此專案的預算,專案範圍的限制是指為了產生專案結果,所需要進行的工作。這三個限制條件常常是互相競爭的:若專案範圍擴大,成本及時間都會增加。若時程縮短,意味著成本提高以及專案範圍縮小,若專案預算減小,可能專案時間加長或是專案範圍減小。

專案管理的工作就是提供專案團隊人員(不只是專案經理)工具以及技術,在滿足限制條件的前提下,組織其工作英語Work (project management)

另一個管理專案的方式是考慮財務、時間及人力資源的限制。若希望早點完成工作,可能可以在此項目上投入多一些人,但這會讓專案的成本提高,此時若要維持專案的成本,就需要在專案的其他部份節省一些支出,使總成本不變。

在一些專案管理的示意圖中,會用三角形來表示時間、資源英語Resource (project management)以及技術目標,不過有些是用來當成三角形的三個邊,不是三個角[10]。John Storck曾任美國管理協會的講師,其「基本專案管理」課程中用了一對三角形,分別是外三角形及內三角形,說明專案的目的:在時限內或是準時完成、恰好符合預算或是較預算低、符合或是超過要求的範圍。二個三角形之間的距離說明三個元素和原先規劃的不同之處。專案偏重的元素可以從距離得知。他用了非常強調時間的專案,是縱貫阿拉斯加管道,不花多少錢,都一定要如期完成。在開發數年之後,在專案時程完成的四分鐘後,油就從管道的末端流出了。在這個例子中,內三角形的時間恰好就在外三角形的時間上,針對技術目標也是如此。不過因為經費超過預算很多,因此內三角形的費用其實已落到外三角形之外。

James P. Lewis [11]認為「專案範圍」即為三角形的面積,可以視為是一個使專案成功的變數。他提到PCTS(性能、成本、時間、範圍),並且認為專案可以選擇其中的三項。

專案三角形的實際價值是表示專案中的複雜程度。三角形的面積表示在這三個互相競爭的價值中,幾乎是無限的選擇方式。在了解這些在三角形內無限多的變化,配合專案三角形的圖有助於專案的決策及計劃,並且讓專案成員及專案所有者可以有一致的資訊。

STR模型

[編輯]

STR模型(STR model)是一個數學模型,將專案管理三角形視為是以下關係的抽象圖形描述:

Scope = Time × Resources

專案範圍(Scope)表示複雜度(也表示品質),資源(Resources)包括人力、財務以及物質方面的,而這些都不是無限量的,而且彼此之間也有一些相關的限制。例如,一位麵包師傅用一個烤箱可以在一小時烘烤一條麵包,但因為烤箱烘烤容量的限制,十位麵包師傅無法同時用一個烤箱,在一小時烘烤十條麵包。

專案管理三角形的三個元素

[編輯]

時間

[編輯]

為了分析需要,可以用一些工具來估算英語Estimation (project management)開發可交付樣品英語deliverable需要的時間。其中一個方式是用工作分解結構(WBS)列出產出可交付樣品過程中需要進行的工作。估計每一項工作需投入的時間,贊再整理得到總時間。

工作之間也要安排優先順序、識別各工作之間的其相依性英語Dependency (project management),在專案時程中列出這些資訊。工作的相依性會影響專案的總時間( 相依限制),也會影響可用的資源(資源限制)。時間和所有其他的資源和成本不同,需要獨立處理。

要預估現有專案成本時,可用以往類似專案的成本為基礎。

依照專案管理知識體係指南(PMBOK),專案時間管理的程序如下:

  1. 計畫時程管理
  2. 定義活動
  3. 排序活動
  4. 估計活動資源
  5. 估計活動期間英語Duration (project management)
  6. 發展時程
  7. 管控時程

計畫時程管理

[編輯]
  • 基於各項關於發展、管理、執行以及控制的文件,擬定政策以及執行步驟,為日後的專案提供一個初步的時程計畫。

定義活動

[編輯]
  • 在此過程,團隊成員透過各種具體的行動,為專案定義一個或數個可交付成果。利用WBS技術,將各項工作分解至最底層WBS工作包,再分解成易於控制的細項活動(工作),構成專案的最基本要素,用來安排時程與進行管制的最小工作單元。
  • 輸入:管理計畫、範圍基線、企業環境因素、組織過程資產。
  • 工具:分解、滾動式規劃、專家判斷。
  • 輸出:活動列表、活動屬性、里程碑列表。

活動排序

[編輯]
  • 排序活動是指透過一系列的行動,定義並記錄各個活動之間的邏輯因果關係。在一個專案裡,除了最初與最終的活動,每個活動至少會有一個甚至數個前置活動、後繼活動,彼此在時程上緊緊相連,互相影響。一個務實、可行的時程計畫,必須為各個活動安排提前與滯後時間,在實務上可透過人工的安排,或者是自動化的技術達成。
  • 輸入:活動清單、活動屬性、里程碑清單、專案範圍說明書、組織過程資產。
  • 工具:活動節點表示法、確定依賴關係、時間提前、滯後量的利用、進度網絡模型。
  • 輸出:專案進度表、活動清單更新、活動屬性更新、需求變動。

估計活動資源

[編輯]
  • 在此流程,團隊成員估算每一項活動所需的材料、人力、設備及用品的種類、需求數量。
  • 輸入:企業環境因素、組織過程資產、活動清單、活動屬性、可利用資源、專案管理計畫。
  • 工具:專家建議與判斷、備案分析、出版的估算數據、專案管理軟體的導入、由下往上估算法。
  • 輸出:活動資源需求、資源結構分解、資源日曆、文件更新

估計活動期間

[編輯]
  • 估算活動工期,是依據活動資源估算的結果,去估計完成每一單項活動所需要的工作時數。活動工期估算所依據的資訊與數據應該都要被記錄。
  • 每項活動,由最熟悉該活動的個人或小組提供活動期間估計的各項所需資訊。隨著專案設計工作的推進,資訊會越來越精確、明朗,活動期間估計的準確性與品質也隨之逐步提高。
  • 輸入:活動清單、活動屬性、資源需求、資源日曆、管理計畫、專案範疇說明書、企業環境因素、組織過程資產
  • 工具:專家建議與判斷、類比估算、參數估算、三點估算、儲備分析
  • 輸出:活動期間估計、更新專案文件

時程建立

[編輯]
  • 分析前述活動順序、工期、資源需求和時程限制等,建立專案時程,來呈現所有活動的預定開始和結束時間。 不同排程目標,會產生不同的時程,如追求最低成本或追求最短時間。當專案時程核准後,即成為時程基線,做為專案進度追蹤或管制基準。 當有專案時程變更請求時,須透過整合變更管制審查核准,始得變更。 排程技術和方法,有里程碑圖、甘特圖、專案網路圖等。
  • 輸入資料或文件:專案管理計畫書 、專案文件 、協議 、企業環境因素 、組織流程資產
  • 工具:時程網路分析、要徑法、排程技術、平行法 、資源最佳法、關鍵鏈法、提前和延後量 、時程壓縮、資料分析、專案管理資訊系統、敏捷釋出規劃
  • 輸出:時程基線 、專案時程、時程資料、專案日曆、專案管理計劃書更新、專案文件更新

時程管控

[編輯]
  • 當時程基線建立後,管制時程過程即開始,須瞭解目前專案之:確定專案時程現況、了解影響時程變更因素、重新考慮必要的時程準備、確認專案時程是否已經變更、變更實施發生時進行管制、績效審查是管制使用中運用的工具,就目前進度資料,比對時程基線以瞭解專案是否落後或提前,以及造成專案時程差異,並做差異分析以決定專案是否採取矯正措施。
  • 輸入資料或文件:專案管理計畫書、專案文件、工作績效資訊、組織流程資產
  • 工具:資料分析、要徑法
  • 產出:工作績效資訊、 時程預測、時程變更請求、專案管理計劃書更新、專案文件更新、組織流程資產更新

成本

[編輯]

專案的成本和許多因素有關,包括資源、工作包、勞動率,以及如何緩和或控制會讓成本變異的影響因素。有關成本的工具有風險管理成本應急英語cost contingency成本升級英語cost escalation及間接成本。不過除了這個之外,需考慮基本的會計學概念,例如固定成本及變動成本,另外,經濟成本也需要考慮到工作者的技能及生產力,這些用各種的專案成本預計工具可以計算的。在公司雇用臨時人員,契約人員或是將工作外包時,這些都是重要的因素。

有關成本的程序
[編輯]
  • 成本預估(Cost Estimating)是有關要完成所有活動,需要所有資源對應成本的近似值。
  • 成本預算(Cost budgeting)會累計所預估的資源,工作包(work package)及活動的總成本,建立成本基準(cost baseline)。
  • 成本控制(Cost Control)利用許多成本管理的工具,影響並且控制那些會造成成本波動及變異的因素。
專案管理成本估算工具[12]
[編輯]
  • Analogous Estimating(類比估算法):將過去類似專案之實際成本作為現在專案預估的基礎,須注意其間差異,如期程、規模、地點、複雜、技術、風險、資源…等差異,做適當調整與修訂。
  • Determining Resource Cost rates(決定資源成本比例):對於完成專案活動所需資源的可能成本,進行量化評估,獲得完成專案所需的期望成本。
  • Bottoms Up estimating(由下而上估算法):估算每一個別活動工作成本,再彙整出專案所需之總成本。
  • Parametric Estimating(參數估算法):依專案特性將其參數應用在數學模型中,以預測專案成本。通常用於專案初步階段。
  • Vendor Bid Analysis(供應商投標分析):將供應商多次投標的結果平均,並分析之。
  • Reserve Analysis (準備金分析):彙總專案裡各項活動的所需成本,在其成果(總成本)加上一筆準備金。準備金的數目,取決專案經理的判斷—經考量各項因素之後而得到結果。
  • Cost of Quality Analysis(品質成本分析):分析、估算專案裡每一項活動,為了達到最高品質所需要的成本
  • Project management software(專案管理軟體):各種可用於成本分析的軟體

範圍

[編輯]

範圍是指要達到成果需要滿足的規格。會針對專案要完成的目的有整體的定義,也會詳細敘述最後完成的內容。範圍的主要成份是最終成品的品質。投入的總時間除以要進行的工作,這可以定義專案的整體品質。有些工作投入一些時間可以有不錯的成果,若投入更多時間,會有非常好的成果。在大型的專案裡,品質對時間及成本有相當的影響(反之亦然)。

若將專案的三個限制放在一起,就形成這句標語:「時程內,符合規格,預算內」。此時,可以將s代表的時程(scope)用規格(spec)代替。

相關條目

[編輯]

參考資料

[編輯]
  1. ^ Atkinson, Roger. Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. International Journal of Project Management. December 1999, 17 (6): 337–342. doi:10.1016/S0263-7863(98)00069-6. 
  2. ^ Brooks, Frederick. The mythical man-month需要免費註冊 Anniversary. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc. 1995. ISBN 0-201-83595-9. 
  3. ^ Erik Bethke (2003). Game Development and Production. p.65.
  4. ^ Michael W. Newell, Marina N. Grashina (2004). The Project Management Question and Answer Book. p.8
  5. ^ Pamela McGhee, Peter McAliney (2007). Painless Project Management. p.74.
  6. ^ Michael Gentile, Ronald D. Collette, Thomas D. August (2005). The CISO Handbook. p.172
  7. ^ Ralph, Paul; Kelly, Paul. The Dimensions of Software Engineering Success. Proceedings of the 36th International Conference on Software Engineering (ACM). 2014: 24–35 [2020-02-06]. ISBN 9781450327565. doi:10.1145/2568225.2568261. (原始內容存檔於2019-02-03). 
  8. ^ Shenhar, A.; Dvir, Dov. Mapping the dimensions of project success. Project Management Journal. 1997, 28 (2): 5–13. 
  9. ^ Delone, William H.; McLean, Ephraim R. The DeLone and McLean Model of Information Systems Success: A Ten-Year Update. Journal of Management Information Systems. 1 April 2003, 19 (4): 9–30. ISSN 0742-1222. doi:10.1080/07421222.2003.11045748. 
  10. ^ Carl S. Chatfield, Timothy D. Johnson (2003). Microsoft Office Project 2003 Step by Step: Step by Step. P. 476
  11. ^ Lewis, James P. Project Planning, Scheduling & Control, 4E. McGraw Hill. 2005. ISBN 978-0-07-146037-8. 
  12. ^ Rose, Kenneth H. Book Review: Construction Extension to the PMBOK® Guide Third Edition. Project Management Journal. 2008-03, 39 (1): 98–98. ISSN 8756-9728. doi:10.1002/pmj.20029. 

外部連結

[編輯]