案例背景

Renegade 是美國東南部的健康保險業者，五年間投保人數由約20萬增加到超過100萬，原有 Microsoft Access 資料庫已難以支撐快速成長，因此管理階層決定升級至 Oracle。專案目標是建立 Oracle 資料庫與既有系統的正確連線，並安全把資料從 Microsoft Access 移轉到 Oracle；預算約 20萬美元，工期 10週。

藥務部門負責專案與成本，指定 Robert Adam 為專案經理、Leila Rakoba 為商業分析師。

問題／衝突

Renegade 所有軟體開發採瀑布式方法（waterfall methodology）：專案必須依序完成每個階段，通過最終審查（Final Walkthrough, FWT）與正式簽核後才能進入下一階段，不允許同時開發。這能提高紀律、文件完整度與設計審查品質，但遇到規格衝突或後期才發現錯誤時，問題會阻塞整個專案並直接衝擊時程。

決策點／實施

啟動階段中，Robert 負責資源需求文件、專案計畫、開發矩陣與資源規畫；Leila 負責蒐集並記錄使用者需求。

第一次 FWT 順利通過後進入規畫階段，但系統分析師 Luke 與其他技術角色對實施規格發生衝突。多次討論仍無法解決後，Robert 向計畫經理 Steven 升級處理；Steven 直接寄信給 Luke 並副本給其主管，Luke 才讓步，專案通過下一次 FWT 並進入實施。

到測試階段，測試分析師 Sam 發現開發階段存在錯誤實作。Robert 再次跨越直線主管體系升級處理，最後開發人員 Jason 回來修正，約 5小時完成；專案得以繼續，但已落後原時程。

原書狀態／結果

案例結束時專案仍在進行，Robert 預期還要持續透過電話與電子郵件協調。原書沒有提供最終完成結果，而是聚焦瀑布式階段審查如何處理規格、簽核、升級處理，以及其對上市速度的限制。

原書討論問題

1. 瀑布式方法有哪些優點與缺點？
2. 你會如何修改瀑布式模型，使它更能回應上市速度壓力？
3. 你同意 Robert 處理問題的方式嗎？為什麼？

原書本 A 檔未提供正式解答。

參考分析（教學延伸／依本章內容推論）

瀑布式方法的強項是階段離開條件與文件清楚；弱點則是後期才發現前一階段缺陷時，重工與等待容易集中爆發。案例也顯示，正式流程之外，專案經理仍必須處理功能部門權限與升級協調。