推動專案管理的陣痛(2)（轉）

國內企業引進專案管理

去年，我們開始為國內一家科技企業進行諮詢工作，這家軟體服務企業本身有一套簡單的專案管理流程，同時聘用了數名專案經理，希望專案管理能夠改善專案超時，超支等問題。統計中顯示過去有超過56％的專案未能如期交付，專案平均延誤時間從三個月到一年不等，部分專案更延誤超過一年多還未能讓客戶驗收。他們希望“專案管理”能夠改善他們的專案交付，提升企業的運營效率及利潤指標。這家科技企業與大多數企業一樣，以為聘用專案經理後，或讓技術人員進行專案管理培訓後便可以改善專案管理的能力，實施科學管理方法來提升企業的效益。假如一個專業潛水員穿上了深海潛水衣後一直站在甲板上，不管這名潛水員的能力有多強，缺乏身在深海中的“環境”，英雄還是沒有用武之地。專案經理未能在企業中發揮其潛力，那是因為大部分企業欠缺一個能夠配
合專案管理的環境。這個所謂“環境”包括企業必須擁有一套適合的“專案管理體系”（project management methodology），一套可以讓專案經理執行工作的“管理機制”（management mechanism）。

強化：先建機制

每一家企業有他本身的商業目標及運營特色，而最重要的是本身的管理文化，建立管理機制是強化企業的管理文化，這個過程雖要企業高層的投入及支援，否則便不能夠達到預期的結果。在這裡與大家分享一些企業普遍需要的管理機制。再回到那家科技企業，須然所有專案都要經過“立項”，讓高層審批後才能夠啟動，而立項申請書的內容也包括專案概述，預估工作量，預計工期，成本預算和資源需求等基本內容，但這些內容卻未能讓管理人員評估其真實性，未能反映出專案本身的複雜性，困難度等等問題，未能把立項申請書成為專案的初步基線。

機制一：基線建設
缺乏一個專案基線便不能夠進行比較，不能夠管理進度。假設你問兩個屬下，從大廈一層到大廈十層要多少時間？A 君告訴你2 到10 分鐘，B君告訴你10 到15 分鐘，那麼你作為一個領導，如何衡量那一個的估算是比較準確呢？你該認同那一個的估算作為基線呢？也許你會自己去衡量，也許你自己估算出來的結果是5 到8 分鐘。答案剛好在中間，那麼你會採用那個估算做基線呢？慿你過去多年在單位上下班經驗，你認為自己的估算會比較正確，所以用8 分鐘作為基線，一聲令下，兩個屬下馬上實行從一層到十層的任務。你便進行進度跟進。一分鐘後，你發現A 君原來是爬樓梯，已經到底一層，但B 君還在一樓等電梯。在進入第四分鐘後，A 君已經在四層了，但B 君還在地下一層等電梯。你開始知道他們也許都不能夠在你的基線內完成任務了，但仍然希望，只有B 君能夠很快進入電梯，那麼還是有希望可以在3 分鐘內到底十層，在基線內完成任務。進入第六分鐘了，A 君報告說現在在六層，但需要停下來休息一會，還好B 君已經進入電梯，在一層停下，因為有人出去。也許這時候你應該建議A 君利用其他的電梯完成餘下的任務。進入第七分鐘，你還是希望B 君能夠順利在一分鐘內到底十層，但B 君卻告訴你說在三層又停下來，因為三層有人把東西搬到六層及八層。這是你便理解他們都不能按你過去多年的經驗在你建立的基線內完成任務。

其實作為一個專案經理，或者高層領導，在自己沒有進行估算前，便應該理解屬下提供的資料是如何獲得，假設你能細問那兩個屬下，他們如何達到這個資料的估算呢？也許你便發現B 君是基於等升降機的時間，加上可能需要在各層停頓的時間估算2 到10 分鐘的結果；而A 君告訴你他爬樓梯，平均1 分鐘到1 分半鐘一層的速度，大概不會超過15 分鐘的時間。有了這些資訊，你才知道他們的估算是如何結算出來的。所以專案建立基線必須要有一個規範，讓每一個專案組成員都能夠知道如果按照這個規範處理專案的工作，是可以在基線的時間內完成任務。COCOMO, Function Point Analysis, EMOD 等都是規範性工作量估算方法，但我們也可以依靠本身的經驗，融合到一個企業本身的開發管理體系框架中，及專案架構分解（Project Breakdown Structure）下各工作包的交付目標來建立估算的規範，便能夠更準確的建立專案基線。這是企業推動專案管理最艱鉅的工作，基線建設規範是整個專案成敗的關鍵，也是專案能否有效管理的根源。在推動基線建設的過程中，平均專案增加3％工作量，而且在推動初期有很大阻力，當專案經理完成基線建設的時候，發現自己以前的估計比基線少了30％的工作量，才發現其中有很多工作量以前在立項時並沒有完全考慮到，這些新資料讓他們體會到專案延誤的一些主要原因。這個階段需要高層的支援，同時需要為專案經理在過程中提供輔導，直至三個月後才能夠讓這個機制成為專案經理編寫立項申請書的部分工作內容，讓專案經理接受及認同。
[@more@]