[分享] 專案失敗的原因及對策

bhcww

專案失敗的原因及對策

企業面對今日市場的動態變化，傳統的功能性組織 (個別獨立的業務、研發、製造、品保、工程等單位) 的運作模式不再能完全滿足企業與市場的需求。企業需要有能力整合跨部門資源，在有限的預算及資源壓力下，在期限內達成特定目標的“臨時性組織”及“專業經理人”-- 而答案就是“專案”及“專案經理”。運用現代專案管理手法，企業有更大的機會可兼顧專案的“產品品質”及“管理品質”，平衡專案管理的“三重限制”(成本、時間、範疇)，並達到顧客滿意。(請參考92年2月號品質月刊第34~38頁，作者的另一篇文章：“從六個標準差談專案管理”。)

依據一個研究，全球僅有25%的專案成功地達到其預算、時程及品質目標。同一個研究並顯示，當專案使用現代專案管理的觀念、工具和技術時，有75%成功機率。這些事實突顯了現代專案管理的重要性。另依據美國 Center for Business Practices (CBP) 的調查，有97% 的企業受訪者認同專案管理對其企業有加值的效應 。
由摩菲定律 (“If anything can go wrong, it will!” 可能會出錯的，一定會出錯！) 可導引出：我們若做成功專案所做的事，我們的專案不見得會成功。而我們若做失敗專案所做的事，我們的專案肯定會失敗。因此，避免做錯的事比做對的事更重要。專案失敗的原因有很多，讓我們在此一起來看看四個常見的專案失敗原因及其對策：
l        管理高層選擇錯誤的專案和對專案的支持不足
l        選擇不適當的人當專案經理
l        未釐清顧客的需要和期望與專案目標
l        專案規劃不周詳

管理高層選擇錯誤的專案和對專案的支持不足
失敗狀況：
管理高層可能未經考量對企業的整體、系統面影響 (通常僅想到一個提案好處，但未考慮到其負面的因素 – 如緊繃的資金、人力及資源)，即下令開始一個專案，並要求在某一期限前看到結果 (當然期望正面的成果)。之後，管理高層可能就認定其屬下“很自然且很自動地”就會將該專案處理好，並很少過問專案所需的錢和人從哪裡來及專案的進展，一直到偶爾或專案快結束時才想起。該專案則依管理金字塔一層一層的交待下去到基層執行單位。企業中的其他部門可能認為該專案是該被指定執行單位的專案，而不是他們所擁有 (own) 可表現績效的專案，可能僅以應付的心態來面對該專案。基層執行單位因缺乏管理高層的方向指引和實質協助，而難以要求其他部門提供所需的支持和資源，使該專案的進展困難重重。最後，該專案可能在超出期限和預算的狀況下，仍未達成專案原先所期望的範疇和品質水準。當有人問起管理高層對該專案的重視度時，管理高層即說明他們完全支持該專案；而執行基層對此可能認為僅是“口惠 (lip service)”。
對策：
u        管理高層應確定專案的目標必須與企業的策略一致。若專案目標與企業的策略不一致，該專案根本不應存在；既使已存在，也應立即終止。因為該專案不會為企業帶來整體的價值 (可能僅是某一部門的本位績效表現，對內外部顧客卻無實質貢獻，卻要耗用企業的整體資源)。
u        管理高層應建立專案組合管理 (Project Portfolio Management) 的督導委員會 (Steering Committee)。可透過平衡計分卡的方式 (亦可合併重要性、急迫性、可行性、顧客影響度、或其他指標)，衡量企業有限的資源 (財力、人力、物力、時間等等)，來管理符合企業策略的專案組合，包含決定專案之間的優先順序、排定專案資源運用的優先順序、選擇並開始新的專案、中斷不適的專案等等。要注意：管理高層必須要選擇對的事來做 (Do the right things – 策略面)，之後專案經理再將事情做好 (Do things right – 執行面)，專案才可能成功。要不然，再優秀的專案經理也不能做好管理高層本身做不好的事。
u        管理高層對專案的態度應言行如一、身體力行 (walk the talk)。管理高層應指定專案的管理階層贊助者 (executive sponsor) 以設定明確的專案目標、明確地授權予專案經理 (藉由專案核准書project charter授權運用企業的各種相關資源)、參與專案會議、在專案訓練課程中露臉、強調該專案對企業的價值、提供資源 (人力、物力、財力)、解決與其他部門的介面及配合問題，以確保專案會成功。如此，企業內才不會有人認為管理高層表裡不一。因此，有人認為GE的六標準差計劃 (Six Sigma program) 會成功是因為其總裁Jack Welch親自領導及強力要求所致。

選擇不適當的人當專案經理
失敗狀況：
經常，專業人員會因其“技術能力”受到管理階層的肯定，被誤認為他們有“專案管理能力”，而“意外地”被指定成為某個專案的專案經理。這是“光環效應 (halo effect)” – 人員在某一方面表現突出，而被誤認為他們在其他方面也會表現得很好。即使有些企業認同專案管理訓練的價值，在受訓人員上完一定時數 (如一天、兩天、36小時等等) 的專案管理課程，便認定受訓人員有資格當專案經理，並期望該受訓人員能馬上學以致用。但很可能的是，該“意外的”專案經理可能不問理由就接受管理階層所設的目標、時間和預算限制，一個人埋頭苦幹地估計專案活動所需的作業時間和金額，將專案時程甘特圖畫出。之後，再召集專案隊員並強力要求他們要按預算和時程進行工作。而專案實際進行時，卻發現有些活動被遺漏了 (根本未規劃在專案計劃內)、工作順序不對而需要重新規劃或重做、活動的時間或預算不足、甚至造成溝通不良和衝突等問題。
對策：
u        不要將教育訓練和顧問混為一談。課堂上的教育和訓練僅能傳授專案管理的知識和基本技能；而協助學員及其企業依它們的特性有效地應用專案管理的方法則是屬於顧問的領域。顧問的知識可以在課堂上學習，但經驗則須靠學員及其企業自行累積 (當然顧問可以在這一方面協助)。就像練習演講一樣，講師再多的解釋也比不上學員親自上台實際演講 – 要做了，再從中學習才會得到經驗。如同六標準差的訓練一般，專案管理訓練的投資並不小，但對企業有長期的幫助。若專案管理能協助企業使一項重要的研發生產專案順利完成，並使產品及時上市，其獲利就有可能值回所有的專案管理訓練投資。
u        專案經理要有正面的人格特質。專案經理須：
n        熱愛他們的工作 -- 在高壓力和高不確定性的環境下，能欣然接受挑戰，並能主動積極地 (proactively) 處理問題。
n        有紀律 – 自我的時間管理做得好，循規蹈矩地完成每一個專案階段。認清自己是管理整體專案工作的整合角色 (integrator)，能抗拒要跳下去自己做細部技術性工作的誘惑。
n        有責任感 (ownership) – “因為我是專案經理，所以我必須對整個專案的成敗負責。我若不持續推動，則專案不會有進展，問題不會解決。”
不像硬性技能 (hard skills) 可透過訓練傳授，態度或人格特質則需要長期的教育才有可能改變。因為專案的有限時間不允許長期間的教育，所以一開始就要選擇有積極態度的專業人員當專案經理。
u        專案經理要有強健的人際技能 (即軟性技能 soft skills)：
n        溝通 – 要會傾聽和知道何時對誰作溝通、談判、協調、化解衝突，並取得利害關係人 (特別是專案隊員們) 的認同 (buy-in) 和承諾。
n        領導 – 要清晰地了解企業的願景和專案目標，授權及追蹤團隊的任務執行，並激勵團隊前進。並了解沒有一個人 (包括專案經理) 是全能的，因為專案的成功是靠匯集並整合所有專案隊員的專長，以teamwork的方式來達成的。
u        專案經理要有專案管理的知識、技能 (即硬性技能 hard skills) 和執行力才能：
n        了解專案管生命週期階段 (起始、規劃、執行、控制、結案) 的過程及其各項作業。
n        以宏觀看整個專案及其所屬組織的狀況，並建立強健的團隊技能和樹立正面的氣氛。
n        與專案團隊一起討論及發展專案計劃，並取得管理高層的核准。
n        與專案團隊討論及建立專案的工作分解結構 (WBS, Work Breakdown Structure)，並由WBS中估計專案活動的時間和成本估計與識別風險。
n        與專案團隊發展專案網路邏輯圖 (network logic diagram)，並監控要徑 (critical path) 上的活動 (必要時需壓縮工期)，以避免延誤專案時程。
n        定期監控專案狀況、審查風險、採取必要的矯正措施、更新專案計劃等。
總而言之，要選適當的人做適當的事，不要草率地認定專案經理的資格！

未釐清顧客的需要和期望與專案目標
失敗狀況：
有些專案在顧客的目標 (需要和期望) 未釐清前 (甚至客戶或使用者是誰都還不清楚時)，即開始專案。而在專案的執行過程中，顧客會要求一些額外的特性或功能，在其他相關的利害關係者未充分參與的狀況下，造成專案範疇的蔓延擴大 (scope creep)。最後導致專案的三重限制 (成本、時間、範疇) 不平衡和失敗。或者是，專案經過團隊辛苦的努力，終於產出成果，且專案快要結束了。但該成果呈現給顧客或使用者時，才發現產品或服務的特性或功能不是他們所需要或期望的，造成顧客或使用者認為專案的產品品質不佳。對企業而言，也可能是在此時才發現當初除了要滿足顧客的需要和期望的目標外，還要透過該專案要達成的技術或服務能力提升、種子人員訓練、經驗累積等等目標亦未達成。

對策：
u        顧客的需要與期望要先確定，之後則可藉由品質功能展開 (QFD) 發展至產品規格、製程需求、材料規格等等。
u        專案的目標 (含範疇、成本、時間、品質) 必須要在專案核准書 (project charter) 中明述，並且要SMART – Specific (明確的), Measurable (可量測的), Agreed upon, Achievable or Assignable (共識同意的、可達成的或可被指派的), Realistic (可行的), Timely or Time-constrained (適時的或有時間限制的) 。
u        專案團隊應建立並運用專案溝通管理計劃 (project communications management plan)，充分地與所有的利害關係者 (特別是客戶) 溝通。較理想的狀況是：顧客也是專案團隊的一員。
u        有關專案的任何變更，均需依照專案變更管制程序處理。必要時，須召開變更管制委員會 (change control board) 以審查相關的變更請求，特別是對專案三重限制的影響。
u        專案團隊應建立利害關係者管理計劃 (stakeholder management plan) 以識別利害關係者、對他們分類、了解他們的需要和期望、規劃如何滿足他們的需要和期望、執行滿足他們需要和期望的活動、監控計劃執行狀況、並做適當的改變。

專案規劃不周詳
失敗狀況：
一個專案管理知識不足的專案領導人很可能認為一幅畫的漂漂亮亮的、巨大的、且上面秀出各項活動時程的甘特圖就是一個專案計劃。他很自豪地把這幅甘特圖秀給管理高層看，管理高層也感到印象深刻。隨後，該專案領導人就將該甘特圖訂在牆上，召集隊員依計劃進行，且該甘特圖就再也沒有修改更新了。在整個專案過程中，一些“意外的”問題會發生。在起初，該專案領導人會想辦法進行矯正行動使專案儘量依該甘特圖進行。當專案工作進入高峰期，當他發現再也無法依該甘特圖進行專案工作時，他就回歸到憑個人經驗和直覺的土法煉鋼式的專案管理。在專案快結束時，各功能部門會將其人力、物力資源從該專案抽調走。對於無原單位可歸隊的專案隊員，他們可能拖延專案使他們仍保有一份收入，同時並尋找下一份專案工作，並無心專注於這個專案。最後，只剩該專案領導人和極少數的人忙著收尾及結案報告。

對策：
u        專案規劃工作是由專案經理和專案團隊一起做出來的；絕對不是專案經理一個人做的。
u        專案計劃絕對不是一幅甘特圖而已。依國際專案管理學會 (PMI) 的專案管理知識體指南 (PMBOK Guide)，“專案計劃 (Project Plan)”包含：專案核准書 (Project Charter)、範疇聲明 (Scope Statement)、工作分解結構 (WBS)、成本估計、時程表 (含里程碑、目標日期、網路邏輯圖、甘特圖)、主要工作人員 (含專案組織架構與責任指派)、績效量測基準 (含範疇、時間和成本)、各項子管理計劃 (範疇、時程、成本、品質、人力資源、溝通、風險、採購) 及未定事項等等。
u        專案計劃不是規劃時僅做一次就一成不變的。只要是專案未完成的部分，其計劃就應依專案執行的現狀和需要，隨時做必要的修改和更新 (最好是每週檢視一次，看是否應更新或修改) 。但一般的專案計劃的更新不應修改專案的基準 (範疇、時程、預算)，以避免無法量測專案的進展。唯當專案現狀已偏離專案計劃太多時，才要修改專案的基準。但原始與歷次版本的基準一定要保存，以利日後的檢討和經驗學習。
u        專案的工作範疇是由團隊自範疇聲明中發展出工作分解結構 (WBS) 至工作分項 (work package) 層級。團隊再由工作分項發展出活動清單 (activity list)，以確保沒有遺漏工作項目。由活動清單再發展出專案網路邏輯圖 (network logic diagram)。網路邏輯圖是非常重要的！它是我們排定活動順序 (含先後與併行順序) 的依據，也是我們要壓縮或延長專案工期的基礎。最後，專案團隊在分析資源需求、行事曆、限制、風險等等因素後，才會產生專案時程 (以甘特圖的方式顯現)。
u        專案規劃需要時間。不要急急忙忙地想要開始專案執行的階段 -- 一定要完成必要的計劃。要不然，“意外的問題”(即“風險risk”) 會發生。每一次的專案會議一定要追蹤檢討已識別的風險、識別新的風險、規劃適當的風險回應 (規避、轉移、減輕、承擔)、並檢討風險回應行動的有效性。
u        不要忘記“專案管理”也是專案工作範疇的一部份。要將專案管理相關活動的時間、成本和資源需求規劃在專案計劃中。
u        要確保工作分項的大小要適中。要能將其權責明確地指派予某一人或一組人，且時間長短最好是在經驗值的8~80小時內。工作分項太小會造成“微細管理 (micro-management)”，會使工作執行者感到被監視，且無法發揮他們的專長，以更好的方法來完成被交付的工作。反之，若工作分項太大，則會無法掌握工作進展。
u        要及早規劃專案的結束，特別是人力資源的流失。以免尚未找到下一個工作的隊員沒事找事做 (make work) 拖延專案，及避免無人幫忙專案的結案工作 (結束下包合約、確定所有應收和應付款項已結清、取得客戶的正式結案通知書、記載經驗學習、撰寫專案報告、完成專案記錄檔案、轉移設備機具、釋放人力資源等等)。

結語

我們要記取失敗專案的經驗學習，避免再做錯的事。因為，在專案管理中，避免做錯的事比做對的事更重要。我們在此檢討了四個專案失敗的原因及其對策：
l        管理高層選擇錯誤的專案和對專案的支持不足。其中，作者認為最重要的是：管理高層必須要選擇對的專案來做 (策略面) 並以實際行動支持，之後專案經理再將事情做好 (執行面)，專案才可能會成功。
l        選擇不適當的人當專案經理。其中，作者認為最重要的是：學歷或經歷並不代表一切；而態度決定一切！先找對的人當您的專案經理，再決定您要/能做什麼專案！
l        未釐清顧客的需要和期望與專案目標。其中，作者認為最重要的是：顧客依其需要和期望來判斷專案的產品品質，而企業依其所需的其他專案目標來判斷專案的管理品質。
l        專案規劃不周詳。其中，作者認為最重要的是：專案計劃是由專案經理和專案團隊一起做出來的，且須隨時做必要的修改和更新。

專案發生的頻率比我們實際上想像的更高。譬如說：
當您的主管或客戶對您說：“請把﹝什麼事﹞，在﹝什麼時候﹞做好。”
您可能就有一個專案要進行 -
                                什麼事 (What) = 範疇 (Scope)
                                什麼時候 (When) = 時間 (Time)
                                做好 = 品質 (Quality)
您還要考慮您是否有足夠的
                                資源和能力 = 成本 (Cost)
來符合上述的條件，以達到
                                顧客滿意 (Customer Satisfaction)
因此，不論其大小，專案是無所不存在的，而且您要去管理它！要不然，它會趕著您跑，讓您失敗的機率大增！
[em04]

老高

不错啊~~

顶上去~~

hellowmeyou

真的很好

水瓶座女子

Very good!

loseleaf

真是骇人听闻！

liujianguoone

找到了,起來

[em08]