專案章程（Project Charter）是正式授權專案啟動的文件，確立專案存在的理由、範圍與負責人。這篇文章將帶你從零開始，掌握專案章程的 7 大核心要素、5 步驟撰寫流程，並提供可直接套用的範本。
目錄
Toggle
什麼是專案章程（Project Charter）？為什麼專案章程如此重要？專案章程的 7 大核心要素1. 專案目的與背景（Why）2. 可衡量的專案目標（Objective）3. 專案範圍（Scope）4. 關鍵里程碑與時程（Timeline）5. 專案團隊與角色（Team & RACI）6. 所需資源與預算（Resources & Budget）7. 風險與假設條件（Risks & Assumptions）專案章程怎麼寫？5 步驟完整流程Step 1｜召集關鍵利害關係人進行需求訪談Step 2｜起草章程初稿（使用範本）Step 3｜與發起人對齊目標與資源Step 4｜跨部門審閱與修訂Step 5｜正式簽核與存檔專案章程範本（可直接套用）範本架構情境範例一：IT 系統導入專案情境範例二：行銷活動專案常見錯誤與最佳實務5 個新手 PM 最常犯的錯誤讓章程真正發揮效用的 3 個實務技巧專案章程 vs. 相關文件比較用數位工具管理專案章程結論專案章程常見問題專案章程和 PMP 考試有什麼關係？小型專案也需要寫專案章程嗎？專案章程可以修改嗎？專案章程用中文還是英文寫？專案章程和商業案例（Business Case）的關係是什麼？
什麼是專案章程（Project Charter）？
一句話定義：專案章程是正式授權專案存在的文件，讓所有利害關係人在同一頁上對齊目標、範圍與責任歸屬。
很多新手 PM 會把「專案章程」和「專案計畫」搞混。兩者的差異其實很明確——章程是「授權文件」，回答的是「我們為什麼要做這個專案、誰負責、大方向是什麼」；專案計畫則是「執行藍圖」，回答的是「具體怎麼做、每週做什麼、誰在哪天交付什麼」。章程通常 1-2 頁就能搞定，專案計畫可能長達數十頁。
在 PMP / PMBOK 框架中，「發展專案章程」（Develop Project Charter）是啟動流程群組的第一個流程。它的輸入包含商業文件（Business Case）、協議與企業環境因素；工具是專家判斷與會議；輸出就是專案章程本身與假設日誌。如果你正在準備 PMP 考試，這個流程的 ITTOs（輸入、工具技術、輸出）是必考重點。
那誰來寫？通常由專案經理起草，但最終需要專案發起人（Sponsor）簽核授權。發起人的簽名代表「公司正式認可這個專案的存在，並承諾提供資源」。
舉個實際情境：一家台灣電商公司決定啟動「會員系統改版」專案。PM 在第一週訪談了業務主管、IT 主管和行銷團隊後，產出一份兩頁的專案章程，讓跨部門主管在同一份文件上確認目標——「行動端結帳完成率從 45% 提升至 60%」。這份文件讓所有人從第一天就知道「我們要做什麼、不做什麼」，後續省下了無數次「當初不是說好要做 XX」的爭論。
▲ 專案章程在專案生命週期中的位置：啟動階段（產出章程）→ 規劃階段（產出專案計畫）→ 執行階段（交付成果）→ 監控階段（追蹤進度）→ 結案階段（驗收與回顧）
為什麼專案章程如此重要？
我們團隊在過去幾年參與過不少專案，有些一開始就有完整章程，有些是「老闆口頭交辦就開工」。兩種模式的結果差異非常明顯。專案章程的核心價值可以歸納為三點：
第一，正式授權。 PM 獲得調動資源的合法依據。沒有章程，你去找其他部門借人，對方一句「我沒收到通知」就能把你擋回來。有了發起人簽核的章程，你拿著文件去協調資源，對方主管至少知道「這是公司認可的專案」。
第二，對齊期望。 利害關係人在專案開始前就確認目標與範圍。我們曾經歷過一個沒有章程的專案，業務主管認為目標是「提升營收」，IT 主管認為目標是「系統穩定性」，行銷主管認為目標是「品牌曝光」——三個人各做各的，直到第三個月才發現方向完全不同。
第三，防止範疇蔓延（Scope Creep）。 這是台灣職場最常見的痛點。專案進行到一半，老闆突然說「順便把後台也改一下」，如果你有章程明確寫著「後台管理介面不在本次範圍內」，你就有依據進行正式的變更評估，而不是默默加班把需求吞下去。
如果你正在學習如何有效管理任務的優先順序，可以參考艾森豪矩陣的四象限法，幫助你在專案中快速判斷哪些需求該納入、哪些該排除。
面向
有專案章程
沒有專案章程
資源調度
PM 有正式授權，跨部門協調有依據
靠人情借資源，隨時可能被抽走
目標清晰度
所有人對齊同一個可衡量目標
每個人心中有不同版本的「成功」
範圍管理
新需求需走正式變更流程
需求不斷膨脹，沒人敢說不
衝突頻率
有文件可依據，爭議快速解決
各說各話，會議反覆討論同一件事
專案結案
有明確驗收標準
永遠「差一點就好」，無法收尾
▲ 有章程 vs. 沒有章程的專案結果對比——左欄「有章程」：目標明確、資源到位、範圍可控、衝突少；右欄「沒有章程」：目標模糊、資源不穩、範圍膨脹、爭議多
什麼時候需要寫專案章程？ 判斷標準很簡單：如果專案涉及跨部門協作、需要調動預算、或執行時間超過一個月，就建議寫。小型專案可以用精簡版（一頁），涵蓋目標、範圍、負責人、截止日即可。如果只是部門內部一週能完成的任務，一封 email 確認就夠了。
專案章程的 7 大核心要素
一份完整的專案章程需要涵蓋以下七個要素。我們會逐一說明每個要素的撰寫重點，並附上實際範例。
▲ 專案章程7大核心要素：專案目的與背景、可衡量的專案目標、專案範圍、關鍵里程碑與時程、專案團隊與角色、所需資源與預算、風險與假設條件
1. 專案目的與背景（Why）
這是整份章程最重要的段落——回答「為什麼要做這個專案」。如果連這個問題都說不清楚，後面的一切都是空談。
撰寫時建議用這個邏輯結構：「因為 ，所以我們需要 ，預期達到 ___」。
範例：「因為現有會員系統無法支援行動裝置，導致 App 結帳轉換率低於產業平均 30%，因此啟動會員系統改版專案，預期在 Q3 結束前將行動端結帳完成率提升 20%。」
常見錯誤是寫成「為了提升公司競爭力」這種空泛的理由。好的背景說明應該包含具體的數據或事件，讓任何人讀完都能理解「不做這個專案會怎樣」。
如果你的專案涉及更大的商業策略規劃，建議先用商業模式九宮格釐清整體商業邏輯，再回頭寫章程會更有說服力。
2. 可衡量的專案目標（Objective）
目標必須符合 SMART 原則：具體（Specific）、可衡量（Measurable）、可達成（Achievable）、相關（Relevant）、有時限（Time-bound）。
錯誤寫法
正確寫法
提升用戶體驗
Q3 結束前，App 結帳完成率從 45% 提升至 60%
降低成本
導入自動化流程後，每月報表產出時間從 8 小時縮短至 2 小時
增加營收
新會員系統上線後 6 個月內，會員回購率從 22% 提升至 35%
我們團隊在撰寫目標時，會用一個簡單的檢核方式：把目標唸給一個完全不了解專案的人聽，問他「你知道怎麼判斷這個目標有沒有達成嗎？」 如果對方答不出來，代表目標還不夠具體。
實務上，你可以用 ClickUp 的 SMART Goals 範本來結構化你的目標設定，範本內建了每個 SMART 維度的檢核欄位，填完就知道目標夠不夠明確。
3. 專案範圍（Scope）
範圍要明確列出「做什麼」（In Scope）與「不做什麼」（Out of Scope）。很多 PM 只寫了 In Scope 就覺得夠了，但 Out of Scope 欄位同等重要——它是你防止範疇蔓延的第一道防線。
範例：
In Scope（本次範圍內）
Out of Scope（本次不含）
iOS / Android App 會員系統改版
後台管理介面重新設計
新增社群登入功能（Google、Apple）
LINE 官方帳號串接
行動端結帳流程優化
金流系統更換
撰寫提示：每次有人提出新需求，先對照 Out of Scope 清單。如果在清單上，就需要走正式的變更流程（Change Request），而不是直接答應。
4. 關鍵里程碑與時程（Timeline）
章程中的時程不需要像甘特圖那樣詳細——列出 3-5 個關鍵里程碑即可，詳細排程留給後續的專案計畫。
每個里程碑務必標注「完成定義（Definition of Done）」，避免模糊的「差不多完成了」。
里程碑
預計完成日
負責人
完成定義
需求確認完成
3/15
PM
需求文件經所有 Stakeholder 簽核
UI 設計定稿
4/30
設計主管
所有頁面 Mockup 通過用戶測試
開發完成
7/15
技術主管
所有功能通過 QA 測試，Bug 數 < 5
UAT 驗收
8/15
PM
業務主管完成驗收簽核
正式上線
9/1
技術主管
App Store / Google Play 審核通過
如果你想把里程碑視覺化，monday.com 的時間軸檢視可以一鍵將里程碑轉成甘特圖，我們團隊用它來追蹤跨部門專案的進度，主管打開看板就能掌握全貌，不需要每週開會報告。
5. 專案團隊與角色（Team & RACI）
列出 PM、發起人、核心成員與顧問角色，建議搭配簡化版 RACI 矩陣。RACI 代表：
R（Responsible）：實際執行的人
A（Accountable）：最終決策與負責的人
C（Consulted）：需要諮詢意見的人
I（Informed）：需要被通知進度的人
任務
PM
IT 主管
業務主管
法務
設計團隊
需求訪談
A
C
R
I
C
系統開發
I
A
C
I
R
上線決策
C
R
A
C
I
合約審查
I
I
C
A/R
I
▲ 簡化版RACI矩陣範例——四個角色說明：R負責執行、A最終決策、C諮詢意見、I通知進度
如果你的團隊超過 10 人，手動維護 RACI 矩陣會很痛苦。我們實際測試過 ClickUp 的 RACI 範本，它能自動追蹤每個成員的角色分配，當有人離職或角色調整時，一個地方改就全部同步。
6. 所需資源與預算（Resources & Budget）
資源分為三類：人力、預算、工具與系統。
人力資源要標注投入比例，例如：
前端工程師：50% FTE × 3 個月
UI 設計師：100% FTE × 2 個月
QA 測試：30% FTE × 1.5 個月
預算概估在章程階段不需要精確到個位數，±25% 的精度即可。例如：
外部設計顧問費：NT$150,000 – NT$200,000
雲端伺服器升級：NT$50,000 / 月
測試設備採購：NT$80,000
工具與系統需求：列出專案執行需要的軟體或平台，例如專案管理工具、設計協作工具、測試環境等。
7. 風險與假設條件（Risks & Assumptions）
這是最常被新手 PM 跳過的欄位。「目前沒有風險」這句話幾乎不可能成立——它只代表你還沒認真想過。
風險要列出 Top 3-5 項，每項標注發生機率與影響程度：
風險描述
發生機率
影響程度
應對策略
核心工程師離職
中
高
確保至少 2 人熟悉核心模組
第三方 API 文件延遲
高
中
預留 2 週緩衝時間
用戶測試回饋需大幅修改 UI
中
中
分階段測試，提早發現問題
假設條件（Assumptions） 是章程成立的前提。例如：
假設 IT 部門能在 Q2 前完成 API 文件
假設行銷預算不會在專案期間被削減
假設現有伺服器能支撐改版後的流量
依賴關係（Dependencies） 則是哪些外部因素會影響專案。這些依賴可能是助力（例如另一個專案的成果可以直接沿用），也可能是阻力（例如法規變更導致需求調整）。把依賴關係列清楚，能幫助你提前識別哪些環節最脆弱。
在撰寫風險評估時，如果你需要更系統化的分析框架，可以參考企劃書的撰寫方法，其中的風險分析段落同樣適用於專案章程。
專案章程怎麼寫？5 步驟完整流程
了解了 7 大要素之後，接下來是實際的撰寫流程。我們團隊每次啟動新專案，都會按照這 5 個步驟來產出章程。
▲ 專案章程撰寫5步驟：Step 1 利害關係人訪談（1-2天）→ Step 2 起草章程初稿（1天）→ Step 3 與發起人對齊目標（半天）→ Step 4 跨部門審閱修訂（2-3天）→ Step 5 正式簽核存檔（半天）
Step 1｜召集關鍵利害關係人進行需求訪談
在動筆之前，先花 1-2 天訪談三類人：發起人、主要客戶（或使用者代表）、核心團隊成員。
以下是我們實際使用的訪談問題清單，你可以直接複製使用：
這個專案成功的樣子是什麼？你怎麼判斷它成功了？
什麼情況下我們應該喊停這個專案？
哪些資源是確定可用的？哪些需要額外爭取？
你最擔心這個專案的什麼？
有沒有其他正在進行的專案會影響這個專案？
訪談不需要很正式，30 分鐘的一對一就夠了。重點是聽出每個人心中對「成功」的定義是否一致——如果不一致，章程就是讓大家對齊的工具。
Step 2｜起草章程初稿（使用範本）
拿著訪談筆記，對照前面提到的 7 大要素，開始填寫範本。建議使用結構化範本，避免從空白文件開始。
這個階段的原則是先求完整，再求精確。初稿不需要所有數字都確定——預算可以寫「NT$500,000 – NT$700,000（待確認）」，時程可以寫「預計 Q3，確切日期待排程」。重要的是每個欄位都有內容，不要留白。
實務上，我們團隊會在 monday.com 的 WorkDocs 中直接起草章程，好處是文件和專案看板在同一個平台上，後續簽核、版本紀錄、成員存取都不用另外管理。免費方案就能使用這個功能，不需要信用卡。
Step 3｜與發起人對齊目標與資源
這是最常被跳過的步驟，也是最多爭議的來源。
拿著初稿和發起人坐下來，重點確認三件事：
1. 預算上限：不是「大概多少」，而是「超過多少需要重新審批」
2. 優先順序：時程、品質、成本三者不可能全部最優，發起人必須明確排序
3. 決策權限：哪些決定 PM 可以自己做，哪些需要上報
這個步驟通常需要半天，但它能幫你在後續幾個月省下無數次來回確認的時間。
Step 4｜跨部門審閱與修訂
把修改後的章程發給所有 Stakeholder 審閱。關鍵是設定審閱截止日——我們通常給 3 個工作天。沒有截止日的審閱會變成無限期修改。
審閱時建議使用有留言功能的協作工具，讓每個人的意見都有紀錄。Google Docs 的留言功能就很好用，或者如果你的團隊已經在用 Notion，它的版本紀錄功能可以追蹤每次修改的內容與修改者。
收到回饋後，PM 負責整合意見、解決衝突，產出最終版本。如果某個意見涉及重大方向調整（例如有人要求擴大範圍），需要回到 Step 3 和發起人重新確認。
Step 5｜正式簽核與存檔
取得發起人（必要時加上高層主管）的簽名或數位確認。在台灣企業環境中，email 回覆「核准」或在文件上蓋章都算正式簽核，重點是有紀錄可查。
簽核後的章程存放在專案資料夾的根目錄，確保所有成員可存取。我們的做法是在 monday.com 的專案看板上建立一個「專案文件」群組，把章程釘在最上方，新成員加入時第一件事就是讀這份文件。
章程簽核完成後，就可以正式召開專案啟動會議（Kick-off Meeting），向全體團隊宣布專案正式啟動。如果你還不確定啟動會議該怎麼開，可以參考我們的專案啟動會議教學，裡面有完整的議程範本。
⭐ Fortune 500 有 60% 是客戶
⭐ 4.8 / 5
monday.com｜250,000+ 團隊的專案管理首選
🎁 免費版永久使用 + 14 天 Pro 試用——內建 200+ 專案範本，看板、甘特圖、時間軸 3 分鐘完成設定
📋 看板、甘特圖、時間軸——同一專案 3 種視圖自由切換⚡ 200+ 自動化範本——截止提醒、任務指派、進度同步全自動👥 從 2 人到 200 人團隊都適用——10 分鐘上手🔗 整合 Gmail、Slack、Zoom 等常用工具——資訊不用到處找
免費建立第一個專案看板 →
✓ 免費版永久使用 · ✓ Fortune 500 有 60% 在用 · ✓ 不需信用卡
專案章程範本（可直接套用）
以下是我們團隊實際使用的專案章程範本架構。你可以直接複製這個結構，根據自己的專案填入內容。
範本架構
欄位
填寫要點
專案名稱
簡潔明確，讓人一看就知道在做什麼（如「會員系統改版專案」）
文件版本 / 最後更新日期
每次修改都更新版本號（v1.0 → v1.1），避免多版本混亂
專案發起人
有預算決策權的人，通常是部門主管或更高層級
專案經理
日常負責推動專案的人
專案目的與背景
用「因為 → 所以 → 預期」的結構，包含具體數據
專案目標（SMART）
每個目標都要可衡量、有截止日
專案範圍（In / Out of Scope）
In Scope 和 Out of Scope 都要列，缺一不可
關鍵里程碑
3-5 個，每個標注完成定義與負責人
團隊成員與角色
搭配 RACI 矩陣，明確誰負責、誰決策
預算概估（NT$）
±25% 精度即可，標注「待確認」的項目
主要風險與假設
Top 3-5 風險 + 假設條件 + 依賴關係
簽核欄位
發起人簽名 / 日期，必要時加上高層主管
情境範例一：IT 系統導入專案
專案名稱： ERP 系統導入專案
專案目的： 因為現有的 Excel 報表流程每月耗費各部門共 120 人時，且資料錯誤率達 8%，因此導入 ERP 系統，預期在上線後 3 個月內將月結報表產出時間縮短 70%，資料錯誤率降至 1% 以下。
In Scope： 財務模組、庫存模組、採購模組
Out of Scope： HR 模組（列入第二期）、客製化報表開發
預算概估： NT$2,000,000 – NT$2,500,000（含軟體授權、顧問費、教育訓練）
如果你的專案涉及數位轉型，ERP 導入通常是其中一個關鍵環節，章程中的目標應該與整體轉型策略對齊。
情境範例二：行銷活動專案
專案名稱： 週年慶全通路行銷活動
專案目的： 配合品牌成立 10 週年，透過線上線下整合行銷活動，預期在活動期間（10/1-10/31）帶來 NT$5,000,000 營收，較去年同期成長 25%。
In Scope： 社群廣告投放、門市活動佈置、會員 EDM 發送、KOL 合作
Out of Scope： 品牌 VI 重新設計、官網改版、新品開發
預算概估： NT$800,000 – NT$1,000,000（含廣告費、KOL 費用、物料製作）
▲ 兩種專案章程情境對比——左欄「IT系統導入」：目標偏效率提升、時程較長（6-12個月）、預算較高、風險偏技術面；右欄「行銷活動」：目標偏營收成長、時程較短（1-3個月）、預算較低、風險偏市場面
常見錯誤與最佳實務
5 個新手 PM 最常犯的錯誤
錯誤 1：目標寫得太模糊。「提升效率」不是目標，「將每月報表產出時間從 8 小時縮短至 2 小時」才是。模糊的目標會讓專案永遠無法「完成」，因為沒有人知道什麼時候算成功。
錯誤 2：跳過 Out of Scope。 沒有明確排除的項目，後期都可能被要求納入。我們團隊有個血淚教訓：某次專案沒寫 Out of Scope，結果上線前兩週被要求加入「多語系支援」，整個時程延後一個月。
錯誤 3：風險欄位留白。「目前沒有風險」幾乎不可能——這代表你還沒認真思考。至少列出 3 個風險，即使是「核心成員請長假」這種看似不太可能的事。
錯誤 4：章程寫完就束之高閣。 章程不是寫完就放著的文件。應在每次重大變更時重新確認，必要時正式修訂。具體的更新觸發條件包括：範圍重大變更、關鍵成員異動、預算調整超過 20%、外部環境重大變化（如法規修改）。
錯誤 5：沒有取得正式簽核。 口頭同意不算數。缺乏簽核的章程無法作為資源調度的依據，當你需要跨部門借人時，一句「老闆有說過」完全沒有約束力。
▲ 錯誤寫法 vs. 正確寫法對比——左欄「錯誤」：目標模糊、無Out of Scope、風險留白、無簽核；右欄「正確」：SMART目標、明確排除項目、Top 3-5風險、發起人簽核
讓章程真正發揮效用的 3 個實務技巧
技巧 1：一頁化原則。 核心資訊盡量控制在 1-2 頁。忙碌的主管不會讀 10 頁的章程——他們需要的是快速掌握重點。如果某些細節需要展開，放在附件中即可。
技巧 2：定期回顧。 在每個里程碑結束時，花 15 分鐘確認章程內容是否仍然有效。目標還對嗎？範圍有變嗎？風險有新增嗎？這個習慣能幫你提早發現偏離方向的徵兆。
技巧 3：視覺化呈現。 用表格和流程圖取代大段文字。一張 RACI 矩陣表格的溝通效率，遠勝過三段文字描述。
如果你是新手 PM，在撰寫第一份章程時可能會感到不確定——這很正常。很多資深 PM 也承認，他們剛開始時也有冒牌者症候群的感覺。重點是先寫出來，再逐步優化。
專案章程 vs. 相關文件比較
很多人會搞混專案章程和其他專案文件。以下是四份常見文件的比較：
文件
產出時機
主要目的
詳細程度
撰寫者
商業案例（Business Case）
章程之前
評估可行性與投資報酬率
財務導向
發起人 / 分析師
專案章程（Project Charter）
啟動階段
正式授權專案、對齊目標
概要（1-2 頁）
PM 起草，發起人簽核
專案計畫（Project Plan）
規劃階段
詳細的執行藍圖
非常詳細
PM
工作說明書（SOW）
採購 / 委外時
定義交付物與驗收標準
合約層級
PM / 採購
流程順序是： 商業案例 → 專案章程 → 專案計畫。商業案例回答「這個專案值不值得做」，章程回答「我們正式決定做了，方向是什麼」，計畫回答「具體怎麼做」。
在 PMP / PMBOK 框架中，商業案例是「發展專案章程」這個流程的輸入之一。也就是說，理論上你應該先有商業案例，才能產出章程。但在台灣實務中，很多中小企業的專案是老闆一句話就啟動的，商業案例和章程可能會合併成一份文件——這沒問題，重點是核心資訊都有涵蓋。
如果你需要撰寫工作說明書，ClickUp 的 SOW 範本提供了結構化的框架，可以和章程搭配使用。
▲ 專案文件產出順序：商業案例（評估階段）→ 專案章程（啟動階段）→ 專案計畫（規劃階段）→ 工作說明書（採購/委外時）
用數位工具管理專案章程
傳統上，專案章程是一份 Word 或 PDF 文件，寫完後存在共用資料夾裡。但隨著團隊協作方式的改變，越來越多 PM 開始用數位工具來管理章程的撰寫、審閱與版本控制。
根據你的團隊規模和工作方式，以下是我們測試過的幾種方案：
5 人以下、剛開始接觸專案管理： 先用 Google Docs 就夠了。留言功能可以追蹤審閱意見，版本紀錄可以回溯修改歷程。搭配 Google Drive 的共用資料夾，基本需求都能滿足。
5-15 人跨部門協作： 推薦 monday.com。我們團隊實際使用它管理日常工作，章程直接在 WorkDocs 中撰寫，和專案看板整合在同一個平台。PM 設定了一條自動化規則：當章程狀態從「審閱中」改為「已簽核」時，自動通知所有團隊成員並建立第一批任務。這個設定讓我們從章程簽核到專案正式啟動的時間從 3 天縮短到半天。
技術團隊跑 Scrum： ClickUp 的文件功能支援 Markdown 格式，對工程師來說很友善。它的範本庫中有現成的專案章程模板，填完直接和 Sprint 看板串接。
15 人以上的大型專案： monday.com 的企業方案支援更細緻的權限控制和審批流程，適合需要多層簽核的組織。
（推薦試試 monday.com 的免費方案，我們團隊實際使用後，專案啟動效率提升明顯，而且不需要信用卡就能開始。）
⭐ 全球 500 萬+ 團隊使用
⭐ 4.6 / 5
ClickUp｜一個平台取代任務管理、文件、白板 5+ 工具
🎁 免費版永久使用——不限任務數，看板、甘特圖、文件、白板全包含
✅ 任務管理 + 文件 + 白板 + 目標追蹤——一站搞定🎨 15+ 檢視模式——清單、看板、甘特圖、心智圖自由切換🤖 Brain MAX AI——內建寫作助手 + 智能任務建議💰 免費版功能超豐富——個人和小團隊完全夠用
免費開啟 ClickUp →
✓ 免費版不限任務數 · ✓ 500 萬+ 團隊在用 · ✓ 不需信用卡
結論
專案章程是 5-10% 的前期投資，換取整個專案的方向清晰與資源保障。回顧本文重點：
專案章程是授權文件，不是執行計畫。 它回答「為什麼做、做什麼、誰負責」，通常 1-2 頁就夠。
7 大核心要素缺一不可： 目的與背景、SMART 目標、範圍（含 Out of Scope）、里程碑、團隊角色、資源預算、風險與假設。
Out of Scope 和風險欄位是最容易被忽略、卻最能保護你的欄位。 寫清楚這兩項，能幫你擋掉後期 80% 的爭議。
撰寫流程是：訪談 → 起草 → 對齊 → 審閱 → 簽核。 不要跳過和發起人對齊的步驟。
章程是活的文件。 在重大變更時更新版本，定期回顧確認方向正確。
你的下一步行動： 打開 monday.com，用「專案啟動模板」建立新看板，把這篇文章提到的 7 大要素填入 WorkDocs 中。10 分鐘就能建好你的第一個專案框架——比繼續用 email 來回確認高效得多。
如果你想進一步提升主管領導力，學會撰寫專案章程只是第一步——如何用這份文件凝聚團隊共識、推動跨部門協作，才是真正的挑戰。
⭐ Fortune 500 有 60% 是客戶
⭐ 4.8 / 5
monday.com｜250,000+ 團隊的專案管理首選
🎁 免費版永久使用 + 14 天 Pro 試用——內建 200+ 專案範本，看板、甘特圖、時間軸 3 分鐘完成設定
📋 看板、甘特圖、時間軸——同一專案 3 種視圖自由切換⚡ 200+ 自動化範本——截止提醒、任務指派、進度同步全自動👥 從 2 人到 200 人團隊都適用——10 分鐘上手🔗 整合 Gmail、Slack、Zoom 等常用工具——資訊不用到處找
免費建立第一個專案看板 →
✓ 免費版永久使用 · ✓ Fortune 500 有 60% 在用 · ✓ 不需信用卡
專案章程常見問題
專案章程和 PMP 考試有什麼關係？
PMBOK 第 6 版將「發展專案章程」列為啟動流程群組的第一個流程，是 PMP 考試的必考概念。你需要記住它的 ITTOs：輸入是商業文件、協議與企業環境因素；工具是專家判斷、資料蒐集與會議；輸出是專案章程與假設日誌。考試不會要你背範本內容，但會考「誰有權簽核章程」（答案是發起人）和「章程的主要目的」（正式授權專案並指派 PM）。如果你想系統性準備 PMP，Coursera 上的專案管理課程是不錯的起點。
小型專案也需要寫專案章程嗎？
不一定需要完整版，但建議至少寫精簡版。判斷標準：如果專案涉及跨部門協作、需要調動預算、或執行時間超過一個月，就值得花 30 分鐘寫一份一頁的精簡章程，涵蓋目標、範圍、負責人、截止日即可。如果只是部門內部一週能完成的任務，一封確認 email 就夠了。面對「老闆說不用寫這麼多」的壓力，你可以把精簡版章程包裝成「專案確認單」——換個名字，核心資訊不變。
專案章程可以修改嗎？
可以，但需要正式的變更流程。具體的更新觸發條件包括：範圍重大變更、關鍵成員異動、預算調整超過 20%、發起人更換、外部環境重大變化（如法規修改或市場劇變）。每次修改應更新版本號與日期（v1.0 → v1.1），並重新取得發起人確認。如果你在用 monday.com 管理專案，WorkDocs 的版本紀錄功能可以自動追蹤每次修改，不用擔心版本混亂。
專案章程用中文還是英文寫？
視組織文化與利害關係人而定。台灣本地團隊建議用中文，降低溝通門檻；跨國專案或外商環境建議英文或雙語版本。如果是雙語，建議以主要決策者的語言為主版本，另一語言為參考版本，避免翻譯造成的理解落差。
專案章程和商業案例（Business Case）的關係是什麼？
商業案例在章程之前產出，回答的是「這個專案值不值得做」，通常包含投資報酬率分析、市場機會評估等財務導向內容。章程則是在商業案例通過後，正式授權專案啟動的文件。簡單來說，商業案例是「提案」，章程是「批准令」。在台灣中小企業中，這兩份文件經常合併成一份，只要核心資訊都有涵蓋就沒問題。