專案起始
您可以在名為「專案起始」的初始階段中，安排專案的基本資源。
本主題內容
計劃會議
反覆開發
這是範圍驅動或日期驅動的專案？
規劃專案資源
定義角色與責任
定義通訊計劃
識別專案關係人
簡述專案計劃
檢閱專案計劃
取得專案認可
計劃會議
在專案的初期階段，數位專案關係人和主題專家應開會討論專案並且進行產品規劃。 您應該根據專案的性質與複雜度與其產品交付項目，選擇專案關係人。
根據專案大小與其複雜度，會議可能需要數天或數週的時間。
反覆開發
在風險管理方面有項重要技術就是以反覆項目規劃您的專案，通常需要四到六週的時間。 反覆項目計劃就是專案小組將要開發與測試的功能清單。 每一項功能都會指定使用者將可利用產品執行的工作或是經過改善的工作變體。 在每個反覆項目結束時，便會示範所規劃的功能。 在某些反覆項目結束時，會發行部分完成的產品以供有限的使用者試用。
來自這類示範和試用的意見會用於檢討計劃。
安排產品計劃，以便在早期階段執行主要使用者情節和主體系統元件，即使只是以簡化的方式而已。
大多數專案的最大風險之一就是需求遭到誤解。 不僅開發小組會誤解需求，而使用者和專案關係人也會誤解需求。 他們發現很難想像安裝新系統將會對其業務活動造成的影響。
此外，在專案的存留期間內業務環境可能會改變，進而導致產品需求改變。
反覆流程可以保證在專案結束前便可適應經由示範產品所發現的任何需求調整，而且不會造成實質的重新作業成本。
另一個重大風險就是開發成本的評估不佳。 在新領域 (或許是新平台) 作業的開發人員很難在專案之前精確評估開發成本。 在某些情況下，很難判斷某種實作策略未來的表現是否夠完善。 但是在每一次反覆項目結束時檢討計劃，小組便可考量先前反覆項目的經驗。 這就是為何良好的產品計劃會在早期階段於每一個主體元件上排程部分工作的原因之一。
這是範圍驅動或日期驅動的專案？
有些專案會要求所有需求在交付之前都必須可運作。 這類專案在軟體環境中很少見。 建造橋樑則是真實世界的範例之一。 完成一半的跨距 (長度) 毫無用處。 從另一方面來說，完成一半但規劃適當的軟體專案應可供有限的使用者部署和使用。 這種軟體專案可以透過數次升級的過程，逐次地完成。
首先，判斷專案是否真的是範圍驅動的專案。 如果是的話，您必須等到有詳細的評估和計劃時才能決定結束日期。 您需為此付出代價。 計劃額外的負荷會增加，同時因為偶發性的評估不善而造成的排程緩衝會使交付日期更加延後，進而增加成本。 因此，請非常確定，然後才決定您具備的是範圍驅動的專案。 相較於在單純的軟體產品或服務情況下，範圍驅動的專案比較可能出現在複雜的系統設計環境中。
因為大部分的軟體專案可以累加方式交付，所以是日期驅動的專案。 例如，如果電腦遊戲即將針對美國的節日推出，則必須在十月以前備妥。 若無法在十月份交付，將會嚴重影響到萬聖節與耶誕節間的銷售，而且如果排程落後兩個月，有可能會完全錯過銷售良機。
規劃專案資源
專案應由專人負責，才能在所需的日期前交付。 先前專案的歷程資料應用於告知資源充足的討論。
在了解您的人員需求之後，請建立專案組織圖，清楚指出專案小組結構、資源層級和地理分佈 (如果適用的話)。 將所有的人員配置資訊儲存到專案入口網站。
定義角色與責任
說明每一個專案角色與責任，並且公佈在專案計劃中。 參與專案的每一個人員都應該了解其在專案中的角色與責任。
定義通訊計劃
定義專案的通訊計劃相當重要。 通訊路徑有助於管理專案的協調成本。 此外，還必須定義應該參加會議的人員、舉行會議的頻率、通訊路徑，以及如何提升任何一個會議的一般與會者所無法解決的問題。
良好通訊計劃的目標在於確保盡可能順利執行專案的協調活動，以及避免溝通不良而浪費精力。
通訊計劃應公佈於專案入口網站上，並且視需要予以維護。 對所有人員 (尤其是新成員) 而言，通訊計劃是一項很實用的工具。 它有助於了解大型小組的作業方式，以及如何透過不同的方式、與不同的小組成員以針對不同的目的適當地進行通訊，進而完成工作。
識別專案關係人
識別所有相關的專案關係人。 除了核心小組成員以外，這份清單應包含業務人員和技術人員，這些人員會很關心專案的成功實作或產品在提供服務後的可能影響。 這些專案關係人可能是軟體工程活動的上游或下游。
簡述專案計劃
建立第一個專案計劃的起草版本，可以在開始開發時予以修訂。 這個版本的目的在於協助與專案贊助者討論資源和期限。 而且應該簡述主要功能與其估計的交付日期。 如需詳細資訊，請參閱規劃專案 (CMMI)。
檢閱專案計劃
在專案入口網站上發行專案計劃大綱。 雖然許多工作已進入計劃中，但這仍是會延緩許多詳細排程決策的高層級計劃。 這是故意的。 現在太過詳細將會導致之後的浪費。
如果不確定需求，請只計劃其大綱，而詳細資料應該延到有更多資訊可供參考時。 請進行規劃以取得所需資訊。
安排與所有專案關係人的檢討會議。 面對面會議最適合這種活動。 請務必安排足夠的時間，以便進行完整的檢討並且讓反對意見得以被聽見。
取得專案認可
既然專案關係人已一致同意專案計劃，請取得每一位專案關係人的認可以便核准專案計劃。
收集認可，並在專案入口網站中封存詳細資料。
其他資源
如需詳細資訊，請參閱下列 Web 資源：
功能驅動型開發實務手冊 (英文)，Stephen R. Palmer 和 John Malcolm Felsing；Prentice Hall PTR (2002)。
IT 度量概論：使用功能性大小度量來估計和檢測成就 (英文)，Manfred Bundschuh 和 Carol Dekkers；Springer，2008 年。