專案管理 是做什麼的？
專案失敗於團隊之間的接縫處，而非團隊內部。工作就在這些接縫處。
設定
- 一個以業務結果陳述的成果，並附上日期。擁有多個同等目標的專案等於沒有目標。
- 一位指定的問責所有者——一個人，而非委員會。專案經理推動；所有者做決定。
- 以包含項目與排除項目書寫的範疇。排除項目負責劃清界線；未書寫的排除項目會以假設形式反饋回來。
- 由相關團隊繪製並同意的相依性，附上他們實際承諾的日期。你計畫中擁有者團隊尚未同意的相依性只是一個願望。
排序
按相依性與風險排序，而非團隊方便性。提前處理那些可能讓計畫無法實行的事項——技術未知、供應商決策、可能不會到來的批准。在第四個月發現計畫不可行是典型的專案失敗。
在整合點預留緩衝，而非專案終點。放在終點的緩衝會過早且無聲地被消耗掉。
值得一讀的狀態
每次三件事：我們是否按時程進行、自上次以來有什麼變化、以及需要什麼決策或排除障礙。其他一切皆屬附錄。
根據承諾日期追蹤狀態，而非努力程度。「80% 完成」不是資訊；「整合已完成，遷移週一開始，簽核是風險所在」才是。
及早且具體地升級問題。明確指出所需決策及其截止日期的升級能獲得解決；一般性的擔憂陳述只會被承認，然後什麼也不會發生。
當進度延遲時
確定是範疇問題、產能問題還是相依性問題——補救方法完全不同，套用錯誤的方法只會讓情況更糟。
然後提出附帶後果的選項：縮減範疇（具體說明要削減什麼）、延長時程（說明延長多少及影響了什麼）、或增加產能（這在後期很少有用，且常常適得其反）。
重新設定基線一次，且要明確，而不是一週一週地延遲。連續的小延遲對信譽的損害遠比一次誠實的重置來得快。
絕不
- 在專案存在未解決的障礙時回報為綠燈。
- 接受擁有者團隊尚未確認的相依性日期。
- 在進度落後的專案上增加人力並假設能加速進度。