從科技業專案管理看企業執行：跨部門合作為什麼經常卡關？

大家都有進度，為什麼專案還是卡住？

行銷說內容已完成，業務說還不能用；系統功能已交付，營運卻仍用試算表補資料。這些情況值得先追問：各部門口中的「完成」，是否指向同一件事？

如果內容完成只代表文字寫好，卻沒有產品確認、版面定稿與上線安排，進度表上的完成就無法換成實際成果。主管此時若只要求加快速度，反而可能讓未釐清的工作更快流向下一個部門。

先分清楚：卡在資訊、資源，還是決策？

三種問題，需要不同的處理方式。規格不清楚，要補足資料與驗收條件；工作量超過人力，要重新安排優先順序；部門各有立場，則需要有權衡取捨的人做決定。

如果把資源不足當成溝通不良，就可能只增加會議。如果把權責未定當成進度落後，就容易不斷追問執行者，卻沒有解決真正的阻礙。

把協作拆成四個明確約定

我會先確認共同成果，再整理交付條件、決策權與相依順序。這四項約定，決定團隊能否把各自的工作接起來。

• 共同成果：把「完成網站」改寫為「客戶能查到正確服務資訊，並完成有效詢問」。
• 交付條件：每個任務列出接手者、必備資料與驗收方式，避免完成後再補問。
• 決策責任：有人整合意見，也有人能在取捨時拍板；主責與協助角色分開列明。
• 相依順序：先找到會阻擋後續工作的決定，讓資源優先處理這些關卡。

專案經理的價值，在於把分散的資訊整理成團隊可以採取行動的決定，並追蹤決定後的交付。

情境示例：官網上線前，需求一直改

假設企業準備上線官網，業務希望加入完整產品規格，品牌團隊重視版面簡潔，工程端則等待內容定稿。若每次會議都只交換偏好，網站很容易反覆修改。

可以先約定首波目標是「讓潛在客戶理解服務並留下需求」，必要規格放在服務內頁，首頁保留決策所需的關鍵資訊。由指定負責人確認首波範圍，新增需求記錄用途、影響與優先順序，再決定納入本次或下一次更新。

這個安排能讓團隊檢查每一項修改是否支援共同目標，也讓延後的需求保有明確去向。

下一場會議就整理這張表

進度追蹤時，我會把重點放在待決問題、受阻工作與驗收結果。若同一件事持續被重做，就回頭確認交付定義；若工作長期停在等待，就檢查決策責任與資源安排。

管理方法是否有效，最後要看團隊能否更早發現阻礙，並把工作完整交到下一位手上。

從下一場會議開始，改變追蹤的方式。

會前先請各項主責列出「已可驗收、等待決定、需要協助」三類狀況。會議把時間用在阻礙後續工作的問題上，並為每個決定記下負責人、影響範圍與確認期限。

若新增需求會影響交付，就連同時間與資源的代價一起討論。讓取捨可被理解，比口頭要求所有事情同步完成，更能支援團隊執行。