管理其實也可以很Easy--專案管理與孫子兵法(14)

專案的工時評估III(2024-5-15)

上次談到工時評估的一些重點，有人問到：「為何工時評估這麼重要？有何用處？」這是一個最基本也是一個很實際的問題。很多人對工時評估的重要性不清楚，結果做了一堆的計畫，卻看不到資源與進度的一些基礎數字，這種專案要成功，自然不易。

工時評估最重要的是要知道一個專案需要花費多少資源，在目標時間內要完成的話，資源該如何配置。如果這些數據都沒有，那專案的規劃，就只好以瞎貓子碰到死老鼠，靠運氣了。

工時評估還有一項更重要的任務，是網路建構。每個工作項目間，如何連結形成一個最有效的網路規劃，是專案成功的重點工作。哪些項目是屬於上下游關係，那些是可以同步進行，如何安排可以讓專案的資源更有效率，工時是這個規畫的主要參考依據。因為有工時的數據，才可能找出關鍵要徑(CPM：Critical Path Management)。專案的時間受到擠壓，有限的資源下，面臨到必須調整資源的配置時，也必須有足夠的工時數據來支撐決策，否則只看到不斷的Delay，卻無法做出有效的變動管理，專案管理的意義將消失殆盡。

工時評估與管理這麼重要，那為何很多的單位卻不是很重視？不知道是一種現象，不會做也是另外一種現象。小企業小貓兩三隻，工時評估根本不需要，因為都是一個人當三個用。但當一個比較具規模的專案運作，如果還是運用土法煉鋼的方式來管理，那代價就無法估計了。高鐵遲延一年的代價有多少，簡單只算到利息就是約要120億台幣。專案的機會成本是難以衡量的一個指標，但絕對是很可怕的。如何做好工時評估，為企業運作專案上，必須面對的管理課題。

下次我們繼續談談專案的資源配置與任務分派。

管理其實也可以很Easy--專案管理與孫子兵法(13)

工時評估II（2024-5-15）

上期我們談到工時評估，這是一個基礎工程，專案資源配置的良窳，都決定於此一步驟。雖然工時評估不是一個很難的技巧，但要做好卻也非易事。今天就來談談工時評估必須注意的事項。

如果平常沒有實施工時管理的單位，那工時評估的基礎根本就不存在，做出來的工時預估，常常都只是片段與印象的數據。這樣的數據來預估所需資源，風險之大，恐難預料。國內企業普遍沒有做工時管理的習慣，特別是研發部門。一般總認為研發的工作成果與時間沒有直接的關係，反正就是做到好為止(上班打卡制，下班責任制)，其實這是一個挺嚴重的問題。

研發是組織裡的稀有資源，應該好好管理與珍惜。常見的誤解是對工程師實施工時管理的話，工程師會認為被監視，認為工時管理是製造現場才必要做的管理。其實工程師做好工時管理，除了可以了解資源的效率外，還可以藉此發覺系統上的一些缺失，針對這些缺失，加以改進，達到持續改善的永續經營。如果各位有興趣的話，不妨請教一下研發主管，工程師的效率有多高？相信大部分的研發主管答不上來，有的話也是很籠統的「不太好，很忙…」幾個字打發過去。

個人輔導過很多企業，一個不是很正式的統計，國內研發單位的效率其實還不到30%。(效率指的是用在研究開發、創意行工作的直接工時)工程師被太多的雜務與間接工作給伴住了，加班成了司空見慣的常態，也沒有人真正的深入去探究。

如果將工程師的工時依「緊迫度」與「重要度」兩個指標來看，工時可以畫分為四種型態。一為既緊迫又重要(HH)；二為緊迫但不重要(HL)；三為不緊迫但卻很重要(LH)；四為不緊迫也不重要(LL)。不知您有沒有思考過，這四個象限的工時分配如何。大部分的公司最多的並非HH，而是HL。也就是對工程師而言，不是很重要，但卻十萬火急。這種工時就是典型的間接或是無效工時（譬如：產線出問題的支持）。如果一個工程師的HH太多，通常是組織資源規劃出了問題，或是個人能力不足；如果是HL時間太多，那大概都是系統與管理上的問題；相對的如果LH太多，可能勞役不均或是工作太鬆了；至於很多人都認為LL應該避免出現才對啊！其實LL是必要的。因為人際關係、成長、寫報告、教育訓練等等，都必須用到這部分的工時。

如果這部分的工時評估沒有做，那就會出現評估出來的工時，到底是屬於工作工時還是日曆工時的問題。工作工時指的是做一件事情需要花多少時間，屬於直接的任務工時。但工時還應該涵蓋游離工時、移動工時、與等待等無效工時。這些都加進來後，才是實際的日曆工時。各位看官不知是否還有印象，以前建築工地管理都是採取以工作天數來控制工程進度，現在幾乎都以日曆天數來管理，主要的原因就是任務工時無法很精確的反應到管控的需要，爭議性高，所以改為日曆工時管理。

另外，工時評估的時候，會牽涉到一個人同時負責多專案的現象，這時的工時評估將更複雜。首先每個成員如果對自己的工時掌握度不夠，連自己已接了多少工作都還不清楚，對新專案只能承受，沒有任何的討論，那執行下去，資源衝突的現象，自無可避免。每個成員對自己的工作負荷的掌握，主管與PM對成員的能力與負荷資訊，是否都已確實掌握，是工時評估的另一個嚴重的問題。

未完，待續！

管理其實也可以很easy--專案管理與孫子兵法(12)

專案的工時評估（2024-5-15）

上次我們談過了專案的WBS展開，這是一個最基礎，卻很重要的工作。孫子兵法始計篇有這麼一段：「夫未戰而廟算＊1勝者，得算多也；未戰而廟算不勝者，得算少也；多算勝，少算不勝，而況乎無算乎？吾以此觀之，勝負見矣。」這段話的大意是這樣的：作戰前，有充分的做好計畫者，勝算就大，因為充分的掌握了整個作戰必勝的條件，可以在資源的配置上做最佳的調適。反之，沒有充分的做好事前的準備，走一步算一步的作戰方法，必定是輸的成分多。因為連必要的條件都未能掌握，當然無法有效的運用有限的資源，失敗是必然的。「整合自己的兵力，了解對方的底細，根據戰時的地形，制定不同的戰法，並且能夠推演出，戰事過程中的各種可能性，這就是最基本的用兵之道」。

把這段話用在專案管理，專案規劃的重要性顯而易見。而要掌握哪些條件？從經之以五事談起，「道」、「天」、「地」、「將」、「法」，為專案致勝的基本要件。簡單再複習一下這五事：

道：專案的任務，目標與範疇。簡而言之，為何需要這個專案？其存在的價值是甚麼？有何目的非做這個專案不可？了解了一個任務的價值後，才能建構一個讓所有成員願意同心協力的共識。知道為何而戰？是專案管理很重要的要務，否則把一堆各種不同機能的人結合在一起，執行一件跨機能的任務，山頭主義將會是專案失敗的主因。

天：當任務與目標明確後，專案也必須充分的掌握大環境的條件。以新產品來說，如果不看競爭與市場，規劃出來的，往往都只是一個自戀產品，往往以失敗收場。要不就是欠缺競爭的條件；要不就是曲高和寡，與市場脫節，如此產品奢談成功。(此部分也就是一般戰略展開通用的工具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是否展得夠充分，手頭上是否有足夠的數據來進行客觀的評估，才是關鍵因素。今天先談到此，明天待續。

*1、廟算：古人遇有大事，或是打仗前，集合重要關鍵人物，到廟堂算計、算計，以做出最佳決策，謂之廟算耶！當然廟算是以戰略為主，WBS則是戰術之一環，支撐糧草的準備與兵力的部署，是計畫的基礎。

管理其實也可以很Easy--專案管理與孫子兵法(11)

專案規劃(IV)

今天在外面上課，剛巧碰到學員問到有關專案管理的一些狀況，更巧的這位學員碰到的問題就是WBS的一些困擾，了解了一下現況，發覺到並沒有甚麼新鮮事，是一般專案管裡常見的問題。我們就接著來談談WBS的重要性與如何應用。

WBS是一個工具，是為了能夠讓任務分派與工時評估科學化的一個步驟。很多人都會說，以往從來沒有聽過與用過WBS之類的工具，公司不還是這樣走過來了。經驗是很可貴的資源，但如何讓經驗不會成為陷阱，及更有效的發揮其價值，是管理的重點目標。如何以更有效的方法，做更多的事，是突破競爭的必要思考。

那WBS究竟有何用途，接下來就來談談。WBS主要是把任務分解，一個專案或是一個任務，題目都很大，大到有時很難掌握到管理的節點。譬如：機構設計，是一個任務，但卻無從管理起，因為機構設計包含了很多的工作在裡面。如果沒有再細分化的話，就看不到進度管理的影子。

把機構設計再往下分解，可以分解出規格確認、資料蒐集、構思、成本評估、技術評估、實驗與測試、草案設計、參數確認、制圖、審圖、出圖等等的細部作業項目。

當把機構設計分解成上述的幾個步驟後，以這幾個步驟來評估工時，是不是比直接評估機構設計的工時來得精準與容易？也就是說，工作項目展的越細，工時評估就越容易與精確，在評估資源的投入與任務分派的過程，也越形明確。因為以機構設計這樣一個大任務來分配工作，勢必很難科學的將工作量與每個人的負荷連結，那就容易出現多人喝水沒水喝的現象。另外，如果WBS展開的作業細項，越接近日常的工作項目，就越容易與日常管理結合，也就越能夠掌握到進度的進行軌跡。

另外WBS還有一個一般常被忽略的好處，一堆不同領域的人在一起，要處理一件並不熟悉任務，很多成員甚至不知道別人在做甚麼、他領域的工作流程與內容。經過WBS分解的過程，就是一個最好的互相學習機會。這點也就是專案管理被認為是學習型組織的原因之一。

如果一個專案裡面有很多的新人，對專案任務的業務並不熟悉，透過WBS的展開，其實也就是一個最好的OJT(On Job Training)。再說，由於以團隊的腦力激盪，展開WBS工作分解，也是建立共識的重要手法。

當然WBS除了上述的任務外，最重要的是要建構一個專案的業務網路。如果沒有細部化的業務分解，所有的專案時程就只會看到里程碑而已，而無法看到互相業務的聯結，自然運作起來，就很容易出現兄弟登山，各自努力的山頭主義，看不到團隊合作的運作模式，專案的價值就難以顯現。

那WBS應該包含哪些部分才算完成？大致上WBS應該含蓋以下的幾個項目：(此部分建議把它化成一個表格的話，可以做為公司內部專案管理的一個標準化表格)

1. 任務描述

2. 投入資源

3. 業務產出

4. 業務規格

5. 需要工時

6. 預估成本

7. 上游業務

8. 下游業務

明天我們就來談談工時評估，待續！(個人有建立一套專案管理的表格，如果有需要的話，麻煩來信(email)索取。

管理其實也可以很Easy--專案管理與孫子兵法(10)

專案規劃(III)

        進入到專案的How many規畫時，會用到幾個重要的工具，諸如：WBS(Work Breakdown Structure)、工時評估（此部分應該是國內最被輕忽的一個步驟，大部分的公司或是PM不懂工時管理的意義重要度）、網路規劃(CPM or PERT、甘特圖等)、能力（能力不等於人力）及負荷評估(R & R：Resource and Responsibility)及風險管理等。這個部份計畫品質與專案的控管的連結度最高，幾乎決定了專案運行的方向與命運，有必要仔細的來談談。

        首先是WBS的展開：WBS是一種系統圖，主要是將一個複雜的專案任務，依層次分解到最低層的作業，再以最低層的作業，評估所需要的工作時間，掌握專案的需要工時，再以這些作業來排定整個專案的進行程序。以新產品開發專案來舉例，WBS的展開如下：

        1.0 商品企劃：

               1.1 專案戰略分析

                      1.1.1 資訊收集

                      1.1.2 戰略規劃共識營

                      1.1.3 戰略思考架構提案

               1.2 競爭分析

                      1.2.1 競爭對手定義

                      1.2.2 材料收集

                      1.2.3 規格與優缺點分析

                      1.2.4 產品使用性能分析

                      1.2.5 SWOT分析

               1.3 事業戰略規劃

                      1.3.1 產品組合確認

                      1.3.2 市場規模評估

                      1.3.3 市場戰略與事業性規畫

        2.0 產品企劃：

               2.1 市場調查

                        2.1.1 產品戰略確定

          2.1.1.1 產品行銷4P戰略

          2.1.1.2 產品損益評估

          2.1.1.3 產品事業性定案

                        2.1.2 需求探索

                                  2.1.2.1 問卷設計

                                  2.1.2.2 目標市場與客戶定義

                                  2.1.2.3 市場調查

                                  2.1.2.4 需求整理

                2.2 VOC(Voice Of Customer)確認

    2.2.1 QFD展開

    2.2.2 VOE展開

    2.2.3 產品概念與賣點

    2.2.4 產品規格訂定

                2.3 產品品質計畫

    2.3.1 產品品質戰略

    2.3.2 產品品質目標訂定

    2.3.3 FMEA展開

    2.3.4 產品品質保證驗證計畫

2.3.4.1 DVT驗證計畫

2.3.4.1.1 樣品組裝

2.3.4.1.2 機能測試

2.3.4.1.3 安全試驗

2.3.4.1.4 環境測試

2.3.4.1.5 可靠性測試

2.3.4.1.6 物流性測試及操作性測試

2.3.4.2 QAT驗證計畫

2.3.4.3 LCA驗證計畫

2.3.4.4 售後服務體制建制

        3.0 技術設計構思(可行性設計)：

                3.1 技術構思：

                        3.1.1 文獻調查(技術資料、IP、論文、技術情報等）

                        3.1.2 TAP: Technical Action Plan展開

                        3.1.3 技術實驗

                        3.1.4 驗證與DR

                3.2 可行性設計(Feasibility design)：

                        3.2.1 DVT(Design Verification Test)

                        3.2.2 DR &移行判斷

        4.0 工程設計：

        5.0 量產設計：

        6.0 量產準備：

        7.0 量產行銷：

        8.0 市場撤退：

        由於篇幅關係，只簡單舉個例子。上面的從1.0~7.0為第一階，1.1、2.2為第二階，2.1.1為第三階，2.1.2.4則為第四階。如此一層一層展開，直展到每個作業的最基本元素。

        這樣展開WBS的好處在哪裡？為何如此重要？且待下回聽曉。