案例背景

Silicon Forest State University 的資訊科技辦公室（OIT）橫跨網路、資訊系統、教學與研究服務、使用者支援等多個部門。原有錯誤回報與服務請求工具並不一致：前端團隊使用 Windows 架構的 Remedy，後端 UNIX 團隊則使用開源的 Request Tracker（RT）。

兩套系統無法直接銜接，必須人工轉換訊息，造成時間與人力浪費、回應速度慢，也可能因轉譯而遺失或誤解資訊。這個問題持續約三年。

問題／衝突

OIT 同時面臨嚴格預算削減，而 Remedy 每年授權費約 20,000美元。團隊必須找出能降低成本、整合前後端流程、又不增加過多學習成本的解決方案。

此外，專案是跨部門進行：Ron Bashley 負責使用者介面，Harry 與 UNIX 團隊隸屬其他主管，成員之間沒有直接的階層命令關係。Ron 原本擔心其他部門會優先處理自身例行工作，而不願投入此專案。

決策點／實施

跨部門委員會先蒐集需求與替代方案，約三個月後決定全面改用 Request Tracker（RT）。理由包括：它已由部分部門使用、開源、無須支付高額授權費，而且主要改變集中在原先使用 Remedy 的部門。

移轉階段由 Ron 擔任團隊領導者，與 Harry 及一名程式設計人員組成小型執行團隊。原委員會不再持續開會，實際執行改以每週會議、電子郵件與 RT 工單協調。工作分派高度非正式，常由有能力且有空的人主動承接。

原書狀態／結果

專案進行順利，沒有重大問題。由於所有人都長期受舊系統困擾，因此跨部門合作阻力並未如 Ron 原先擔心的那麼大。系統移轉在當年 11月完成，比原定六個月時程提前一個月。

OIT 後續全面使用 RT；雖然團隊承認它並不完美，但因為開源、易於客製，整體滿意度明顯高於原本的 Remedy。

原書討論問題

1. 根據案例資訊，為 Ron 的專案建立工作分解結構（WBS）。
2. 辨識本專案的風險，並提出因應計畫。
3. 本專案的關鍵成功因素有哪些？
4. 提出一套適合此類專案的專案管理方法。

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

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

本案顯示，小型內部資訊科技專案未必需要高度正式化的方法；但成功仍依賴需求共識、共同痛點、適合的工具與跨部門信任。非正式管理之所以有效，是因為問題高度共享、技術方案已有使用經驗，而且團隊關係成熟。