專案管理指引（八之五）

（續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱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
專案、專案群和專案組合管理 — 專案管理指引

（未完，見續篇）

專案管理指引（八之二）

（續前篇）

適合一般專案及專案管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱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
專案、專案群和專案組合管理 — 專案管理指引

（未完，見續篇）

專案管理指引（八之一）

 

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

該文件係基於ISO 21500:2012的修改版（即2021年版本）而撰寫的指引文件，更新事項如下述：
a）專案管理的邊界擴展到專案發起人機構的專案監督和指導工作；
b）新增專案成果和專案收益的有關內容；
c）新增專案的組織級前後環節的因素；
d）新增專案組織的角色和責任；
e）新增專案生命週期決策點、門禁的描述，擴充了專案管理業務；
f）新增專案前和專案後的工作描述；
g）內容形式從基於過程性的描述轉變為按業務和基於事實陳述的描述（參見附錄A）。

簡介

該文件提供專案管理中重要的概念與實務指引，對於專案的成功交付產生衝擊。
該文件的目標讀者群包括（但不限於此）：
a）執行階層及資深管理階層人員，提供更深入的專案管理之理解，並協助他們給予專案經理及專案相關人員適當的支持與指導；
b）參與專案治理、指導、保證、稽核及管理的個人，如專案贊助人、專案董事會、稽核員及專案經理；
c）專案經理與專案團隊成員，建立共同的基礎，以理解、執行、比較、評估及溝通專案所採用的實務；
d）國家或組織專案管理標準、流程與方法的制定者。
此外，該文件對參與支持的個人也非常有用：
—投資組合與計畫的治理、指導與管理；
—專案團隊、計畫與專案辦公室或類似組織架構；
—專案、計畫與組合管理的學術研究；
—與專案管理相關的職能，如財務、會計、人力資源管理、採購及法務。

目錄

1 範圍

該文件給出了專案管理的指導性內容，適用於企業與事業單位、機關和社團等不同組織的各式各樣目的、承接與交付成果方式、使用的生命週期模型、複雜程度、規模、成本或持續時間的專案。

註：交付成果方式可能是適合於各種差異之產出類型的各種方法或過程，例如預測型、增量型、反覆運算型、適宜型或混合型，包括敏捷方法。

該文件概括描述歷年來視為行之有效且獲得良好結果的專案管理前後環節。該文件並未給出專案群、專案組合的指引。僅在專案管理前後環節下描述共同適用的管理主題和內容。

3. 辭彙及術語

3.1	基線 baseline 對績效進行監督和控制的比較參考依據。
3. 2	收益benefit 創造的優勢、價值或其他正向影響。
3.3	營運論證案例 business case 用於支持對專案（3.20）、專案群（3.18）或專案組合（3.15）做出承諾的決策所提供的書面佐證說明。 註：按行業和專案階段，具體可形成立項佐證說明報告、專案建議書、商業計畫書、投資計畫書、可行性研究報告、開題報告、實施方案、方案報告、任務書等。
3.4	變更申請 change request 提議專案（3.20）做出變更的文件。
3.5	配置管理 configuration management 對控制（3.6）、關聯和維護文件化、規格和實際屬性的程序應用方式。
3.6	控制 control 將實際績效與規劃績效加以比較，分析偏差，並根據需要採取適當的矯正和預防措施（3.17）的活動。
3.7	矯正措施 corrective action 修正工作績效以使績效符合計畫的指導/方向和活動。
3.8	關鍵路徑 critical path 決定專案（3.20）或其中的各個階段最早可能達成日期的活動之前後順序。
3.9	交付物 deliverable 專案（3.20）需要產出的獨特且可查證的元素。
3.10	治理 governance 組織受到指導與控制的原則、政策及架構。
3.11	問題 issue 專案（3.20）期間發生的事件，需要將之解決，使專案（3.20）能夠繼續進行。
3.12	機會 opportunity 可能產生正面衝擊的風險事件。
3.13	成果 outcome 使用專案（3.20）產出（3.14）所出現的變化。
3.14	產出 output 構成專案（3.20）結果的有形或無形交付物（3.9）的總合成果。
3.15	組合portfolio 為促進管理以實現策略目標而將專案組合元件（3.16）聚集在一起的集合。
3.16	組合元件 portfolio component 專案（3.20）、專案群（3.18）、專案組合（3.15）或其他相關工作。
3.17	預防措施 preventive action 消除潛在不符合或其他潛在不期望情況的原因所採取的措施。 駐：採取預防措施以防止不符合發生，而採取矯正措施（3.7）以防止不符合再次發生。
3.18	專案群 programme 為實現收益（3.2）以協調的方式管理的一組專案群的組成物件（3.19）。
3.19	專案群組成物件 programme component 專案（3.20）、專案群（3.18）或其他相關工作。
3.20	專案 project 實現一個或多個既定目標所付出的臨時性努力。 補充說明： 一個「專案」就是為了達成某個特定目的，在一段有限的時間內，透過有計劃、有組織的付出努力來完成一系列獨特任務的過程。它與日常營運活動的區別在於其「臨時性」和「獨特性」，且需要一群人付出努力而達成專案目標。
3.21	專案保證 project assurance 使發起組織和專案發起人（3.26）相信專案（3.20）有可能實現其目標所採取的有計劃和有系統的必要措施。
3.22	專案治理 project governance 授權和指導專案（3.20）實現規劃設定目標的原則、政策和程序。 補充說明： 「專案治理」，是從經營層面設計橫跨多個專案管理與控制機制的相關知識。目的在確保企業內形形色色目前運作中專案能夠在預定的時間、預算和品質範圍內完成。
3.23	專案生命週期 project life cycle 從專案（3.20）開始到結束所定義的一組階段。 補充說明： 專案生命週期是指專案從構想到完成所經歷的結構化流程，通常分為五大階段：啟動、規劃、執行、監督與結束。
3.24	專案管理 project management 指導和控制（3.6）達成規劃設定目標的協調活動。
3.25	專案範圍 project scope 授權完成規劃設定目標的工作。
3.26	專案發起人 sponsor 負責獲取資源和執行決策以使專案成功的人。
3.27	專案利害相關者 stakeholder 對專案（3.20）、專案群（3.18）或專案組合（3.15）的任何方面有利益或可能影響、受其影響或認為自己受其影響的個人、群體或組織。
3.28	威脅 threat 可能產生負面衝擊的風險事件。
3.29	工作分解結構 work breakdown structure 將專案（3.20）或專案群（3.18）所定義的工作範圍逐層分解為更低層級工作單元而形成的結構。
3.30	工作包 work package 具有合宜定義出來的範圍、交付物（3.9）、時間表和成本的一組活動。

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


（未完，見續篇）