你的專案是不是涉及陌生技術或材料？是不是規模遠大於你過去帶過的？任務是不是團隊以前沒處理過的？
何時傳統工具會失效#
若上述問題任一答案是 yes，傳統專案管理可能失靈。
傳統法假設你能精準訂出該做什麼、要花多少、需要多久。 在不確定性高、潛在結果範圍極廣、可能出現意外風險的情境下，ROI、NPV、IRR 等決策工具的前提（可預測的未來現金流）不再成立。
此時要採用**適應式（adaptive）**做法。
適應式模式的四個特徵#
Lynda Applegate、Robert Austin、Warren McFarlan 在大型 IT 導入研究中發現，Cisco 等公司用以下做法獲得成功：
- 以迭代方式接近任務（iterative）：團隊執行小幅增量任務、評估結果、再前進時做出調整
- 快速循環（fast cycles）：短的提前期才能支撐迭代
- 強調早期價值交付（early value delivery）：小而早的交付物會帶來反饋，並讓學習融入後續活動
- 配置「能適應」的人：有些人學得快、對改變的接受度高，這種人是首選
Cisco 把這套做法稱為「rapid iterative prototyping」。許多任務本身就是探針（probe）——是後續步驟的學習經驗。
這類似 R&D 機構慣用的「cheap kills」概念：用低成本的小實驗快速分辨可行與不可行的選項。即使是失敗的實驗，也能提供「什麼會行得通」的洞察。
對發起人角色的重新定義#
Robert Austin 在 2002 年《Science》文章〈Project Management and Discovery〉中，將適應式管理下的發起人比作創投家（venture capitalist）：
- 不在一開始把所有資源一次給足
- 而是分階段支援，根據結果是否進來決定是否續投
- 每筆投資都是在購買資訊、降低不確定性——並保留「繼續玩下去的權利」
兩種補充技巧：What-If Planning 與 Chunking#
Cathleen Benko 與 F. Warren McFarlan 在《Connecting the Dots: Aligning Projects with Objectives in Unpredictable Times》中介紹兩種強化適應力的技巧：
What-If Planning（情境規劃）#
瑞典軟體公司 Ellipsus Systems 要決定其軟體採用哪種程式設計標準——WAP（Wireless Application Protocol）還是 Java。共同創辦人 Rikard Kjellberg 同時設計兩個版本的專案，把早期原型帶到展會，測試與會者偏好。這種偶發規劃最終促成與 Java 製造商 Sun Microsystems 的成功合作。
Chunking（分塊）#
明尼蘇達州的 Carlson Hospitality Worldwide 用 chunking 把昂貴大專案拆成可批准、可獨立運作的小塊。
董事會曾否決一筆 1500 萬美元的中央訂房系統升級。經理們把專案拆成各自具獨立效益、彼此相依性最低的小塊——若其中一塊被取消，其他塊仍能繼續。
董事會很快批准了第一塊。最終新系統獲得業界最佳評選；其中僅語音訂房一塊在 2003 年就帶來 4000 萬美元年營收。
CIO Scott Heintzeman：「Chunking 讓我們持續學習、持續重新評估優先順序，降低風險、聚焦每個工作單位；而且因為每塊只持續三到六個月，人員的能量與熱情得以維持。」
在水平與垂直之間取得平衡#
適應式並不意味著要消滅所有水平活動。水平活動帶來成本效益和規模經濟。
關鍵是平衡：把垂直、快結果與水平、規模經濟混合進整體執行策略，並讓洞察在團隊間流動。
改寫自：「Close the Gap Between Projects and Strategy」，Harvard Management Update（product #U0406A），June 2004；以及「Project Adaptation: Dealing with What You Cannot Anticipate」，Harvard Business Essentials: Managing Projects Large and Small（product #6273BC），Harvard Business Review Press, 2004