專案管理指引（八之七）

 （續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

7.6 進度管理

7.6.1 概述

進度管理的目的是使工作能夠及時進行，並將延誤減少到可接受的水準。進度計畫宜是專案計畫的一個組成部分，並在專案經理的指導下制定（見7.2）。

根據專案實施團隊對工作的承諾或工作之間的影響，時程管理宜包括對活動進行排序、估算活動持續時間以及制定和控制進度。排列活動順序須合乎邏輯順序，以支援發展為切合現實、可實現和可控制的時程計畫。專案中的活動宜用依賴關係來描述，以便確定關鍵路徑或確定替代方法。

專案經理宜根據批准的進度基線監督進度，以使專案範圍能夠在既定的進度約束和目標範圍內按時交付。進度控制宜包括監督與專案相關的階段、工作包和活動的狀態。控制還宜包括管理進度變更、監督里程碑和引入其他適當的控制措施。掙值管理等技術可用於監督進度和預測未來績效（參考ISO 21508）。

7.6.2 估算活動持續時間

在制定時間表之前，專案經理宜與專案團隊合作，估算專案活動的持續時間。與當前活動相比，可以對未來活動進行更詳細的定義。隨著專案的進展和更多資訊的提供，活動可作進一步的定義和詳細說明。活動持續時間可以表示進度約束和資源可獲得性之間的權衡輕重。宜定期重新估計活動持續時間，根據進度基線更新預測是必要的。在專案的整個生命週期內，宜重新考慮活動持續時間的估算。一旦活動基線化，其變更宜使用變更請求（見7.10）。同時，宜識別衝擊專案的新風險和其他事件。

7.6.3進度展開

宜根據所採用的交付方法安排活動。活動的層別宜適合於展開工作、分配資源、確定最終預算和管理控制，提供足夠的解決方案。除了活動網路圖之外，還可以採用其他的進度計畫表達格式。

宜制定進度展開方式，以決定：
a) 專案目標能否如期達成；
b) 關鍵路徑及其相關風險；
c) 對照預定義的基線進度計畫，在進度計畫中實現的實際進度。

進度計畫的制定和查證宜在整個專案中繼續進行。隨著工作的進展，專案的計畫發生了變化，預期風險發生或消失，新的風險被識別出來。如有必要，宜審查和修訂活動持續時間估算和資源估算，以制定經批准的專案進度計畫，該進度計畫可作為跟蹤進度的修訂基線。

7.6.4 控制進度計畫

一旦專案進度計畫和基線得到批准，宜控制專案工作，識別差異項目，並在必要時採取適當的預防和矯正措施。

專案經理宜瞭解在專案早期階段延誤的複雜效應及其對專案目標的衝擊。在決定對任何觀察到的進度延誤的回應時，宜考慮不同約束之間的權衡輕重，例如風險與成本（見4.2.4）。進度控制宜將進度目標重新調整到原始基線，或建立新的進度基線（見7.10），考慮到專案的約束，衝擊盡可能小。宜考慮在工作提前完成時，利用該等機會採取措施。

在控制進度時，重點宜放在：

a） 決定迄今取得的進展；
b） 將進度與批准的進度基線進行對比，以確定任何偏差；
c） 預測完工日期；
d） 實施適當的預防或矯正措施，以避免不利狀況耽擱進度。

宜根據以往趨勢和當前知識，定期制定和更新完工時的進度預測。通過應急或管理儲備各其他的項目管理策略，也可以加快進度。在管理進度時，可使用歷史資料和生產資料、進展資料、專案計畫、資源需求以及識別和記錄的風險來審查總體進度。

7.7 成本管理

7.7.1 概述

成本管理的目的是建立整個專案生命週期內應用的財務控制，便於在批准的預算範圍內交付專案。預算宜是專案計畫的一個組成部分（見7.2）。

成本管理宜包括估算每個工作單元的成本、制定預算、獲取資金和控制專案支出。掙值管理技術可用於監督成本以及預測未來績效，參考ISO 21508。

7.7.2 估算成本

估算成本宜包括制定完成每個專案活動所需成本的近似值。至少宜為第一階段以及整個專案確定成本估算。成本估算可以用多種度量單位表示，例如工時、設備小時數或貨幣價值。

當專案以多種貨幣進行成本估算時，則宜記錄所使用的匯率。應急儲備或管理儲備可用於處理不確定性，如果使用，宜在成本估算中明確說明。

7.7.3 制定預算

將預算分配給計畫工作單元，宜提供基於計畫的預算，以便與實際績效行比較。

宜估算專案的總成本，並確定預算，以確定何時需要資金以及何時預計產生成本。宜根據資金約束和要求，確定和建立管理和衡量成本績效的方法。編制預算時，宜確定成本績效的客觀衡量準則。在進行成本績效評鑑之前制定客觀的措施，可加強問責制，避免出現偏差。

專案成本估算與制定預算密切相關。未分配給活動或範圍內其他工作單元的管理儲備或應急儲備，可以創建並用於管理控制目的或支付不可預見的成本。宜清楚地確定管理儲備或應急儲備，以及如何使用和與之相關的風險類型。將預算資金分配給工作活動形成監督基線，並在批准變更請求時能夠重新確定預算基線。

7.7.4 控制成本

控制成本宜側重于確定當前成本的狀態，將其與成本基線進行比較，以確定偏離變異現象，預測完工時的預計成本，並實施適當的預防或矯正措施。

一旦工作開始後，宜累積績效資料，包括預算成本、實際成本和完工估算。為了評估專案的績效，有必要將成本與累積的計畫資料相結合，例如計畫活動的預估時程對照到當前和未來活動的預計完工日期。

在控制成本時，可以審查幾種資源，包括預算、實際成本和估算成本、預測成本、進展資料、活動清單，變更請求以及授權的變更、矯正措施和專案計畫。

監督著實際成本、預期的未來成本，以及相關的成本差異等，宜促使專案團隊採取適當措施，將專案保持在預算範圍內或提交申請追加資金。

7.8 風險管理

7.8.1 概述

風險管理的目的是提高實現專案目標的可能性。已識別的風險和處理每個風險的選項，宜是專案計劃的一個組成部分（見7.2）。

識別風險是專案團隊全體成員的責任，宜包括識別潛在風險來源及其特徵，如果發生該等風險，可能會對專案目標產生的正向衝擊或負向衝擊。風險管理宜包括在整個專案生命週期內識別、評鑑、處理、控制和應對風險。

7.8.2 識別風險

風險可以在整個專案生命週期內中識別，之前識別的風險可會改變或再次發生。識別風險時宜記錄風險。風險可能有多種來源，既可能是內部或外部。每個風險都應該有一個指定應對者。

註：風險記錄可稱為「風險登記冊risk register」、「風險日誌risk log」或組織內部使用的任何其他術語。

7.8.3 評鑑風險

宜評鑑每個風險的概率(probability)、後果和臨近度，並優先考慮進一步的風險應對行動。宜評鑑各個風險之間的相互關係和依賴性。
注1：後果也稱為「衝擊impact」。
注2：概率也稱為「可能性likelihood」。

7.8.4 應對風險

應對風險宜包括制定若干變通型選擇事項和不同措施，以增加機會並減少對專案的威脅。風險應對措施包括但不僅限於：
a) 接受；
b) 規避；
c) 降低；
d) 轉移；
e) 應急對策；
f) 盡量利用（狀況、情勢）；
g) 強化（自身、韌性）。

為應對特定風險而採取的措施宜與威脅或機會相適應，具有成本效益、及時，在專案前後環節下切合實際，並得到利害相關者的理解，並分配給適當的風險負責人。

剩餘風險可能是由於處理各種風險所採取的措施造成的。在處理風險時，偏離原來計畫時可能需要變更計畫或基線（見7.10）。

7.8.5 控制風險

控制風險宜包括通過確定是否採取了風險應對措施，以及該等措施是否達到預期效果，確保對負面風險的應對措施儘量減少對專案的干擾，而對正面風險的應對措施則最大限度地發揮有益的衝擊。應對措施將對專案的干擾降到最低，而正面風險的應對措施則使收益最大化。在控制風險時，可審查專案管理資訊，包括風險的相對優先順序、進展資料、專案計畫、變更請求和矯正措施。跟蹤風險的發展以及追蹤風險處理的有效性，宜屬控制風險的一個組成部分。

7.9 問題管理

7.9.1 概述

問題管理的目的是解決問題，以免對專案目標的實現產生負面衝擊。

凡涉及的各相關方宜識別問題，並在整個專案中予以解決。宜建立將問題逐級申報至適當管理層級的方法，以處理團隊無法解決的問題。

7.9.2 識別問題

問題發生時宜及時予以識別。大多數問題都須加以處理，以儘量減少其負面影響或利用其對專案的正面衝擊。在定義每個問題時，專案團隊宜包括圍繞該問題的相關事實。宜為專案利害相關者提出問題建立一種安全又可靠的方法。影響專案的問題宜在專案團隊各層級進行識別，並由專案團隊進行管理。涉及到的利害相關者宜明確定義和理解問題。

一旦發現問題，宜立即對其進行初步記錄和分析，以便對其確定優先順序，並首先處理對專案目標衝擊最大的問題。宜分配管理每個問題以解決問題的責任。記錄問題有助於獲取每個問題的詳細資訊，以便專案團隊可以查看問題的狀態以及誰負責解決問題。每個問題的詳細資訊可以包括標題或名稱、問題類型、識別出來問題的日期、問題描述、優先順序、衝擊摘要、措施步驟和當前狀態。

註：問題記錄可稱為「問題登記冊issue register」、「問題日誌issue log」或組織內部使用的任何其他術語。

7.9.3 解決問題

問題解決涉及記錄和處理已發生的事件或問題，該等事件或問題威脅到專案的成功，或代表著可利用的機會。宜建立將問題升級到適當管理層進行決策的方法，以根據團隊和其他利害相關者的建議處理問題。問題管理規劃和解決問題的方法宜納入到專案的治理和管理架構（見6.5.3），概述評估和解決問題所用的方法。

解決問題的決定和理由，宜傳達給適當的專案團隊成員、問題提出者和利害相關者。問題解決宜包含升級方法，當解決方案未出臺或所提供的解決方案被認為不切合實際或不符合利害相關者的要求時，該方法可用於提高認識或優先順序別。問題解決方案宜包括評估問題的影響以及解決問題所需的行動。宜記錄問題的解決情況，以供將來參考和學習。在解決問題時，可能需要偏離計畫或變更基線（見7.10）。

7.10 變更控制管理

7.10.1 概述

變更控制的目的是控制專案和交付物的變更，並正式接受或拒絕該等變更。

變更可能源於專案績效中發現的偏差，也可能源於任何利害相關者，包括決策者、執行管理層、最終用戶、供應商或團隊成員。或者，對風險或問題的處理時可能會導致變更。變更控制宜包括為專案建立一個架構，其中包括識別、評鑑、實施和關閉變更請求的活動。

註：評鑑包括確定變更對專案約束的衝擊（見4.2.4）。

7.10.2 建立變更控制架構

變更控制架構宜定義要使用的變更控制過程和工具。宜通過一套既定的綜合程序（如型態管理）來控制交付物的變更。

7.10.3 識別和評估變更請求

在整個專案中，有必要記錄變更請求，從目標、收益、利害相關者期望、範圍、資源、進度、成本、品質和風險等方面對其進行評鑑，並在實施前評鑑其衝擊並獲得授權。只宜執行授權的變更請求。

註：變更請求的記錄可稱為「變更登記冊change register」、「變更日誌change log」或組織內部使用的任何其他術語。

7.10.4 規劃變更請求實施

如果獲得授權，專案經理宜確定如何實施變更。對現有計劃的變更宜嚴格按照7.2中概述的規劃方法形成新的計畫。在適當情況下，專案經理宜查證相關合約是否仍然適用，如果不適用，則宜在變更合約的活動納入實施變更請求的計畫中（見7.17）。

7.10.5 實施和關閉變更請求

宜根據衝擊評鑑結果，批准、修改、拒絕和推遲變更請求。一旦批准了變更請求，宜將決定傳達給相關利害相關者，適當時更新專案檔案，並實施變更。宜記錄和跟蹤變更請求的狀態，直到其得到實施和關閉。

參見標準ISO 21502-2020
Project, programme and portfolio management — Guidance on project management
專案、專案群和專案組合管理 — 專案管理指引

（未完，見續篇）

專案管理指引（八之六）

 （續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

7 專案管理實務

7.1 概述

此章描述了在整個專案裡宜考慮的專案管理實務，並可在實施第6章所述綜合專案管理實務時使用。

該等實施如圖8所示。

根據專案的前後環節和和所使用的交付方法，該文件中描述的概念和實施的應用可能會因特點專案的側重點而異。

7.2 專案規劃管理

7.2.1 概述

專案規劃管理的目的是定義需求、交付物、產出、成果和約束，並確定如何實現專案目標。在制定專案計畫時，宜考慮不同的解決方案、交付方法和實施方案。

圖 8 專案管理實務與綜合專案管理實務的關聯

7.2.2 制定計劃

在可能的情況下，專案規劃宜作為一種協同活動，團隊成員就團隊的工作計畫提供建議。估計宜佐證說明。專案計畫可以包括：
a) 將可實現的收益（見7.3）；
b) 範圍：要交付的產出和成果（見7.4），同時考慮到品質（見7.11）；
c) 所需資源，如人員、材料、工具和設備以及其他組織（見7.5）；
d) 時間表：何時進行活動（見7.6）；
e) 成本（見7.7）；
f) 專案計畫中固有的風險（見7.8）；
g) 假設和約束。

宜定義活動與其他工作組件（如專案群和專案）之間的依賴關係。專案計畫宜包括並允許進行保證和決策活動。專案計畫可以基於層次結構，顯示每個工作組件在層次結構中的位置，並為工作包和活動分配單點責任。專案計畫宜在不同層級結構的不同級別進行查看，並顯示適合查看計畫者需求的詳細程度。

在專案的整個生命週期中，規劃宜是反覆運算的和漸進的，對於近期的工作比遠期的工作內容更詳細。隨著工作進展，可以細化和澄清範圍，以制定一個在可接受風險水準下交付的專案計畫。專案計畫可以包括當前確定性水準的指標，例如使用某個區間或信賴度指標。

7.2.3 監督計畫

專案計畫宜一致的且整合性。專案計畫宜足夠詳細，從而建立基線。該等基線可以反映專案計畫的任何方面，如要求、範圍、品質、時程、成本、資源和風險。基線計畫的變更宜以可控的方式進行（見7.10）。

一旦獲得批准，宜定期監督和予以分析計畫的基線的進展情況，並將其進行匯報（見7.15）。宜考慮到迄今為止的進展情況和現存的主要假設和風險，對未來活動進行預測。宜審查專案計畫，特別是在重大決策點之前（例如專案關卡）（見4.4）。

7.3 收益管理

7.3.1 概述

收益管理的目的是説明發起組織和顧客從專案成果中實現專案的預期收益，如營運論證案例或其他類似文件所述。如果收益的實現在專案範圍內，則收益宜成為專案計畫的一個組成部分（見7.2）。

專案目標和預期收益宜予以識別、分析、排出優先順序、文件化，並傳達給專案的利害相關者。宜定義計畫活動，以便於監督和控制預期收益。

7.3.2 識別和分析收益

宜在考慮潛在專案時（見6.2）開始識別和分析收益。收益主要由專案發起人與發起組織、利害相關者共同決定。收益宜包含在營運論證案例中，並可在支持文件中進一步詳細說明。專案交付物可以創造產出、組織與社會變革或成果，進而為發起組織或顧客實現收益。

在專案開發了營運論證案例後，專案發起人或其他授權機構，如專案管理委員會（見4.5），宜予以識別、分析、排出優先次序，並決定要實現的一系列更詳細的分項收益。

收益識別和分析宜包括但不僅限於：
a) 識別預期收益，並排出優先次序；
b) 識別預期收益可能產生的負面衝擊；
c) 識別整個專案生命週期內的附加收益；
d) 識別所需的任何組織與社會變革的程度；
e) 為要實現的每項收益識別利害相關者；
f) 使收益與策略目標和其他目標保持一致；
g) 定義績效衡量指標並匯報每項收益；
h) 確定實現收益的時間節點；
i) 查證規畫的產出和成果有可能實現所需的收益。

註：潛在專案在專案前期進行處理（見6.2和圖7）。

7.3.3 監督收益

監督收益包括（但不僅限於）下列事項：
a) 在整個專案生命週期內，監督實現成果的進展情況，以及他們對實現預期收益的衝擊；
b) 收集每項收益的績效量測事項；
c) 匯報和傳達預期收益的狀態。

專案計畫變更可能會衝擊預期收益。專案經理宜告知專案發起人計畫變更（見7.10）可能產生的衝擊。收益可以在專案期間、專案結束時或專案關閉後實現。在專案結束前，未來實現收益的責任（如有的話）宜移交給負責實現當前或未來收益的利害相關者。

7.3.4 維持收益

如果在專案範圍存在與規畫收益的偏差，則宜採取矯正，並在需要時採取預防措施。

7.4 範圍管理

7.4.1 概述

範圍管理的目的是促進交付物、產出和成果的創建，以實現發起組織或顧客的既定目標。範圍管理只允許正式批准的工作納入專案。該範圍宜是專案計畫的一個組成部分（見7.2）。

宜定義範圍（見7.4.2）。宜展開管理活動，以管理範圍的偏差，並確認須交付的範圍。

7.4.2 定義範圍

定義範圍宜明確專案計畫對發起組織或顧客的目標做出的貢獻。在未來決策中，以及在溝通專案的重要性及其目標和收益時，宜將定義的範圍作為一個考慮因素。範圍宜反映需求及其相關驗收準則，並宜隨著工作進展進行細化和澄清。

構成專案範圍的授權工作可以根據專案目標、對照式映射或工作分解式結構予以制定。若適當時，宜進一步詳細說明範圍，並將其分解為工作分解或其他類型的結構中的工作。分解須加以識別、定義和記錄所需的工作，是專案規劃的基礎（參考ISO 21511）。宜商定相關的驗收準則。

7.4.3 控制範圍

控制範圍宜包括當擴大範圍變更（見7.10）時產生最大限度地正向衝擊，及最大限度地縮小負面衝擊。宜將當前範圍的狀態與批准的基線進行比較，以確定任何偏差。控制範圍還宜關注影響範圍變更的因素，並控制該等變更對專案目標的衝擊。範圍變更請求宜以可控的方式進行，並與其他控制域整合在一起（見7.10）。

7.4.4 確認範圍交付

宜根據制定的驗收準則確認構成專案範圍的產出和成果的交付，包括：
a) 查證和確證專案的品質要求和品質標準已得到滿足（見7.11）；
b) 確認發起組織、顧客和其他利害相關者已準備好接收並在適當情況下使用專案的交付物；
c) 管理交付物的移交，以及在相關情況下，從專案團隊到發起組織或顧客的責任移交；
d) 獲得已完成移交的確認。
註：有關專案引起的組織與社會變革的管理，見7.14。

7.5 資源管理

7.5.1 概述

資源管理的目的是確定在品質、數量和最佳使用方面交付專案範圍所需的資源。資源須為專案計畫的一個組成部分（見7.2）。

資源可以包括人員、設施、設備、物料、基礎設施和工具。資源管理宜包括規劃、管理和控制資源，以確定實現專案目標所需的資源品質、數量和需要的最佳化事項。

參與資源管理的人員宜瞭解人力資源管理的關鍵方面，例如：專業能力、經驗、可獲得性、行為和文化方面。資源的需求和屬性，例如資源的來源、所需時間以及開始和結束日期，宜根據需要進行定義、記錄和更新。

由於不可避免的情況，例如設備故障、天氣、勞工騷亂、技術問題或其他工作的競爭性需求，難免可能發生資源可獲得性衝突。此種情況可能需要重新安排活動時程，並可能導致當前或後續活動的資源需求發生變更。宜規劃資源，使其在需要時可以獲得，並包括一個儲備容許量，用於及時干預適當的預防和矯正措施。宜制定程序，以識別重新分配現有資源或徵集額外資源可能導致的風險和問題（見7.8和7.9）。

7.5.2 規劃專案組織

工作中涉及的資源宜根據完成工作所需的角色和責任，進行合理配置。該等責任宜根據具體的專案組織進行定義，該組織可與適當的工作分解層級保持一致（見4.5）。

專案組織可以由各種因素定義和影響，如組織結構、政策、專案環境和專案類型。在規劃專案組織時，宜考慮專案利害相關者的需求、機會和要求。資源的規劃和選擇宜考慮多個因素，例如但不僅限於：內部或外部來源、專業能力、適用性、相關法律要求、參與的期限和時間、日曆、以及發展和訓練要求。

7.5.3 組建團隊

組建團隊包括獲取所需資源，並為他們提供展開工作的指導。宜確定工作地點、承諾、角色和責任，以及匯報要求。專案經理宜確定如何以及何時需要獲得專案團隊成員並將其分配到專案，以及如何及何時將他們從專案中釋放出去。在某些情況下，專案經理可能無法完全控制專案團隊成員的選擇。在相關情況下，工作包負責人宜參與選擇分配到其工作包的專案團隊成員。

通常宜在每個專案階段或工作包開始時成立一個團隊。如有必要，宜重新評鑑和調整團隊組成。在組建團隊時，專案經理宜考慮技能、專業知識、文化、成本和團隊動力等因素。

當組織內未獲得合適的資源時，宜考慮雇傭或資源外包（見7.17）。

7.5.4 開發團隊

開發團隊旨在幫助團隊成員以一種有凝聚力和協作性的方式共同工作。這種開發過程取決於專案團隊的專業能力，並可能需要以持續的方式提高團隊成員績效和互動，以增強團隊合作、動力和績效。

宜在專案早期制定可接受行為的基本規則，以儘量減少誤解和衝突。宜識別能力差距，並通過適當的訓練、輔導和其他舉措來彌補，包括採取措施提高團隊動力和職業成長。

7.5.5 管理團隊

管理團隊的目的宜是激勵團隊，保持積極的工作環境，讓團隊成員產生參與感，表現出最佳狀態並專注於他們分配的工作和專案目標。專案經理宜通過提供回饋、解決個人糾紛和鼓勵合作來最佳化團隊績效。

當發生衝突時，宜酌情採取適當的領導作為和管理風格，包括談判、自信、同理心和循證決策。

必要時，宜更新或修訂資源需求，提出並解決問題，如果超出專案經理的職權，則宜向上級反應。

宜收集資訊，作為人員績效和經驗教訓的輸入。如適用時，宜與工作包負責人、專案經理、專案發起人和個人直屬經理協商，進行團隊和個人評估及績效監督。

7.5.6 規劃、管理和監督實物資源

實物資源的可獲得性和使用宜進行規劃、管理和控制。為此，專案經理和團隊宜根據資源的可獲得性和專案要求，考慮和權衡最佳的「成本-收益」解決方案。物料、設備、設施、實驗室和工具等實物資源宜根據關鍵性、成本、可獲得性和交付週期等因素進行規劃。此種資源規劃通常宜與資源規劃、能力和預算相協調。

設備和物料資源的管理宜與專案時程（見7.6）相互協調，並考慮潛在的衝突情況，如不能獲得和未能交付的風險。宜考慮備用資源和資源配置。

宜檢查資源的績效和生產力，以及正在（或可能）實現目標的程度。必要時宜採取預防和矯正措施。

參見標準ISO 21502-2020
Project, programme and portfolio management — Guidance on project management
專案、專案群和專案組合管理—專案管理指引

（未完，見續篇）

專案管理指引（八之五）

（續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

6.6 控制專案

6.6.1 概述

控制專案（包括階段和工作包）的目的是根據商定專案計畫（含經授權的變更）來監督和衡量專案績效。專案經理宜以專案的初始規劃（見6.5.5）為基礎，增加設計和開發的活動、產出和成果的詳細資訊，並根據需要反映授權變更（見7.2）。

註：專案經理在控制專案方面的角色見4.5.6。

6.6.2 持續佐證說明

隨工作的進行，可以在專案多個階段針對不同的備選方案進一步佐證說明專案的理由。宜與專案發起人協商，更新營運論證案例，以反應專案前後環節和範圍的變化，然後在每個關卡或決策點確證是否繼續專案。

6.6.3 管理專案績效

專案經理宜在專案團隊的支持下，定期審查所要求的產出和成果，以達到要求。專案經理宜監督和查證專案團隊在承擔專案計畫中分配給他們的工作方面的績效，以便：

a) 將專案團隊的工作整合到後續的專案工作中；
b) 確定專案可能在可接受的風險水準內交付所要求內容，並建議和做出獲得授權且管制下的變更。

專案經理宜收集和分析進展和績效資料，以評估專案計畫相關的進展，包括：
—已完成的工作，實現的里程碑和產生的成本（見7.2）；
—計畫著或實現出的收益（見7.3）；
—管理著範圍（見7.4）；
—獲去足夠的資源來完成工作（見7.5）；
—管理進度和成本（見7.6和7.7）；
—識別和管理風險和問題（見7.8和7.9）；
—管理變更控制（見7.10）；
—工作品質（見7.11）；
—計畫和預測的利害相關者參與和溝通狀況（見7.12和7.13）；
—管理專案產出至發起組織或顧客的過渡，並為組織與社會變革做好準備和管理（見7.14）；
—匯報進展情況（見7.15）；
—保持資訊和文件的完整性和可用性（見7.16）；
—管理採購活動的狀況（見7.17）；
—總結新學習到的經驗教訓（見7.18）。

專案經理宜向專案發起人、專案團隊和選定的利害相關者提供一份與專案計畫一致的專案狀態和績效報告（見7.15）。宜包括對專案未來績效的預測。

專案經理宜管理專案內的各種技術性、行政支援和組織性活動及其介面。

宜記錄並實施預防和矯正措施，並在必要時提出和實施變更請求（見7.10），以使專案保持標的，繼續實現專案目標。

6.6.4 管理各個階段的啟動和關閉

在工作包領導人或其他主題專家的協助下，專案經理宜通過以下方式為專案每個階段的開始做好準備：
a) 準備或審查該階段的詳細計畫；
b) 審查治理和管理要求；
c) 與專案發起人確認專案仍然合理；
d) 修訂管理方式，以反映該階段所需的工作；
e) 獲得開始下一階段的授權。

一旦獲得授權開始該階段，專案經理宜調動團隊和其他資源並開始工作。

專案經理宜確認專案各階段的完成情況，包括但不僅限於：
—確認已完成的、遭到取消的或是暫停的採購；
—查證任何不完整的措施並記錄未解決的問題；
—釋放或轉換資源（如果不再需要）；
—根據組織的資訊歸檔政策，歸檔資訊和文件；
—查證已完成、已交付和已接受的產出和成果；
—記錄學習到的經驗教訓。

6.6.5 管理每個工作包的啟動、進展和關閉

專案經理宜通過以下方式照料著每個專案階段的工作包：
a) 在確保每個工作包的計畫和各個階段的整體計畫一致並整合後，對其進行查證和批准；
b) 確保工作包之間的整合工作和交付物得到規劃和實施，且達到要求；
c) 將每個工作包責任分配給工作包負責人；
d) 根據專案計畫或針對風險或問題啟動工作包；
e) 查證工作進展，包括解決任何風險、問題或變更請求；
f) 查證交付物的品質；
g) 確認工作包的完成、交付和關閉。

6.7 管理交付

管理交付的目的是確定所需的產出和成果，並計畫和實施其交付，以實現專案的成果和收益。

專案的工作組織成工作包，用於分配和控制各個團隊進行的工作。工作包宜分配給工作包負責人（見

4.5.8）。宜適當定義、規劃、監督和控制工作，宜積極管理品質。在專案環境中，工作方法和流程須

適合使用，以最大限度地提高成功的可能性。工作包負責人須按照第7章中制定的做法，根據專案批准的計畫，監督、測量和控制分配的工作。宜採取預防和矯正措施，並在必要時提出變更請求，以實現制定的工作目標。

工作包負責人宜通過（但不僅限於）以下交付管理其工作包的交付：
a) 規劃分配的工作包（見7.2至7.7）；
b) 動員團隊；
c) 處理風險、問題、變更請求和利害相關者的意見（見7.8、7.9、7.10和7.12）；
d) 管理供應商（如有的話）（見7.17）；
e) 使用適當和相稱的方法和技術開發所需的產出（見7.11）；
f) 查證和確證交付物；
g) 讓專案經理瞭解進度、升級式的風險、問題以及決策和指導請求（見7.15）；
h) 獲得和應用經驗教訓（見7.18）；
i) 一旦經專案經理確認工作包已完成，立即關閉工作包（見6.6.5）；
j) 維護所展開工作的記錄（見7.16）。
注1：有時輸出被稱為「資產assets」（見ISO 55000）。
注2：工作包負責人在管理交付方面的角色見4.5.8。

6.8 關閉或終止專案

關閉專案的目的是確定專案範圍的完成，在終止情況下關注未完成的活動，使專案後的收益得到實現，並管理剩餘資源和設施的遣散。在關閉專案之前，如果不是由於終止而導致時，則宜查證所有活動的完成情況，以確認該專案範圍已經完成，並且每個工作包已完成或是終止。同樣地，在適用的情況下，宜商定並接受任何剩餘的營運責任。

如果專案是專案群或專案組合的一部分，則宜將未完成的措施之跟蹤、風險和問題的責任移交給專案群經理或專案組合經理。如果專案不是現有專案群或專案組合的一部分，則宜確定是否將不完整的措施、風險和問題移交給適當的管理權責機構或其他指定人員，以進行後續的跟蹤和管理。宜審查為實現部分專案範圍而建立的所有合約，查證其狀態，並在適當情況下將其正式關閉（見7.17）。

專案經理宜與專案發起人、關鍵團隊成員和利害相關者進行諮商，進行審查關閉過程。審查關閉宜根據計畫評鑑績效，以及達到目標的程度。該審查宜正式記錄下來，正式文件化宜作為授權專案關閉的依據。專案發起人宜就任何關閉後審查的職權範圍和時間達成一致。

宜審查從整個專案學習到的經驗教訓，包括在類似專案和未來其他專案的管理中宜考慮的改進建議（見7.18）。此類審查可以是任何正式關閉審查的一部分，也可以作為單獨的活動進行。

宜告知利害相關者關閉的情況。宜採取措施，以實現專案產出的移交，並在移交期間任何相關的組織與社會變革管理措施，包括實現的收益。還宜採取措施，以實現持續性的收益。

在專案完成之前，專案發起人或發起組織可能會因為以下原因終止專案，包括但不僅限於：
a) 不再需要該專案或不再可行；
b) 與其相關的風險高到無法接受的程度；
c) 外部顧客不再需要專案產出。

除非存在特殊原因，否則終止專案宜包括與完成專案類似的活動，即使可能沒有要發佈最終的結果。

在專案終止的情況下，宜採取以下措施：
—確認並記錄已完成的活動，包括供應商所進行的活動；
—記錄未完成的活動；
—確認宜移交給顧客的交付物；
—確認並記錄顧客接收（或拒絕）已確定需要移交的交付物；
—記錄工作包的狀態；
—按照現行的組織政策，收集和歸檔專案檔案（見7.16）；
—釋放專案資源和設施；
—就任何持續的營運責任達成一致；
—根據需要關閉或終止工作令與合約。

註：專案經理在關閉或終止專案方面的角色見4.5.6。

6.9 專案後活動

專案後活動之目的是查證專案成果是可持續的，預期的收益已經實現。

凡屬專案群或專案組合，或某些需要結束後活動的專案，則專案發起人宜執行審查，以確定專案的成功程度，包括：
a) 達到既定目標；
b) 實現收益；
c) 實現組織或社會變革或成果，例如營運績效；
d) 實現可持續的變革，包括繼續滿足營運論證案例中設定的期望事項。

收益和組織與社會變革可能包括在專案範圍內，也可能不包括在專案範圍內。
宜吸取和交流學習到的經驗教訓（見7.18）。
註：發起組織在專案後活動的角色見4.5.2。

參見標準ISO 21502-2020
Project, programme and portfolio management — Guidance on project management
專案、專案群和專案組合管理 — 專案管理指引

（未完，見續篇）

專案管理指引（八之四）

 

（續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

5 專案管理必要條件

5.1 概述

所有組織都以正式或非正式的方式展開專案管理工作。在建立實施、維護和改進專案管理環境之前，組織宜考慮各種必要條件。此種環境有時被稱為「專案環境project environment」或「專案管理環境project management environment」。專案管理環境因組織而異。

組織內正式實施專案管理前，宜評鑑以下內容：
a) 現有和未來專案的類型、規模、重複率和複雜性；
b) 對組織的積極和消極衝擊，包括對組織的策略目標、願景、使命和其他方面的衝擊；
c) 為籌建實施專案管理的組織，包括人力資源需求和必要的組織結構、系統和流程變更；
d) 對顧客和其他利害相關者的衝擊。

5.2 實施專案管理的注意事項

根據組織或社會變革的規模和複雜性，專案管理在組織內的正式實施宜作為專案、專案群或專案組合的一部分進行管理。在考慮專案管理方法的正式實施時，組織宜考慮但不僅限於以下因素：
a) 識別出的正式專案管理需求和收益；
b) 整合其他相關工作並與策略和業務目標保持一致的能力；
c) 在組織治理、結構和文化內實行必需變革的容量；
d) 組織實施變革的資源能力，包括（但不僅限於）人力資源和預算；
e) 對內外部利害相關者的潛在衝擊；
f) 跨越組織之間區隔邊界的工作能力；
g) 將來專案方法實施時所需專業能力的可獲得程度；
h) 對組織內正在進行和計畫的活動的預算、已識別的風險、進度和要求的衝擊。

實施正式專案管理的營運論證案例，宜遵循4.3.2規定的指導內容。

5.3 專案管理環境的持續改進

執行階層和高階管理階層宜營造持續改進的環境和文化，以查證和維持組織內專案管理的持續適宜性、充分性、有效果性和有效率性。必要時，宜展開促進持續改進的活動，活動宜包括（但不僅限於）：
a) 建立組織專案管理架構的評估過程，重點查證與組織策略、業務和營運目標的一致性，以及總結和吸取經驗教訓的程度；
b) 評估專案管理架構和治理的有效性；
c) 實施識別出並經過協議同意的改進；
d) 實施已確定和議定的改進措施，及須要實施的調整事項；
e) 為當前和未來的專案收集和吸取經驗教訓；
f) 通過教育、訓練和輔導，培養員工的專案管理技能。

專案管理過程評估可以為組織提供資訊，以持續改進專案管理架構、方法和技巧，並可與5.4識別出來的架構結合使用。

資深管理階層、品質保證職能部門或專案辦公室(見4.5.7) 宜制定定期評估的時間表和方法，定期評估宜：
—促進專案管理過程、方法和技巧的持續改進，並定期評估組織內的專案管理成熟度；
—包括與受變革影響的人就如何在組織內進行專案管理進行溝通。

作為採行任何評估的一部分，宜諮詢專案發起人、專案經理及其團隊。

5.4 與組織流程和系統保持一致

專案治理架構宜與其他組織流程和系統保持一致，包括但不僅限於：
a) 組織治理；
b) 績效報告；
c) 適用程序和相關的交付方式；
d) 風險管理；
e) 專案組合和專案群管理；
f) 投資和財務管理；
g) 業務分析、策略和營運規劃；
h) 資訊與文件化管理；
i) 品質管制。

在協調專案管理實務和系統時，還宜考慮以下內容：
—職能和實體組織結構或其他主流結構；
—衝突的程式、流程、計畫和系統；
—溝通方式和週期；
—技術的可獲得性和獲取；
—組織營運前後環節；
—社會、經濟和環境特徵的平衡化與最佳化；
—行政支援和授權系統；
—可持續性和監督要求。

6 綜合專案管理實務

6.1 概述

綜合專案管理實務宜覆蓋專案實施時使用的實施，從專案前活動到專案啟動決策，從規劃和控制活動到專案後活動。此章識別展開專案，各個階段和其他專案活動或活動組時宜使用推薦的專案管理實務。此章實施借鑒了第4章所述的概念。

將第7章中識別的專案管理實務整合和調整為管理專案工作的統一方法，可能是專案成功的關鍵。

綜合專案管理實務的目的是使組織能夠：
a) 實現專案目標；
b) 在約束範圍內定義和管理專案範圍，同時考慮風險和資源需求；
c) 從每個參與和執行的組織中獲取支援，包括資源所有者、發起人、供應商、顧客、使用者和其他利害相關者的承諾。

管理專案宜採用整合型方法，考慮影響專案成功的各種因素，例如：各項角色、紀律、能力以及組織和環境因素。綜合專案管理實務宜與其他實施保持一致並相互關聯，如圖4所示。

專案管理方法的剪裁和應用，宜考慮到組織的需求、現行的風險水準、相關人員的能力以及專案的其他特殊性。宜根據相關組織政策對第6章和第7章的實施進行剪裁和應用。組織政策和專案管理實務之間的衝突宜與專案發起人協商解決。

整合型專案管理實務如圖7所示，包括專案前和專案後的活動。各項活動和相關角色之間的關係（見4.5）。6.2到6.9詳細描述了各項實務。

圖 7 整合型專案管理實務、關係和相關角色概覽

6.2 專案前活動

專案前活動的目的是發起組織查證該專案是否值得啟動。專案前活動是指在決定啟動專案之前須完成的活動。宜評估組織策略或業務需求產生了已識別出來的需求和機會，使資深管理階層能夠，例如組織管理、專案組合管理或專案群管理，以確定可以將部分或全部需求和機會轉化為實現收益的潛在專案。例如，該等需求和機會可以專注在新的市場強烈需求、當前的組織需求或新的法律要求。在正式授權啟動新專案之前，宜對需求和機會進行評估（見4.3.2）。

專案的目標、收益、合理性和投資進行佐證並詳細記錄，以便能夠決定是否啟動專案。此類文件可以用於確定需求和機會的優先順序排序。此種優先順序劃分可能涉及：
a) 組織策略或商業計畫的某些面向；
b) 更高層級的專案群或專案組合的需求；
c) 顧客的需求。

佐證說明的目的是獲得組織對所選中的專案投資之承諾和授權，同時瞭解其約束、風險和假設。

註：啟動專案的佐證說明可以在文件中定義，如職權範圍（terms of reference）、簡報、提案或初步營運論證案例（見4.3.2）。

宜進行評估，以確定專案是否宜於在組織、專案組合或專案群層面進行。此種評估宜基於多種準則，如定量、定性和財務準則、對齊組織策略、可持續性以及社會和環境衝擊。不同的組織、專案組合、專案群和專案的準則可能會有所不同，具體取決於面對的前後環節。

在授權啟動專案之前，發起組織宜：
—識別專案發起人和專案經理，並確定其最初的責任和職權；
—制定初步的治理安排；
—決定組織是否有資源和準備資金用於整個專案，或者至少用於第一階段，並相信可以隨著專案進展而獲得額外的資金進行其餘專案部分。

6.3 觀察專案

觀察專案的目的是發起組織確信專案團隊有能力實現專案目標，該專案仍然滿足組織的需求和專案利害相關者的期望，並且專案風險處於可接受的水準。

照管專案可以經由以下方式為之：
a) 參與關鍵決策；
b) 定期匯報；
c)保證性的審查和稽核；
d) 臨時地知會上一層級和及時干預。

儘管許多決策可以委派給專案發起人，但發起組織的高階管理者通常更適合保留一些決策。受專案外部因素（例如：經濟、社會和環境可持續性，以及資金或資源的可用性）影響的決策，只能在更高階層的位置做出決策，因為它們會衝擊其他專案和工作。發起組織宜隨時向專案發起人通報專案的最新前後環節情況，根據需要或要求提供指導和方向。發起組織宜使專案發起人有足夠的時間來有效地履行責任。

註：發起組織在照料專案方面的角色，見4.5.2。

6.4 指導專案

指導專案的目的是使專案在組織前後環節中持續具有相關性和客觀佐證。

在專案委員會的支持或照看下，專案發起人宜確定：
a) 組織的需求正獲得關注，願景和目標正在與策略假設相互溝通，並已制定衡量專案成功與否的準則；
b) 如果組織治理有要求，則該專案須持續加以客觀佐證，且營運論證案例須持續更新；
c) 就產出、成果和預期收益而言，解決方案達到組織的需求；
d) 採用適宜及具備專業能力的資源；
e) 當組織的客觀佐證未足以支撐時，專案即須終止。

註：專案發起人和專案委員會在指導專案方面的角色分別見4.5.4和4.5.3。

6.5 啟動專案

6.5.1 概述

啟動專案的目的是規劃專案、定義專案組織、動員專案團隊、定義專案治理和管理、識別利害相關者並查證專案的客觀佐證。宜考慮相關專案的經驗教訓。該等活動可以反覆運算，直到制定出可接受的解決方案和計畫為止，並可以在專案的後續階段進一步反覆運算。

注1：「啟動專案initiating a project」也可以稱為「開始專案starting a project」或「專案初始化project initiation」。

注2：在啟動專案方面專案經理的角色見4.5.6。

6.5.2 動員專案團隊

專案經理宜調動該專案所需的團隊、設施、設備和其他資源。專案團隊宜瞭解他們的角色以及專案的要求、假設、約束和潛在風險。專案工作宜在跨職能團隊中進行，並分配給有專業能力完成角色並有能力容量交付預期成果的人員。更多資訊見7.5。

6.5.3 專案治理和管理方法

宜定義治理和管理架構，為參與專案的個人提供指導和工作方法。治理和管理架構以及控制措施宜與要完成的工作及其預期的複雜性相稱和適當。

專案經理宜諮詢專案發起人，定義出專案啟動、指導、監督、控制和關閉的方式，同時符合治理要求（見4.3）。通常，這包括：
a) 專案生命週期（見4.4）；
b) 專案組織、角色和責任（見4.5）；
c) 第6章和第7章描述的進行管理活動的過程和方法；
d) 交付專案產出和成果的過程和方法（見6.7）。

專案管理方法可用一份文件、含一組輔助文件的總文件檔、或涵蓋特定實施（如風險或品質管制計畫的一組輔助文件予以描述（參考ISO 21505）。

註：專案管理方法文件的名稱可能有所不同。例如「專案管理計畫project management plan」、「專案啟動文件project initiation documentation」、「專案定義文件project definition document」、「項目實施計畫project implementation plan」、「專案章程project charter」、「專案職權範圍project terms of reference」等。具體專案管理實務的文件有時被稱為「管理計畫management plans」，例如「風險管理計畫或策略risk management plan or strategy」、「品質管制計畫或策略quality management plan or strategy」、「範圍管理計畫或策略scope management plan or strategy」。

6.5.4 初步專案佐證說明

專案啟動的佐證說明宜建立在專案前活動（見6.2）的初步查證基礎上，進一步深化專案佐證說明。該佐證說明宜記錄在營運論證案例中（見4.3.2）。營運論證案例可以隨著工作的展開，在多個專案階段中進行開發並更新營運論證案例，以反映專案前後環節和範圍的重大變化。

營運論證案例宜證明在可接受的風險水準內，與組織策略、財務可行性、商業活性和可交付的實用性相匹配。宜評鑑要採取的方法和選擇的解決方案的備選方案，並給出拒絕的理由。如果專案是專案群的一部分，則其營運論證案例可以包含在該專案群的營運論證案例中。

註：佐證說明專案實施的文件通常稱為「營運論證案例business case」，但實際使用的名稱可能因行業或使用的方法而有所不同。

6.5.5 初步專案規劃

專案的初步規劃宜根據專案生命週期制定里程碑、關卡或決策點，並至少結合專案的當前階段的詳細計畫。如果將過渡階段視為專案的一部分，則宜考慮將專案產出過渡至營運或顧客。在專案的早期階段，可形成多個備選方案，在專案後續階段進一步開發（見7.2）。

參見標準ISO 21502-2020
Project, programme and portfolio management — Guidance on project management
專案、專案群和專案組合管理 — 專案管理指引

（未完，見續篇）

德國巴伐利亞邦高科技議程（Hightech Agenda Bayern）概況（六之二）

（續前篇）

適合一般科技技術界。此文僅供個人參考與資訊喚回，尚非標準或官方內容。內文引用人工智慧平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱德國的巴伐利亞邦官方網站。 CC BY-SA 4。0。

乙：未來醫學的「人工智慧AI輔助診斷」與「醫療機器人」：

在德國巴伐利亞高科技議程（Hightech Agenda Bayern）中，「AI輔助診斷」與「醫療機器人」是「未來醫學（Medicine of the Future）」領域的核心策略。該議程總計投資超過 55億歐元，透過跨區域的「巴伐利亞AI生態系（Baiosphere）」將全邦打造成全球頂尖的醫療科技重鎮。

以下詳細解析慕尼黑（Munich）與紐倫堡-埃爾朗根（Nuremberg-Erlangen）兩大核心雙子星節點的分工、重點技術與具體應用：

一、 慕尼黑節點（Munich）：智慧醫療機器人與前沿手術整合

慕尼黑在巴伐利亞AI網路中被指定為「智慧機器人（Intelligent Robotics）」的中心，其核心目標是將AI、先進感知與機械手臂結合，直接應用於臨床手術與照護。
核心科研機構：

• 慕尼黑工業大學（TUM）及其附屬醫院（Klinikum rechts der Isar）。
• 慕尼黑機器人與機器智能研究所（MIRMI）。
• 慕尼黑大學（LMU）醫院與亥姆霍茲慕尼黑中心（Helmholtz Zentrum München）。

重點發展領域與具體項目：

1. ForNeRo 醫療機器人專案：由 TUM 領銜的 ForNeRo 研究計畫 獲得巴伐利亞研究基金會200萬歐元資助。該項目專注於將多元化的手術機器人系統與即時醫療影像（如術中 CT、MRI）進行無縫整合，讓機器人能在外科手術中提供極高精準度的輔助，減少人為失誤。

2. 微型與奈米醫療機器人（Nano and Microrobotics）：利用高科技議程增設的專屬教授席位，研發利用「DNA摺紙技術」製成、病毒大小的奈米機器人。未來這些微型機器人可進入人體血管，將藥物精準傳送至腫瘤部位，或在微觀層面進行細胞修復。

3. 大廠生態系協同：與總部位於慕尼黑的數位醫療大廠 Brainlab 密切合作，將影像引導手術（Image-guided surgery）軟體與硬體機器人深度結合，推動技術的快速臨床商品化。

二、 紐倫堡-埃爾朗根節點（Nuremberg-Erlangen）：AI 醫療診斷與數位健康樞紐

紐倫堡與鄰近的埃爾朗根共同構成了國際著名的「醫療谷（Medical Valley）」，在巴伐利亞高科技議程中被官方指定為「健康 AI 節點（Health Node）」。這裡側重於大數據、機器學習演算法以及智慧感測器的醫療診斷應用。
核心科研機構：

• 埃爾朗根-紐倫堡大學（FAU）：設立了專門的「生物醫學工程人工智慧學系（AIBE）」。
• 紐倫堡技術大學（UTN）：新創立的現代化大學，主力研發 AI 基礎模型。

重點發展領域與具體項目：

1. AI4health 診斷與影像研究：FAU 的 AIBE 學系 專注於開發「AI 輔助醫學影像診斷」。透過深度學習演算法分析 X 光、電腦斷層（CT）與核磁共振（MRI）影像，AI 能在幾秒鐘內識別出早期癌症細胞、心肌梗塞徵兆或腦中風病變，輔助醫生避免肉眼漏診。

2. 巴伐利亞 AI 基礎模型倡議（Bavarian AI Foundation Model Initiative）：由 UTN 領銜的跨學科倡議，正在開發醫療專用的「多模態大模型」。此模型能同時整合並分析病患的臨床病歷、基因數據、生物訊號與醫學影像，實現極度客製化的「個人化精準醫療」預測與療程規劃。

3. 數據整合中心與在地產業優勢：埃爾朗根大學醫院建立了數據整合中心，將區域醫療網路的病患數據結構化去隱私整合。更重要的是，全球醫療設備巨頭西門子醫療（Siemens Healthineers）總部位於此地，與學術界直接對接，讓智慧感測器與遠距醫療診斷系統能迅速落地。

三、 兩大城市的協同效應與未來願景

巴伐利亞高科技議程並非讓兩地孤立競爭，而是透過互補建立密不可分的「強強聯結」：

評比維度	慕尼黑（Munich）	紐倫堡-埃爾朗根（Nuremberg-Erlangen）
官方策略定位	智慧機器人與感知中心	醫療健康 AI 中心
核心優勢技術	手術機器人整合、奈米機器人、照護自動化	醫學影像 AI 識別、多模態大模型、智慧感測器
代表性企業夥伴	Brainlab、羅氏製藥（Roche）	西門子醫療（Siemens Healthineers）

願景總結：

這項龐大的科技投資旨在應對高齡化社會帶來的醫療資源短缺。透過紐倫堡開發的「超強大腦（AI 診斷演算法）」 與慕尼黑開發的「精準雙手（醫療機器人）」 相結合，巴伐利亞邦試圖建立一個從早期篩檢、精準診斷到自動化手術與術後照護的完整全自動化數位醫療鏈，保持其在歐盟乃至全球醫療科技市場的「冠軍聯賽（Champions League）」領先地位。

丙：醫療健康的「健康AI節點」與「醫療谷」

在「巴伐利亞高科技議程（HTA）」策略下，紐倫堡-埃爾朗根的「健康AI節點」與「醫療谷（Medical Valley）」深度融合，與慕尼黑的「智慧機器人中心」共同構成了德國最頂尖的數位醫療網路。

以下詳細梳理這兩個核心區域在微型機器人、AI4health、AI基礎模型以及 ForNeRo 專案中的重要研究方向、主導大學、核心教授及其生平與學術成就：

💡 核心總覽與快速檢索
紐倫堡-埃爾朗根（健康AI與醫療谷樞紐）
微型與奈米醫療機器人：[FAU 埃爾朗根-紐倫堡大學] Prof. Dr. Franziska Mathis-Ullrich
AI4health 診斷演算法與臨床實踐：[FAU] Prof. Dr. Florian Knoll & Prof. Dr. Bernhard Kainz
巴伐利亞 AI 基礎模型倡議：[UTN 紐倫堡技術大學] Prof. Dr. Wolfram Burgard（共同總主持人）
慕尼黑（智慧機器人與前沿手術中心）
ForNeRo 手術機器人整合計畫：[TUM 慕尼黑工業大學] Prof. Dr. Dirk Wilhelm（臨床與機器人主導） & [LMU 慕尼黑大學] 跨學科團隊

一、 紐倫堡-埃爾朗根節點：頂尖科學家與科研重點

1. 微型與奈米醫療機器人（Nano- und Mikrorobotiks）

承辦機構：埃爾朗根-紐倫堡大學（FAU）人工智慧生物醫學工程學系 (AIBE)
領進/主導教授：Prof. Dr. Franziska Mathis-Ullrich（手術規劃與機器人認知教授）
學者履歷：她是醫療機器人領域的青年領軍學者。博士畢業於全球頂尖的蘇黎世聯邦理工學院（ETH Zurich）多尺度機器人研究所（MSRL），導師是微型機器人泰斗 Bradley Nelson。隨後在卡爾斯魯厄理工學院（KIT）擔任終身軌教授，並於巴伐利亞高科技議程（HTA）啟動後，獲重金延攬至 FAU AIBE 學系。
科研成就與重點：她專注於「微創與奈米手術機器人」的感知與智慧控制。其研究重點是開發能夠進入人體血管、眼球或微小器官深處的磁控微型機器人，透過 AI 演算法精準預測人體組織的形變，從而實現自動化的微觀藥物遞送與精細手術。

2. AI4health 診斷演算法與臨床實踐（AI4health Algorithmen und Praxis）

承辦機構：FAU AIBE 學系 結合埃爾朗根大學醫院（Universitätsklinikum Erlangen）
領進/主導教授：
Prof. Dr. Florian Knoll（計算影像學教授）
學者履歷：奧地利格拉茲科技大學博士，隨後任職於美國紐約大學（NYU）朗格尼醫學中心（Langone Health）放射學系副教授，是全球醫療影像 AI 的一線權威，後透過 HTA 計劃受聘回德國。
科研成就：他引領了「快速核磁共振（Fast MRI）與 AI 重建」的革命。利用深度學習，他的演算法能將 MRI 的掃描時間縮短高達 4 倍以上，且重建出的醫學影像比傳統方式更清晰，大幅降低病患在儀器內的幽閉恐懼與檢查成本，目前該技術已與西門子醫療（Siemens Healthineers）深度整合落地。
Prof. Dr. Bernhard Kainz（醫學影像探索與分析教授）
學者履歷：曾任英國倫敦帝國學院（Imperial College London）終身制副教授，並於 2021 年起加入 FAU AIBE 學系。
科研成就：專精於即時臨床影像分析與安全 AI（Safe AI）。他開發的演算法主要應用於即時超音波引導與胎兒醫學影像識別，讓非資深醫生也能在 AI 輔助下精確診斷複雜的先天性疾病。

3. 巴伐利亞 AI 基礎模型倡議（Bavarian AI Foundation Model Initiative） 

承辦機構：紐倫堡技術大學（UTN）計算科學與人工智慧學系（CSAI） 
領進/主導教授：Prof. Dr. Wolfram Burgard（UTN 創系主任 / AI 與機器人講座教授）
學者履歷：全球人工智慧與自主機器人領域的殿堂級宗師。他是波昂大學博士，曾長期任教於弗萊堡大學，是德國科學院（Leopoldina）院士、IEEE Fellow 及 AAAI Fellow。他在機率機器人學（Probabilistic Robotics）上的奠基性著作是全球機器人科學家的必讀聖經。2022 年被特聘為新建紐倫堡技術大學（UTN） 的創始學系主席。
科研成就與重點：Prof. Burgard 與慕尼黑大學（LMU）的 Björn Ommer 教授（Stable Diffusion 創始人）共同出任「巴伐利亞 AI 基礎模型倡議」的科學總協調人。在健康節點中，他帶領團隊研發歐洲自主、多模態（Multimodal）醫療基礎大模型。這個模型能同時吃進病患的病歷、基因組學數據、生物訊號與高維度 3D 醫學影像，打破傳統單一診斷的藩籬，進行全方位的疾病預測。

二、 慕尼黑節點：手術室未來的開拓者

ForNeRo 手術機器人整合計畫（Seamless and ergonomic integration of robotics into clinical workflow）
承辦機構：慕尼黑工業大學（TUM）機器人與機器智能研究所（MIRMI） 與 人機工程學系
領進/主導教授：Prof. Dr. Dirk Wilhelm（TUM 醫療機器人學講座教授 / 微創手術資深外科主治醫師）
學者履歷：身兼雙重頂尖身分——他既是 TUM 醫學院附屬右岸醫院（Klinikum rechts der Isar）的資深外科醫生，也是高科技議程資助下設立的 TUM 醫療機器人學系主任。這種「醫工結合」的背景使他成為將實驗室技術帶入手術室的最佳人選。
科研成就與重點：他是巴伐利亞研究基金會資助的 ForNeRo 核心計畫主持人。
計畫細節與落地：ForNeRo 著眼於解決現代手術室的痛點——過去機器人體積龐大且與醫生流程脫節。Prof. Wilhelm 團隊在實驗手術室中，將多臂手術機器人（如 MIRO 系統與新興的 Neura Robotics 手術臂）與先進的感知環境（Sensory environment）和 AI 整合。AI 能自動識別當前的手術步驟、預判醫生拿取哪種手術刀、辨識被操作的器官，並在不干擾醫生的情況下主動調整機器人手臂的位置。該項目與 LMU 醫院及產業界巨頭 Karl Storz（內視鏡大廠）深度協同，大幅提升手術的流暢度與人體工學舒適度。

三、 總結：兩地在巴伐利亞 AI 生態系中的協同聯動

在巴伐利亞的整體佈局中，這幾位教授所主持的項目形成了一個強大的閉環：
紐倫堡（UTN - Burgard）開發底層的「醫療多模態大模型」，提供全邦醫院最強大的人工智慧運作大腦；
埃爾朗根（FAU - Knoll / Kainz / Mathis-Ullrich）利用這套大腦進行超快速的影像 AI 診斷和精準的血管內微型機器人控制；
慕尼黑（TUM - Wilhelm）則將這些診斷數據和 AI 實時感知能力，無縫裝載進大型手術室的機器人（ForNeRo）中，直接輔助外科醫生完成高難度手術。

這種由「巴伐利亞高科技議程」以數億歐元打造的頂級陣容，正是該區域成為全歐乃至全球醫療科技（MedTech）領頭羊的核心底氣。

參見：Bavaria High Tech Agenda (網站： www.hightechagenda.de/)

（未完，見續篇）

德國巴伐利亞邦高科技議程（Hightech Agenda Bayern）概況（六之一）

適合一般科技技術界。此文僅供個人參考與資訊喚回，尚非標準或官方內容。內文引用人工智慧平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱德國的巴伐利亞邦官方網站。 CC BY-SA 4。0。

概述：

🏛 計畫背景

2019年10月，巴伐利亞邦長索德爾（Markus Söder）在邦議會的施政聲明中，正式宣告啟動《巴伐利亞高科技議程》。

簡單說，這是一套由巴伐利亞（德Bayern，英Bavarian）邦政府主導、以技術創新驅動未來競爭力的「國家級投資計畫」。

💰 投資規模

巴伐利亞邦透過此計畫，總計投入約55億歐元，打造一場獨一無二的科技攻勢。
這個數字放在德國地方邦的層級，是相當罕見的豪賭，約略等同於台灣某些年度科技預算的規模。

🎯 六大核心主題領域

計畫聚焦於七個攸關未來的生活領域：

主題	內容
未來交通	自動駕駛、Hyperloop等新型移動技術
醫療健康	AI輔助診斷、醫療機器人
智慧城市	都市數位化、智能社區管理
高齡自主生活	輔助機器人、老年照護科技
能源安全	核融合研究、再生能源穩定供應
未來職場	新型態工作與創業生態系
農村振興	讓科技紅利普及至非都市地區

 

🔬 重點科技投資

人工智慧 在巴伐利亞各大學中設置了100個AI相關教席，以慕尼黑為機器人核心，並在維茨堡Würzburg （數據科學data science）、埃爾朗根-紐倫堡Erlangen-Nürnberg（醫學medicine, health）、因戈爾施塔特Ingolstadt （移動mobility）設立節點。

量子計算 加興的萊布尼茲計算中心（LRZ Leibnizrechenzentrum）被規劃成歐洲量子電腦quantencomputer的頂級基地，量子處理器將整合進超級電腦系統。2026年5月，歐洲首台量子電腦（Euro-Q-Exa）已在此正式啟動。

核融合 Nuklearfusion巴伐利亞聯合漢堡Hamburg、薩克森Sachsen等六個德國邦，成立核融合研究聯盟，目標是推動核融合從研究走向實際電廠應用。

👩‍🏫 人才策略：最重要的一環

高科技議程新增1,000個教授職位與13,000個學位名額，其中許多集中於AI與超級科技領域。
更特別的是「頂尖教授席次」計畫： 邦政府為少數頂尖學者提供每個教席最高500萬歐元的特別預算，延攬世界一流人才。

🏗 創新轉移機制

2023年啟動「Hightech Transfer Bayern」攻勢，在全邦設立15個技術轉移中心，投入逾1億歐元，目標是將研究成果落實到中小企業，尤其是農村地區。

📊 五年成績（2024回顧）

科學部長布魯姆（Markus Blume）在2024年10月的內閣報告中總結：「全巴伐利亞就是一座校園，而且是德國最好的。」他強調高科技議程是巴伐利亞因應時代轉型的成功回應，足以作為全德國的典範。

甲：上層規劃：巴伐利亞AI生態系（Baiosphere）：

「巴伐利亞AI生態系（Baiosphere）」是德國巴伐利亞邦政府在其總額 55 億歐元的「高科技議程（Hightech Agenda Bayern）」下創立的國家級人工智慧網路策略品牌。

Baiosphere 的核心宗旨是建立一個將頂尖學術科研、跨國巨頭、初創企業以及社會大眾緊密相連的強大網路，將巴伐利亞打造為全歐洲最具活力的 AI 研發、商業應用與負責任發展（Responsible AI）的國際核心重鎮。

以下詳細拆解 Baiosphere 生態系的四大支柱與核心架構：

一、 核心治理機構：推動生態系的「雙引擎」

Baiosphere 的運作並非鬆散的學術聯盟，而是由邦政府三大部門（科學與藝術部、數位事務部、經濟部）共同倡議，並設有明確的官方治理機構：
巴伐利亞 AI 局（Baiosphere Agency）：作為生態系的中央聯絡窗口，負責促進產學合作、推動技術轉移、營運媒合平台（Matchmaking Platform），並提升巴伐利亞 AI 在國際上的能見度。
巴伐利亞 AI 委員會（Bavarian AI Council）：由國際知名 AI 學者與企業領袖組成，定期發布《Baiosphere Monitor》等策略白皮書，為邦政府的科技政策提供具前瞻性的策略導向。

二、 基礎設施與科研實力（人才與資金支柱）

巴伐利亞政府透過「高科技議程」直接向 AI 領域注入超過 3.6 億歐元的專項資金，建立極高的競爭壁壘：
破紀錄的教授席位：在全邦各大高校增設了 130 多個全新 AI 專屬教授席位（Professorships），吸引全球頂尖科學家進駐。
龐大的人才庫：全邦開設了與 AI 相關的學位課程，提供超過 10,000 個學習名額，每年產出約 2,200 篇高水平科研論文。
頂尖研究聯盟：包含慕尼黑工業大學（TUM）、慕尼黑大學（LMU）、亥姆霍茲中心、弗勞恩霍夫研究所（Fraunhofer）及德國航空太空中心（DLR）等頂級機構。

三、 跨區域的「節點與網路（Hubs & Nodes）」架構

Baiosphere 採取「輻射狀」的地理分工，將不同城市的科研與產業優勢最大化，主要由四個核心節點（Hubs）與一個生產網路組成：

[ 慕尼黑總部 Munich ] (智慧機器人、大語言模型、MCML)
[ 紐倫堡-埃爾朗根 Erlangen ] (數位醫療、健康AI、醫療谷)	[ 烏茨堡 Würzburg ] (數據科學、生命科學、自動化)
[ 因戈爾施塔特 Ingolstadt ] (智慧移動、自動駕駛車聯網)

智慧機器人中心 —— 慕尼黑（Munich Hub）：
定位：整個生態系的地理與技術核心（2024年 CS-Robotics 全球機器人排名第二）。
重點：聚焦於智慧機器人（Intelligent Robotics）、機器學習基礎理論（如 LMU/TUM 共同創立的 慕尼黑機器學習中心 MCML）。
健康醫療 AI 節點 —— 紐倫堡-埃爾朗根（Health Node）：
定位：結合傳統「醫療谷（Medical Valley）」的優勢。
重點：聚焦於AI 輔助診斷、醫學影像識別與多模態醫療大模型，並擁有西門子醫療等企業支持。
智慧移動節點 —— 因戈爾施塔特（Ingolstadt Hub）：
定位：德國汽車工業重鎮（奧迪 Audi 總部所在地）。
重點：聚焦於自動駕駛、智慧交通網路（Mobility）、車聯網安全與工業 4.0 的 AI 應用。
數據科學與生命科學節點 —— 烏茨堡（Würzburg Hub）：
定位：由烏茨堡-施文福科技大學（THWS）的 CAIRO 中心等機構領銜。
重點：專注於將 AI 應用於數據科學、生命科學以及跨行業的技術落地。
AI 生產網路（AI Production Network）—— 奧格斯堡（Augsburg）：
專注於如何將 AI 技術落實到傳統製造業的生產線上，協助中小企業進行數位轉型。

四、 產業轉化與新創孵化（企業支柱）

Baiosphere 確保學術成果不會停留在紙面上，而是快速轉化為經濟價值：
兩大重量級平台：
appliedAI：歐洲領先的可信賴 AI（Trustworthy AI）應用平台，直接協助 BMW、西門子等巨頭以及中小型企業將 AI 導入其核心業務。
AI+MUNICH：專為 AI 新創公司設立的孵化專案，提供早期資金、技術對接與商業化指導。
巴伐利亞 AI 基礎模型倡議（Bavarian AI Foundation Model Initiative）：為應對 OpenAI 等美製大模型的競爭，生態系正全力資助研發屬於歐洲本土、符合高隱私標準的工業與醫療專用基礎大模型。

總結

Baiosphere 就像是巴伐利亞政府用政策與數億歐元資金灌溉出的一座「AI 熱帶雨林」。在這個生態系中，大學負責提供人才與演算法突破，Baiosphere Agency 負責牽線搭橋，而西門子、BMW 與無數新創企業則負責將 AI 實體化，最終形成一個從理論、硬體、軟體到法規（可信賴 AI）的完整閉環。

如果您對特定部分感興趣，我們可以繼續探討：
註冊 Baiosphere Matchmaking 平台 的跨國產學合作流程。
歐盟 AI 法案（AI Act） 規範下，Baiosphere 如何推動「可信賴 AI（Trustworthy AI）」。

參見：Bavaria High Tech Agenda (網站： www.hightechagenda.de/)

（未完，見續篇）

專案管理指引（八之三）

（續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

4.5 專案組織和角色

4.5.1 專案組織

專案組織是一個臨時結構，包括定義妥的專案中角色、責任和職權。通過名稱將個人分配給專案組織中的特定角色。專案組織宜：
a) 明確匯報路線；
b) 由專案發起人或專案委員會批准；
c) 與專案涉及的每個人進行溝通。
專案組織的設計可以取決於專案前後環節（見4.2）、組織環境（見4.4）和專案利害相關者（見4.5.10）。

宜為每個人詳細地定義專案組織，以瞭解他們的角色和責任，以及與他們一起工作的個人的角色和責任。在整個專案中，責任宜相互一致且可追溯。專案組織的設計和實施還宜考慮專案管理的非正式面向，例如組織文化、專案團隊成員的動力和協調，以及人際交往能力和行為水準。

專案組織結構的示例如圖5所示。宜定義專案組織內各個角色之間的關係，並可按照7.5中所敘述事項進行管理。
注1：當存在專案委員會時，可變更匯報路線以適應治理的安排。
注2：並非所有組織中都設有專案辦公室。

圖 5 專案組織結構示例

個人可以承擔多個角色，但擔任專案發起人角色的個人不宜同時擔任專案經理、工作包負責人或專案團隊成員的角色，因為可能存在利益衝突。

專案組織也可以包括顧客或顧客代表，以及供應商或外包商，如4.2.3中所述。根據所需完成的具體工作和所需的專業能力，專案組織可以在整個專案生命週期中發生變化，尤其是在各個階段交接處。

專案組織的角色和責任詳見4.5.2至4.5.11。

4.5.2 發起組織

發起組織是上層權責機構，宜向專案委員會或專案發起人提供指導和資源，應對不斷升級的風險和問題，並做出或參考超出專案委員會或專案發起人授權範圍的決策。專案發起人可以代表發起組織，因此可能沒有將風險和問題的上報的或尋求指導的上級權威機構。發起組織代表、實際擔任此職務的個人或主體取決於專案所處的前後環節。例如：

a) 對於專案組合內專案，上級權威機構可以是專案組合經理或總監；
b) 對於專案群內的專案，上級權威組織可以是專案群經理。
註：與發起組織相關的綜合專案管理實務內容見6.2、6.3和6.9。

4.5.3 專案委員會

如有需要，專案委員會宜通過向專案發起人提供方向和指導來為專案做出貢獻（見圖5）。相對於專案發起人，專案委員會角色的許可權因組織和專案而異。例如，專案委員會可以包括：
a) 代表專案發起人負責的上級權威機構或治理主體；
b) 或由專案發起人任職、向專案發起人提供高級建議的董事會。

專案委員會宜：
—監督專案進展和發展，以確保其為組織利益服務；
—通過會議形式協助策略決策、消除障礙，並解決問題。

如果專案是兩個或多個組織之間的結合，則專案委員會可以包括各個組織的代表（參考ISO 21505）。註：專案委員會的常用術語包括「專案指導小組」、 「專案指導董事會會」、 「專案指導委員會」或「治理委員會」等。

4.5.4 專案發起人

專案發起人對已定義的上級部門負責，以實現專案目標、交付所需的產出和成果，以實現所需收益。

專案發起人的責任宜包括但不僅限於：專案發起人宜承認或擁護營運論證案例，並對專案治理負責，包括審查、覆核和保證（參考ISO 21505）。此外，專案發起人的責任宜包括但不僅限於：
a) 查證專案在整個生命週期中的合理性；
b) 確認專案經理和團隊有技能並且有能力執行分配的工作；
c) 向專案經理提供決策、方向、建議和前後環節，以使營運論證案例中定義的陳述的商業需求能夠在專案或組織可接受的風險水準內得到滿足；
d) 確認組織為組織變革或社會變革做好了準備和承諾，並且確定變革的發生（見7.14）；
e) 解決升級的問題和風險；
f) 吸引關鍵的專案利害相關者；
g) 在其授權範圍內做出決定；
h) 將風險和問題升級到其授權範圍之外，擴展到更高級別的許可權；
i) 設定專案的文化和道德基調。

專案發起人通常是專案委員會的成員，代表專案委員會在日常工作或事先議定的專案管理活動中的利益和立場。在某些情況下，個人可以支援專案發起人，也可以履行既定責任來代表專案發起人行事。在此種情況下，宜在專案組織中定義責任分工。

注1：專案發起人常用術語包括「專案執行官project executive」、 「專案負責人project owner」、「產品負責人product owner representative」或「資深負責人senior responsible owner」等(見圖5)。
注2：與專案發起人相關的綜合專案管理實務，見6.4。

4.5.5 專案保證

雖然專案發起人對稽核、審查和保證等承擔最主要責任，但該等活動可分配給一名或多名人員，代表專案發起人行事，而且獨立于專案經理和項目團隊。

4.5.6 專案經理

專案經理對專案發起人或專案委員會負責，以完成定義範圍，並領導和管理專案團隊。專案經理的其他活動可能包括（但不僅限於）下列事項：
a) 建立與議定的治理方法一致的管理方法；
b) 激勵專案團隊；
c) 提供日復一日常規型監督和領導力；
d) 為團隊設定方法、責任、工作範圍和標的；
e) 根據專案計畫監督、預測和匯報專案總體進度（見7.2和7.15）；
f) 管理風險（見7.8）和問題（見7.9）；
g) 控制和管理專案變更 (見7.10)；
h) 按照相關合約的規定管理供應商績效（見7.17）；
i) 確保專案利害相關者按計劃參與（見7.12）和溝通（見7.13）專案；
j) 確證專案提供的產出和成果。

專案經理可以由專案管理團隊協助，其成員擔任特定的角色，例如排程、成本控制和品質保證。
註：與專案經理相關的綜合專案管理實務，見6.5、6.6及6.8。

4.5.7 專案辦公室

如有需要，專案辦公室宜有其明確的角色、責任和匯報線。專案辦公室可以執行各式各樣的活動來支持專案經理和專案團隊，包括但不僅限於：
a) 分析；
b) 制定出和行政支援治理；
c) 使專案方法和過程標準化；
d) 專案管理訓練；
e) 規劃和監督；
f) 資訊管理；
g) 提供行政支援。

此外，專案辦公室可以支持多個專案，可與專案群或專案組合管理辦公室結合，也可以執行專案群或專案組合管理辦公室的職能。

專案辦公室可以支持除專案經理之外的角色，例如專案發起人、專案委員會或專案團隊中的其他職位。專案辦公室可以承擔專案管理組織能力中心或卓越中心的角色，支援組織提高其專案管理的成熟度。

註：專案辦公室可以稱為「專案管理辦公室project management office」、 「專案支援辦公室project support office」，或其他組織批准的術語。

4.5.8 工作包負責人

工作包負責人對專案經理領導、管理和交付工作包中定義的指派的產出或成果。工作包負責人或團隊負責人可以是發起組織的一部分，也可以來自協力廠商組織，例如：供應商。工作包負責人的責任包括但不僅限於：
a) 確定工作包已按要求的品質、進度和預算完成；
b) 協助和審查重要的管理文件；
c) 對照工作包計畫，規劃、監督、預測和匯報總體進度；
d) 管理著去解決風險和問題，並向上呈報超出其決策許可權的風險和問題；
e) 控制工作範圍的變更，並向上請求超出其許可權的變更授權；
f) 管理和最佳化資源的使用；
g) 將最終產出移交給專案團隊或專案經理。

注1：專案經理可以承擔工作包負責人的角色。
注2：與工作包負責人相關的綜合專案管理實務，見6.7。

4.5.9 專案團隊成員

專案團隊成員執行專案活動，並對工作包負責人或專案經理負責完成其分配的活動和提供相應的交付物。

4.5.10 專案利害相關者

專案利害相關者是指對專案感興趣、可能影響、受到影響，或者是自認為會遭到影響的個人、團體或組織（見圖6）。專案利害相關者可以來自專案和組織的內部或外部。

圖 6 潛在的利害相關者示例

4.5.11 其他角色

宜確定其他角色，以適應所需工作，例如管理產出開發的角色。例子包括與敏捷交付、服務和營運管理、組織化與社會變革、溝通和各種工程學科相關的角色。

4.6 專案人員的專業能力

專案管理的專業能力可分為（但不僅限於）以下事項：
a) 技術型專業能力，指導、管理、規劃和交付專案的技術能力，包括該文件定義的概念和實施；
b) 行為型專業能力，與人際關係相關的行為能力，例如領導力、開發團隊、人員管理、輔導、談判和衝突管理等；
c) 在組織、合約和外部環境中與專案管理相關的業務和其他專業能力。

不參與專案管理的專案團隊成員宜具備在相關領域的專業能力，使其能夠履行分配到的責任。

宜將所需專業能力與現有專業能力的差距視為專案的約束或風險。宜審查並縮小專業能力差距。專業能力和技能可以通過持續的個人和專業發展來改進或提升。

參見標準ISO 21502-2020
Project, programme and portfolio management — Guidance on project management
專案、專案群和專案組合管理 — 專案管理指引

（未完，見續篇）