把範圍和分工寫在同一份資料裡。
開始前確認誰擁有帳號、誰提供資料、誰批准權限、誰負責驗收。目標環境、交付物、前置依賴和商務條件需要相互對應。模型、地區、系統介面或專案範圍改變時，應說明對計畫的影響，並由相關負責人確認。
選擇專案目前需要的服務。
評估、架構、實施和持續維運解決不同階段的問題。從現有環境和目前決策開始，依這一階段產生的資料確定下一步。
討論服務範圍選擇目前需要做出的決定
先看眼前要解決什麼。
剛形成的想法，可以先討論可行方向；已有原型的專案，可能需要架構審查、系統整合或運作職責梳理。溝通時說明業務任務、現有系統、帳號安排和使用團隊，讓服務範圍對應實際情況。現有的有效設定、原型和文件也可作為輸入，先確認適用性與缺口。
讓「完成」有可檢查的依據。
依階段約定樣例和審查材料，可以是路線圖、架構圖、設定紀錄、測試結果或操作手冊。成功結果之外，也記錄未完成事項、適用假設、負責人和下一步行動。客戶據此決定接受交付、補充驗證，或調整後續工作範圍。
提前安排交接和後續支援。
實施與日常運作分別確認責任。交付後由誰保管存取權限、監測用量、核准變更和處理供應商問題，需要有明確安排。服務時段、回應方式、檢討頻率及新增工作在專案協議中確定。首次溝通以簡要系統說明和估算用量即可選擇服務階段。
從專案現況開始討論。
說明已經可用的部分、準備改變的部分，以及團隊目前需要作出的決定。