專案規劃與估算會直接影響到專案本身的健康程度,規劃不當會直接反應在專案的範疇、時間、成本、品質等交付指標上,由於我本身負責的專案都是屬於新產品的發展,很難一次將所有的需求看清楚,必須隨著專案的展開而逐步精進,但因為這種性質,我們可能會在專案執行1/5時才知道有個模組必須要被加進專案裡頭,而這個模組的總工作量佔了整體專案的30%,所以一開始提報給老闆的時程與成本將會大幅增加,專案的SPI/CPI也將失準,為了讓專案後續的運作可以更順暢的執行,一般我會進行重規劃(Re-plan)的動作。
(原文來自gipi的學習筆記:http://www.dotblogs.com.tw/jimmyyu/archive/2012/10/05/project-re-plan.aspx)
(原文亦刊載於專案管理雜誌)
在職場上擔任多年的主管角色,主導、參與過的專案早已不計其數,有些專案執行的狀況堪稱良好,但千奇百怪的專案現象也不斷的在我們身邊發生,有些專案的工作時程一旦壓下去,也不管後續是否有其他的變更發生,就依循著一開始的規劃一路往下作,我們來看看下面這個案例:
甲專案一開始估算的工作量與工期為A,但做到一半後才發現需求收集不完整,趕緊又將新的需求納入專案中,導致專案的工作量與工期變成B,而專案完成度也從本來的60%降到了40%,SPI也從本來的0.95降到了0.7,整個專案的一直到結案的績效表現都很不好,即便專案完成了,但帳面的數字還是很差。
相信這案例中的狀況大家都不陌生,一個專案立案後,不管後續有什麼樣的變動,專案經理也不會再去對專案進行調整,就在錯誤的指標數字上持續的作下去,因此在專案變動之後的SPI/CPI數據,其實都已經失去意義。
另一個常見的規劃問題是發生在估算上,估算是專案的基礎,時程與成本的展開都是來自於估算,準確的估算可以讓我們對專案有個可被預見的預估,反過來說,如果估算錯了,整個規劃可能就完全失準了,以下是一個真實發生的案例:
乙專案是個新產品的研發專案,專案初期交由過去開發另一項產品的的開發人員來協助估算,這個成員以過去維護產品的經驗來估算開發新產品的人力投入,結果最後多花了三倍的時間才將專案完成。
專案本身必須因為特性不同而使用不同的估算方式,以研發性質的專案來說,我們會儘量使用考慮到風險的三點預估法(PERT)來估算,並以過去有研發類似產品經驗的成員來協助作估算與風險識別,這樣可將我們估算的精準度提到最高。
專案的重規劃(Re-plan)
專案規劃與估算會直接影響到專案本身的健康程度,規劃不當會直接反應在專案的範疇、時間、成本、品質等交付指標上,由於我本身負責的專案都是屬於新產品的發展,很難一次將所有的需求看清楚,必須隨著專案的展開而逐步精進,但因為這種性質,我們可能會在專案執行1/5時才知道有個模組必須要被加進專案裡頭,而這個模組的總工作量佔了整體專案的30%,所以一開始提報給老闆的時程與成本將會大幅增加,專案的SPI/CPI也將失準,為了讓專案後續的運作可以更順暢的執行,一般我會進行重規劃(Re-plan)的動作。
所謂的重規劃並不是將整個專案砍掉重練,而是在既有的基礎之上,考慮到真實的狀況下,對專案的剩餘工作作重新規劃的動作,例如以單一工作項來說,你本來今天要完成工作項A,但你卻沒有完成,你的主管問你:「那你還要多久?」,你回答他說:「明天可以完成。」,從今天—>明天,這就是你對你工作時程的更新,這也讓主管對你的工作交付是心裡有底的,專案也是一樣,你必須把新加入的、未完成的工作項重新估算並規劃,拉出你專案調整後的時程與成本,讓你的專案再次回到軌道上,也讓sponsor與專案成員對於專案時程有個清楚的認知。
為重規劃作準備(Plan to Re-plan)
專案的重規劃,一般有兩個可以識別的時機:(1)當專案的績效已經脫離預估太多時,(2)當專案突然會有較大規模的變動,無法以變更管理(Change Control)的程序解決時,專案經理應該啟動重規劃的動作,但準則為何呢?一般我們會在專案啟動前先規劃好重規劃的標準。
當專案的狀況滿足該標準時,就必須要重新規劃,例如以我帶領的專案來說,我們會設定若SPI/CPI<0.8或SPI/CPI>1.2的狀況下要作重新規劃,這樣設定的原因是為了確保後續專案的狀況是健康的,且能符合實際的狀況,在重新規劃前會先經過變更管理的會議,取得共識後開始進行重規劃,並在新的計畫完成後知會專案成員與sponsor更新後的基準。
看到這邊其實我們應該對重規劃有個正確的認知,重規劃並非一項不可赦免的大罪,也不見得代表專案經理作的不好,它是一個專案應變的動作,重規劃不是問題,不斷的重規劃才是問題。
變更管理與重規劃
專案的重規劃某種程度很類似專案的變更管理,不同的是重規劃一般是在專案滿足重規劃準則時才會被執行,並且會對整個專案的計畫作重新的調整,但變更管理則是屬於專案執行過程中一定會發生的正常現象,我們面對這兩者的心態應該是不同的,我在執行專案時習慣依以下的方式來決定是要進行變更管理還是直接進入重規劃階段,決策點只有一個-是否滿足重規劃原則。
當一個專案被規劃好,並開始執行後,一般都會碰到變更,這個變更可能只是一個小功能的增修,也可能是一個批量的功能新增,我們都會先進行變更的程序,先評估必要性與影響性,若影響時程、成本較大,已經超過重規劃原則(SPI/CPI<0.8, >1.2),則進入重規劃,否則則以一般變更管理的程序處理。
以正確的心態面對重規劃
其實專案規劃失準的原因非常多,估算不準確、需求不清楚、範疇蔓延、人員的異動、不當的變更管理等等,可能都會導致專案在執行過程中才發現與原先的預估落差較大,這時候專案經理就應該適時的進行重規劃,重規劃並不見得是因為你專案控管不佳,即便是,身為專案經理你也應該勇於對你的主管,你的sponsor負責,給他們一個更準確、更可預估的專案計畫,若你的專案已經偏離軌道太多了,就試著重規劃吧。
gipi提到:
甲專案一開始估算的工作量與工期為A,但做到一半後才發現需求收集不完整,趕緊又將新的需求納入專案中,導致專案的工作量與工期變成B,而專案完成度也從本來的60%降到了40%,SPI也從本來的0.95降到了0.7,整個專案的一直到結案的績效表現都很不好,即便專案完成了,但帳面的數字還是...(恕刪)
專案目標訂定太整體太后段都是一種折磨:
專案系統工具熟練度 是一種指標
專案系統架構完成度 是一種指標
專案流程資料完整度 是一種指標
這些沒學過管理會計的專案經理
也要知道管理就是分類揪出問題
少個欄位沒規劃進來 是制度分析師的問題
專案不分責任範圍 就是沒能力管理的專案