| 核心主題 | 主要觀點/概念 | 實務或理論意義 | 重要條件/限制/延伸 |
|---|---|---|---|
| Why Tailor | 每個project在product、uncertainty、team、culture、governance與environment上不同 | 避免把同一method或process detail機械套用到所有專案 | Tailoring需維持必要controls與organizational requirements |
| What to Tailor | Life cycle/development approach、processes、engagement與其他practices | 把框架轉成符合project context的working system | 需考慮regulation、contracts、standards與organization policies |
| Select Initial Approach | 先依deliverables、uncertainty與organization選predictive、adaptive或hybrid | 建立第一版delivery與planning邏輯 | 初始選擇不是永久不變 |
| Tailor for Organization | 對齊governance、policies、PMO、culture、methods與enterprise systems | 確保project practices能與組織正常運作 | 過度標準化也可能降低project responsiveness |
| Tailor for Project | 再依product/deliverable、project team、culture與specific conditions微調 | 把管理成本放在最能降低risk/提高value的地方 | 需讓stakeholders理解被調整後的working agreements |
| Ongoing Improvement | 以retrospectives、reviews、metrics與lessons learned持續改善 | 讓方法隨新資訊與execution feedback演進 | Tailoring本身也是iterative activity |
原書把Tailoring視為專案管理的核心能力,因為project characteristics不可能完全一致。相同流程在高度regulated construction、small software initiative或uncertain innovation project中的必要detail、cadence與control strength都可能不同。
主要包括 life cycle and development approach selection、processes、engagement,以及Performance Domains中各種methods、artifacts與working practices。裁適的目標不是減少文件本身,而是讓管理mechanisms與project value、risk與complexity相符。
任何裁適仍需滿足law、regulation、contract、organizational policy與必要quality/risk controls。若某process被精簡或替換,團隊仍需確認其原本要解決的管理目的是否由其他mechanism實現。
每個Performance Domain都提供tailoring considerations與examples。這表示Scope、Schedule、Finance、Stakeholders、Resources、Risk與Governance可以採不同程度的formalization,但它們之間的interactions仍需維持一致。