上次我們談過了專案的WBS展開，這是一個最基礎，卻很重要的工作。孫子兵法始計篇有這麼一段：「夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也；多算勝，少算不勝，而況乎無算乎？吾以此觀之，勝負見矣。」這段話的大意是這樣的：作戰前，有充分的做好計畫者，勝算就大，因為充分的掌握了整個作戰必勝的條件，可以在資源的配置上做最佳的調適。反之，沒有充分的做好事前的準備，走一步算一步的作戰方法，必定是輸的成分多。因為連必要的條件都未能掌握，當然無法有效的運用有限的資源，失敗是必然的。
把這段話用在專案管理，專案規劃的重要性顯而易見。而要掌握哪些條件？從經之以五事來談，「道」、「天」、「地」、「將」、「法」，為專案致勝的基本要件。簡單再複習一下這五事，為：
道：專案的任務，目標與範疇。簡而言之，為何需要這個專案？其存在的價值是甚麼？有何目的非做這個專案不可？了解了一個任務的價值後，才能建構一個讓所有成員願意同心協力的共識。知道為何而戰？是專案管理很重要的要務，否則把一堆各種不同機能的人結合在一起，執行一件跨機能的任務，山頭主義將會是專案失敗的主因。
天：當任務與目標明確後，專案也必須充分的掌握大環境的條件。以新產品來說，如果不看競爭與市場，規劃出來的，往往都只是一個失敗的產品。要不就是欠缺競爭的條件；要不就是曲高和寡，與市場脫節，如此產品奢談成功。(此部分也就是一般通用的SWOT工具的O與T)
地：大環境很重要，但本身的條件也不可忽略。資源、能力、技術、時間限制等等，都必須充分掌握，才可能做到最佳的資源配置。(此部分就是SWOT工具的S與W)
將：一個好的專案管哩，專案經理人是關鍵靈魂人物。常見的管理專案與專案管理的差異就在這個角色。管理專案並不見得有一個明確的專案主管，隨著里程碑的進行，專案負責人是由一個機能移轉到另一個機能，專案的目標被切割成為機能目標，所有的機能主管只負責機能的目標，整體的專案目標反而被忽略了，因為沒有任負責，總經理常成為唯一的PM。但專案管理的PM是必須負責整個專案的成敗的主角，所以必須具備高於一般的管理才能才得以完成使命。將才必須具備智、信、仁、勇、嚴等要件。此部分等我們談到專案經理的成功要件時，再來詳談。
法：一個好的專案管哩，不只是人的因素，一個能夠讓上下都能依循的系統也是必要的，否則將會因人而異，出現各自耍花找的怪現象。這部分包含組織的運作，有一陣子很流行矩陣式管理，很多的企業在導入矩陣式管理後，發覺到問題重重，最後大都又回歸到功能式的管理架構，當然問題並沒有解決，只是被掩蓋掉了而已。還有專案的指揮系統(都是雙重指揮)、職責與權限、管理制度與流程等等。
專案管理WBS展開的就是屬於經之以五事所談的「地」的部分。從任務與範疇的展開，清楚掌握達成任務範疇所需要的資源，再依此需求評估本身可能投入的資源，才可能做出最好的規劃。譬如說：有個任務需要投入60個人月的資源，而公司只能投入六個人在這個專案上，那意味著這個專案需要花十個月的時間來完成。但如果市場傳過來的訊息是必須在六個月內完成，那是否必須投入十個人才有可能完成任務？甚至公司也沒有那麼多人，又必須在六個月內完成，如果都不考慮其他因素，是否代表是一個不可能的任務？這時候策略思考就益形重要。而要知道需要花多少資源，就必須從要做多少事談起，那就是WBS的重點。但多少事只是工作的項目，要花多少時間，則必須做好工時評估。顯而易見的工時評估的重要性也不言可喻。
那接下來就來談談工時評估的部分。相信很多人都有這樣的經驗，同樣類型的產品開發專案已做過了很多遍，但因為過程中有很多的不順利，所以都以推遲收場。有趣的是，當下一個案子出現的時候，在工時規劃的部分，還是依樣畫葫蘆，甚至還增加了時間(籌碼)來應付以前出現過的問題處理。如果是以這樣的思維來規劃專案，那是否代表專案都沒有學習曲線效果(Lesson learning)的存在？這種土法煉鋼的管理，普遍存在國內的企業，也司空見慣，見怪不怪了。其實這些現象都是沒有做好WBS及工時評估的結果，如何做好一個可行又能贏的規劃，是專案管理成功的關鍵要項之一，不得等閒置之。
常見的工時評估有兩種模式：一為目前專案管理(PMBOK)所用的方法，也見諸於專案軟體(Microsoft Project)裡。是以經驗法則為基礎，輔以對各個項目的風險毛估，以樂觀、悲觀與正常工時三種程度來評估。譬如說，有個任務是製圖工作，正常工時評估需要一個工作天，如果樂觀判斷的話0.5個工作天就夠了，但考慮一些因素，悲觀的話則可能會拖到1.5個工作天。那這個工作的需要工時就是(樂觀 + 普通 X 4 + 悲觀) / 6，得到的數字就是製圖工作所需的工時。這種評估方法是以統計為基礎，加上經驗法則，本來應該很客觀，但如果專案成員的經驗差異很大，或者根本沒有數據來支撐，很可能會出現漫天灌水的怪現象，那專案就沒完沒了了。
另一種評估的方式是以變數來評估。還是以上個作業製圖來說，在這個專案裡，製圖這個工作執行上，有可能出現哪些變數，把這些變數評估一下，再統合考量需要的工時。譬如：這種類型的專案已執行過好幾個了，所以有某些程度的經驗曲線效果，這個部分工時只要用80%就夠了；但這次的新專案策略上為了Cost down，採取了一些新的部件，這些部件需要花點時間找資料，所以需要加5%的工時；另外因為有部分新的工程師加進來，默契與對流程的認識都不夠，所以需要再加5%的工時來做OJT。所以所需的工時 = 經驗工時 X 80% X 105% X 105%。這種工時評估的好處是考慮到變數對業務的影響，但重點是要評估變數本身就是一個經驗變數。兩種方法都有人在用，不知您喜歡哪一種？
工時評估本身並不難，問題是WBS是否展得夠充分，手頭上是否有足夠的數據來進行客觀的評估，才是關鍵因素。今天先談到此，明天待續。
沒有留言:
張貼留言