專案管理：組織相關的專案管理思維－哈米尼斯的天空

引用自 Vic的PMP Blog ,以下是我節錄部份文章

另外根據VitaSmarts Company針對35家公司近乎10,000個專案的調查研究報告，專案失敗的主要原因不是因為技術或工具等因素，最主要的原因是溝通的不良(Communication breakdowns)所造成，而會溝通不良起因於企業的文化，因此造成大多數的人對於專案有問題時都傾向於沉默的態度，最後導致專案的失敗。

這份調查報告列舉了５個失敗發生的原因：
１.Absent Sponsors.：77%的人認為Sponsors沒有提供權力、時間或精力來參與，然而卻只有14%的人會反應處理此種情況。
２.Failure to "get real."：80%的專案常在沒有依據現實規劃的情況下，被限定在短期內完成，但卻只有18%的人會反應此問題。
３.Power Play.：只有15%的Project Team會試著用各種影響力來提升專案的流程效率達到最佳化，但卻有61%的Project Team選擇屈服。
４.Team Failures.：62%的專案成員是在不情願或沒有能力的情況下被指派參與專案，卻只有19%的人會提出討論。
５.Denial Issues.：當專案發生問題時，82%的專案成員不承認有問題，只有18%的人會面對。
以上都會造成專案的失敗，因此要改善此種情況最主要的建立一個鼓勵大家互相溝通的企業文化。(To avoid these scenarios, project managers and sponsors should try to build a culture that encourages communication. If people are discouraged from bringing these issues up, or are afraid to, we're missing a crucial component of what drives success.)
資料來源：2006年10月份的PMI雜誌
========================================================

看完這一個數據後，我的想法是：

其實公司不只是只有PM需要接受專案管理的訓練，越是高階的主管，專案的訓練越是必要。

每一個角色在公司所扮演的角色不同，但是受過一致性的訓練後，會比較容易建立起「共同的語言」
只有在有共同的語言的前提下，才有辦法產生專案方面的管理文化
無奈的是，我過去曾待過的單位，越是高階的主管，越是不願意接受訓練或是他們認為他們過去的經驗已足夠Cover

在這樣的狀況下，對於問題發生時，就不容易用完整而客觀的角度去分析、思考和解決問題；
此外，在員工的部份，還需要學習所謂的「向上管理」，在公司做事，不是只有服從，而是在不同的位階上，各自完成各自的任務。

說個例子吧，之前我曾面試一個人，有問到類似事情衝突的解決方式，他給我的回答是：
以主管交待的事項為第一優先，其他的事往後延。
我不能說他的想法有錯，不過，我會認為當事情的優先順序有所衝突時，你應該要先設想好你的優先順序，並與主管討論及確認，以避免也許有更急迫的狀況被忽略的狀況。
不然，以此方式來工作，當所有的事情都是第一優先時，就等於所有的事都沒有優先順序了。

我常常聽到類似的故事：

工程師：我們時間已經被維護和新的案子都塞滿了，Sales還一直接新的案子進來
經理：A客戶因為時程或交付上的Delay，要求要全力支援，所以我們把XXX和YYY的時間安排給他們
副總：B客戶的功能到底好了沒，還有C客戶的那些報表的數字有沒有對過啊？

其實這些話對軟體公司來說一定都不漠生，我們看這樣的故事一再發生，但是是不是有認真在思考過，怎麼改或解決？
我的看法是，在專案文化之前，還有一件事要做：建立專案管理的Process

所以整個看起來，我們會發現，要建立專案管理的文化，會有以下幾個步驟

一致性的專案管理訓練==>建立共同語言及共識
從訓練的要求中，留下每一次的專案記錄 ==> 建立文件
依據每一次的專案紀錄，回饋和整理專案的流程 ==> 建立和修正流程，建立"組織"角度的專案管理
强化每一次文件紀錄的內涵，加入量化的觀念 ==> 產生專案衡量的基準
透過衡量的基準，達成更準確的專案預估，更有效率的執行結果 ==> 專案執行最佳化，並影響"企業"角度的專案管理

以上，其實就是 CMMI 的能力成熟度希望達成的結果，從實際的經驗上來看
1->2 就已經算是一個鴻溝了(叫工程師寫文件難度很高的，叫PM寫文件，那你得看他有沒有時間)
2->3 的Gap也不算小(主管在意的是專案的收款，對於專案過程的支持，往往很低)
3->4 是整個CMMI設計上Gap最大的地方(光是要度量什麼就沒人知道了，而且度量這一件事會讓人聯想到績效，想想看有誰會提供真實的數據)
4->5 反而是在於專案累績的數據足不足夠成為一個Database，難度不見得這麼高

對於我個人來說，公司是不是要走CMMI，我也不一定會支持，不過，若是您有餘力去了解 CMMI 的設計和精神，會對您的專案功力大大加分，最後也補充CMMI 對於「能力成長」所建議的 Cycle --IDEAL，和傳統的 PDCA 很像，不過它定義的更細，給大家做一下參考，想進一步了解的可以這裡有 URL 。