第 13 章異常專案管理　

第13章異常專案管理　

本章大綱 • 13.1　何謂異常專案？ • 13.2　異常專案的管理　 • 13.3　異常專案的評估　 • 13.4　專案的救援計畫　 • 13.5　救援計畫的實施 • 13.6 專案的健康管理 • 13.7 結語　

學習目標 • 瞭解專案即將失敗的警訊 • 知道如何管理異常的專案 • 瞭解異常專案的救援策略 • 瞭解異常專案的救援計畫與管理 • 瞭解專案的健康管理

何謂異常專案？(1/5) • 所謂異常專案，基本上是指「專案偏離了常態」。至於何謂偏離，其意義取決於個別的情況。專案是否出現問題，通常是主觀的認定，屬於政治性的判斷。 • 初步判斷專案出現異常的指標如下： • 當專案的主要關係人（如顧客、專案贊助人等）已失去對專案的耐性，或者超過了忍受的極限。 • 專案的誤差趨勢超過了可容忍的範圍，例如，專案的時程或成本超過了預定的30%，此時我們可說專案已出了狀況，正朝向失敗的道路前進。 • 專案的產出趕不上問題出現的速度，專案成員不斷地加班工作，對於時程與專案進度的估算，開始不切實際。

何謂異常專案？(2/5) • 異常專案的初期徵兆 • 愈來愈多的專案會議，但是進度卻很慢。 • 專案早期就吃掉了時程上預留的緩衝時間。 • 關鍵要徑上的工作項目開始無法結案。 • 時程與成本上的壓力開始浮現。 • 專案成員開始加班。 • 開發者與用戶之間的關係開始惡化。 • 關鍵成員間出現不安的情緒。 • 對於關鍵需求很難下決定。 • 專案或許落在誤差容忍範圍內，但以犧牲品質作為代價。 • 顧客對專案的成功失去興趣。 • 顧客與專案團隊之間的關係出現問題，例如，兩者之間開始出現敵意，或甚至故意的破壞（或抵制）。

何謂異常專案？(3/5) • 異常專案常見的原因 • 挑選了不合適的專案。 • 專案初期未將應規劃的事情做好，發生了常見的專案疏失。 • 專案缺乏有效的領導。 • 專案的資源投入不足，或者人數足夠，但能力不足。 • 需求／功能的問題。 • 用戶與開發者之間的溝通問題。 • 不當的品管與測試。

何謂異常專案？(4/5) • 異常專案的結果 • 專案的里程碑一再地延誤。 • 專案失去控制，無法知道真正的專案進展，無人知道專案何時可以完成，且大部分人也放棄估計完成的時間。 • 專案超出預算，成本估算不斷變更。 • 基於壓力專案成員每週工作超過60小時。 • 產品充滿瑕疵。 • 團隊對於專案的進度充滿防衛心。 • 顧客對該工作團隊與計畫失去信心。 • 溝通出現問題、團隊處於無法化解的衝突中。

何謂異常專案？(5/5) • 專案開發者、市場人員、管理者、驗收人員和顧客間的關係緊張。 • 團隊士氣跌到谷底，人員態度厭倦。 • 到處都是90%完成症候群。 • 顧客威脅採取法律行動。

異常專案的管理(1/4) • 一般而言，通常導致專案失敗的問題都不是突然才造成的，而是早已存在一段時間。若能採取異常專案的管理，問題或許可提早被發現；至少在發生初期就採取有效的措施加以導正，如此專案還有機會被挽回。 • 異常專案的管理層次 • 異常專案的管理可分成三個層級 • 沒有任何管理：直到專案瀕臨失敗。 • 被動式管理：當專案出現問題時，先進行評估與診斷，找出問題的根源，然後決定取消專案或進行救援。 • 主動式管理：將專案視為是個人的健康管理一樣，定期進行預防檢查。

異常專案的管理(2/4) • 異常專案的管理目標，由小到大分別是： • 回應異常專案所導致的失敗危機，將損害控制在可以接受的程度。 • 在異常專案威脅到軟體開發前，辨識、評估、介入、追蹤，將專案帶回常軌。 • 利用異常專案的管理資訊來改善組織與流程，以消除專案出現異常的原因。 • 建立異常專案管理的原則與實務，以達到上述目標。

異常專案的管理(3/4) • 異常專案的危機處理 • 異常專案的危機處理有兩項選擇：取消或救援專案。 • 取消專案的時機： • 該專案已經無法帶來商業價值。 • 政治環境已不支持該專案。 • 專案的主要贊助人已經離職，且沒有明顯的繼任者。 • 市場情況或商業需要已發生改變。 • 重要的科技改變已經發生。 • 法律訴訟已在進行。 • 合約糾紛已經出現。

異常專案的管理(4/4) • 異常專案的救援架構 • 專案救援可概略分成三個階段（如圖13.1），分別是： • 評估階段：此一階段的任務包含問題診斷、資產分析，以及專案團隊的現況評估。 • 計劃階段：主要是準備救援計畫，以及成立救援專案。 • 執行階段：介入管理，接掌一個失控專案的運行並取得控制權，於獲得初步成功後的淡出，讓專案回到正常軌道。其管理流程如圖13.2所示。

圖13.1 專案救援的基本架構

圖13.2 專案救援的管理流程

異常專案的評估(1/6) • 評估異常專案的目的，在於確認專案是否值得繼續存活，或者應被取消。 • 評估的重點主要是三方面 • 發現問題：其重點是要發現「問題背後的問題」，亦即進行問題的根源分析（root analysis），直到找出專案為何出錯，以及其中的原因。 • 找出專案現在的位置：包括重新確認專案的現況、對商業的重要性，以及進行資產分析（EVA），計算已完成與待完成的資產價值。 • 評估專案團隊的能力：確認團隊具備足夠的知識、經驗與專業來完成專案，以及評估團隊當時所處的發展階段落在團隊的哪個時期：起始、風暴、常態或效率化。

異常專案的評估(2/6) • 根源分析 • 根源分析是要找出「問題背後的問題」。在進行調查時，要問直接、關鍵、重要的問題，才能找出專案真正需要救援的理由與目的。 • 根源分析可從三個方向來發掘問題 • 人員 • 能力不足、無法合作或無法掌控的問題成員。 • 在已經延遲的專案中增加人員。 • 因為不切實際的期待或者其它原因，開發者和顧客間發生嚴重摩擦。 • 缺乏有效的專案領導。

異常專案的評估(3/6) • 缺乏專案關係人的投入。 • 用戶或顧客沒有能力定義自己的功能以及非功能的需求。 • 無法建立一個開放、強健與公平的買－賣方關係。 • 流程與管理 • 不切實際或過於野心的專案時程。 • 風險管理不足。 • 軟體的設計不當。 • 不良的專案規劃、管理與執行。 • 估算遺漏了重要的工作。 • 應用了尚未成熟的新科技。

異常專案的評估(4/6) • 產品 • 產品的範圍蔓延。 • 產品的定義不斷改變。 • 不切實際的期望或商業判斷。 • 缺乏變更管理與版本控制。 • 對於問題的評估 • 評估的目的除了確認專案的現狀之外，更進一步還要找出需要執行哪些改變，才能將專案恢復常態。因此，一些關鍵因素需要仔細地評估，這其中包括當初假設的商業價值是否依然有效、組織對專案的支援如何、問題的定義與範圍是否清楚、工作的分解結構（WBS）是否妥當等。

異常專案的評估(5/6) • 其次是專案的基本面。評估的範圍包括：專案風險、品質與瑕疵、專案資源及預算、專案時程，以及專案管理與控制流程（包括變更管理、團隊合作與領導）等。 • 在資訊蒐集的過程中，應注意以下事項： • 人力是否充足？技能是否勝任？ • 專案贊助人是否全力支持？或者只是表面功夫？ • 是否存在負面的團隊因素需要克服？ • 是否有內部的政治因素損害了專案？ • 團隊成員的判斷是否公正，會不會因為太過於投入而失去客觀性？

異常專案的評估(6/6) • 團隊成員是否理解專案經理的角色，以及專案開發所用的方法？ • 如果前專案經理還在的話，他是否會擔心自己的職位不保而有所保留？ • 準備評估報告，其內容應包括： • 專案的背景。 • 專案的商業價值再評估。 • 專案評估的範圍。 • 主要的發現。 • 建議事項。 • 需要立即採取的行動方案。

專案的救援計畫(1/5) • 專案救援是一項危機處理，需要方法與策略。在發展解決方案前，首先是量化問題發生的或然率以及衝擊大小。若問題已發生，則依照重要性排序，先「攻擊」其中最重要的。 • 解決方案必須能夠去除根源分析所找出的根本性問題，並說明如何能同時滿足專案的三項基本要件：成本、時程及產品（或品質）。因為異常專案之所以出現問題，通常就在於無法同時滿足這三項條件（例如，時程落後或預算超支）。

專案的救援計畫(2/5) • 專案救援的策略考量主要有三個方向： • 縮減產品性能 • 其目的是重新確認產品應具備的特性，避免浪費人力在不確定的需求上。 • 縮減產品性能包含有：降低產品功能到至少可接受的程度、穩定已有的產品功能、減少瑕疵的發生及重新檢視整個設計流程。 • 增加流程生產力 • 基本上，專案之所以需要救援，一個主要的特徵，就是專案的產出趕不上原訂的計畫或期望。

專案的救援計畫(3/5) • 拯救專案必須檢視並修正任何流程上的疏失。應注意以下問題： • 是否有軟體設計不足或設計不當的現象？ • 流程的控管是否不足以讓專案上軌道？ • 是否為了趕時程而犧牲品質？ • 是否真有一個確定的專案期限？ • 是否有責任空隙？是否有人對結果負起責任？ • 變更控制是否落實？是否有版本管理？

專案的救援計畫(4/5) • 提升團隊的效能 • 恢復士氣最好的辦法，就是採取一些具有象徵意義的行動。 • 若團隊裡有問題成員，此時務必除去，即使他是主要的貢獻者。這種人對士氣影響所造成的損失，會遠超過他在技術上的貢獻。 • 適當的團隊調整是必要的，應儘可能避免再用原班人馬去拯救一個將要失敗的專案。 • 打破專案的惡性循環：時間的急迫性導致壓力→壓力導致錯誤→錯誤導致更多的工作→更多工作導致更緊迫的時間壓力。

專案的救援計畫(5/5) • 救援方案的取捨 • 救援方案的恰當與否，關係著救援能否成功，因此，需要獲得各方專案關係人的同意。最理想的情況是能夠將專案的預算與時程拉回到原來的設定，但很少解決方案能如此完美，通常必須做出取捨。可能的選項包括： • 增加流程產出，花更多錢但可以早一點完成。 • 縮減產品性能，不增加預算但可以早一點完成。 • 加長時程，在儘量不增加額外支出的情形下完成專案。 • 或者以上皆是。 • 圖13.3是KPMG於1994年所做的專案救援方法統計，可作為決策時的參考。

圖13.3 專案救援方法的統計

救援計畫的實施(1/4) • 專案救援除了計畫之外，還需要有良好的執行力配合，任務才能成功。其內容主要包括：建立可達成任務的時程計畫、重建專案團隊、重建顧客與管理階層的信任，以及重建專案的計畫與管理等。這些目標的達成，都有賴於小心、正確地實施救援計畫。 • 介入執行的步驟 • 暫停正在進行的專案，以便專注在真正需要完成的任務。 • 取得決策的控制權。 • 依照救援計畫的規劃，實施新的專案時程表，進行專案改造的工作。

救援計畫的實施(2/4) • 審查流程與計畫執行的情形，如狀況報告、變更控制、構型管理等。 • 建立一個能夠永久性解決已知問題的架構。 • 重新恢復專案原始的工作。 • 在完成上述介入執行的步驟之後，可重新擬訂一個有把握的開發時程表，向管理階層提出新的計畫方案，然後觀察一段時間，倘若一切正常即可結束救援的任務（如圖13.4）。 • 要切記的是新計畫必須經過周延的思考與驗證；如果隨便提出，那麼就像是以一個爛計畫取代另一個爛計畫，讓專案的信用再一次的折損，打擊了專案好不容易才恢復的團隊士氣。

圖13.4 救援執行的兩個階段

救援計畫的實施(3/4) • 應注意事項 • 專案失控出於各式各樣的原因，每一個專案的情況都不同。因此在執行救援時，應儘量運用經驗與判斷，任何建議的作法都只是參考。 • 專案的評估與救援，並不是要找出誰是「壞人」。評估人員有時會有先入為主的想法，認為是因為現有的團隊能力不足，才造成專案的失敗；這種負面氣氛可能會導致救援的失效。評估者必須讓團隊成員知道，他們是去發現問題，而非去責備人。

救援計畫的實施(4/4) • 對於專案問題的發掘與討論要有所節制，尤其不要追根究底地問，誰做了什麼？ • 為了在最快的時間內實施變革，永遠專注在「資訊」、「目標」，以及「前進」的方向上。切記不要責備，將來有的是時間可以進行檢討或教育訓練。

專案的健康管理(1/7) • 專案健康管理的用意，在於建立一套流程，定期到「醫院」進行生理檢查，提早注意不正常的生理徵候，以避免專案變成災難。 • 專案的顏色管理 • 以顏色代表專案的健康狀態，灰色區代表專案依照預算與時程，沒有嚴重的風險信號；套色區代表專案出現嚴重的麻煩，有很高的可能性會失敗；白色區則代表專案處在風險之中，但是還有挽救的機會（如圖13.5）。利用顏色管理可以建立一套客觀的警告系統，提早偵測、提早治療。

期望與實際的落差 挑戰掙扎遇到麻煩臨界狀態失敗終止專案區失控專案區常態專案區生理健康指標圖13.5 專案的顏色管理

專案的健康管理(2/7) • 定義專案健康指標與臨界值 • 異常專案的主要特徵，就是專案的產出趕不上預定的計畫。所以監督專案產出的誤差範圍，可當作一個有效的指標。 • 一套專案的「生理健康」指標，可利用點值來衡量專案的健康狀態；點值愈高，表示專案的健康狀態愈差（如表13.1所示）。 • 如果參考點值落在8分以內，則專案處於健康的狀態（灰色區）；若點值落在9～15分之間，則專案處於白色區，表示專案有了麻煩，可能需要外力的協助，儘早將專案拉回正常軌道；若專案的點值大於16分，則表示專案的異常已經發生，需要介入與救援，或者專案必須被取消。

表13.1 專案健康評估的九項指標

專案的健康管理(3/7) • 指標中的團隊傾向（disposition of a team），主要是評估團隊運作的健康情形。觀察的項目包括： • 專業極佳、技術良好。 • 良好的人際互動能力。 • 願意分享、給予。 • 尊重權威（authority）。 • 在意顧客的需要。 • 自我信任、正面、愉快。 • 歡迎回饋、願意接受批評。 • 隨時注意最新的狀況。

專案的健康管理(4/7) • 信守承諾； • 正直、誠實、信任。 • 贊助人（sponsor）對專案的支持，也是重要的評估項目。觀察的範圍包括： • 專案的贊助人負責專案的各個面向與組織的連結。 • 讓其它的高階主管認同專案的願景。 • 保持日常的專案投入與組織的策略目標相結合。 • 確保專案開發的內容符合政策、法律、規定等。 • 幫助專案受到終端用戶社群的認同與支持。

專案的健康管理(5/7) • 自我健康檢查 • 可用來自我檢查的參考指標如下： • 錯過專案截止日期。如果專案經常錯過截止日期，或根本未設定截止日期，則表示專案缺乏紀律。 • 缺乏明確的最後決定。某些重要的決定必須及早確認，缺乏這些明確的資訊，會導致許多專案後來的重工與各種的修補。專案的變數愈多，專案後期承擔的風險就愈大。

專案的健康管理(6/7) • 沒有問題反映上來。如果專案一直都沒有遇到問題，那麼不應該高興，反而要猜想是否專案挖得還不夠深，或者是專案出現溝通問題，下情不能上達。 • 缺乏關鍵交付項目。關鍵項目是專案重要的里程碑，缺乏了他們就無法真正衡量專案的進度。 • 人際關係的問題。若未能管理好此一問題，則會導致人員的流動率升高、士氣低落，以及其它問題，包括時程延誤與低品質軟體。

專案的健康管理(7/7) • 品質不佳。在軟體開發過程中，此一問題有時被解釋成暫時性的現象，等待將來改善。但若品質問題始終無法解決，就是一個嚴重的警訊，表示系統設計不良。這會導致專案後期的生產力降低與時程延誤的風險。 • 風險管理。任何專案總有各種未知的變數，專案是否定期檢查各種高衝擊、高可能性的風險因子，是專案是否健康的另一項指標。風險管理可幫助專案提早預防各種突發狀況。

結語 • 異常專案是軟體開發上常見的現象，也是如今軟體工程領域裡逐漸受到重視的議題。異常專案如果及時處理得當，專案還有被救回的機會；否則，專案最後會落入無法挽回失敗的境地。但是人性對於異常專案的鴕鳥心態，往往導致專案不易介入，讓問題變得更棘手。 • 要避免專案出現問題，最好在專案開始時就把事情做對（預防重於治療）。對於異常專案的辨識，要十分警覺，愈早發現愈好。 • 要避免異常專案的發生，應有定期健康檢查的概念。透過定期的追蹤，可適時地評估專案的健康情形。

第 13 章 異常專案管理