作者：Loren Gary

過去的專案管理是「驅趕不確定性」——一開始就把所有交付物與規格鎖死，讓執行盡可能例行化。但今天的複雜專案——新產品開發、IT 導入、流程改造——不確定性已無從消除。

模糊前端為何重要#

對於上市時間（time-to-market）至關重要的產業，傑出專案經理的研究顯示：複雜專案的初期階段（亦即模糊前端，fuzzy front end）對最終成果有不成比例的影響。

David Schmaltz（華盛頓州的專案管理顧問）舉例：替鞋廠改造製造線時，

• 真正花在「建造新產線」的工時可能只有 10%
• 高達 50% 的工作要處理的是「下一季哪一款鞋會熱賣」的不確定性

結論：與其拚命縮短「建造新產線」的時間，不如建造容易適應款式變化的產線。把問題框得更廣，方案空間會變大。

先定義問題，不要急著動工#

Bob Gill（Product Development and Management Association 主席）的建議：

「先定義問題，可以讓你在解問題時擁有更大的自由度。」

例：

• 錯誤的框架：「鉚釘設備跑得太慢」→ 解法只剩買更快的設備
• 退一步問：「真正的問題是這個產品的製造成本太高」→ 解法可包含重新設計流程，讓產品需要的鉚釘變少

早早建立你的社群#

要對工作的本質與範疇形成穩固理解，必須先收集關鍵利害關係人的意見。Peter Koen（Stevens Institute of Technology 教授）建議：

• 找出可能受專案影響的各個族群
• 邀他們一起探索機會、提出未被滿足的需求與所創價值

Antara 公司執行長 Chuck Kolstad 的觀察：「只在初期提供資訊的利害關係人，到後期可能會握有決策權。」一開始就讓他們感覺意見被重視，後續要他們的 buy-in 會輕鬆許多。

招募技巧：

• 把專案的願景與你需要協助的同事分享
• 問對方：這個專案對你有什麼好處？
• 幫他「在你的專案裡找到他的專案」

Schmaltz 的觀察：通常一個複雜專案不到一年。初期一兩週只是「跟人聊天」看似無用，實則建立的是一張關係網路。當計畫滑落、需求增加時，這張網會變成一個「願意一起想辦法把專案做成的善意共謀」。

從終點逆推（Work Backward）#

研究指出，決策者會過度受到「最初框架」的影響（認知偏誤）。Jim Goughenhour（Sealy 資訊長）的建議：

• 定義完問題後，先別急著研究現有流程或產品
• 先想像理想的終局狀態長什麼樣
• 再依時間、預算、組織政治反推，盡可能接近理想

他舉例：要做一個「全公司一致的銷售報表系統」，傳統作法是逐一檢視所有現有報表並設法整合：

「如果我們那樣做，會把大部分預算花在小幅度改善上，最終離理想差很遠。」

當理性的聲音#

模糊前端的尾聲，你會對外輸出一份通用計畫，為專案社群與整個公司設下期望。但更難的，是管理發起人的期望——那位高你三、四級、堅持「四週內做完」的專案擁護者。

記得 Schmaltz 所謂「神聖的失望責任（sacred responsibility to disappoint）」：模糊前端對話接近尾聲時你心裡那股不安——這專案會花更多時間、花更多錢——只有在一開始就讓擁護者失望，最後才有機會讓他驚喜。否則你會淪為他不切實際期望的奴隸，幾乎注定失敗。

Loren Gary 曾任《Harvard Management Update》主編。 改寫自：Harvard Management Update（product #U0306C），June 2003