專案交付
專案是一個有明確邊界、有結束點的工作單元。協調多個專案以達成共同成果，屬於
pmo:program-management（專案組合管理：專案群管理）。
以排除條款界定範圍
納入條款容易達成共識，但各自理解卻可能不同。真正發揮作用的是排除條款：明確寫下並經發起人確認的、此專案不會交付的內容。
未書面記錄的排除項目，最終會以假設的形式重新浮現，而且總是在最晚的時候出現，並被包裝成「明顯該包含」的東西。事後再來修正這種情況，就叫做範疇蔓延；這通常起始於文件記錄的缺失。
以區間估算，並說明區間的意義
單點估算是一種偽裝成承諾的預測。應給出一個區間，並附上會導致變動的假設，同時明確說明信心水準。
要估算的是工作量，而非期望的完成日期。向下妥協的估算並不會改變工作量；它改變的是你發現問題的時間點，而這個發現時刻往往發生在最難補救的時機。
將工作拆解到可理解的粒度為止。對一個龐大的未知數進行估算，所得數字與其說是反映工作量，不如說是反映樂觀程度。
關鍵路徑才是關注所在
並非所有延遲都同等重要。關鍵路徑上的延遲會推遲結束日期；非關鍵路徑上的延遲則消耗浮時。能夠區分這兩者，就是有用關切與泛濫焦慮之間的差別。
隨著情況變化重新計算關鍵路徑——關鍵路徑會移動，而一個只盯著原始關鍵路徑的團隊，是在關注錯誤的對象。
將緩衝保留在專案層級，而不是在每個任務中都加入緩衝時間。加了緩衝的任務只會消耗自身的緩衝，並不會提早交付，因為工作會膨脹，而且沒有人會報告自己提前完成。
追蹤完成狀態，而非投入進度
完成百分比是自行申報的樂觀數據，而且眾所周知，它會卡在 90% 這個瓶頸。應追蹤已定義交付項目的二元完成狀態——已完成或未完成，並以事先約定的定義作為判斷標準。
觀察趨勢：剩餘工作量是否以所需的速度在減少。一個剩餘工作沒有減少的專案，就是一個落後的專案，無論其報告的百分比是多少。
復原
先診斷，因為不同的補救措施並不重疊：範圍比認知的大、產能比規劃的低、依賴項目未交付、或估算從一開始就不現實。
然後提出選項並說明後果——縮減範圍並具體指明要刪減什麼、延長時程並說明延長多久、或增加產能（但在專案後期增加人手通常只會讓事情更慢）。進行一次且公開透明的重新基準化。連續的一週延遲對公信力的摧毀速度，遠超過一次誠實的重新設定。
變更控制是讓範圍聲明具有意義的關鍵
一個可以在對話中被任意移動的範圍邊界，就不是邊界。變更控制就是將這個邊界固定下來的機制，而且它必須足夠輕量，讓人們願意使用它，而不是想方設法繞過它。
- 變更是指任何會影響範圍、日期或成本的事——包括那些被描述為「釐清事項」的工作。大多數的範疇蔓延，是以一連串看似合理的小請求的形式進入的，而其中任何一個都從未被放在整體中評估過。
- 在決定之前，評估對這三項的影響。「可以，但會增加兩週」是一個別人可以據以做出決策的說法。單純的「可以」則是一個在計畫中悄然讓目標變得無法達成的說法。
- 能夠核准變更的人，是能夠承擔後果的人。 如果發起人核准了範圍變更，但讓團隊吸收日期延遲的影響，那麼變更就會一直被核准。
- 也要記錄被拒絕的變更。 哪些請求曾被拒絕的記錄，可以阻止同樣的請求再次出現三次，並且當有人問為什麼某個功能缺失時，這份記錄就是最誠實的答案。
當一個已核准的變更讓舊計畫失去意義時，就進行重新基準化，否則不要輕易為之。為了掩蓋變異而重新設定基準線，只會毀掉你手上唯一的參考依據。
工具
交付追蹤工具：Jira、Asana、Linear、Monday.com、Smartsheet、Microsoft Project 以及類似工具。
組合與產能規劃工具：Jira Align、Planview、Adaptive Work 以及類似工具。在需要協調多個團隊的計畫以對齊同一個產能池時，才值得引入這些工具，在此之前則不必。
工具記錄的是計畫，但它並不能讓計畫成真。一個在會議之間無人更新的狀態欄位，比完全沒有這個欄位更糟。
決不
- 在沒有書面排除條款的情況下同意範圍。
- 將單點估算作為承諾提出。
- 以完成百分比回報進度。
- 在專案落後時增加人員，並期望它能加速進度。