範疇管理通常包括:
- 在專案計畫書中描述如何進行範疇管理
- 通常公司或組織會有既定的範疇管理流程，如:收集需求、定義範疇、產生WBS、確認範疇、控制範疇
- 收集需求 (Collect Requirements)
- 定義範疇 (Define Scope)
- 產生WBS (Work Breakdown Structure)
- 確認範疇 (Validate Scope)
- 範疇控管 (Control Scope)
- 在後續的監控中就必須進行範疇的控制，當需求有變更時，必須要進行控管，以避免專案失控
- 一般的專案是定義了範圍在去思考時程與所需要的人力，但是，我們的專題期限跟人力是固定的，所以，要以期限跟人力去推估範圍
- 敏捷
- 就敏捷式開發而言，還是需要分析與設計，可是，敏捷式開發的情境是使用者可能也不知道需求，就算知道可能也會改變，那怎麼辦呢? 以Scrum為例，需求是以Product Backlog來呈現，Product Backlog裡會有很多產品待辦事項 (Product Backlog Items, PBI)，每個PBI可以是一個功能性需求(如:use case或user story)、非功能性需求或bug。當需求相對清楚的時候，可以利用use case作為PBI，當需求相對較不清楚或確定時，可以採用user story。與傳統的作法不一樣的是，敏捷式開發接受(或認為是理所當然的)不明確的需求，尤其是專案剛開始的時候，需求不明確是沒有關係的，所以，這時候的需求內容是相對的較大較不清楚的，有些人會把很大的故事稱為史詩(Epic)，這樣的需求被排進Sprint(通常是2~4週)時，細節也必須被確定，或者被拆解為更小的故事(Story)(詳參: Story Splitting Cheat Sheet)。
- 在每個Sprint開始之前，會先決定這個Sprint要完成的項目 (Sprint Backlog Item)，每個項目大概花兩到三天的時間完成，完成之後，所有完成的部分都是可交付的程式，而且都是隨時可一起上線(使用)的。
- 傳統做法
- Define activities
- Sequence activities
- Estimate activity resources
- Estimate activity durations
- Develop schedule
- 敏捷
- 專案風險管理
- 專題常見的風險類別及風險有:
- 時程
- 不實際的時程規劃 (對於什麼時候該完成多少功能完全不清楚)
- 規劃時忽略了重要的工作 (沒有認真的討論WBS，以至於很多工作並沒有被規劃進去，太多事沒有規劃在時程中)
- 一個重要工作落後，導致後續的相依工作延宕 (如:需要使用的程式語言一直沒確定，無法開始開發)
- 部份重要的系統功能，花了比預期還要多的時間去設計與開發
- 需求
- 需求並沒有排優先順序 (花太多精神在不重要的功能上，導致重要的功能無法完成，或沒有足夠時間完成)
- 專案開始時，只知道部份的需求或需求不斷更改 (老師或產學合作的公司不清楚需求或一直不斷的更改需求)
- 需求並未清楚定義 (老師或產學合作的公司跟專題團隊對需求的認知不一致)
- 不實際的需求 (老師或產學合作的公司對開發團隊的能力認知錯誤，需求遠大於開發團隊在特定期限前可以完成)
- 客戶
- 客戶的決策時間過長 (老師或產學合作的公司決策時間過長，需求的確認或最終產品的確認花太長的時間)
- 客戶對時程有不合理的期待 (產學合作的公司忘了學生還要上課，有期中考、期末考或者老師或產學合作的公司不清楚學生的產能)
- 人力
- 重要的開發工作依賴特定的同仁 (只要特定的同學出了狀況，沒有人可以接手或幫忙)
- 花太多時間學習新的軟體工具、硬體、程式語言
- 團隊發生嚴重衝突導致溝通不良、設計不當、無法整合或花時間沒必要的工作上
- 列出你們的風險並思考如何風險管理
- 對你們的組，哪些是很可能會發生的風險? 影響程度是? 如何因應 (降低發生機率、減少影響程度、備案)?
- 利害關係人管理計畫
- 專案關係人分析 (詳參: Stakeholder analysis)
- 就專題而言，一般會包括指導老師、產學合作的對象(窗口、主管)、評審老師
- 影響力(power)、相關性(Interest)
- 涉入程度
- 溝通管理
- 針對不同的利害關係人的影響力、相關性、涉入程度應該有不同的溝通策略
- 問題管理
- 在溝通過程中所發現的問題，必須記錄並決定處理的方式
- 專案溝通管理計畫
- 需要溝通的內容(要求)、溝通的頻率
- 溝通的技術
- 資訊發佈
- 績效報告
- 結案
- 根據專題的評分項目，進行品質管理 (如何達成這些目標?)
- 文件初稿
- 文件內容的系統描述是否流暢，是否使人容易了解；需求規格與設計規格是否正確、是否與系統功能一致。
- 文件內容應包含系上所訂文件格式第一至四章中的項目
- 系統功能
- 是否具有
- 創新性：系統在功能及技術方面是否具有創意
- 實用性：市場、使用者是否接受
- 技術性：技術的難易程度
- 親和性：人機介面之親和性及互動性
- 豐富性：資料內容的正確性、充實程度
- 系統功能是否與文件所述相符
- 系統發表
- 展示
- 口齒清晰、條理分明、言之有物，充分活用簡報工具。
- 神情舉止是否自然、態度是否端莊、服裝則整潔即可。
- 簡報畫面是否生動,展示過程是否順暢,是否能使聽者了解系統之功能、特色、成就與貢獻。
- 英文發表是否流利。
- 應對
- 注意聆聽問題，充分把握題意，回答簡明扼要，態度從容，能表現出對該系統的專業知識，且有技巧的回答問題。
- 時間控制
- 系統功能