| 發表者 |
討論內容 |
冷日
(冷日) |
發表時間：2008/3/17 5:41 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [轉貼]你的專案管理管對關鍵嗎?
| 你的專案管理管對關鍵嗎? | 文/ iThome (記者)2006-04-17
| 隨著專案管理的風潮襲來，企業端的營運部門的管理階層逐漸意識到其重要性；而個人端的認證取得，也有將近100％的成長，然而，在走向專案管理的過程中，究竟有哪些環節需要重視，我們試圖從組織型態、專案經理以及方法論等多個角度進一步探討其中奧妙。
| | 走向專案型組織，首重定位
目前專案管理在臺灣市場的發展，雖然已經從狹隘的工具應用導向，轉變成為專案管理流程的骨幹，但是，整體的發展態勢還在緩慢轉型過程中，事實上，從企業的組織型態來看，臺灣大多數的企業，仍舊屬於功能性的組織型態，只有少數的企業已經轉型成專案型態的組織架構，而在轉型的過程中，專案管理辦公室的定位與策略相當重要，否則也會導致專案協調與資源調度的功能無法發揮。
專案經理人的領導魅力重於一切
一般來說，專案經理在專案團隊之中，雖然不一定是技術領域的佼佼者，但絕對是整合專案團隊的靈魂人物，一方面必須激發團隊的工作熱情，另一方面又必須要精準掌控專案進度，而不至於陷入技術導向的迷思中，在這樣的前提下，如何把對的人，放在對的位置上，對於專案經理人來說，不僅是「識人能力」的考驗，同時也突顯了「用人能力」。
為結案而管理，還是為專案而管理？
外在商業環境所帶來的「複雜」與「變動」使企業在專案上面對更多的挑戰，這也是現今企業專案的本質。專案管理並非萬能，可將複雜轉變為簡單，將變動轉變成穩定，而專案經理也不應該像個醫生，為注定失敗的專案帶來醫治的良方，如此一來就演變成「頭痛醫頭，腳痛醫腳」的庸醫。專案經理應該像是健康顧問，時時關心專案的健康程度，適時地提醒，也就是預防重於治療，不是在專案失控後才冒出來善後。
系統思考力為專案帶來整體觀
專案以團隊的合作力量執行時，各成員緊密互動，但只有專案經理能站在團隊整體以上的巨觀角度，時時檢視潛在的問題。此時，專案經理必須具備「系統思考」的客觀能力，以免產生緩慢漸變且不易察覺的複雜問題。一般專案經理會以片段的解決方法處理團隊互動下的問題，但卻越治越糟，也就是我們俗稱的治標而不治本。
專案管理究竟教了我們什麼？
專案管理課程適合每位企業成員共同學習，因為它的定位不應該是培養專案經理，而是傳授單純的專案執行技巧。從課程層面來看，它的內容是專業與科學，但不是管理，也不是專案「管理」，企業不應對專案管理課程有過多的期望。此外，人們也勿以為學習專案管理課程後，就足以擔任專案經理。
專案管理知識體系，越來越重視專案管理風險結構分析
專案管理知識體系2004版中，針對風險管理新增風險分解結構（Risk Breakdown Structure；俗稱RBS），讓專案經理可以由範疇、成本、時間與品質目標中，分析各構面的風險值與衝擊程度。 |
|
|
|
|
|
冷日
(冷日) |
發表時間：2008/3/17 5:42 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [轉貼]走向專案型組織，首重定位
| 走向專案型組織，首重定位
目前專案管理在臺灣的發展已漸上軌道，而從原本的功能性組織轉換成專案型組織的過程中，專案管理辦公室的定位與策略相當重要。
計畫趕不上變化，變化永遠趕不上客戶的一通電話或是老闆的一句話，這不僅是大多數企業相互揶揄的說法，同時也是專案能力成熟度低的寫照，因為從專案管理的角度來看，所有的計畫與可能性的變化，應該都能有一定程度的掌控，如果一開始就沒有一個很好的專案規畫，根本就談不上什麼計畫的變化，所有的忙碌也只是瞎忙一場，最後可能無法如期、如質、如成本地達成目標規畫。
目前專案管理在臺灣市場的發展，雖然已經從狹隘的工具應用導向，轉變成為專案管理流程的骨幹，但是，整體的發展態勢還在緩慢轉型過程中，事實上，從企業的組織型態來看，臺灣大多數的企業，仍舊屬於功能性的組織型態，只有少數的企業已經轉型成專案型態的組織架構，而在轉型的過程中，專案管理辦公室的定位與策略相當重要，否則也會導致專案協調與資源調度的功能無法發揮。
漸進式的策略、從旁輔助的定位，增加轉型成功機率
以精業的情況來說，雖然花費了將近半年的時間構思籌畫，最後才在2005年7月正式成立「專案管理辦公室」，但卻是組織型態轉換過程中，少數成功的例子，一方面是因為專案管理辦公室決定從旁輔助的定位，另一方面則是因為專案管理辦公室所採取的漸進式策略，都減緩了與既有事業單位的直接衝突。
精業專案管理辦公室資深協理高添水娓娓道來，當初專案管理辦公室的成立，雖然是直接隸屬於總經理室之下的空降部隊，但是由於專案管理辦公室的「定位」，是從「幕僚」的角度協助各個事業群的專案管理，因此並沒有直接介入既有專案的管理，不過，只要是跨事業群的專案以及跨層級的專案，都會由專案管理辦公室負責。
高添水表示，隨著產品的生命周期越來越短，專案管理的應用會越來越重要，因為過去的開發專案，大多是以硬體為主的專案時代，開發過程不僅單純，風險也相對較低，一般的情況下，簽約就可以開香檳慶祝了，現在的開發專案則是比較複雜，除了會同時涉及軟硬體以外，甚至是多系統的整合，在這樣的情況下，專案計畫如果不好，簽約就等於是災難的開始。
值得一提的是，由於專案管理辦公室的定位，是一個協助者、幕僚者的角色，因此，專案管理辦公室成立之後的第一步，就是進行專案管理的教育訓練，並且藉此凝聚專案管理的共識，高添水表示，過去在談成本的時候，大多是指直接成本，然而從專案管理的角度來看，有沒有符合品質所產生的成本影響都必須涵括在內。目前精業的140多個專案經理中，已經有40多個人取得專案經理證照。
相較之下，忠訓國際雖然一度試圖把組織型態，從功能性組織轉變成專案型組織，但最後卻在經歷了半年的陣痛之後，宣告失敗。當初一手負責規畫、執行的康志遠，雖然已經換了東家，並且擔任宏琦科技副總經理一職，但是談起不久前的專案組織轉型過程，仍舊難掩遺憾的心情。
回想忠訓國際轉向專案組織型態的過程，雖然也是想要透過一個中央層級的協調單位，也就是專案管理辦公室（專案執行小組），來達到專案管理的目的與資源協調，進而降低人力嚴重重疊的問題，但是後來卻陷入了轉型之敗的窘境，康志遠表示，主要是因為當初的做法太過急躁，而且在求好心切的情況下，想要讓組織的轉型一步到位，結果卻出現既有人力跟不上組織調整步伐的情況。
這個過程中，忠訓國際的組織架構，其實有很大的轉變，康志遠表示，過去忠訓國際旗下總共有11個事業群，每個事業群之下都有完整的編製，其中包括財務、業務、IT、行銷等等，但是，為了因應組織架構的轉變，既有的11個事業群必須解散，進而裁撤了將近100人的重複性人力，在此同時，專案管理辦公室順勢成立，精簡編製後所剩餘的人力，再依照個人專長項目，編列到資訊處、營運處或管理處之下。
值得注意的是，專案型的組織架構，固然有它的好處，例如專案組織可以採用臨時編組的任務型態，結案後團隊成員就各自歸到原屬部門，對於企業來說，不僅可以根據專案的需求，抽取適當人力的彈性等，由於人力的重疊性降低，加上重複使用的機率增加了，因此，將能為企業大幅降低人事成本支出，以忠訓國際的經驗來說，在裁撤近100人的重複性人力之後，平均每個月雖然可以大致省下400萬元的支出，但是後來依舊是轉型失敗。
目前大多數的企業，仍以功能性組織型態為主
整體來說，一般企業的專案管理，所面對的不只是9個知識領域所涵蓋的範圍，更重要的是，企業原來的功能性組織型態與專案組織型態之間的差異，以及兩者對專案的角度不同。以成本為例，專案經理只要考量是否有足夠的專案經費以支付專案執行，但在企業經營上，卻包括所有營運成本，而專案成本只是其中的一部分。
除此之外，專案團隊如何配合企業營運，向來也是不容忽視的議題，對於專案團隊的成員來說，一方面要應付專案臨時交付的任務，另一方面還得持續原屬部門例行性的作業，在工作上是一個很大的負荷，而專案經理與部門經理如何協調人力資源，也是雙方所面臨的重大挑戰。
資策會數位教育研究所組長吳念祖表示，目前臺灣雖然仍以功能性組織掛帥，只有少部分的本土企業與外商公司，才是屬於專案型態的組織架構，不過隨著企業的營運規模日益壯大，對於企業內部的橫向資源整合需求也會跟著增加，在這樣的前提下，企業的組織架構，也會從原本的功能性組織，走向專案型態的組織架構，否則很容易出現資源重複的問題。文⊙楊惠芬
何謂專案與專案管理？
根據專案管理知識體系2004版中對專案（Project）的定義：「專案是指一種暫時性的努力，藉以創造出獨一無二的產品或服務。」換句話說，專案因為具備暫時性與獨特性，因此與一般例行性的作業不同；專案管理（Project Management）則是將管理知識、技術、工具和方法綜合運用到一個專案活動上，藉以達到符合專案的需求。
至於從專案管理定義延伸出來的5個管理流程，則涵蓋了起始、計畫、執行、控制與結案等；除此之外，專案管理所涉及的9個知識領域，則包括整合管理、品質管理、溝通管理、範疇管理、時間管理、成本管理、人力資源管理、風險管理、採購管理等。 |
|
|
|
冷日
(冷日) |
發表時間：2008/3/17 5:43 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [轉貼]專案經理人的領導魅力重於一切
| 專案經理人的領導魅力重於一切
溝通與用人能力往往是專案經理能否適任的關鍵指標
對於專案經理人來說，專案管理無非就是對內管控以及對外找資源，然而不論是對內或是對外，專案經理所扮演的角色，都必須透過溝通來達到目的，有的專案經理人，甚至以「我很會開會，就是我的專長」來調侃自己，事實上，不論專家學者或專案執行者都一致認為，專案經理人至少有80%～90%的時間，都是在開會或溝通，當然專案的成敗也往往隱藏在這其中。
專案的失敗，往往不是因為技術無法克服，而是人沒有搞定
在這樣的情況下，溝通能力往往是專案經理能否適任的關鍵指標，事實上，大多數的專案經理都認為，一個專案的失敗，往往不是因為技術上的問題無法解決，大部分的時候，都是因為人的問題沒有搞定，例如，溝通不良、缺乏共識或是利益擺不平等等。
以BS7799的導入來說，持續性營運的做法本來就可大可小，而大多數企業主想要擴大導入範圍的情況下，專案經理人很容易就陷入兩難，因為導入範圍變大之後，雖然順了企業主的意，但導入的時間與成本，甚至是風險都相對提高，在這樣的前提下，專案經理必須要有能力阻止事情發生，例如，協助客戶釐清需求，如果是以通過BS7799認證為前提，那麼原本的計畫就已經可以達到目標，但是如果在其他考量下擴大導入範疇，可能就會無法如期通過認證等等。
過去曾在安侯企管顧問公司擔任專案經理的蕭正元不諱言地指出：「有時候專案經理的工作，並不像是在做專案管理，反而像是在撮合一筆生意，買（專案委託者）賣（服務提供者）雙方都不能得罪，彼此之間的合作關係才能永續經營下去」。Quint顧問黃以任則是認為，專案經理必須成為商業與技術之間的橋樑，尤其是商業考量與技術考量產生衝突的時候，專案經理必須想辦法滿足客戶的期望，同時也必須達成老闆的要求。
一般來說，專案經理在專案團隊之中，雖然不一定是技術領域的佼佼者，但絕對是整合專案團隊的靈魂人物，一方面必須激發團隊的工作熱情，另一方面又必須要精準掌控專案進度，而不至於陷入技術導向的迷思中，在這樣的前提下，如何把對的人，放在對的位置上，對於專案經理人來說，不僅是「識人能力」的考驗，同時也突顯了「用人能力」。
精業專案管理辦公室資深協理高添水說：「訓練一隻鴨子爬樹，不如直接找一隻松鼠來；訓練一隻松鼠游泳，不如直接找一隻鴨子來。」這樣的比喻道破各有專長，並非是誰的技術特別好或不好的用人哲學。
專案經理人的養成，非常依賴實戰經驗
除此之外，對於大多數的企業來說，專案執行的過程，往往也就是專案經理的養成過程。一家國際物流公司的專案經理就表示，由於行業特殊性的專業知識需要慢慢累積，因此，專案經理的「養成」過程，大多會從基層的專案執行做起，然後再慢慢地升起來帶一些小型的專案，最後才會隨著專案能力成熟度的提升，調整所能負擔的專案規模，而養成過程中，其實有很多可以觀察的機會，因為專案管理的任何一個環節，只要出錯，相關的專案執行者就會面臨到相當大壓力，這個時候，往往就是觀察的最佳時機，一般來說，如果在高壓力的情況下，還能有良好的溝通能力，並且妥善執行專案，往往就是比較適合擔任專案經理的人選。
專案經理的個性特質，是否喜歡溝通，而且有很好的溝通能力，將是決定一個專案經理能否成功的關鍵，因為一個好的專案經理除了能做好內部的溝通與控管以外，當專案團隊遇到技術瓶頸時，也能透過人脈找到解決的方法，事實上，臺灣的專案經理在遇到問題時，大多會透過人脈關係尋求協助並且得到解決，下下之策或非到不得已的時候，才會與專案利害關係人開會討論。
除此之外，從企業的角度來看，如果專案經理能夠兼具專業知識與善於溝通的個性特質，會是擢昇為專案經理的不二人選，但是如果兩相比較之下，個性特質的重要性仍舊會比專業知識重要，因為人的個性本質難以撼動，而專業知識卻是可以靠後天的努力補足。
不過在臺灣，有的專案經理人，必須是和尚兼撞鐘，什麼都要做，除了專案規畫以外，甚至必須參與執行，這樣的情況，其實常常就是專案規模小的企業常態，一般來說，專案團隊規模如果沒有10～20個人，專案經理人的所扮演的角色，很難真正只是做單純的管理工作，在這樣的前提下，專案經理人對於技術的掌握度也必須相對提高。
然而，不論是和尚兼撞鐘的專案經理人，或是以管理為核心要務的專案經理人，「溝通」仍是相當重要的一環，專案團隊的工作熱情與願景，甚至也必須透過溝通來完成，好的專案經理人，可以讓正在砌磚的工人知道，他不只是在砌磚，而是在蓋全世界最高的一棟大樓，進而達到激發工作熱情的目的，專案品質甚至也會因此受到影響。文⊙楊惠芬
| 給專案經理人的小叮嚀 專案管理失敗的原因 | 進度與現況報告的利用度不夠充分 現況報告盡是表面文章 專案經理的行政、人際關係以及技術層面的能力不足 專案經理的影響力與職權不足 與客戶之間的協調很差 與客戶、承辦機構之間缺乏默契
客戶對於預算的標準不夠關心 在做決策與解決問題方面，專案團隊少有參與的機會 專案團隊的組織架構過於繁複 專案團隊缺乏工作上的保障 專案團隊缺乏團隊精神與使命感
| 承辦機構過於保守，缺乏策略上的改變 承辦機構之間的協調性很差 新的專案「類型」 專案比承辦機構之前進行過的專案更為複雜 初期的資金籌措不足 整個專案在設計上，無法在初期就加以鎖定 無法結束全部的作業 專案的時程不切實際 不適切的變更程序
資料來源：專案管理聖經，臉譜出版 |
|
|
|
|
冷日
(冷日) |
發表時間：2008/3/17 5:44 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [轉貼]為結案而管理，還是為專案而管理？
| 為結案而管理，還是為專案而管理？
企業期待專案管理的技巧能挽救失敗的專案，卻忽略「管理」才是專案管理此領域的本質，而其精神是透過管理專案讓成功是水到渠成的美事，卻不是為結案而勉為其難的手段。
專案是企業重要的獲利來源，但目前對於高達70%以上的失敗率，尚缺乏有效的因應方式，讓企業處於兩難的選擇，因而更期待專案管理能解決這個兩難的困境，只是這麼一來造成對專案管理的失焦與錯誤認知，以為專案管理所傳授的技巧能挽救失敗的專案。可是，這只是專案管理的目標之一，忽略「管理」才是專案管理此領域的本質，而其精神是透過管理專案讓成功是水到渠成的美事，卻不是為結案而勉為其難的手段。宏琦科技副總經理康志遠認為，「企業如果沒有專案精神，不如走ISO就好了」。在專案管理這個領域中，企業尚需要更多的時間從挽救濱臨失敗著專案上，學習如何管理（Management by Projects）讓成功是必然，而非偶然。專案管理知識體系所傳達的哲理在於「預防重於治療」，但不是「急病亂投醫」。前者是為專案而管理，提高結案的品質，後者卻是為結案而管理，在身心俱疲後結束。
外在商業環境所帶來的「複雜」與「變動」使企業在專案上面對更多的挑戰，這也是現今企業專案的本質。專案管理並非萬能，可將複雜轉變為簡單，將變動轉變成穩定，而專案經理也不應該像個醫生，為注定失敗的專案帶來醫治的良方，如此一來就演變成「頭痛醫頭，腳痛醫腳」的庸醫。專案經理應該像是健康顧問，時時關心專案的健康程度，適時地提醒，也就是預防重於治療，不是在專案失控後才冒出來善後。以資訊專案為例，它的交付物不明確、不易切割、何時完成與完成後的品質都難以事前知曉（相對於營建專案，整座橋樑可以分段完成、明定完工時程與橋樑的可靠度等），正反應出專案的複雜性，因而更需要管理，無論是透過經驗性法則，或是採用專案管理的科學技藝，也都是為實現管理的奧義。雖然資訊專案常面對客戶需求變更，但這樣的變動只是成為複雜的其中一個因素，而管理的目的就是採用嚴密的組織控管變動與複雜，但絕不是為結案而抑止任何的改變。
要「管理」，不要「領導 」
如果專案管理是為結案而管理，那麼專案經理應扮演著領導者的角色，施以威脅利誘的手段，督促專案成員結案。相對地，如果是為專案而管理，那麼專案經理應伴演著協調者的角色，激勵專案成員朝向結案努力。目前企業仍將專案管理當成結案的良方，相對地更倚賴專案管理，甚至一開始就上癮，如同重症病患對藥物的渴望。
舉例而言，領導者出現在戰爭時期，以獲勝為目的，此時需要時勢造英雄，而且正反兩方處於對立的局面，領導者就必須採用高壓懷柔等手段讓部屬在戰場上不至於退卻，並所向披靡。這一點，精業公司資深副理高添水精闢入裡地點出「專案經理要有領導者的風範與修為」，但不是帶著領導者的權杖。企業專案不是戰爭（當然，與競爭者爭奪標案是場你爭我奪的戰爭，但這僅是專案管理的一個環節而已），專案關係人（Stakeholder）也不是處於對立的敵人，更不需要英雄人物撐場面，大家應像是唇亡齒寒的夥伴，而專案管理代表是「共通語言」，而不是掌控全局的「遊戲規則」，否則專案管理很容易淪為制度下表面功夫的結果。
如果專案經理將自己視為領導者而不可一世，那麼專案注定失敗，因為資訊專案中充滿技術專家，扮演英雄人物正適得其反並造成更多的對立，專案經理應帶領成員一同為專案努力，而不是自己奮力向前衝刺，將成員拋諸腦後。康志遠表示：「如此一來，專案成功只是成為專案經理個人的豐功偉業，為個人升遷與績效帶來成就，成員仍在原地踏步。」更重要的是，這群人後續將不再為這位專案經理效命，對企業而言，或許這創造了一位優秀的經理人，但失去一個優秀的團隊。專案常因為成員信心與認同的瓦解而導致失敗。
管理的重要技能就是激勵成員
專案組織的特性是高度的依存性，每個成員的工作與技術都與其他人緊密相關，無法獨立於團隊之外，而且沒有絕對的管理中心，每個人都伴演橋樑的角色，牽一髮動全身。也因此，專案成功是團隊高度分工合作的結果，而不是專案經理個人的權利與義務。此時，專案經理的角色類似操舵手，引導著專案團隊朝著正確的方向。但在組織中，人是有思想的生物，所以專案經理常必須透過激勵與啟發賦予成員執行專案的活力與熱情，讓結案是水到渠成，而不是像控制機械人一般，將成員推往結案的方向。前者是管理，後者是領導，但對企業必須歷經接案與結案的頻繁過程，過度強調領導手段容易使成員疲累，降低專案品質。團隊中的專家在專案中常透過掌握自己的時間、技術與流程方式，來執行專案的進度，以高度領導力來強迫他們改變，容易遭受反抗，即使只是消極地抵抗，都會瓦解專案的結果，而且這種消極性很容易感染或散布到其他成員上，特別是起因於有聲望的資深工程師。這是為何專案經理透過激勵，誘導出專案成員戮力執行專案的熱情與衝勁，視專案成功為實現理想目的。專案經理在組織採取激勵的方式，高添水建議「傾聽每位成員對專案的期待」，以及樹立角色模範，兩種管道的目的都是帶給成員對專案執行的成就感，以及對專案團隊的歸屬感，並促使工作轉變為發自內心的原動力，而不是基於薪資與升遷等私利。
過度管理適得其反
現實上，我們很容易發覺控制常成為專案管理的核心，也就是專案負責人常以領導權力，讓成員在壓迫感下執行專案。此外，專案負責人有時也因為過度管理而不自知，通常是採取緊迫盯人的監視方式，也對專案成員形成無形的壓力，而且這類情況下，專案經理常歸咎於成員無法承受壓力，而不是反省自身過度管理等問題。這類情形最容易發生在一切以績效為主的企業團隊中，通常許多KPI（Key Performance Indicator）都是可量化的數字，但專案成員對團隊的貢獻有時是無法量化的，正如異術科技多媒體部協理陳俊賢所說的，「中小企業的專案經理常因為人力資源精簡政策下，不得不參與專案細節作業，擔任救火員的角色」，常見的例子就是替另一位資歷較淺的工程師除錯等。
信賴感為管理加分
然而激勵不是容易的事，專案經理認為具備偶像般的光環或英雄般的氣質，也可以間接帶來激勵的效果，但在以技術專家為主的團隊中效果很低，因為這些專家本身就是眾人仰慕的技術明星，專案經理一點也占不到便宜。但專案經理人在管理專案時，還需要在方法論中融入因地制宜的因子，高添水就提到自己因為「神經比較大條」，反而為自己本身創造出管理者的優勢，以及因為「草莽性格」而讓團隊成員感到信任。與一般以英雄式撼動人心的領導者（例如Apple的Steve Jobs）不同，在於高添水這類的資深經理人很容易親近與融入群眾，也因此他們在言談間表現出親切，不因為知識或證照讓自己居高臨下、不可一世。從成員的角度來看，就是具有高度的可信度，我們也發現這種草莽性格有助於快速地傳達訊息，而訊息的通透性則可提高成員對團隊的向心力與認同感。康志遠提到，專案經理對成員指派任務常附帶一句命令式的口吻：「儘管照吩咐的事去做，其他就不用管。」通常這種激勵方式像是在馬前吊一根蘿蔔，馬會努力地向前跑直到筋疲力竭為止。文⊙張瑞隆
| 管理（把事情做對）與領導（做對的事）的差異 |
擅長領導與變革題材的管理學家John Kotter曾在「哈佛商業評論（Harvard Business Review）」發表「領導人真正做些什麼？」一文中，提到「管理」與「領導」的重要區別：「管理要克服的是複雜的狀況。相對地，領導要克服的則是變動。」文中並舉出軍隊類比，「和平時期的軍隊需要的是良好的行政與管理」，而「作戰時期的軍隊每個層級都需要有稱職的領導」。在專案管理領域中，管理重於領導，而我們在訪談過程中也確認，具領導特質的專案經理並不足以代表專案成功，但擅長管理的專案經理卻能獲得團隊與客戶的滿意度作為回饋。此外，文章中另外提到「公司以為擁有長期計畫就是吃下一顆萬靈丹，可以解決缺乏方向，以及無法適應商業環境日益競爭、變動的問題。」，所以「過度管理和缺乏領導是企業最常犯的錯誤之一」。 我們從訪談對象獲得的答案，也認為長遠的專案計畫書效用低，因為成員並無法按規畫的進度，而且永遠有例外發生，此外，專案經理無法辨別管理與領導間的差異，則是成員常抱怨對專案方向充滿困惑的問題。這個問題不僅發生在專案團隊上，也發生在企業主管挑選專案經理的時刻，選擇缺乏管理意願與能力的技術工程師擔任專案負責人，結果如James Lewis所形容：「組織失去一名優秀的技術人才，換來一個平庸，甚至拙劣的經理。」。文⊙張瑞隆 |
|
|
|
|
冷日
(冷日) |
發表時間：2008/3/17 5:45 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [轉貼]系統思考力為專案帶來整體觀
| 系統思考力為專案帶來整體觀
專案以團隊的合作力量執行，只有專案經理能站在團隊整體以上的巨觀角度，時時檢視潛在的問題，此時，專案經理必須具備「系統思考」的客觀能力，以免產生緩慢漸變且不易察覺的複雜問題。
從Henry Mintzberg所提專案經理應具備的10種角色，可知專案經理雖然不一定要十八般武藝俱全，但至少應具備八面玲瓏的手段。此外，專案經理與一般部門經理或資深工程師最大的差異，在於專案經理應具備更長遠的思考能力。高添水指出，「業務單位最常面對部門經理與專案經理在資源分配上有衝突，從企業的角度來看則是成本無法有效地控制」。一般企業常以功能導向，將組織依功能性區分，然而，企業面對外在商業環境的高度複雜性，常使問題跨越部門，但各部門僅能專注在各自領域的職務上，無法了解超越部門層級以上的互動過程，以及衍生的問題，因此也造成專案經理在思考上受到嚴重的侷限，依部門的視野來看待問題便是所謂的「線性思考」。宏琦科技副總經理康志遠說到另一個普遍存在的失敗因素，則是「一開始範疇就定不清楚！太業務導向！」，他進一步解釋道「企業常提攜資深業務人員擔任專案經理，尤其是以產品銷售為主的企業，而業務背景的專案經理常對客戶所提出的需求給予過多的承諾」。這些都是線性思考下的結果。
重複工作的悲劇
專案以團隊的合作力量執行時，各成員緊密互動，但只有專案經理能站在團隊整體以上的巨觀角度，時時檢視潛在的問題。此時，專案經理必須具備「系統思考」的客觀能力，以免產生緩慢漸變且不易察覺的複雜問題。一般專案經理會以片段的解決方法處理團隊互動下的問題，但卻越治越糟，也就是我們俗稱的治標而不治本。
Peter Senge在「第五項修練」一書中提到缺乏整體且有系統觀的處理方式的問題：「它會抵消個人或群體改善問題的所有努力，它會誘使我們捨本逐末、避重就輕、愈治愈糟、一再犯錯，甚至興奮而努力的製造共同的悲劇。」我們在專案常遇到的「重工（Re-work）」便是這類典型的問題。這種狀況常發生在因為專案時程受擠壓，讓專案經理採用「坐而言不如起而行」的果斷處理，造成後續更難以收拾的局面。舉例而言，人們在飢腸轆轆時，面對眼前的山珍海味，反射動作便是飢不擇食、狼吞虎嚥。由於胃消化的速度跟不上進食的速度，通常人們已飽食而不自知，仍持續地進食，當大腦意識到飽足時，其實胃以塞滿過多的食物，此人會因為無法思考，甚至被迫傾吐所有食物以舒緩胃所承受的消化壓力，抵消了之前所有的努力，回到最初饑餓的情形，只好再進食，這就是專案的重工效應。
專案經理常處於「救火」時，更能體會出系統思考的重要性。我們常見到專案進入某個里程碑而必須交付產品雛型給客戶時，專案經理便會調動人力全力加班趕工，然而這些被臨時抽調的人力，本身的專案進度便延宕，很快地便影響到下一個里程碑的進度，專案經理又必須再次「救火」，結果是整體時程延後。
實務經驗強過個案研究
專案經理如何養成系統思考能力，信仁軟體設計公司軟體架構師王克明建議在「實務經驗中不斷學習與啟發」，而且有制度的企業所採用的學徒制是目前較可行的方案。簡單地說，許多企業管理與經營的書籍以及為數眾多的管理學家，普遍認為哈佛大學最初所提暢的「個案研究」有助於培養專業經理人的思考與應變能力，但現實中的企業主管還不至於將專案交由精於個案研究的專案經理人，他們還是回到實務的訓練上，反應出「想是一回事，做又是另一回事」的簡單道理。這群現實中的專案經理人認為個案研究教導年輕的經理人思考問題之際，最後也是在思考中解決問題，可是回到現實世界後，如何將解決方案落實到專案組織上，還是需要高度的執行能力，特別是克服對危機的恐懼感，這是課堂無法學習到的。高科技產業非常講究「唯才主義」，並非可從高階企業管理課程就可以造就。
從Linux專案學系統思考
如果說能從Peter Senge學到什麼的話，應該是「集體遠比個體更有智慧」，仰賴專案經理解決系統層級的問題有點緣木求魚，但由專案團隊共同努力的話，三個臭皮匠畢竟勝過一個諸葛亮。我們可以從Linux開放源碼社群看到典型處理系統層級的範例。Linux是個複雜且高品質的作業系統，但卻由鬆散的團隊所完成的，那麼這群人如何看出複雜系統中的臭蟲（Bugs）並除錯（Debugging）？Eric Raymond在「教堂與市集（The Cathedral and the Bazaar）」一書中提示了答案：「給予足夠多的注視，所有的錯誤都無所遁形。（Given enough eyeballs,all bugs are shallow.）」Raymond也提到，開發社群雖然集結了一群專家，也無法避免程式沒有臭蟲，但在Linux社群中，「了解並解決問題的人不一定是第一個發現問題的人，有些人發現問題，有些人解決問題，發現問題和解決問題的速度都很快，而且避免偶爾笨拙的修補」。如果專案團隊成員能參與解決問題，勝過專案經理單打獨鬥。但這不是要專案經理時常召開腦力激盪大會，而是透過與成員不斷地溝通與交換意見，這一來，又間接證明專案經理為何在溝通過程中花費多數的時間。
專案經理到底掌握了什麼？
當專案經理必須在實務上運用專案管理知識體系所陳述的9個知識領域時，他將發現此職位僅足以掌控品質管理與溝通管理兩項，至於範疇管理、時間管理、成本管理可能控制權在客戶手上，而人力資源管理與採購管理則由公司主管或部門經理所掌握著，至於風險管理隨時因內在與外在環境交互作用而變動，總結後還談不上整合管理，這一點在缺乏專案管理制度的企業中更明顯。直覺上，品質管理似乎是專案經理把握的控制項，但這項因素卻又與時間、成本、人力資源、採購等緊密關聯，而且總要到專案末期才塵埃落定。於是乎專案經理手中握有的重要資源，僅剩下溝通管理。陳俊賢與康志遠異口同聲地表示，「專案管理知識體系主要是提供團隊成員間共通的語言。」有趣的是，陳俊賢提到「異術科技初期曾指派5位工程師參與中華專案管理協會所提供的訓練課程，結業後只有2人順利考取證照，而且專案管理實務經驗越深的人所得分數卻越低。」
這一點多少扭轉一般人對專案經理的看法，認為學習相關的課程後就足以在專案資源上調度自如，卻也反應出專案經理人辛苦而難以道人知的另一面。許多技術人員常抱怨專案經理缺少運籌帷幄的高明手段，但當自己也轉任到這個職位時，才發覺專案經理不過是漢堡中的一塊雞腿肉，從外表上看來很有份量，味道更是棒，但終究是夾在兩塊麵包之間，品嚐時總是受到全力擠壓後才得以入口。文⊙張瑞隆
| 專案經理的技術本位與管理本位應以何者為重？ | | 如果專案管理偏重管理層面，而專案管理知識體系常用來傳授專案執行技巧，與實務有所脫節時，我們不禁要問是否MBA課程更適合專案經理？同時具備MBA學位與PMP證照的陳俊賢表示，管理背景適合擔任專案經理，而MBA課程訓練經理人思考邏輯，對專案經理有正面的助益。陳俊賢進一步表示，MBA與PMP可相輔相成，都是專案經理養成教育中的一環，沒有絕對的優劣。但可以確定的是，如果專案經理下一階段要邁向CEO/CIO/CTO的階層時，MBA可補足在企業管理廣度的不足。至於專案管理知識體系會不會培養出「計算型的經理人」？高添水表示「優秀的鋼琴家不只是懂樂理、背琴譜，還得要在鋼琴上多練習才行」。不過，技術背景出身的專案經理未來更容易轉任技術長（CTO），而管理背景出身的專案經理則是資訊長（CIO）的接班人。 可是，在資訊專案上卻有不同的見解。資策會講師高義智本身曾擔任HP專案經理一職，他卻認為資訊專案的特性是重用許多技術，「此時由技術背景出身的工程師轉任專案經理」，比起管理本位的人更適任，而且因為對技術的高度了解與實現能力，更能順利推動專案。
企業對專案管理的看法，認為專案管理課程所傳授的是執行專案的技巧大於管理的技能，但至少有助於專案團隊成員間有共同的「溝通語言」，解決以往專業經理人與技術人員間對專案認知 的差異，以及企業與客戶間更有效地控管變更事項。文⊙張瑞隆
|
|
|
|
|
|
|
冷日
(冷日) |
發表時間：2008/3/17 5:46 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [轉貼]專案管理究竟教了我們什麼？
| 專案管理究竟教了我們什麼？
專案管理課程適合每位企業成員共同學習，因為它的定位不應該是培養專案經理，而是傳授單純的專案執行技巧。
專案管理協會（Project Management Institute，PMI）成立於1969年，並推動專案管理知識體系（Project Management Body of Knowledge，PMBOK），直到近年來資訊領域因認同專案管理師（Project Management Professional）認證，更促使此張認證成為IT技術與管理前十大認證，使得企業對專案管理投以高度注視的眼光。資策會數位教育研究所組長吳念祖提到，在此風潮前「專案管理原本就有市場上的需要」。美國國防部早期採用俗稱「498文件（Mil-Std-498）」規範資訊系統研發的標準便是一例。從專案管理協會成立至今已過37年，專案管理知識體系仍無法解除企業在執行專案所遭遇70%以上的高失敗率獲得舒緩，直到最近業界才慢慢釐清專案管理背後長久以來隱而未現的一些問題。
資策會數位教育研究所組長高義智認為，「臺灣視專案管理為單一的課程，通常只有在工作上遇到困難時才知道這門課程的重要性，而鄰近的新加坡大學已將專案管理納入正式的大學教育中，美國德州與澳洲等甚至提供專案管理的碩/博士學位。以往臺灣沒有導入專案管理相關的知識，採取土法鍊鋼的執行方式，現在我們必須學著國際化。」
如果專案管理課程不是培養專案經理的必經之路，那麼專案管理知識到底教了我們什麼？或者應該說，我們能從專案管理學到什麼？
從專案管理知識體系中可看出，每一個領域都是專業科目，也就是說，一般人無法未經學習就可以瞭解箇中奧妙。但我們會發覺企業導入專案管理時，常遭遇成員的抗拒。而且「直覺上這些抗拒是對組織的變革與工作流程更動所帶來的負擔，事實上卻是成員對專業知識的不瞭解與恐懼。」康志遠從以往的經驗中提到這些經驗很正常，因為職場上的人們常使用熟悉的工具與方法，鮮少冒險嘗試新的事物，縱使勇於嘗鮮，也都是在奠基在原有穩定的流程基礎上。
企業在初期導入專案管理時，常派特定的員工接受專案管理課程，並擔任種子教師或導入負責人，也許在簡單的命令佈達後便開始推動專案管理，而忽略了成員對專業知識水準不參齊的情形下，即使不抗拒，也難以配合。
專案管理課程適合每位企業成員共同學習，因為它的定位不應該是培養專案經理，而是傳授單純的專案執行技巧。從課程層面來看，它的內容是專業與科學，但不是管理，也不是專案「管理」，企業不應對專案管理課程有過多的期望。此外，人們也勿以為學習專案管理課程後，就足以擔任專案經理。我們從企業對學習過此課程的人員訪談結果，也支持這樣的看法。主管還不至於貿然地讓學習過專案管理課程的人擔任專案經理，特別是大型專案，而是經過內部培訓以及篩選，將無法賦與重任的人轉調它職。高義智提到，外商企業重視專案經理人的養成教育，吳念祖也提到，取得專案管理證照並不一定反應在薪資與職位上，可是外商卻願意承受專案失敗的成本，讓專案經理在失敗中更提升管理的能力，甚至有充足經驗的專案經理其薪資高於主管。文⊙張瑞隆
| 專案管理認證臺灣與全球倍數成長 | |
根據專案管理協會臺灣分會的調查數據指出，2004年底全球通過專案管理認證的人數只有8.6萬人，但是，到了2005年底已經快速成長到17萬，足足暴增了一倍以上；相較之下，臺灣市場的表現並不遜色，整體的專案管理認證人數規模，雖然不高，但成長幅度有過之而無不及，並且從2004年底的400多人，一路攀升到目前的1359人，短時間內成長了3倍之多。
在臺灣，專案管理的發展，似乎是由個人端驅動，因為專案管理證照所產生的效益，即便無法直接得到加薪或升遷等等的待遇，但是仍舊增加了個人競爭力；企業對於專案管理的看法，甚至也相當兩極，一種是積極接受並且培養相關人才，認為專案管理有助於專案品質提升，另一種則是以消極的態度因應，在沒有急迫性的情況下，完全不考慮斥資培養人才。 目前企業並沒有普遍要求專案經理人，一定要有專案管理證照，才能成為專案經理人，而是著重實戰經驗的具體表現，然而，大師級的專案管理人才，在臺灣卻是鳳毛麟角，主要是因為臺灣的專案規模普遍較小，大師級的專案管理人才也相對不易養成，再者，許多經手過大的專案，最後的發展又會走向顧問或是行政職，因此，臺灣始終難有大師級的專案管理人才。文⊙楊惠芬 |
|
|
|
|
冷日
(冷日) |
發表時間：2008/3/17 5:46 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [轉貼]專案管理知識體系，越來越重視專案管理風險結構分析
| 專案管理知識體系，越來越重視專案管理風險結構分析
RBS讓專案經理可以由範疇、成本、時間與品質目標中，分析各構面的風險值與衝擊程度。
專案管理知識體系2004版中，針對風險管理新增風險分解結構（Risk Breakdown Structure；俗稱RBS），讓專案經理可以由範疇、成本、時間與品質目標中，分析各構面的風險值與衝擊程度。
精業公司資深協理高添水提供風險管理的範例，「如果企業為規避10項風險，每項的代價是10萬元，那麼就必須準備100萬元作為緊急應變用。可是萬一風險都沒有發生，則資金都卡住了，反而增加專案成本。相對地，如果再加上風險發生的機率，假設每個機率是10%，則單一風險發生所付出的代價就只是1萬元，此時企業只要準備10萬元，就足以因應10項風險的所有需求。」
專案計畫下的工作分解結構讓專案經理可將工作細分後，再逐一指派成員執行。高度完整性的WBS可讓專案經理控管與追蹤專案進度。
風險分解結構也基於相同的精神，基於完整的RBS所擬定的管理計畫可提升規避風險的機率。文⊙張瑞隆 |
|
|
|
冷日
(冷日) |
發表時間：2008/3/17 5:49 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [轉貼]速食麵式的軟體專案
- piggy | 14 Apr, 2007 17:56
「速食麵式的軟體專案」是我這兩天想到的一個新名詞，原本是要寫另一篇文章，剛好文章裡取了這個名詞，所以就先來解釋一下什麼叫速食麵式的軟體專案。
先說說為什麼會有速食麵？就是為了方便嘛，所以顯陸內地稱它為方便麵。既然叫速食，就表示可以在很短的時間內就可以使用，不論好吃或難吃，它已經滿足你肚子餓的基本需求。當你去便利商店或是大賣場想買泡麵時，你會怎麼挑選？如果沒有口味偏好/限制(例如不吃牛)時，一份泡麵擺在架子上，能吸引你伸手去拿的，通常只有一種情況，就是它的外表。
外表包括了品牌、文字(名稱和文案)和封面圖片。品牌就得靠廣告打得兇不兇來吸引客人注意，但文字和封面就是很直接主觀的東西，名字取得好、文案寫的有說服力再加上封面拍得漂亮，通常你會給它一次機會，回家吃吃看。問題來了，大家應該都知道，每一碗泡麵的封面上，一定會在某個小角落印上「封面照片與內容物不完全符合」之類的字眼。你知道這一點、我知道這一點，大家都知道封面照片是騙人的，而文案也不會真實到哪去，可是大家還是一再被騙(其實說吸引會比較好一點)。買回去真的很難吃，頂多下次去不買這個口味了，但還是會用這樣的模式去挑其它的泡麵來吃。
有些泡麵可能真的很用心去設計，比如請什麼師傅啦、手工麵條啦(不可能)、非油炸啦等等…就是要說明它的麵用了許多新的技術，不過吃的人往往只care好不好吃，有什麼技術跟本不是重點，重點是要好吃，才會吸引他下次來買；不好吃的話，就沒有下次了。那個什麼非油炸麵條就是一個很好的例子，我跟本不想再吃第二次。
那跟專案有什麼關係？台灣的客戶都要求快速(指開發時間)、漂亮(指介面)和便宜，然後只要解決目前的需求即可，這個不就跟下午三點肚子餓去買泡麵的模式一樣嗎？我只要解決我現在肚子餓就好了，其它的就再說囉。假如我是PM，我只要軟體能跑、該有的功能都有，老闆看到美美的畫面和完整(?)的功能，我就可以全身而退了。用了什麼高級的技術、Framework，好不好維護、能不能擴充(軟硬體)跟本不關我的事。很無奈，但這也是我看到的現實。
原文出處：豬言豬語 - 速食麵式的軟體專案
冷日： 最悲哀的是，看了前面這麼多的專案管理，台灣真的是很「速食麵」！
|
|
|
