（續前篇）
| 適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。 |
4 專案管理概念
4.1 概述
4.1.1 總體說明
此章描述了第6章和第7章所講述的《專案管理實務》以及在專案過程中進行的總體考量事項。圖1闡述一個專案產生的前後環節及其環境。《專案》可以是獨立的（stand-alone），也可以是《專案群》，或者是《專案組合project portfolio》的一部分 （見4.2.5），也可以跨越組織邊界，在不同組織之間形成專案。宜根據組織策略，識別出來的對象、記錄以及評估各種機會、威脅、弱勢和優勢，為未來的專案措施提供決策指導。在《營運論證案例business case》裡進一步審視、展現相關的機會和威脅。一份營運論證案例可形成一個或多個專案。專案的產出具有預期成果，為專案發起人組織以及內外部的利害相關者實現收益。
4.1.2 專案
組織展開工作以實現特定目標。一般來說，這項工作通常可以分成營運和專案。營運和專案的不同之處在於：a) 專案是臨時性的，專注於為發起組織、專案利害相關者或顧客獲取或增加價值或能力（capability）；
b) 營運則經由持續性的活動，專注於組織的持續化發展，例如，交付可重複性的產品和服務。
專案目標可以通過專案的交付物、產出、成果和收益的組合來實現，取決於專案的前後環節（見4.2）和專案治理（見4.3）提供的方向。專案的目標宜有助於利害相關者的成果和實現收益，包括發起組織、其他內部和外部利害相關者、顧客及其利害相關者。雖然很多專案具有相似的特性，但是每一個專案都是獨特的。各個專案相互之間可能發生的差異包括（但不僅限於）以下幾種因素：
|
目標 |
前後環節 |
期望的成果 |
|
提交的產出 |
利害相關者受到的衝擊 |
使用的資源 |
|
複雜性 |
約束（見4.2.4） |
使用的過程或方法 |
4.1.3 專案管理
專案管理整合了實務各個面向，以指導、啟動、規劃、監督、控制和關閉專案，管理分配給專案的資源，激勵參與專案的個別人員，實現專案目標。專案管理宜通過一套過程和方法進行，該等過程和方法須設計為系統化形式，亦須包括該文件中描述的專案所需的實務條件或狀況。4.2 前後環節
4.2.1 專案前後環節的衝擊
4.2.1.1 概述專案的前後環節會影響專案的績效和成功的可能性。專案團隊宜考慮組織內部和外部的因素。
4.2.1.2 組織內部因素
組織內部的因素，例如：策略、技術、常規和專案管理的成熟度、資源可獲得性以及組織文化和結構，都可能對專案的成功產生衝擊。在調整適應專案管理方法，開發營運論證案例，執行可行性研究以及過渡到營運和顧客的設計時（適用時），宜考慮專案與其前後環節之間的關係及相互作用的效應。
4.2.1.3 組織外部因素
組織外部因素可以包括（但不僅限於）社會經濟、地理區域、政治、法規、技術和生態各種因素。該等因素可以通過額外的需求或約束，或者通過引入影響專案的風險，來對專案產生衝擊。儘管該等因素通常超出專案發起人或專案經理的控制或影響的容許能力（capability），但在指導時、合理佐證時（見4.3.2）、啟動時、規劃、監督時、控制和關閉專案時，仍宜考慮和規劃該等因素。
4.2.2 組織策略和專案
組織通常根據其願景、使命、價值觀、政策和組織內外部的因素來制定總體策略。專案是實現策略目標的一種方式。在識別組織的機會和威脅時，宜考慮潛在的產出和成果。圖2說明了從承接的專案中創造價值的過程。當專案產生的收益超過投入的資源時，便會產生正向價值。創造的價值可以是有形的或無形的。圖 2 通過專案和專案群創造價值
4.2.3 顧客和供應商觀點
可以從兩個觀察角度執行專案：a) 顧客或發起組織：組織掌握要求事項，可以承擔所有工作或將部分工作外包給供應商組織；
b) 供應商或外包商組織：該等組織的核心基礎或部分業務，是向其他組織提供服務或產品。
示例1：供應商或外包商提供服務或產品，作為一個營收型專案，可以包括規劃與建置道路、機場、鐵路和資訊技術系統。
在大多數情況下，供應商的專案範圍是顧客專案範圍的一部分。合約的每一個參與者宜注意自身在專案中的組織利益，並具備執行該專案的理由。顧客與供應商的關係可能引起參與者某種困惑，因為對於某些專案，此種關係可能是不同組織之間的或是組織內部的。在此種情況下，供應商的部分角色由外部的外包商或供應商，為來自另外一個部門或同一組織其他部門的顧客承擔。
示例2：一家公司的資訊技術部門可以使用製造部門的合約資源或合作夥伴進行軟體升級。在該等情況下，供應商-顧客的角色可以是多個向度的。
合約各方參與者宜明確區分下列事項：
—專案治理（見4.3）宜如何在合約劃定範圍的邊緣情況之兩側和跨邊界進行；
—組織的專案管理團隊結構（見4.5.1）；
—參與專案的合適人員；
—將來被採用的與交付所需的專案生命週期有關的工作實務。
4.2.4 專案約束
專案的產出和成果宜在確定的約束條件下實現，例如（但不僅限於）：a) 完成專案的期限或目標日期；
b) 組織從財務上支援資金的可獲得性；
c) 批准並分配到各階段的預算；
d) 專案資源的可獲得性，例如未展開專案前的需求事項、相關的專案活動所須具備的適當技能、設施、設備、材料、基礎設施、工具和其他資源的人員；
e) 與員工健康和安全有關的因素；
f) 保全安全性；
g) 可接受的風險水準；
h) 專案及其產出的潛在社會、環境和生態的衝擊；
i) 法律、規則和其他的政府要求事項；
j) 最低程度須達到的品質標準。
各式各樣約束通常是相互關聯的，因此一個約束的更改可能會影響一個或多個其他約束。因此，宜瞭解、平衡並定期檢查該等約束的影響。
專案的主要利害相關者，尤其是決策者，宜就專案的約束和相對優先順序達成一致，為旨在促進成功的決策和後續行動奠定堅實的基礎。
4.2.5 獨立型、專案群部分或專案組合部分的專案
專案可以由專案群、專案組合元件組成，也可以是獨立型的（參考ISO 21503、ISO 21504）。專案與其他元件之間的關係，見圖3。專案管理的原理在所有情況下都相同的，但是一個典型的區別是專案治理的工作方式，尤其是匯報和決策的水準。如果專案是專案群或專案組合的一部分，專案的目標和治理宜與該專案群或專案組合的治理保持一致（見4.3）。
圖3：專案組合、專案群和專案之間關係的示例
4.3 專案治理
4.3.1 治理架構
專案治理宜包括組織根據議定的營運論證案例進行指導、授權和控制專案的原則、政策和架構。治理宜提供以下主題的監督，例如：a) 用於進行該文件中定義活動和實施的政策、過程和方法；
b) 管理架構，包括專案生命週期（見4.4）；
c) 角色和責任，包括決策許可權（見4.5）。
維持專案治理的責任通常由發起組織的治理主體分配給專案發起人（見4.5.4）或專案委員會（見4.5.3）。
專案治理宜是發起組織整體治理架構中的一個組成部分。
4.3.2 營運論證案例
營運論證案例為專案治理提供基礎。營運論證案例宜用來佐證說明專案執行和得以繼續的合理性，並且至少包括或參考以下內容：
a) 預估擬實現的目標；
b) 策略配合一致性和將會實現的潛在收益；
c) 定義衡量指標（metrics）以評估所創造的價值；
d) 組織可接受的風險水準；
e) 預算、進度和品質要求；
f) 潛在的營業以及對組織其他營運的干擾；
g) 專案利害相關者管理和關係管理；
h) 人力資源和物質資源的使用；
i) 所需的技能、知識和能力；
j) 目標範圍；
k) 情境介紹；
l) 建議的管理方法；
m) 通過變革維持業務和組織活動的能力。
4.4 專案生命週期
在定義出專案生命週期時，宜考慮以下因素：a) 組織型式和專案治理；
b) 各式各樣風險；
c) 控制各種因素；
d) 專案的性質或特徵事項；
e) 其他組織型式和環境因素。
專案階段的數量和名稱取決於面對的專案類型、期望的治理和參雜在內的風險。各階段反映所採取的交付方法，例如預測型（predictive）、反覆運算型（iterative）、增量型（incremental）、自我調整型（adaptive）或者混合型（hybrid）。管理方法通常使用不同的字詞來表示階段，例如「步驟stages」、「反覆運算iteration」和「發佈release」。
每個階段宜有明確給定的開始和結束。專案生命週期的每個階段宜都有與決策、關鍵交付物、產出或成果相關的特定里程碑。每個階段之前都宜有一個決策點。該等決策點通常稱為「關卡gates」，是專案治理的重要面向。宜定義專案開始某一個階段所需的準則，但可能因組織環境、具體使用的專案生命週期和既定的專案治理而有所不同。在某些情況下，專案階段可能會前後重疊。
宜定義專案的決策點和階段，如圖4所示，並且可以根據組織和外部環境、資金、所需收益、風險和約束條件而有所不同。圖4進一步闡述了專案生命週期、綜合專案管理實務（見第6章）和專案管理實務（見第7章）之間的關係。
注1：在某些情況下，各階段可能重疊。
注2：階段（phases）有時被稱為「步驟stages」。
圖 4 專案生命週期、綜合專案管理實務和專案管理實務之間的關係
參見標準ISO 21502-2020
Project, programme and portfolio management — Guidance on project management
專案、專案群和專案組合管理 — 專案管理指引
（未完，見續篇）
沒有留言:
張貼留言