2009年5月31日 星期日

【破窗】"The Broken Window"-您與人交往,是相信"資料"還是相信"感覺"?


肥蝦是一個推理小說迷,在美國當代的推理小說中,個人非常推崇與喜愛Jeffery Deaver(傑佛瑞·迪佛)的「神探萊姆」系統。還記得當初觀看「人骨拼圖」電影,丹佐華盛頓飾演林肯·萊姆;安吉莉娜裘莉扮演的艾米莉亞,深深吸引了肥蝦的目光。在日後,陸續購置與閱讀了一系列的「神探萊姆」,更是對林肯·萊姆的細緻、有序的邏輯推理能力,以及精確縝密的證物資料庫;艾米莉亞無畏、勇敢的精神,以及玲瓏有緻的身材著迷不已。

趁著這四天連假中陪個小孩的空檔,翻閱了「神探萊姆」最新出版的翻譯作品-The Broken Window【破窗】-身為碰觸資訊軟體的人,心中有著不同的感觸!肥蝦曾參與過某些銀行的信用卡核心與週邊系統,對於銀行利用持卡人的消費行為資料,進行產品行銷,有實際的參與;也對於稅務單位為掌控國民的稅務資料,要求銀行逐筆傳送交易資料,也有很深刻的印象。

近來有些許的小說,都在談論個人資訊保密的問題,如肥蝦先前看過的"Digital Fortress"【數位密碼】-Dan Brown(丹·布朗)著。【破窗】乙書,就在闡述犯罪者掌握了被害者的相關資料,利用被害者熟悉的生活作息與社交的弱點,加害於被害者。在應用現代人彼此間的疏離,對於"個人虛擬資料"的信任,大於對個人實際印象的信賴,入罪於他人。

其中,肥蝦對於書中431頁到449頁所列示的個人特徵的明細項目,對於作者的功力與細心,不得不深感欽佩!若有某家行銷公司真能掌握該書所列示明細的40%,其時就可以完全掌握該人所有的一切了。(其實若有需要分析個人特徵,該書431頁到449頁的明細,可作為一個非常有價值的參考依據)。

想到此處,肥蝦不禁憶起,近來參加過相關的專案管理資訊系統(PMIS)產品的發表會。雖然很多專案管理資訊系統,均強調使用者能經由該產品完全掌控專案(單一/所有)的"實際"進度,相關風險與問題的議題處理狀況,精確控制專案的實際成本,以及…諸多的好處。這就讓肥蝦想到,資訊系統所顯示的"虛擬"資料,就真得能完全精確的反應出專案的"實際"狀況嗎?

姑且不論專案管理資訊系統在專案管理中扮演的角色!若專案經理僅僅是利用資訊系統(如:PMIS,eMail,線上會議系統…)就能完全瞭解專案團隊成員的個人性格、品行、作為、習慣,進而就能完全掌握專案的確實狀況嗎?若是公司高層或是客戶,僅僅單憑專案經理以"虛擬"的資料所提報的專案進度數字,就是否能完全相信專案是在按照既有的計劃推進中?

肥蝦常碰到一些友人,他們相信資訊科技可以處理所有一切的事務,也在追求一個所謂的完整解決方案(Total Solution),但是他們卻往往忽略自己的真正需求,也未深入評估過自己真正的處境。更是有些客戶,更是滿心盼望引入一套資訊系統,就能完完全全解決他們從未認真評估與仔細探索過的問題。

肥蝦想起先前一個手機業者的廣告詞「科技始終來自於人性」-強調其產品,乃是應用理性的科技原理,並考慮感性的人性因素設計出來的。可是肥蝦所遇過或聽過的很多資訊系統的問題,也是來自於人性。人性真得能用科技來完全取代嗎?我想這是一個見仁見智的問題!但是,肥蝦個人還是以為:「惟有藉由人與人實際、有效的接觸與信任,才是專案成功的不二法門。」

2009年5月24日 星期日

專案管理厚黑學-"大明王朝"讀後感


肥蝦這幾日因為得到"類"流感,臥病在床。還好,肥蝦是身無三兩銀,人家一看也不像剛從國外回來的貨色,因此沒被認為得到的是"豬流感"。

這幾日在病榻上,全身無力,也看不下一些電腦專業書籍,也讀不進專案管理的閒書;恰好生病的前兩天,逛到了天瓏隔壁的幼獅書局,在全館七五折下買了四本對岸劉和平先生寫的大明王朝。

肥蝦這幾日看完了大明王朝。不知道是專案管理學過了頭?還是著了專案管理的迷竅裏?突然對嚴嵩,這個歷史書上的大貪官,起了無限的同情心!單就專案管理的角度看來,肥蝦我突然覺得張居正跟海瑞他們那夥人,才是阻礙專案進行與破壞專案成功的壞人。

初看這部小說的第一眼,就覺得本書的故事主軸-"改稻為桑"-在國庫通府庫的時代,不就是為了彌補府庫的虧空,不就是為了滿足上位者的主要欲求。而胡宗憲所執行的蕩倭,也是服譍在同樣的策略目標-戶部尚書張居正說的:「海外一匹絲綢的價格是國內的兩倍。」-的一個專案。

而那大明王朝內惟一的sponsor與惟一的customer是誰?那就是「雷霆雨露,莫非王恩」的嘉靖帝了!而portfolio manager是內閣首輔-嚴嵩;program manager是浙直總督-胡宗憲;"改稻為桑"專案的project manager是浙江巡撫-一開始是胡宗憲兼,後來則改由倒楣的鄭泌昌;專案的end user是淳安跟建德兩縣五十萬的平民,利害關係人則是天下四萬萬兆民;那擔任淳安縣令的海瑞不過是專案團隊的成員之一而已。

整部小說所講的,就好像公司內部為了奪取公司資源而引發的人事糾纏,而最佳的觸發點,就是一個重要的專案-"改稻為桑"-的執行成功/失敗。就如那胡宗憲一開頭所點出的重點:本來專案的問題,僅是專案要如何的在制約下(減緩end user的衝擊下),追求目標的達成(改稻為桑,擴大絲綢生產)。結果因為下一任sponsor與customer-裕王,跟裕王週邊的師傅-徐階、高拱跟張居正,為了爭取portfolio manager的職位,藉由引入海瑞,去阻擋"改稻為桑"專案的進行,將一個原本的專案擴大為公司內部派系糾葛的鬥爭。

一方的人馬為了要加速專案的進行,不惜違反的專案管理應有的倫理與道德─破壞堤道,毀壞民田;一方的人馬為了阻礙專案的進行,拉高土地收購的價格,降低了"改稻為桑"的獲利率。就在這兩方人馬爭執當時,那一方有真得替end user著想?就如胡宗憲去向江蘇巡輔趙貞吉借米時,趙貞吉說的:「兩邊都有人打招呼,不要把米借給浙江。」最後是誰打破這僵局!還是portfolio manager-嚴嵩。嚴嵩倒台後,張居正還是仿傚了同樣的作法-六成歸田主跟棉商;三成歸朝廷;一成歸棉農-去取得專案的成功-十萬匹棉布。

看了整個故事,肥蝦不禁想起作過的一些專案!當專案的customer跟end user是不一樣的人時,在執行專案有真正為了end user的需求與需要在用心嗎?捫心自問!沒有,因為專案驗收的時候是customer,而不是end user。而且end user遠比customer的人數多得多了!誰有辦法去伺候那些沒有權力直接決定驗收,又人數眾多的人。

如果為了加速專案的完成,您會選擇為了拯救九百九十九個人,而去犧牲一個人嗎?雖然那犧牲的作法有點違背心裡的良知跟倫理!就像影響五十萬人口的一點生計(不會餓死他們,只是變為農奴!)但確可增進四萬萬兆民的福利。肥蝦個人是會考慮去作!

雖然大明王朝說得是嘉靖跟海瑞,肥蝦確把它看成是一本專案管理厚黑學的四部曲─(1)藉由推薦與專案目標與意念相反的人,到專案團隊去阻礙專案的進行;(2)藉由彰揚受到專案成果負面影響的利害關係人,去摧毀專案基本的策略目標的正當性;(3)藉由非自己負責的專案失敗,去奪取所要的公司資源;(4)藉由消滅異己後,再採行同樣的手法,獲致專案的成功。

以上是肥蝦在病床上對大明王朝這部書的感想,還請 指教!

2009年5月20日 星期三

遇到更正時程問題時,專案經理的優先選項是?


Question : When correcting a scheduling problem, what is the FIRST technique a project manager should consider?
A.Crashing.
B.Reducing project scope.
C.Fast-tracking.
D.Out-sourcing.
題目所標示的正確答案是A,但肥蝦深不以為然!我個人無意就個人經驗或坊間其它書籍的看法進行說明!

就針對PMI的考題與PMBOK的內容,說實在地!此題出得並不好!此題的情境並不足以支持選擇Crashing。

在PMBOK裏面,並未寫到PM要修正時程的問題時,首要優先採用的工具或技術為何?

此題有很多的模糊地帶!

(1)scheduling problem:此處大家是假設是delay!
但從6.1-6.5規劃的階段,我們可以發現可能的問題有:
6.1漏/多了activity。
6.2依賴邏輯關係弄錯了。
6.3漏/多估了所需要的資源。
6.4漏/多估了所需要的duration。
6.5太過樂觀/悲觀。

當然結果就會出現在6.6.(監控)。6.6的recommended corrective actions強調的是分析偏差,可沒有說一定是delay。

(2)crash跟fast-tracking是6.5的TT-schedule compression,如果此題考的是規劃的問題,不管那一個都要針對在critial path上的activity,然後再重新界定critical path。

(3)就6.6的recommended corrective actions說明中,只有說包含expediting;另外也要求要有root cause analysis;還有強調除了造成偏差的activity進行分析外,也會進行多個schedule activities的分析!

肥蝦以為PMBOK的精神,在於告訴我們不管是造成delay或advanced,都應該要去找出問題何在,並去解決真正的問題。

"運用協同專案管理,創造企業競爭力研討會"會後感想


2009年5月19日下午一點半的這場研討會,肥蝦一個非常詭異的感受!

雖說是名義上是由凌群電腦、PSIG博鴻國際專案管理顧問公司,以及台灣思科系統合作舉辦,但真正的主辦者應是博鴻;而凌群電腦與台灣思科,不過是趁此機會推銷一下凌群電腦所代理思科的【WebEx】網路會議系統。會場中的主要主題是博鴻在推展自己的顧問服務、認證課程,以及所提供的8th Management專案管理系統。

當天下午計有四場主題的演講,分別是:

第一場(14:10-14:50)
主題:專案溝通與利害關係人管理
主講人:熊培霖 博士/PSIG博鴻國際專案管理顧問公司

第二場(14:50-15:20)
主題:專案管理整合服務
主講人:馬淑怡 處長/PSIG博鴻國際專案管理顧問公司

第三場(15:40-16:10)
主題:建置企業e化的專案管理溝通平台-提升專案如期、如質、如預算的目標
主講人:徐重光 處長/PSIG博鴻國際專案管理顧問公司

第四場(16:10-17:00)
主題:強化企業協同模式,提升企業競爭力
主講人:陳德利 經理/凌群電腦公司

第一場應該算是整個下午惟一有些內容的場次。為搭配8th Management專案管理系統,以及【WebEx】網路會議系統,熊博士應是特別以PMBOK 2008第十章的溝通管理為講題。不愧薑是老的辣!熊博士近五十分鐘的演講可說是幾無冷場。雖然內容不脫PMBOK第九、十章的內容,但與台下聽眾親密的互動,演說中間雜博士自己個人的經歷,在博士流利的口才,笑口常開的嘴型,溝通管理講來真是頭頭是道。惟一少數缺憾,是熊博士把專案經理的referent power定義講解成expert power;以及過於把conflict的根源窄化為資源缺少,以及將資源缺少與制度間拉上等號。

至於第二場的專案管理整合服務,美其名為整合管理服務,但全部的內容就是把博鴻的主要營業項目講一遍,內容乏善可呈。

第三場8th Management專案管理系統的介紹也僅只流於表面。說是產品介紹呢?又僅是帶過幾張系統的投影片。說是PMIS的重要性呢?連PMBOK所強調的Configuration management system與Change management system,又沒有明確解說。整個對8th Management的介紹,反而不如肥蝦先前參加百加資通所舉辦的「線上多專案管理操作體驗營」。由於肥蝦並沒有明確的資料,也無法線上測試,因此無法妄加斷言。

第四場介紹【WebEx】系統,思科在網路領域是領導廠商,所併購來的系統產品自是有一定的水準。

整個下午將近三個半小時的感受,比對起肥蝦的原先懷抱的期望,是有一段落差,這不禁讓我想起很多IT先進在IT邦幫忙的發言。的確一家公司是確實需要以營利為導向,但如果是文不對題的研討會,有可能會容易引人不當的聯想。不過對肥蝦個人來說,如果博鴻真得給了兩個PDU(尚未拿到須待博鴻寄發電子郵件),那也是不無小補。

2009年5月17日 星期日

Brook定律-加人有用嗎?


Brook定律:"在一個時程已經落後的軟體專案中增加人手,只會讓它更加落後"

以肥蝦個人的想法:" Brook's Law"不管是個人定義或是Law!所陳述的問題是在Crashing所要顧慮以及解決的問題。

就肥蝦個人淺薄的經驗發現目前對" 加人",在公司與專案團隊之間有下列背後的駝鳥原因:

(1)逃避問題或找不出問題的推託藉口
專案經理:工作太多,作不完!人手不夠,無法完成當初專案的規劃!
高層主管:金額才那麼一點大,竟然要那麼多人作!

(2)推卸責任的推諉藉口
高層主管:照你的意思給你人了喔!還無法如期作完,是你專案經理專案管理不力!
專案經理:給的人素質、經驗都太差,來這邊是搞破壞的,專案延遲是主管找的人有問題!

這以上的對話是肥蝦個人常碰到的!然後就變成內部爭議,對專案只有雪上加霜!

其實專案延遲,一定是現況與當初所預定的計劃有了出入,有了當初未想到的問題!如果不能先找到問題的癥結,把一切都推到人手不夠,就算有一個功能強大的協同運作系統,也是無濟於事!況且新的成員對於協同運作系統也需要學習的時間,良好的協同運作系統,也僅能增進團隊運作的效率與效度!協助釐清專案的問題!但它可不是可以完全取代專案團隊在專案管理中的角色與功能。

增加資源(Crashing)所說的可不一定是加人,就算加人也要考慮幾個重點:
(1)時點:
專案晚期再加人,應考量新人學習成本與專案管理的成本,以及公司的成本!有時全面的考量終止合約,可能是比較划算的方案!

(2)經驗與配合度:
加入新的專案新成員,應先設定好他的角色與作用,需要何等程度的水平。先前肥蝦就遇過專案找進了一個經驗豐富的新成員,一來就批評那裏作錯!那裏不對!結果造成來一個走三個的困境。有時候,新成員的配合度比經驗還重要。

(3)其他選擇方案:
加快專案進度有很多種方式,基本上就有Crashing跟Fast-Tracking兩種!就算是Crashing也有提升開發環境與工具,採用外包把特定工作轉包,…。也不一定要直接於專案團隊中增加人手。

遇到專案延遲,專案經理應先跟團隊間開誠的找出問題根源,以及建議方案。如果需要加人,也要釐清新加入的成員所應負責的工作區塊,需要的技能與水準,融入專案所需要的時間。

專案成員對於變更控制程序應有的認知與責任


「Change Control Plan Preparation Guidelines」讀後感
原文:http://www.pm-i-study.net/dis/redirect.php?tid=127&goto=lastpost#lastpost

看了【專案管理交流論壇】成員Miller所上傳的「Change Control Plan Preparation Guidelines」後,肥蝦心中有一些想法,想提出與各位分享。

說實在的,「Change Control Plan Preparation Guidelines」是一篇不錯的變更管理計劃的範本,搭配文章中所提到的「Change Log」、「Status Report」、「Change Request Form」可以成為一個變更管理、監控與追蹤的完整架構。

文章中的章節-本文目的(Purpose of Document)、變更控制程序目標(Objectives of Change Control Process)、名詞定義(Terms, Acronyms and Abbreviations)、變更審核權限(Approval Authority for Changes)、變更控制委員會(Change Control Board)、變更控制程序(Change Control Process)、角色與責任(Roles and Responsibilities)-也是一般所常用到變更控制計劃的節次。各位讀者可以細讀這一份這11頁的指導手冊,相信可以有一個完整明確的瞭解。

肥蝦此時所要闡述的是,個人對於專案團隊成對於變更控制程序所要參與的程度,以及相關的權限設定。

在「Change Control Plan Preparation Guidelines」乙文中主要陳述專案經理(Project Manager)、專案贊助人(Project Sponsor)、變更控制委員會(Change Control Board),與變更控制委員會之上的指導委員會(Steering Committee)的互動與分工。文中並依據專案的大小與複雜程度,提供了假想的【簡易】與【比較複雜】的兩個層次。但文中就如PMBOK一般,並未對專案成員對於變更控制程序的參與程度,以及有關的權限多所著墨。

肥蝦也仿照該文的【簡易】與【比較複雜】的假設,提出個人認為專案成員對於變更控制程序的可能作法。
(一) 【簡易】
假設:系統分析、設計與程式人員,並未直接與使用者面對面溝通需求。

在此假設下,專案經理應設法瞭解客戶的需求背後目的與理由,協助客戶擬具變更的目的與要項,再請系統分析、設計與程式人員就需求提出意見與建議解決方案。如果專案經理並未具有相關的技術與商業邏輯能力,應先設法尋求團隊成員的協助。在客戶與專業的團隊成員間,扮演一個完善的中介界面,儘量設法不加入自我的主觀判斷。

(二) 【比較複雜】
假設:有專屬的需求分析人員,直接與使用者面對面溝通需求。

在此條件下,需求分析人員應先設法釐清變更後面的動機與原因,並由需求分析人員擬據與客戶討論過的解決方案。再經由填寫「Change Log」、「Status Report」後進行變更控制的流程。如果需求分析人員能自行處理,則專案經理僅需要經由以客戶具名填寫的「Change Log」,以及專案成員填具的「Status Report」的review與檢驗,確認客戶的需求是否有效的滿足;如果需求分析人員無法自行處理,再由專案經理、需求分析人員,與客戶進行溝通,瞭解客戶的真正意圖,確認需求分析人員的分析與建議後,請客戶在需求分析人員協助下填寫「Change Request Form」,再依據該文的流程處理。

此外,「Change Control Plan Preparation Guidelines」中以對專案預算與時程影響程度比例,為介定權責歸屬的依據。這雖然也是一個參考準則,肥蝦也建議就每個activity、work package的角度以及buffer與reserve的owner權限著手。

如果一個要求僅限定在特定的activity或work package,不影響到別個activity或work package的owner所定義的資源、要求與條件,原則上專案經理應尊重每個activity或work package owner的判斷與建議;如果影響層面牽涉到不同的activity或work package owner應由專案經理進行協調與掌控。

肥蝦所繪製的流程圖可加入原文的前半,以為更完善的變更控制程序流程圖。以上肥蝦的看法與作法,還請 各位先進給予指教與建議!

2009年5月14日 星期四

風險鑑別與管理工具-VIRT簡介


「Visual Ishikawa Risk Technique(VIRT) - An Approach to Risk Management」讀後心得
原文網址:http://www.pmi.org/Resources/Pages/Risk-Management.aspx

專案的本質就是【不確定】,因此如何管理、辨識、分析、回應與監控專案的不確定因素,對於專案的成敗有著非常密切的影響!在PMBOK Guide 2008的第十一章風險管理程序群組中列了六個管理程序-11.1 Plan risk management; 11.2 Identify risks; 11.3 Perform qualitative risk analysis; 11.4 Perform quantitative risk analysis; 11.5 Plan risk response plans; 11.6 Monitor and control risks-在鑑別風險程序所產生的risk register,持續地於整個專案生命週期扮演非常重要的角色,需要不斷的追蹤、更新與新增。

在肥蝦個人從事專案的經驗中,很少有專案團隊會專注於風險的管理。一來,是因為專案經理已經花費大量的精力,在滿足緊迫的時程與嚴苛的成本金額要求。二來,風險有點虛幻,因為還沒發生,所以很難擁有實際的感受與急迫感。三來,風險管理的工具,大多感覺太理論了,與現實的專案實際狀況好像有些脫節。

以往,肥蝦自己在整理風險因子列表,會先檢視專案的相關文件(如:合約、RFP、建議書…);接著詢問已有經驗的同事。再來就是憑藉相關的會議與自己的認知進行分析。在PMBOK Guide 11.2 Identify Risks也提出的七項工具-Documentation review; Information gathering techniques; Checklist analysis; Assumptions analysis; Diagramming techniques; SWOT analysis; Expert judgment。

在鑑別風險因素的程序中,肥蝦個人的慣常作法:(1)先進行SWOT的分析區分出幾個風險類型群組。(2)根據每個風險類型群組思考可能的潛在問題(其實肥蝦之前很少考慮到機會)。(3)思考每個風險間可能存在的關聯性。(4)建立風險清單,標明序號、等級、風險類別、風險項目與內容、負責人、狀態、登錄日期與備註。

但肥蝦遭遇最大的問題是溝通,因為風險清單是以表列與文字的方式呈現,所以很難讓團隊成員或長官瞭解整個風險的架構跟全貌。一旦逐一就每個風險因子進行討論,常會陷入「見樹不見林」的窘境。僅針對每個風險項目深入討論,有時所提出的意見會牽扯到其它的風險因子;但是在缺乏整體架構的討論基礎下,有時會產生太過或不及的回應與處理方式。

Rubin Jen於PMI網站所發表的-「Visual Ishikawa Risk Technique(VIRT) - An Approach to Risk Management」說明了一個風險管理的圖形工具(VIRT)。文章也闡述了風險管理的基本概念-【Risk management should not be performed in isolation and must be performed as a group, while being championed by the project manager.】,以及使用VIRT的步驟-(1)建立風險分解結構(Create the RBS)。(2)鑑別專案失敗要點(Identify Points of Failure)。(3)鑑別顯著的障礙(Identify Significant Obstacles)。(4)分解專案失敗要點至風險細項(Decompose Points of Failure to Detailed Risks)。(5)完成後續的風險管理活動(Complete Following Risk Management Activities)。(6)運用至持續狀態報告與重複狀態顯示(Apply to Ongoing Status Reports and Recurring Status Presentations)。

Visual Ishikawa Risk Technique(VIRT)是一個以圖形呈現與分類風險因子的工具。以圖形陳列出高階的風險群組與風險因子,在依據每個高階的風險因子,繼續探究其下的相關風險要項,其間用實線描繪出風險因素間直接的關聯性,如此可以呈現出一個風險的整體架構,也易讓人具有完整的印象。

肥蝦深覺VIRT是一個不錯的鑑別、追蹤與重新檢視風險的好工具。以肥蝦個人的愚見:如果再以虛線描述之間的不同群組或類別間風險因素的互動,如此將更能助益於之後的風險回應計劃的討論與建構。本文所展現的圖形,即是肥蝦個人稍加修改過的圖形表示法。但是麻煩的是會把圖形弄得非常複雜,因此肥蝦利用MS Visio的圖層屬性去分層表示以保持圖形的明確性與可見性。

本文附屬的圖片,所表現的是肥蝦近來負責內部研發專案的風險清單中的部份項目轉化為VIRT的樣貌。黑框藍底的方塊表示可能導致整個專案失敗的Failure point;紅色橢圓表示主要的風險要素;褐色方框表示次要的風險要素。

其中肥蝦以綠色的虛線表示不同Failure point下風險要素間的邏輯相關,如【外面訓練課程不符合實際需求】與【三個月內完成第一階段雛型】,以及【內部研發成本限制】三者之間也有緊密的互動;【跨部門合作溝通】與【組織部門間成本計價】也有密切的關係。這些關聯的風險因素在後續進行風險質性分析與量性分析,以及擬定回應計劃,都會存在TRADE-OFF或相關性的依存關係。

以上是肥蝦的個人淺見,還請 各位先進不吝指教!

2009年5月13日 星期三

Project與Project Management的差別!


有些朋友在面對專案跟專案管理、專案計劃跟專案管理計劃,有著模糊與存疑的態度,不太明瞭其間的異同。其實在PMBOK Guide 2000之時也把兩者攪混,直至2004與2008才明確的區分兩者的不同。

在PMBOK Guide 2008的第一章第二節與第三節,分別闡述什麼是專案(1.2 What is a project?)跟什麼是專案管理(1.3 What is project management?)。雖然專案管理指導手冊(PMBOK Guide 2008)中對專案定義為:「進行一段時間地努力,去創建一個獨特的產品、服務或結果。」;專案管理就是:「應用知識、技巧、工具與技術去達成專案的要求。」

說實在的,肥蝦對指導手冊中對專案管理的說法不甚滿意。肥蝦比較偏好用企業與企業管理的解釋邏輯,去解釋專案與專案管理。

以一般公司行號來說,企業就是人與資源的實體存在集合體;公司目標就是公司法第一條所序:「公司以營利為目的。」而企業管理就是組織、規劃、領導、指導、執行、控制、監督等行動或作為,去達成營利的目標。

而專案與專案管理與上述是反過來的,專案是為達成一個特定的目標,所存在人與資源的暫時性集合體。專案管理就是為經由規劃、組織、領導、指導、執行、控制、監督等行動或作為,達成專案目標。

因此肥蝦把企業與企業管理,認定為是由內而外的互動循環;而專案與專案管理,是由外而內的互動循環。

專案的目標大體上是由外來的因素決定的。目標是先設定的、是外來的,選擇執行那一個專案也是企業先行決定的。在PMBOK Guide 2004將Project Selection Methods設定為發展專案許可證(Develop Project Charter)的一個工具技術(TT);在2008版則將其刪除,而在投入中新增一個Business Case,肥蝦以為這是比較貼近實務的現況。在一般公司的運作中,選擇一個或數個合適投資的專案,大多也是另一個專案,而此專案的目標是「最有效率與有效性的達成公司已定義的公司策略。」

當選擇特定專案後,為延續與追蹤的考量,應把公司策略、所要達成的策略目標、選擇此專案的理由等Project Selection Methods的投入與產出,列入專案計劃中的第一章源由或目的。依據此目的,進一步標示所要達成的實際與可見的成果,以及確認達成目標的檢測標準。

而專案管理就是要在專案要求之下,規劃、組織、領導、指導、執行、控制、監督等行動或作為,籌建一個暫時性人與資源的集合體,去完成專案目標。

那何為專案計劃與專案管理計劃?其間的差異何在?

專案計劃其實標準範例很多,大至行政院的施政計劃、小至一般家庭的購屋計劃,都是標準的專案計劃。專案計劃大多會先述及專案的背景與源由,專案所要達成的內容與目標,需要的資源,專案交付物的內容,專案的成效,專案的期限。

專案計劃書的重點是陳述-Why為什麼有這個專案;What專案所要達成策略目標的內容;When此專案在公司策略的要求上,應該要何時完成,或者每個重要時點的重要產出;Who公司內部的主導部門。

專案管理計劃所述的主要會集中如何達成專案的策略目標與要求-How執行專案的方法與戰略依循;What組成專案要求的成份內容;When在專案策略期限下的執行時程;Who專案工作的實際負責、執行與監控人員(小組);Where每項專案工作的作業地點;Why每項專案工作的發展原因與使用工具的原因。

專案計劃書中對於專案的內容與時程,就會是4.1 Develop Project Charter的投入-Project Statement of Scope與Business Case-的主要依據。

那專案計劃書與專案管理計劃的順序性如何呢?以肥蝦個人的經驗,基本上是Start-to-Start的依賴關係。在專案目標與要求確定後(不是專案計劃書完成後),其實就可以開始進行專案管理的程序與活動。

也許有人會問:「那在沒有Project Charter下如何進行專案管理活動呢?」如果在專案計劃中掛名的主要負責人員或組織部門,其實很多就是公司內部此專案的Sponsor(公司最大的Sponsor是董事長/總經理,但此專案的Sponsor可能是一個事業群的副總/協理)與負責部門。在實務上,執行部門的主管就會先行指派特定人或一組人馬開始擬定專案管理計劃。執行權力的來源與型式,很多是執行部門的內部的會議記錄、或口頭佈達、或備忘錄等非正式的溝通型態。此時除研擬專案管理計劃外,也會同時起草專案許可證。尚在起萌的階段,所需要跨部門溝通時,會由(或透過)部門的主管進行或協助下進行。

此外,在專案管理計劃的擬定上,也非一定依照PMBOK Guide的順序依次執行,也有可能是平行進行的。PMBOK Guide所說的Progressive elaboration(rolling wave planning)大多是進行專案管理規劃的進行方式。而且範圍、時程、成本、品質、人力、溝通、風險與採購管理群組的規劃作業,是互相糾葛,有時很難明確切割。但最重要的是專案管理計劃必須具有一致性,因此PMBOK Guide 2008將所有的計劃產出都匯入4.2 Development Project Management Plan後,再行匯出為其他程序的投入,是符合實務的,其目的就在要求專案管理計劃的一致性。

肥蝦拉拉雜雜的寫了一堆,為了說明肥蝦的認知,個人舉一個生活上的購屋還款計劃,來說明專案與專案管理。

(一)購屋還款計劃
(1)專案目標:在二十年內,還清五百萬的房貸。
(2)專案計劃:於每月的二十日前,須要籌足本金二萬一千元與依據特定利率計算的利息。

(二)購屋還款管理計劃(不用initiating process group的活動了)
(1)專案管理目標:如何從每月的收入,扣除生活必要開支後,擠出每月的本金加利息的還款金額。

(2)起始作業:
還款人就是我;來源就是每月的微薄收入;利害關係人是XX銀行。

(3)規劃作業:
(a)支出方面:檢討每月生活開支項目,並進行必要性的確認。預估生病或突然狀況所可能引發的支出(風險)。
(b)收入方面:先考量失業所可能帶來的問題,以及因應之道(風險)。其次,考量增加收入來源的可能性與作法(如:每月買一次樂透)。
規劃作業產出:每日允許之生活開銷計畫、每日生活開銷記錄表。

(4)執行作業:
每日要花錢前先檢核該商品或支出是否列入專案每日允許之生活開銷計畫中的允許項目。支出後應確實填入當日生活開銷記錄表。

(5)監控作業:
可再細分為:
(a)執行績效的監控:每日睡前,針對實際支出與預計支出進行比對。
(b)每日允許之生活開銷計畫檢討:所列項目是否合理,如漏列了衛生紙的開銷,那總不能不用衛生紙!所以只好回頭修改每日允許之生活開銷計畫。
(c)專案管理目標的監控:貸款銀行的利率是否比其他銀行高?是不是要轉貸,以降低還款的利息金額。

(6)結案作業:
拿到銀行的還款完結證明文件。

以上是肥蝦的個人認知,還請 各位先進不吝指教與給予指導!

時間表的用途-"Making Things Happen" Chapter 2


歐萊禮所出版的「專案管理之美學-讓事情發生(Making Things Happen)」(Scott Berku著,陳建勳編譯)的第二章-【時間表的真相】,提到時間表(Project Schedule)有三個用途。肥蝦覺得非常好玩與有意義,因此予大家分享個人的心得。(以下將文中的時間表"schedule"改稱為時程表,以配合肥蝦自己的用法;大陸的PMBOK Guide 2008簡中版稱"schedule"為進度計劃。)

肥蝦在未看到本文之前,一直認為時間表僅是定義工作作業的起、迄時間,以及作為監控管理的用途-就是公司用來迫害專案工作人員的工具。當然從PMBOK Guide 2008的角度看來,時程表(Project Schedule)除了是監控時程的重要投入外;也是估計成本、決定預算,以及計劃採購的重要參考依據(input)。

但是Scott Berku所提出的三個用途:
(1)對事情何時完成許下承諾。
(2)鼓勵每個人將其付出視為整體的一部份,並盡力使其工作能和他人配合。
(3)提供一個追蹤進度的工具,並把工作切分成可管控的小部份。

第三點在PMBOK Guide中有著明白的解說,實際從事專案的人也有過切身被"傷害"的經驗,肥蝦就不在多說明。

第一點則是一個心理作用,有一個明確的完成時間,就好像給了客戶與內、外相關的利害關係人,對未來一個承諾一樣。這就好像男女交往當初,男方發誓說:「我會永遠愛妳!」一樣,大多不切實際,但對女方確很受益,男方也有了進一步行動或需索的藉口。

在肥蝦個人的經驗上,最後定版的結案日期很多是來自專案團隊之外的要求。比如:合約上的日期(有些議價方式的合約,專案團隊會跟客戶進行協商,但最後還是由客戶決定)、法律的落日條款、行銷部門的要求、長官的決定…。

專案的最原始假設(或說幻想):就是專案所交付的產出、服務或結果是一定存在的,也會如期在特定日期產生。依憑於此,專案贊助人(Sponsor)或客戶(Customer)才願意把資源投注在專案的身上,就比如男方發誓說我永遠愛您後,女生才有可能委身於他(不過現在很多一夜情或…,不在觀念呆板的肥蝦理解之內)。

第二點則是肥蝦覺得最有趣的。從PMBOK Guide 2008的觀點來論在6.5發展時程表之前在6.2排序活動項目下的專案時程網路圖(Project Schedule Network Diagrams)就會標明出每個活動的順序與依存關係,就是每個人工作的關聯性。這依存關係與專案時程中定義的完成日期,有著關係,但確沒有絕對的關係。因為就算專案延遲,這每個活動間的依存關係依然存在,除非一開始專案活動間的排序是不合理與盲目制定的。但這背後所發揮的對團隊成員的推進作用(forcing function)的心理活動-事情一旦發生,能自然而然的迫使觀點、心態或行為改變,就稱為推進作用。這個心理因素肥蝦有深切的經歷,但在Scott Berku未標明前,肥蝦還沒有深切的思考過。

時程表的完工日期,背後是一個機率的概念(此書與「與熊共舞」、「關鍵鏈」、「人月神話」以及一些專案管理書籍都是此種觀點。)機率在實務上,是客觀跟主觀的混合產物!在統計或機率學上,機率是企圖去猜測上帝的未來作為。任何機率的分配都有很多的假設與限制,能提供一些客觀的分析;但如何確認自己所處專案的情況符合特定的假設與限制則就有很多主觀的因素在內。

最重要的主觀因素就是"你相不相信",對專案的利害關係人因為所處位置的不同常會有不同的認定與理解。

一般人會為可能達成的目標努力奮鬥;但不會對絕不可能有機會成功的事情打拼。因此如何凝聚,以及延續大家的機率共識,是很重要的!

之前,肥蝦也碰過一些情況,當公司內部於選擇專案之時,重要高層對於一個近新台幣三億元金額的案子有95%的人認為絕不能成功(機率為0%);另一部份的人認為是沒問題(機率為100%)。但是不幸的是有決定權的人就在5%的人裏面(這其中,竟然還有因為子公司的一位副總),因此有決定權的人決定引進子公司的人,擔任最重要的角色(專案經理與AP組長),而且是以T&M的合約方式引入。

專案初始時期,團隊成員已經缺乏對完工日期達成機率的共識,進入規劃的搜集需求與差異比較後,團隊成員對於達成完工日期的機率是大幅下降。更嚴重的是。來自這些子公司的重要成員眼見專案無法如期完工,竟然開始閃避與推拖,更使得團隊成員的信心瓦解。因此專案的下場可以想見。

因此時程表背後所代表著的信心機率,是一個專案成功與否的重要立基!雖然專案延遲,如果沒有外在的限制下,而且專案團隊與客戶或利害關係人認為延後完工日期後成功的機率是上增的!那專案將會繼續執行直至這機率降至無法接受的地步。

2009年5月11日 星期一

專案經理追求的修為-"Pursuing the Perfect Project Manager"讀後感


近來正開始翻閱Scott Berkun所著的"Making Things Happen"(專案管理之美學-讓事情發生),對於第一章「專案管理簡史」所提到Pursuing the Perfect Project Manager乙文感到非常的好奇,因此依據書中所記載的網址(http://www.tompeters.com/col_entries.php?note=005297&year=1991),上網複製原文內容,細細拜讀了一番。

針對文中所提到的八種相互衝突的特質─1. Total ego/no ego(自我/無我);2. Autocrat / delegator(獨斷者/委託者);3. Leader/manager(領導者/管裡者);4. Tolerate ambiguity/pursue perfection(忍受模糊/追求完美);5. Oral/written(口頭/書面);6. Acknowledge complexity/champion simplicity(承認複雜/支持單純);7. Think big/think small(思慮廣懋/思慮精微);8. Impatient/patient(急迫/耐心)。─必須內化於一個優秀的專案經理,深感贊同,但也覺得惶恐。贊同的是:專案本來就是要面對複雜、不確定的環境,努力追求一個被認同、有效的結果。惶恐的是:這八種特質真的是很難以學習跟內化。

在拜讀之後,肥蝦把這八個特質區分為專案經理的心態、思考、行動與經營四個層面。

(一)心態:
Total ego/no ego(自我/無我);Impatient/patient(急迫/耐心)
專案經理應該要比專案成員投入更多的心力在專案上,對自己負責的工作與要求,必須能以「日日新、茍日新」的心態,不斷的催促自己往前邁進。但對於專案成員負責的相關工作,必須能讓成員去追求表現與成長;必須能"寬"以待人,以"共工"的態度對待相關的專案成員與協力夥伴,對於成員的意見與反應必須能寬容的對待與討論。
以下是肥蝦的一些想法:
(a)專案的成功是成員一起開創的,不是您"英明"的領導。
(b)成員的問題是您的問題;您的問題千萬不要變成所有成員的問題。
(c)身教重於言教,身體力行取代碎碎念。

(二)思考:
Tolerate ambiguity/pursue perfection(忍受模糊/追求完美);Think big/think small(思慮廣懋/思慮精微)
專案本質就是模糊與不確定。專案經理應該具有一個思慮清晰與條理分明的的頭腦,在模糊之中應設法釐清其間的脈絡與層次;在不確定之中捉住重點與順序。
思考上,應先以鳥瞰的方式,試圖捉取全貌,並加以分類;再設法以關鍵因素/不同的使用者角度,去深思其間的影響與互動;經由以上二維的角度切割出不同的區塊;針對每個區塊再行仔細思索,追求每個區塊明確的意圖。接著從明確的區塊,再回頭組合成專案的全貌與架構。如此重覆的反復思考才能儘量貼近事實的真象。
在這思考的過程中是非常耗費心力的,也不斷的有所疏忽!因此自我的心態調整與壓力舒緩是很重要的!不要把壓力直接呈現在成員面前,也千萬不要把壓力累積在自己的心頭。

(三)行動:
Oral/written(口頭/書面);Acknowledge complexity/champion simplicity(承認複雜/支持單純)
一個專案的工作非常的繁瑣。上至專案管理計劃,下至例行會議的舉行與記錄;內與團隊成員間彼此的溝通;外與客戶、長官等人的協談,這諸多的事前、事中、事後工作,都需要去執行與管理。如何將複雜的事項與因素,轉化為簡單、明確的工作事項與作業流程;如何有效的宣導、溝通、記錄與追蹤,這需要"眼高手低"的行動準則,採用合適的溝通管道與方式。
專案管理工作目的,在協助專案工作的執行與完成。千萬不可將手段目標化,造成團隊成員疲於滿足管理工作要求,而佔用了執行專案工作的時間與資源。

(四)經營:
Autocrat / delegator(獨斷者/委託者);Leader/manager(領導者/管裡者)
在專案團隊的經營上,專案經理應記住的是:「不要急著去解決成員的問題,當他們可以自行處理時!」專案經理的首要工作應是主導專案團隊的正面氛圍,以及創造前進動力的因素。在專案團隊的正面氛圍與創造前進動力的因素上,個人以為可以扮演獨斷者與領導者的角色;對於專案成員間的溝通以及成員的工作上,應該要以信任的態度,以及從旁協助管理的立場,則以一個委託者與管理者的角色出發。

以上是肥蝦的心得與感想,還請 參考原文,以及「專案管理之美學-讓事情發生」的第一章「專案管理簡史」給予肥蝦一些批評跟指教。

2009年5月10日 星期日

推薦一個不錯的新專案管理論壇


這個論壇剛成立不久,專注在專案管理的領域,感覺也很中立,肥蝦也在其中貢獻小小的版面,還希望大家能多多共襄盛舉!

肥蝦衷心希望專案管理能在臺灣蔚為風潮,在基礎的專案管理與作業上能走向一定的制度與架構;並能傳遞前輩與大家的心智精力,讓臺灣的軟性產業與服務業,能在國際市場上一爭長短!

論壇網址

http://www.pm-i-study.net/dis/index.php

2009年5月9日 星期六

問題,真得是問題嗎!-"你想通了嗎(Are you lights on?)"


本書如同"從需求到設計(Exploring Requriements)"一書,也為溫伯格(Gerald M. Weinberg)與高斯(Donald C. Gause)合著。本書的重點在闡述問題的界定、發掘與陳述,提供了如何去釐清問題陳述的方法。本書與肥蝦先前所閱讀的"發現問題的思考術(Professional Problem Finding)"(作者:齋藤嘉則)有著同工異曲與互補之妙。齋藤嘉則的重點則在分析"未來願景"與"現狀"去找出問題;溫伯格強調問題的陳述與自省。

肥蝦以為溫伯格所強調的問題的循環:問題=>解決方案=>解決方案所帶來的新問題=>解決方案=>解決方案所帶來的新問題=>…。說明了問題是永無止盡與無法百分之百解決的,但是要藉由問題釐清、思考、分析、陳述;進而界定功能、特性、限制、偏好、期望,轉化為可解決方案的空間;轉化為設計,以提供特定客戶與供應者可接受的解決方案;重新追蹤原問題與鑑別新問題;重新不斷地循環,以將期望與滿意度之間落差縮小至客戶可容忍(tolerance)的範圍內。

本書內容區分為六大部份:(一)問題是什麼-定義問題(Definition);(二)這是什麼問題-問題定義(Analysis-What is the problem?);(三)真正的問題是什麼-問題溝通(Communication);(四)這是誰的問題-問題共同化(Analysis-Who has the problem?);(五)問題是從哪來的-自我反省(Analysis-Where does the problem from?);(六)我們真的想解決問題嗎-回應到目的(Problem and solution must be return to the business need)。

以下將各部份的重點摘要如下:
(一)問題是什麼
(1)問題是期望與感受間的落差;問題是Expectation與satisfaction的落差;問題是未來的願景與現狀的落差。
(2)解決問題可以考慮改變期望?或是改變感受?還是兩者均設法改變。

(二)這是什麼問題
(1)不要把問題的解決方案當作問題的定義(尤其解決方案是自己提出的時候),回復問題的原貌,試著用不含解決方案的語意去陳述問題。
(2)你永遠無法確定自己是否已經取得了正確的問題定義,甚到到了問題已被解決!但決不要放棄追求一個正確的定義。

(三)真正的問題是什麼
(1)解決方案引發新問題與不合身,一旦設定任何決定其實就給定了範圍與限制。
(2)問題陳述需要不斷重覆調整,直到問題清楚的進入每一個人的腦袋。
(3)釐清問題陳述的方法:
-按順序強調一個字詞。
-字典法。
-肯定與否定互換。
-強迫語句與可選擇語句的互換。
-所有格的互換。
-頻率用字的轉換。
-籠統字眼的特定舉例與明確描述。
(4)定義問題應回應到真正原始的目的。

(四)這是誰的問題
(1)問題的共有化,解決問題的人必須要跟問題有實際的關聯。
(2)不要急著解決別人的問題,如果他們可以自己解決很好的話。意即要克制自我膨漲的欲望,先設想與尊重對方的立場。
(3)提供別人問題的解決方案,有時不如一個簡單的提醒。

(五)問題是從哪來的
(1)問題基本上都不會是從"自然"而來,但確是推諉問題的最佳藉口。
(2)問題的來源大多跟自己有密切的關聯(53.27%問題是出問題解決者身上)。

(六)我們真的想解決問題嗎
(1)人們很少知道他們的真正需求是什麼,直到你給了他們要求的東西。
(2)到了最後分析階段,沒有多少人真的願意想解決問題。
(3)解決方案絕對沒有所謂的絕對完美,因此不要想著不斷修改解決方案,達臻所謂的絕對完美。
(4)問題解決方案提供者,一定要忠於自我,忠於專業。

肥蝦以書中的一句話:「可以確定的是,大多數的人都認為自己知道問題到底是什麼,然而,實際上他們通常是錯的。」與各位共勉,還請 指教!

2009年5月8日 星期五

推薦微軟的一位技術經理的程式開發專案管理專欄


昨日有幸與一位微軟的技術經理-周旺暾先生見面,看著他名片上的PMP標識,因此上去台灣的MSDN看看,結果到他所撰寫的程式開發專案管理!

雖然專欄內的篇數不多(僅有三篇)時間也稍嫌久遠,但文章的內容非常不錯!
1.成功開發團隊的八項特質 (2005 年 3 月)
2.軟體架構師的成功秘訣 (2005 年 1 月)※第二篇應該是【程式開發工作的時程預估】。
3.談程式開發專案進度管控 (2004 年 12 月)
大家可以上網參考!
http://www.microsoft.com/taiwan/msdn/columns/PMP/default.htm

肥蝦對於【成功開發團隊的八項特質】乙文最有感觸!近來負責的研發專案,由於團隊成員缺乏一個成長與激勵自我的態度,在溝通與願景的凝聚上困難重重!
特別把八項特質列述於下,以供肥蝦與各位先進一同勉勵與參考!
1.促進開放的溝通
2.為共同的願景工作
3.授權給團隊成員
4.建立明確責任並共同負責
5.專注於提供商業價值
6.為了變動, 隨時保持最佳的彈性
7.投資於品質
8.從經驗中獲得學習

2009年5月5日 星期二

Five ways to make or break your team


PM Network Vol. 23, No. 4, Page 53-57.
本篇文張舉出了五個會嚴重破壞專案團隊的五種狀況─(一)失控的會議。(二)隨機變更專案的方向。(三)利害關係人的過份需求。(四)未預期延遲。(五)專案人員的爭執。─這種情況在肥蝦的專案經驗中其實常常遭遇,對於專案的進行,以及專案成員間的和諧,真得有莫大的衝擊。文中提供了一些實務的經驗予讀者分享,個人認為非常具有參考性。因此肥蝦特就文章內容,並對應個人的經驗,分述五種情況的核心,以及可能有效的建議。

(一)失控的會議(Out-of control meeting):專案從啟始到結束總有不斷的會議要開-kick off meeting, group progress meeting(Daily), status review meeting(weekly, project performance report meeting(monthly), change control meeting, project management meeting…。但經常都是流於形式,參與者大多不知道會議的目的與要求;或是成為長官單向佈達的會議,無法真正的有效溝通,更進而長官們厭倦聽到問題;簡報的資料一再重複,會議資料與實際狀況嚴重脫節,無法真正的反應現況,更進而專案經理或長官玩起數字遊戲,藉由變更計算方式粉飾太平;與會人員雜亂,主題失焦…。這種種的會議惡象,我想很多人都有經驗。

在本文中提供了一些方法試圖杜絕上述的惡果:(1)聚焦:每個會議必需有確定的目標與議題,切忌離題。(2)慎選與會人員:會議人數應適當參與人員須對會議主題有明確相關。(3)訂定基本規則(ground rules):遵守既定的規則獲取與會人員以及未與會人員的信任。(4)限制會議時間:會議應有明確的起始與結束時間,冗長的會議徒使與會人員喪失注意力。(5)確保會議是雙向(上層與執行者)有效的溝通。

(二)隨機變更專案的方向(Seemingly random changes in project direction):專案管理計劃最重要的是標明what、when、how、who (why基本上會建議寫在project document)去執行一個專案。因此專案的目標必須非常明確;標明每個特定區間與milestone的重點,專案成員才有依循的努力方向。

但是專案的本質就是【變化】,在遭逢無法避免的改變下,惟有開誠佈公的跟專案團隊說明變更的理由,大家同心合意下,才能化解因為專案方向變更,所導致成員戰鬥力的衰減。試想,如果專案方向經常在成員無法獲知、無法理解的情形下變更,專案成員將會如何迷失工作的方向,喪失鬥志。當一個人不知道今天或以往的努力是否有效的情況下,誰願意去努力達成目標。

(三)利害關係人的過份需求(Overly demanding stakeholders):在專案的進行中利害關係人(包含使用者或客戶或公司高層)常會無端的加進很多臨時的要求。這不只發生在客戶身上,更常遇到的狀況就是公司內部的高層,常會為了某些理由(如公司管理…)要求專案成員提供相關的資料或報表,更可悲者,還會限定交付時間。

一般的情況下,每個成員在瞭解專案的目標與方向下,大多會擬定每日的工作進度與內容。突然安插的要求,常會導致成員淪落於疲於應付非專案主體的工作。此時專案經理必須有所擔當,除了建立一個暢通完善的溝通管道與流程,應將要求記載於書面,獲致正式的同意,按照標準的作業流程處理;對於不合專案目標的要求,應該要明白的向要求來源陳述事實跟現況,爭取有利與合理的作法;對於不可避免的要求,也要向成員坦誠的溝通,獲取成員的支持。

(四)未預期延遲(Energy-zapping soul-sucking unexpected delays):專案的任何計劃均無法保證百分之百無誤,難免會有疏漏或執行上有所錯誤,進而影響專案的時程。因此最重要的處理方式就要是向成員充分的揭露,發現問題,戮去解決,保持專案不斷的往前進行;而不是去找個替罪羔羊,想個卸責的藉口。因此在遭遇某些問題或發現疏失,第一步是要向成員主動的說明。再來,就是與團隊中的相關人員商討解決的辦法,凝聚團隊的共識,朝向克服問題與達成專案目標前進。

(五)專案人員的爭執(Team squabbles gone awry):專案團隊間常會諸多因素引起爭執或紛爭。雖然PMBOK說明要求爭執的雙方先行協商合解;如果無法獲致解決爭端的方法時,再由專案經理介入。但在本文中要求專案經理應立即安排面對面的會談;如果無法解決,接著是專案經理與爭執的雙方依序的一對一面談;如果確定爭執雙方無法在一同合作之時,專案經理應透過上層管理階層留下對專案有較大的貢獻者。

針對上述五種情況,肥蝦認為主要可歸類於專案的溝通管理(失控的會議、隨機變更專案的方向、利害關係人的過份需求、未預期延遲),以及人力資源管理(專案人員的爭執)。由於專案的本質就是要集聚特定人員與資源的力量,處理變化難測的狀況,達成既定的目標。因此對於專案團隊、公司內部以及客戶,首要的是建立"信任"的關係。

如果客戶能相信您與所有專案成員,都是為了建置一個為客戶設想的系統的前提下,對於雙方的溝通奠定穩固的基礎,在共通的基礎與限制上,雙方才能進行折衝商談,共同追求一個較佳的解決方案。肥蝦至今的經驗還沒有遇到一個案子,客戶擺明就是要您掛掉的狀況。一旦專案無法完成,不只會對vendor side造成傷害,對user side也有一定程度的損失,惟有設法使客戶認清這個事實,才可以有效減少客戶過份的要求。

在公司內部的溝通上,也是如此一旦公司上層懷疑或認定專案出現問題,上層主管將會不斷地想探索專案團隊,甚至每個成員,每天的工作內容與進度。如此一來專案成員會光填寫報告與進度回應將浪費掉無數的寶貴光陰,進而使專案停滯不前。坊間很多專案管理的工具或方法論,但實行的結果往往本末倒置。原本為著加速與方便控管專案的管理流程,反過來變為成員每日的主要工作。因此專案經理應設法強化公司與專案間的溝通,扮演一個折衝的角色,必要時應坦白的向上層反應。說句實在地,如果上層執意如此,並可預知將造成團隊的生產力與士氣蕩然無存,與其委曲求全,不如另謀他路。

至於處理專案成員爭執的作法,每個人基於自身的經驗與瞭解有著不同的作法。個人能認同文中所說:「專案沒有時間可以浪費。」因此先由爭執雙方自行處理可能無法獲得滿意的答案。以肥蝦個人的經驗,會建議由專案經理與爭執雙方一同與會討論。但是會前專案經理應設法私下分別與爭執雙方以及相關的周遭成員討論,設法釐清爭執的"起源"-工作界面不明、專案資源爭取、或個人情緒問題…。不同的爭執原因應有不同的處理方式。如果是雙方個人情緒上的問題,已經無法排解,我會建議如溫伯格(Gerald M. Weinberg)在"從需求到設計(Exploring Requriements )"乙書中所說的讓雙方都離開團隊,以免可能造成留存的人自大的心態。

2009年5月3日 星期日

有效收集需求-"從需求到設計(Exploring Requriements)"


溫伯格(Gerald M. Weinberg)在IT軟體專案管理界是耳熟能響的國際大師,伊寫了一系列的專著,都是專案管理人士的必讀經典。本書為溫伯格與高斯(Donald C. Gause)合著,主要在探討如何有效的釐清客戶的期望,以精確、正確、完整,且保留應有設計空間的去記錄使用者的需求。個人以為每章之後的摘要,敘說why(為什麼?)、when(何時?)、how(如何?)、who(誰?)可說是精華中的精華、值得一再的閱讀與深思。

本書區分為五大部份:

第一部 先有一點共識:語意曖昧(ambiguity)是整個需求要件(requirements)作業的最大問題,因此如何有效的釐清需求,並建立與客戶間的信任關係,是收集需求階段的最重要目標。

第二部 起步的方式:需求要件作業重點在縮短客戶的期望(expectation)與感受(satisfaction)間的落差。在探訪需求之前,雙方均一同假設解決方案一定存在,再經由有效的訪談、找到對的人與群組、有效的會議、不斷澄清與調查,去減少語意曖昧的字句與敘述。

第三部 探所各種可能性:說明經由有效方式,集思廣意去擴大解決方案的基底。

第四部 釐清客戶的期望:逐步以功能、特性、限制、偏好、期望的作業程序,從解決方案的基底,進一步獲致一個合理與認可的解決方案空間。

第五部 大幅提升成功機率:應儘量設法將解決方案的界限與問題加以數字化與圖表化,藉由一些有效的工具─技術審查、滿意度的檢測、黑箱測試案例、與現有產品的比較與區隔─達致雙方一致的意見,雖然承諾繼續溝通,但以獲得客戶有效(sign off)的認可,為一切的後續作業核心。

本書提供了很多有效,而且實用的工具,如:叢群法、決策樹、使用者分類法、功能表、特性表、所值幾何圖(what-if worth) 、期望表、語意曖昧的衡量指標、滿意度測試、黑箱測試案例等等,協助分析人員有效地搜集、彙整、分析,以產出精確、正確、完整,且不失嚴苛的需求文件。

文中也對如何舉行一個有效率的會議(一般的討論會議、激發創意的腦力激盪會議、技術審查會議) !如何進行訪談!如何進行開放式問題詢問!如何調和衝突!如何界定解決方案的適當空間!均提出不少有用的建言、規則,與應注意防範的重點。

本書也一再強調:收集需求重點,不但在產出有效的需求文件;也在經由建置、研議、探索需求的過程中,獲得重要的收獲,回饋至專案的成功。因此過程與結果是同等的重要。

書中以兩個例子貫穿本書探討的所有主題:一、超級粉筆專案。二、電梯資訊裝置專案。因此對沒有IT背景的人士而言,閱讀起來也一樣"輕鬆愉快"。

書中對肥蝦啟發較大的有:

(1)不可將困難的部份留給他人處理。各人對圖表的解讀不同,務要接受不同的解讀意見;而不可要求齊一意見。並且要確認每人都可以瞭解與使用,相關的圖表與方法。

(2)使用圖表的目的應根據我們現有手上的工作類型,以及希望避免的錯誤(使用工具;而非被工具使用)。

(3)使用者的確認(Identify stakeholders)後應再繼續將其分別群組;並列示產品(product, service or result)對使用者的態度-friendly ,Ignore, Unfriendly。鑑別使用者或利害關係人是專案初期(initial)的重要工作,但肥蝦往往並不會再加以分類;並記錄產品對使用群組應有的態度,以致後續在處理需求變更或相關變更、修正的議題時,迷失的應有的立場與態度。

(4)偏好的度量與以圖形化表達需求、期望與限制。肥蝦非常喜愛作者於第四部份-藉由功能、特性、限制、偏好、期望-這五個步驟,來建立一個解決方案的有效空間的說明。

(5)對於專案決策的分類-選擇(基於有意識的思考判斷) 、假設(未察覺、偏見、資訊不足、錯誤判斷)與強迫(法律、習慣、高層指示)-應加以區別,並寫下原因。以便後續可以追溯決策立基的緣由,檢視其是否已經不存在或異動,以擴大專案成功的可能性。

(6)凍結需求要件是一種妄想,收集需求的最後一個步驟是:雙方同意繼續溝通。但可以進行下一階段作業的前題是:有足夠的同意書(客戶簽字) ,以及有效的需求收集程序。

(7)培養自己以專業做事的勇氣,以及至少要將一半以上的時間花在自己的身上;而不要被技術層面的事務,或為他人進行協調佔據所有的時間。

本書不但是一本探索如何作好需求文件的說明書籍,更可以當作是一本工具書。對應於PMBOK 5.1 Collect Requirements有著幾近完美的闡述,與詳盡的作業說明。

The Global Risk Factor


PM Network, vol. 23, No. 4. Page 34-39

此篇文章一開頭以去年十二月所發生義大利與埃及間的海底電纜斷線,說明目前專案國際間合作模式所遭遇的風險因素與風險考量。主要可說集中在PMBOK方法論架構中的第十二章(外購管理)與第十一章(風險管理)。

由於國際間因為國家間藩籬的降低,以及網路無國界,專案經理為追求預算的最大效益與縮短開發的時程,會考慮將專案的部份工作(task)或工作包(work package)經由採購(procurement)的方式轉移出去。但如果轉包予國外的廠商,就必須考慮到國際間的溝通、不同國家間的文化差異,以及外包商所在國家的國家風險等,不同於一般專案所認知的風險。

該文中所提及的風險,包含供應商所在國家的政治、經濟的動亂到恐怖攻擊、重大公共基礎設施的損害(如本文一開頭所提及的海底電纜斷線。)、當地流行疾病等都應列入考量,並提出適當的風險因應對策(contingency plans, fallback plans, workaround),以減緩所遭受到的衝擊。其所建議的方式有:(1)一定至少一次的面對面溝通。(2)將外包商結合至整體專案的利益。(3)儘量分散在不同的區域或國家。(4)對於比較重要的部份應轉向成本效率高以及標準高的國家或地區。(5)該國的公共設施是否允許在家工作。(6)合約中訂定服務水準等級與處罰條款。(7)堅強穩固的fallback計劃。

因此專案經理在將自國外外購專案的工作應首要思考:「什麼是可以外購?什麼不應該外購?如果外購的話會附帶進什麼樣子的風險?」而且也要建立一個觀念:「外購也不是經由合約將應有的責任完全轉包出去,而應要考量自己與外包廠商不同但互相關聯的義務與責任。」因此最終的決定,還是在於專案經理的理智與聰明的決策跟判斷!

2009年5月1日 星期五

土法煉鋼出來的─肥蝦版"訪談作業程序"


在建置應用服務資訊系統時,需求分析師或系統分析師最重要的工作之一就是去訪查客戶的需求與期望,釐清現有的作業流程,溝通雙方彼此的意見。因此肥蝦在初步累積了近十年來的經驗與參考一些書籍的方法,土法煉鋼的擬定了一個簡單的訪談作業程序"一個基本、二個希望、三個步驟、一個注意":,希冀經由這拋磚引玉的動作能獲得更多的收獲。
(一)一個基本:
(A)"採購合約"與"工作說明書"要滾瓜爛熟。

(二)二個希望:
(A)希望工程師可以不用跟(只要能有效掌握需求,並不需要工程師跟,有時兩者間的語言不同會造成更大的問題;而且有可能造成客戶直接跟工程師約定了不當的承諾!)
(B)若非有工程師在場不可,希望要跟我事先先演練或套好招。

(三)三個步驟:
(1).訪談前:
(A)瞭解受訪者的背景、單位、與專案利害的衝突,以及受訪單位在專案中的角色與定位。
(B)瞭解此次訪談目的、牽涉到專案的範圍與重要性。
(C)詳列訪談的重點與預測可能的發展。
(D)事先約定受訪者受訪之人、時、地、物,以及告知預估所需花費的時間。
(E)訪談記錄的標準format。

(2).訪談
(A)約定前五到十分鐘到達與準備。
(B)穿著打扮要得體(注意工程師)
(C)先行詢問可否錄音或記錄
(D)注意訪談的技巧(避免誘導、避免主觀...)與問題的次序性。
(E)受訪結束前詢問是否還有我們應該要知道的
(F)告知訪談記錄交付時間,並請求訪談若有不足或不夠詳盡處,是否可以電話通知或再次見面。

(3).受訪後
(A)快速並有效整理撰寫受訪記錄(受訪記錄的詳細程度與次序應要斟酌)。
(B)先給予會自己公司的內部同事看過。
(C)email給受訪者,特電話告知已寄出,並請受訪者告知記錄中有任何不妥或不當之處!
(D)訪談事項進行分析、歸納,並列入相關的專案議題或追蹤項目。
(E)條列出三到四行的訪談重點email給主管。

(四)一個注意:
對於需求超出合約的部份通常我會如下處理:
(A)刺探需求的重要性跟急迫性。
(B)以客戶角度出發是否有更好的方案。
(C)哀兵政策或博感情。
(D)儘量不當面回絕,會說帶回研究。
(E)針對此點會在訪談記錄作些小小的..。
(F)看程度是否要報告主管。
(G)從其他人再刺探受訪者。
(H)非作不可,那就上呈主管與業務,請他們再去溝通(或要錢)。

以上是肥蝦個人的作法,還請 各位先進惠賜更適當的建議或任何忠告!