2013年11月29日 星期五

管理其實也可以很easy--PMP沒有教的專案管理 16 任務分派


       任務分配要考慮哪些問題?有甚麼重點?任務分配有幾個重點,其分別為:

         1. 受派任者的能力是否足以勝任此任務

         2. 完成此一任務必須具備哪些籌碼

         3. 受派者的工作態度與做事方法

        從資源調查過程,應該事先確定專案進行需要具備哪些能力,同時也該調查有哪些資源可用。(哪些人,具備哪些能力,本身還有多少工時可用)當然如果採取的專案模式是單一專案的話,每個成員被賦於單一的任務,那倒簡單,因為整個工時都用在單一專案上,只要考慮能力與知識的要素即可。但現況幾乎在人力極度缺乏的狀況下,特別是工程師的總體人力不足是世界性的問題。如果要讓一位工程師只負擔一個專案,幾乎不可能,多專案管理的現象已是不可避免的選擇。此時如果不考慮每個人的負荷與工時的利用情況,那影響到的不是一個專案而已,而是一卡車的問題,所有的專案都可能因此受到骨牌效應,受到牽連。所以在多專案管理的現實考量上,每個成員的工時管理必須謹慎與務實一點。

        專案的資源配置,還存在一個問題,每個成員都有其人格特質,能力與工作方法也不盡相同。如何適才適所,也是PM不能忽略的重要工作。PM應該在任務分配之前,多方了解每個成員的能力與工作習慣,花點時間與成員面談常是最直接的方法,透過向成員的主管請益,更是最好的方法。依據對成員的喜好與能力的了解,在任務配置的過程,比較能夠做到用最佳的人打最難打的仗。有時工作分配也會受到很多現實的牽絆,例如:成員主管的管理風格、成員的工作態度、其他專案的進度與公司的企業文化等等。如果有這些問題存在的話,PM就必須花更多一點時間,研究一下這些問題對專案的可能影響有多大,必要的時候恐怕要調動更高層級的主管給于事前的指導與協調。

        當任務分配完後,成員必須立即著手業務規格的製作。何謂業務規格?從WBS展開的每件任務,接受任務的成員,將任務的規格製作出來,以再次確認及掌握每件任務的關聯網路。業務規格書應該包含以下的幾個內容:

        1. 專案名稱及編號:這是一個專案的基本資料,應該不會是問題,但為了方便未來的K/M(Knowledge Management)的應用,還是要依步驟來。

        2. 業務名稱與編號:指被分配的任務(Task)的內容,譬如:概念提出,C002等。

        3. 業務的上、下游:這個業務的上游作業與下游作業,這些是網路規劃的重要依據,也是未來控管上很重要的資訊。

        4. 業務的主要輸入(Input):這個業務有甚麼必要的輸入資訊,才能夠完成任務。如上項的概念提案的輸入就包括專案目標、目標市場、對象客戶、競爭資訊、技術盤點資料等等。

        5. 業務的主要內容(Process):此業務的主要工作內容,譬如:針對上述的概念提出要做市場調查、規格研讀、資料收集、概念形成、概念評估及概念選擇等等。

        6. 業務遂行上的必要前提條件(Issue or Assumption):要順利完成此業務有沒有一些前提條件?如果有的話,這些前提條件必須在何時、如何結合進來。

        7. 業務的產出(Output):這個業務完成後,會出現何種類型的產出。每個業務都會有產出,包括有形與無形的,但可能有不同的面貌。每個成員應該以專業的角度,提出自己的產出物。而下游單位的人,也可以依此判斷是否足夠,如果不夠,那還需要互相間再多加討論。此部分的資訊很重要,也是PM在日常管理上,要能做到不遲延的一個必要手段。讓每個成員懂得自主管理,才是專案管理成敗的關鍵。如果以上述Task的案子來說,專案概念提案書或許就是一個最直接的產出,但背後或許還有一些其他的模型或是資訊等等的產出物。

        8. 業務完成的判斷基準:這個業務做到何種程度可以判斷結案的依據。此部分也是PM對於不熟悉的領域,日常管理上的重點。對於成員提出的資訊如果不夠清楚,代表某些程度成員對自己的業務都還不夠純熟。這時就該拿這份資料去跟成員的主管請教,聽聽專家的看法,同時請主管給于成員一些指導,這也是OJT的一環。

        此部份的工作量很大,但卻很重要。要確實掌握每個Task的上、下游關係,輸入、作業與產出,如果此工作沒做好,那專案的管控就很難做到日常管理了,只能做到以專案會議的方式,進行定期的追蹤與管控。問題是當任何一個環節只要出現問題,專案就開是進入負面循環的現象了,事前管理才是讓專案不遲延的最佳手段。
        今天就暫時談到此,後續。

管理其實也可以很easy--PMP沒有教的專案管理 15 任務分派


        休息了一下子,跑到別個主題去了幾天,接下來就來談談專案的任務分配。有人是否會懷疑,怎麼不一口氣把專案管理系列談完,中間還岔了題。其實這就是專案管理常有的現象。在專案進行的過程中,有時會有一些時代性的話題,或是比較上有時間性的工作,會讓專案的資源被吸引過去,而造成與原計畫不一致的現象。這也是專案管理的一部分,突發事件。雖然理想上不希望專案有突發事件的出現,但如果能夠那麼的精準預估的話,這個專案要不就是資源太充裕,要不就是主題太單純了。

        專案的任務分派,是專案資源配置的主要步驟,也是專案計畫過程,讓資源效率極大化的步驟,不得不謹慎為之。因為一旦進入到專案執行的階段,才發覺到資源配置不足,整個專案的進行將會受到很大的影響,結果也將難以預料。

        任務分派,延續上個步驟的WBS展開與工時評估,估算出整個專案所需花費的資源,接下來當然就是要尋找完成任務所必須具備的能力與人力。再來規劃如何投入?何時投入?任務分派涵蓋幾個領域,其分別為:網路建置(CPMCritical Path MethodPERTProgrammer Evaluation and Review Technique)、能力評估及人力評估、任務與職掌(R & RResources & Responsibility)。今天我們把重點先擺在R&R的部分,至於CPMPERT部分留待下回再談。

        專案的資源計畫,在此階段也有兩種不同的規劃模式。一種是以既有的人力,來展開網路布局,此種作法,往往會出現時間拖長,應付不了市場所需的困境(TTMTime To Market);另外一種作法是以專案的任務與目標為基礎,從專案的目標結束時間點,往前推算,籌措需要投入的資源。此種作法的好處是能夠滿足專案的價值所在,做到TTM的目標,但也可能會因此產生現況資源不足的現象。

        兩種模式看起來總投入資源好像都是一樣的,但其實專案的時間卻有很大的不同。理論上既然採取專案管理模式,理應採取後者的作法,才比較符合專案的精神,但現實上,很多的企業都是採取前者的做法,基本的原因就是資源有限。管理沒有對錯,只看有效與否。如果只看效率,或許就是一般常說的,把事情做好(Do The Thing Right ),但回歸到專案管理的基礎面時,思考一下,為何需要專案管理,無非就是組織面對各種現實的經營壓力需求,嘗試錯誤帶來的經營風險,恐會讓企業陷入經營危機,不能夠再以嘗試錯誤的方式來應變,只能做到一次就做對的思維來預變。傳統金字塔式的組織結構無法滿足現況彈性與效能需求,才會借重專案管理的模式來進行非常態的任務。因之,專案管理必須要具備做對的事(Do The Right Thing)的觀念,才能突顯其貢獻價值。所以任務與目標才是重點,資源多寡是策略考量的方向。

        那要如何規劃?接下來就來談談資源規劃與任務分派的作法。任務分派與資源配置是互動的規劃作業。資源少的時候,每個人分派的任務自然會增加;資源充裕的時候,每個人分派的任務量相對比較少,(這就是俗話說的:用時間換取金錢,還是用金錢換取時間的概念)所以首先要進行資源與任務調查。任務調查透過WBS展開後,只要製作出一張矩陣表,以WBS展出來的工作項目(Task)為縱軸,需要的技能為橫軸,可以再加上一個需要的負荷量(工時)Y軸,構成一個Y行矩陣表(三次元矩陣)的話,那就更方便評估了。

        這部份的工作在東西方的專案運作上,也存在很大的差異。西方的PM(專案經理人)得以依據獲得的授權,自己去找尋具備完成任務上必要技能的成員。西方人的觀點很簡單,專案的成敗是PM最重要的責任,所以PM必須自己去解決資源上的問題,經營者的責任是決定GO/NG與給預算。相對的經營者對專案也不會去多干預,因為花錢請一位PM是來幫助企業完成專案任務的,而不是請一位來聽您指揮的助手,經營者只要關注結果與資源的價值就夠了,管理的問題是PM的權責。但在東方這個邏輯是行不通的,聽命行事與和為貴的儒家文化思想,讓經營者與PM的關係變得很微妙。經營者喜歡給于建議(但他絕對不會查覺,其實等於是他直接在管理),培養出來的PM也都有志難伸。至於資源的尋找,往往是以現有隊伍中,調出一些人馬來應付。至於這些人的能力、技巧、與負荷是否足以勘任專案的責任,似乎的不是重點。想像的到,東方的PM辛苦多了,成了有責無權的協調人,真正的PM的任務,反落在經營者身上。

        資源調查要調查三方面,一為知識(Knowledge),一為能力(Skill),一為負荷(Loading)。知識是完成專案任務的首要資源要素,當分析出來需要一位懂電子工程的工程師,公司給三位機構工程師是無濟於事的。但除了知識的需求外,能力也是不可忽略的要素。試想丟給你一位學校剛畢業,一點工作經驗都沒有的工程師,他能負擔的任務就必須打折扣,否則將影響到整個專案的銜接。至於負荷更不能等閒視之。一位手頭上已負責60%的業務量的工程師,如果你還以100%的工作量來要求他,結果可想而知。這三個要素是相乘效果,而非相加效果。
        今天不仿就先談到此,明天待續。

管理其實也可以很easy--PMP沒有教的專案管理 14 工時評估


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

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

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

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

2013年11月28日 星期四

管理其實也可以很easy--PMP沒有教的專案管理 13 工時評估-II


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

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

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

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

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

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

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

管理其實也可以很easy--PMP沒有教的專案管理 12 工時評估


        上次我們談過了專案的WBS展開,這是一個最基礎,卻很重要的工作。孫子兵法始計篇有這麼一段:「夫未戰而廟算勝者,得算多也;未戰而廟算不勝者,得算少也;多算勝,少算不勝,而況乎無算乎?吾以此觀之,勝負見矣。」這段話的大意是這樣的:作戰前,有充分的做好計畫者,勝算就大,因為充分的掌握了整個作戰必勝的條件,可以在資源的配置上做最佳的調適。反之,沒有充分的做好事前的準備,走一步算一步的作戰方法,必定是輸的成分多。因為連必要的條件都未能掌握,當然無法有效的運用有限的資源,失敗是必然的。

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

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

        天:當任務與目標明確後,專案也必須充分的掌握大環境的條件。以新產品來說,如果不看競爭與市場,規劃出來的,往往都只是一個失敗的產品。要不就是欠缺競爭的條件;要不就是曲高和寡,與市場脫節,如此產品奢談成功。(此部分也就是一般通用的SWOT工具的OT)

        地:大環境很重要,但本身的條件也不可忽略。資源、能力、技術、時間限制等等,都必須充分掌握,才可能做到最佳的資源配置。(此部分就是SWOT工具的SW)

        將:一個好的專案管哩,專案經理人是關鍵靈魂人物。常見的管理專案與專案管理的差異就在這個角色。管理專案並不見得有一個明確的專案主管,隨著里程碑的進行,專案負責人是由一個機能移轉到另一個機能,專案的目標被切割成為機能目標,所有的機能主管只負責機能的目標,整體的專案目標反而被忽略了,因為沒有任負責,總經理常成為唯一的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是否展得夠充分,手頭上是否有足夠的數據來進行客觀的評估,才是關鍵因素。今天先談到此,明天待續。

管理其實也可以很easy--PMP沒有教的專案管理 11 專案規劃


        今天在外面上課,剛巧碰到學員問到有關專案管理的一些狀況,更巧的這位學員碰到的問題就是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)索取。