PMP沒講的是...

PMO應分擔專案的成敗，而不只是有權無責！

前些天，到某公司做諮詢，該公司設立有PMO專案管理辦公室，專責公司CMMI制度的推行及監督。在和其中一位PMO成員會談時，他透露，公司各部門的PM與專案成員，對PMO所推行的這套CMMI制度多所怨言。同仁們認為CMMI很麻煩，過多的流程及文件、表單，讓他們很反感。我亦認同不必要的文件、表單不要做，因為每一份文件、表單，都在耗費專案的資源，包括時間與成本。但這並不代表專案裡所有的文件都不必做，必要的文件還是要做。

　　
我再仔細追問，是哪些流程或文件讓同仁們覺得不必要呢？他說，CMMI有規定，凡是基準(Baseline)的變更，都要進行變更控制程序，都要納入控管，包括要登記變更、送審變更…等。但同仁們總是說，太麻煩了，當他們在客戶端作業時，只是一個小bug，現場修復了程式，問題也就解決了，但因為CMMI的規定，還得回公司來填表單、跑流程，愚蠢極了。

　　

我也認同CMMI對於涉及基準的變更皆應納入控管的要求，這個立論並沒有錯。只是，CMMI並無強制規定專案中哪些項目應納入基準，更沒有強制規定專案中的大大小小事物皆須納入基準、大大小小事物皆須納入控制。所以，更正確的好觀念是，『必要者，納入基準；納入基準者，必好好維護之』。

由人來決定制度，而非由制度來統御人

 
好比，一份專案管理計畫書是專案執行與監控的依據，此份文件對專案而言，當然是一份很重要的文件，必須納入專案基準，列入構型管理或變更管理的對象。但一張便條紙，就不需要納入基準。但要進一步說明的是，雖然專案管理計畫書應納入基準，應予以控管，但只是涉及文字語句流利順暢與否的調整，未涉及任務專案最終交付要求的改變，這樣的修改就不需要納入複雜的流程控管。所以，什麼要納入控制，又要控制到多細，由人決定！

　　

又如，對於專案交付期限、里程碑等重要資訊，理應納入專案基準，一旦要變更交期或里程碑，自是茲事體大，必須納入控制，不可便宜行事。但對於每一隻程式的開始日或完成日的改變，都要跑複雜的流程，則是不必要的。惟～此亦不應被過度解釋為，任何程式的開始日或完成日的改變，PM都不必注意、不必管理。對於關鍵性程式的控制，若有其必要性，則當然要列入控管；而對於所有程式的開始日或完成日的改變，PM當然需要監督，要記錄下來，要注意其是否有變化、是否會影響專案成敗，只是不必要跑複雜的流程表單。

把專業判斷的空間還給專案

 
做專案，不可能事事如願、事事如料，總難免發生事實和原來想得不一樣，故應有容許的誤差。在容許的誤差內，讓專案擁有自主的彈性；在容許誤差之外的，才納入控制程序。而這樣的專業判斷空間，應該還給每個專案、還給PM、甚至還給成員。不應設計複雜的制度，把人綁手綁腳、把專案綑死。

 
若PMO很堅持，並能列舉許多的實例，認為開放這樣的彈性，會造成如何又如何的後果，既是如此，那表示這些的舉例，是有必要納入控制的，是在權衡了利弊得失後，判斷值得這樣做的，那就照辦。制度建立者總要能細心判斷，確保其所設計的制度，使組織資源的投入耗費是很有價值的。若PMO只是因為不相信PM或專案成員有能力做出專業的判斷，那PMO應該做的是教育訓練，而不是設計更多複雜的流程表單來控制人。

 
PMO的使命之一，是讓組織的專案管理成熟度更高，這也包括對PM及成員能力的提升。做為一位PM，必須有能力判斷一個變更是否會對專案產生重大影響，是否需要納入控管；身為一位專業技術人員，必須有能力判斷一個變更是否會對產品產生重大影響，是否需要納入控制。每個人都要能為自己在專案中所擔負的責任負責，每個人都要學著能對自己所負責的任務，做最佳的判斷。

 
PMO應該要相信，身處在專案中的PM及成員們，他們比PMO更了解專案的狀況，他們會知道什麼樣的判斷決定，對專案才是好的。PMO只須給予PM所需的訓練，讓PM與專案成員們變成是有能力的人；或者，讓他們知道，當他們無法做判斷時，能夠請教組織裡的誰；或者，讓他們知道，哪些是他們能自行決定的，哪些是他們不能自行決定的；或者，讓他們知道對於他無權決策的事務，他應該如何處理。

制度建立者的正確態度與觀念

 
有制度是很好的，是為了讓運作更順暢，是為了讓人產出更好的績效，是前人希望後人不要重蹈覆轍。只是，建立制度的人要有正確的觀念。

首先，制度的設計不應只是為了通過認證，卻讓公司競爭力更差。如果制度只是要通過認證，那很簡單，照本宣科即可。但如果這種照本宣科的制度，讓原本只需四個月即能上線的產品，因為制度而要花上五個月，或者只是讓同仁們的工作更加困難，那便不是一個好制度。制度設計者應抱持著，要建立一個能讓組織更有競爭力、讓同仁們有更好績效產出的制度。制度設計者要去針對公司所處的競爭態勢、所擁有的資源多寡，去權衡這樣的制度設計是否是有價值的。

制度單位要能做QA、做稽核；而不只是做QC、做檢驗。好的稽核人員不只會找人麻煩、挑毛病；好的稽核人員更能做診斷、做改善，能找出流程運作上的不順暢與弊端，能解決問題、勇於調整、勇於推翻、勇於對抗組織中的錯誤，能創造有價值的流程。如果PM總能從PMO得到很多的幫助，讓專案管理更順暢；如果專案的成功，總是很依賴PMO的協助。這樣的PMO，不需要大聲疾呼，也能使所有同仁與之共行。若背此道而行，就難怪人們會群起反之。

 
推行制度前，先做訓練
 

其次，推行制度之前，應先對同仁們施以教育訓練，讓同仁們具有好觀念。當一個人的觀念不同了，他的行為自會不同。就像某位創新PMP說，她上完了課，對做專案更有觀念，她以前在參加產品設計審查會議時，有時候會因為忙碌而覺得不耐煩，但現在很清楚這是一個很重要的動作，如此一來，也會耐著性子了。這就是給成員教育訓練的重要，當同仁們有了好的觀念，他懂了為什麼要這樣做，他才更能發揮這個流程的功用，而不只是為了制度而制度。

 
施以訓練，同仁們會知道，為什麼要花時間做規劃，而不是急猴猴地就開始動手；施以訓練，同仁們會知道，為什麼要寫文件、要做記錄，因為人的記憶力不會這麼好，不會大大小小的事全都可以記得住，且寫下來的動作，還能幫助你釐清你只是以”想像”方式所做的規劃，其實前後存在許多矛盾衝突。

 
PMO應分擔專案成敗，才可能易地而處
 

再來，PMO應當有能力去分擔專案成敗，而不只是一個有權無責的單位。PMO負責管理公司裡所有的專案運作，而管理的功能不只是做控制，還包括規劃、組織及領導等功能。而當PMO必須開始負擔公司裡每個專案的成敗時，它的思考邏輯就會開始改變。它會把心力放在如何讓專案運作績效更好的研究改善上，而不是專注於只為了能很容易地通過每年的CMMI認證查核作業。

 
如前述，如果只是設計一個能通過認證的流程，那很容易，不必思考，照本宣科即可。但要能創造一個有價值的流程、建立組織很有價值的流程資產，那很不容易，那得夠專業、得很用心。

 
順道一提，某次因緣際會，與某公司的軟體開發制度建立部門主管會談，他說他之前已建立了一套軟體開發的制度（是某廠商不知從何處抄襲而來），我看了一下，發覺其中有許多不合理、沒效率的流程表單，但那位主管說，制度不能改，制度不應昨是今非。乍聽之下，好似鏗鏘有理，但～真是這樣嗎？制度應與時俱進。若制度不該是昨是今非，那這個部門應該也可以裁掉了！

 
PM不可只是遵循制度的表面，而是要了解制度的意義

 
『制度』是組織把各項作業做異中求同的設計，而藉由這套設計來確保組織裡所有的專案能有好的產出。但這不代表有了制度，PM就只要照著做，即可做好專案管理。每天只要管好流程、管好表單，就叫管理專案了（就像有許多PM，誤以為把MS Project軟體管好了，就叫專案管理）。

 
每個專案有其獨特性，別人的專案因為沒有這些問題，所以它只需做這樣處理即可，但不代表你如法炮製亦行得通。每個專案的組成成員特徵不同、要面對的顧客其所在意的不同、專案收取的價格不同、要求條件不同，做法便大不相同。

建立制度，能有效預防專案團隊犯下無法回復的疏失，進而避免專案得付出極大代價！但一套沒效率、無價值的制度，也該做些改變。就是那句話，『制度是死的，人是活著的！』