2009年6月28日 星期日

串連PMBOK IV的思維模式-個人心得


肥蝦這幾日來整理了PMBOK IV的內容,自己想了以下的方式去串連PMBOK IV各章節!

(1)組織活動與專案:區別出組織活動中專案的本質。
-作業與專案
-部門經理與專案經理

(2)組織目標層級與專案:明瞭專案與組織的關聯性。
-Portfolio、Program、Project

(3)組織架構與專案:專案成立的基準原點。
-Organizational Structure

(4)影響專案的外在因素:專案的限制與資源。
-Enterprise Environmental Factors
-Organizational Process Assets

(5)專案參與者的角色:專案的人為互動與責任。
-The category of stakeholders

(6)專案創造的價值:專案成立的價值。
-Project Life Cycle
-Product & Project (Product, service, or result)
-From Product Scope Description to Final Product ,Service, or result

(7)專案文件:專案活動的基準與記錄。
-Project Management Plan
-Project Documents

(8)PMBOK的程序與互動:專案流程的運作。
-9 Knowledge Domains & 5 Process Groups
-42 processes
-throughout the project
-iterative
-Change Requests

(9)PMBOK的工具:專案可參考使用的工具。
-估算工具
-量化工具
-圖形工具
-合約型態
-Cost of Quality

肥蝦目前是利用上述九個區塊架構出PMBOK IV!

不知各位是如何去閱讀PMBOK IV,探討PMBOK的核心精神與應用!

2009年6月22日 星期一

會寫程式就是會做專案嗎?


肥蝦之前和最近都遇到一些朋友,他們對於不具有程式能力的專案經理會有一定的排斥。在軟體開發業界,程式撰寫能力被一直認為是專案成功的必備條件。目前也由於很多公司主導專案的專案經理都是從以往的技術人員出身,因此也反相的認為程式撰寫能力是專案成功的惟一條件。

在如此交互作用下,導致目前市場上很多以技術專業自居的專業人士,在專案團隊內會有意無意地輕視"專業"專案經理,導致專案經理的主要職責之一:「創造與維護專案團隊的正面氛圍」非常不易作到。

在PMI網站上的有下列一道考題:
To be a good project manager, how much do you have to know about the industry or business that you are serving?
A. It is more important to have a good project management foundation than to know the business.
B. Each business is so different, in-depth knowledge in the field is key to a successful project.
C. Organizational politics drive project success, so focus on your ability to sway management.
D. Project success is random, so all you can do is work with the skill sets you have.

PMI網站,Barbee Davis, MA, PHR, PMP,所公布的答案是A。各位讀者可上去看伊的說明(網址:http://www.pmi.org/eNews/Post/2008_09-12/QQ_ToBeGoodPM_HowMuchToKnowAboutBusinessYourServing.html) ,Barbee Davis從大中小型專案來分析為何專案經理的專案管理知識、技能與能力,比商業的瞭解、認知重要。

就考試的立場而言,肥蝦認可Barbee Davis的解說,以PMI立場,專案管理能力一定是比產業專業知識更為重要!但肥蝦在此,想從另一角度去說明專案成功的要件中,專案經理的職能與角色中所謂的管理能力,是不是僅瞭解如何去管理專案比較重要?

因為此篇不是為考題解析,準備考試的朋友還是不要看肥蝦以下的推論比較好!

何為專案經理所需要的知識領域,在PMBOK IV版中,已經第III版中圖1.2-Areas of expertise needed by the project team拿掉,針對專案經理的角色寫在1.6 role of a project manager。針對專案經理的角色,PMBOK說明好的專案經理應具有下列特性:
(1)知識(Knowledge):針對專案管理的知識。
(2)技能(Performance):有效的運用專案管理知識。
(3)個人特質(Personal):態度、性格與領導力。

肥蝦個人是以為如此的修正,是PMI為了行銷目的,強調專案管理知識與技能的重要性。一個專案團隊應具有PMBOK III版所載明的五種專家領域知識─應用領域的知識、瞭解專案所在的環境因素、一般的管理知識與技能、個人的特質與技能,以及專案管理的知識。因此專案經理必須能有效的與專案團隊與客戶進行溝通,設法營造整體環境的正面氛圍,以提升專案的成功機率。

在前述的要求與架構下,專案經理的第一要務是什麼?肥蝦個人是以為要先設法取得信任-來自公司內部的信任、來自客戶的信任、來自專案團隊的信任。基於肥蝦的認知,對於專案管理知識與其它應用領域知識作了如下的解釋:
(1)專案管理是一個基本面的know-how,就算不是專案經理,專案團隊成員也應該要有基本專案管理的知識,才能解讀專案工作的本質,瞭解專案團隊成員的互動必要,如此才能促進團隊的有效運作。

(2)那專案經理要強化的那些專案管理能力,才能顯出他適合當一個專案經理!因為每一個專案都是獨一無二的,且有一定的時限。所以專案經理的專案管理能力如果依據堅強(兼具廣度與深度)的應用領域專業知識,以及應有的一般管理知識,那可能無法有效的去整合(Integrate)專案團隊成員、客戶與公司的需求。

(3)專案管理能力跟一般的企業管理能力差異在那裏?
試想:「一個資訊公司行銷部門的經理,進入房地產公司擔任行銷經理比較容易?還是一個從資訊專案的專案經理,進入房地產專案的專案經理容易?」
肥蝦先前曾撰寫【MBA乎?PMP乎?-兩種管理"專業人材"之我見】乙文,說明兩者之間並不違背,而且是相輔相成,並且是糾葛難分的!

(4)PMI的想法!
PMI是試圖把專案經理知識抽離出來向企業管理一樣。就像行銷學一般,不管你是資訊公司行銷部門的經理,,還是房地產公司擔任行銷經理,大家的基礎學術訓練,都是都唸行銷學。
但是因為專案的本質,導致很多專案管理的應用都要立基於對專案的領域知識有一定深度的瞭解,才能進一步發揮我們所學到的專案管理知識,強化PMBOK IV版中所說的技能(Performance)。

(5)「領域專家不一定適合當專案經理,可能比較適合當顧問。」
肥蝦可以同樣把這句話反過來說:「一個專案管理的專家不一定適合當專案經理,可能比較適合當顧問。」因為一個專案經理重要的是營造完成專案的正面氛圍,引入專案所必要的專家,並與伊溝通,作為溝通的中心介面。就如同在PMBOK IV版第26頁,對專案經理的說明:「The project manager is the lead person responsible for communicating all stakeholders. The project manager occupies the center of the interactions between stakeholders and the project itself.」

基於上述肥蝦淺薄的認知,肥蝦將原有第III版中圖1.2-Areas of expertise needed by the project team的圖形,修改為如上圖的專案經理知識架構。

2009年6月15日 星期一

RISKOLOGY-"與熊共舞"所提供的風險評估工具


肥蝦近日於專案管理交流論壇(http://bbs.pm-i-study.net/)寫了一系列"與熊共舞"的導讀!
再看過該書提供的風險評估工具(Riskology),雖然只是一個用EXCEL寫的工具,但已包含了一些風險評估的要點,加以該工具是作者免費提供給讀者大眾,因此肥蝦特把下載網址與個人的觀感整理如下,以供大家一起分享!

下載網址:http://www.systemsguild.com/riskology
版本名稱:RiskologyV4.xls
使用說明:RiskologyManual.pdf

使用簡要說明:
使用者需要輸入專案名稱、預估起迄日期、風險名稱、對應每個風險的三點估計值,每個風險導致專案取銷的百分比值。RISKOLOGY將協助您計算最小與最大完成期間概估。

工具背後理論:
基於三點估計法(three-points estimate)與利用隨機變數(random),隨機取樣五百次(取樣值介於三點估計的最佳與最壞之間),以蒙地卡羅(MONTE CARLO)模擬風險的概估值。

肥蝦建議:
(1)目前該工具僅能提供十個RISK FACTOR的輸入。可客製化加入新風險因子。
(2)奈米機率日必須先行輸入。使用者可再工具算出最小與最大期間之後,再行參考修正奈米機率日!

2009年6月11日 星期四

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


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.

肥蝦就個人對PMBOK的瞭解解析該題答案;並分享個人的經驗,關於專案經理在發現時程問題的考量與對應作法。

(一)PMP考題解析
各位可以注意本題的關鍵詞:「correcting a scheduling problem」。在第六章的六個processes,那一個process有"Recommended Corrective Actions"?各位可以發現是在6.6 Control Schedule,那時project management plan已經產生,其中的cost baseline都已經放入project management plan了。

因此,如果cost reserve不夠,那要怎麼辦?因為向公司要人、要錢,如果超過cost baseline都是要Change Request;而針對專案經理所掌控的contingency reserve是針對know-unknown;如果這個問題是unknown-unknown,那就要動到management reserve,那就要sponsor的approved。

而Project Schedule Network Diagrams不是schedule baseline喔!並未納入project management plan中。所以應該思考調整fast-tracking中的選擇性依賴關係的順序,設法變更其中的leads 跟lags的安排,還有請記住Schedule Compression是6.5Develop Schedule的Tool and Technique;Adjusting Leads and Lags可是6.6 Control Schedule的Tool and Technique喔!

(二)實務經驗分享
在實務上,肥蝦碰到的專案中,很多的管理高層在碰到時程的問題時,很多人是喜歡優先採用crashing,但個人以為這是受到"人多好辦事"這古老諺語的影響!可是相對地,很少人去考慮到為什麼會造成延誤(提前)的原因!

一般專案經理最普遍的作法,就是回去跟公司要人、要錢!

我以為,這一方面是專案經理給自己一個藉口:「這是資源不夠,而不是專案當初規劃有問題,或是專案經理管理上有些不當的地方。」另一方面,當專案經理向公司要資源之時,就把專案的問題,上綱到公司人力資源管理政策的問題!把問題推給公司,然後變相的給自己增加緩衝的時間。

肥蝦認為每個專案經理處理的方式會跟,會因為外在的限制、sponsor的壓力與利害關係人的要求而變化!也會跟時程問題發生的時點在專案作業的時點有很大的關係!

以肥蝦個人參與專案的淺薄經驗與認知,肥蝦在解決更正時程問題時,會進行以下的程序:

(1)釐清原因:為什麼?造成問題背後的原因是什麼?與當初所設想的差在哪裡?
=>事前的規劃與現在的狀況之間到底出了什麼狀況?到底是有什麼沒想到?或是想到了而沒去注意?背後造成的原因在哪裡?真正的關鍵點是什麼?

(2)設法集中問題的焦點,縮小問題的範圍!
=>基本上, crashing如果不是用專案已有的reserve,你會發現你將落入公司內部競爭的難題!如果你很紅,有時候你會發現跟公司要錢比要人可能簡單一些!如果公司是要給你現有公司的員工,有時候要到的人很多都是別的團隊不要的!如果是招募新人,很多公司的政策跟管理,會需要一定的時間,新進的人如何融入團隊,多久融入,這些都是問題的範圍!

(3)考量對問題解決方案外在跟內在的限制!
=>比如合約的限制,專案團隊成員是否已經呈報買方,而且變更需要申請跟審核;合約的金額是否允許你增加成本;專案現有的文件跟作法,是否足以訓練一個新手儘速的融入團隊;團隊是否存在強烈的排外性。

另外,針對同一個更正時程的問題,肥蝦會考慮更正的時間點:
(1)時間點:合約簽定前
=>完工日期是買方強力要求的,那用crashing增加成本,或減少產品功能與性質(scope)或品質(quality)。

(2)時間點:規劃中
=>crashing跟fast-tracking,我會同時思考!尤其對於fast-tracking中的選擇性依賴關係儘量去調整,crashing所增加的成本則可納入cost-baseline。

(3)時間點:執行前期
=>我會先看看fast-tracking中的選擇性依賴關係!如果schedule reserve能cover,那不管它,但要強力監控!如果cost reserve充足,那我會考慮用crashing。而且在專案執行的前期,新人的加入,可以有一些緩衝與容忍度讓新人融入團隊!或者外包給別人,但自己的團隊要花費些心力在外包廠商跟專案範圍的接合處!

(4)時間點:執行後期
=>如果reserve都已經被用了差不多,而且團隊之間已有一定的默契跟向心力,那我會考慮fast-tracking先。因為rework的風險,跟加人把團隊搞雜的風險,我會比較擔心團隊垮掉的風險!

(5)時間點:快驗收的時候
=>考量工作的本質,如果只是文件撰寫等行政工作,或是黑箱測試可以比較獨立於原有團隊之外的工作,可以考慮crashing!那fast-tracking就比較不考量了,因為大概沒有什麼activity可以平行運作了!如果這些時程所包含的activity的delivery不太影響交付產品的主要功能,也在stakeholder的tolerance的邊界,那我會設法去嚕掉它,作變相的scope change。

以上是肥蝦個人小小的看法!以下,肥蝦將分享一個我個人的實例:

曾經有一個專案的部份活動在執行發生delay,經深究原因發現是兩個同事在工作的接合界面有衝突。因為前者工作的負責人,比較懶散與不負責任,因此導致後者activity的負責人必須花費很多精力跟時間,去檢核前者的delivery。後來跟後者打個商量,如果他去cover前者的工作,他是否能負荷?對他是否也比較方便?而後者的回答是正面的。因此前者被要求離開團隊,不但省錢、省人,省下的錢一部份,發給後者當獎金!結果,大家是皆大歡喜,且有效的縮短delay的時間呢!

因此如果把時程問題背後的原因找出來!你會發現:並不是增加資源就會有效喔!

2009年6月10日 星期三

資訊相關文件的分類方式-利用ISO27001為分類的依據


在資訊單位裏,我們都會發現我們辦公室內存放著滿坑滿谷的文件,舉凡如縈縈大者的公司管理政策、法規與標準,組織圖,軟硬體清冊,網路架構圖…,到每位使用者的權限與申請單。很多單位都有自己的一套分類標準,這分類依據可能已經不可考,或是參考特定的規範而訂定。

針對資訊文件的分類,肥蝦個人以為,如能照國際的標準與規範進行分類,不但能有較完整的架構,在申請國際認證時也能有一定的幫助。憑藉著肥蝦先前上過ISO27001的課程,對於對於ISO27001的初淺認識,建議可以依據ISO27001的架構訂定分類。

在此處必須先強調的是先約定分類的大綱,暫且不要去新增記錄或表單,因為新增表單將會擴大組織的抗拒。表單的適用與新增、變更,需要因應組織的需要與需求去訂定,此處僅是單純的標明分類大類,以供參考!

(1)資訊安全管理政策
如:公司資訊政策、公司資訊作業標準...

(2)資訊安全組織管理作業流程及程序
如:資訊組織架構、聯絡表、聯絡程序、聯絡記錄...

(3)資訊資產管理作業流程及程序
如:資訊資產清冊、資訊標示與處理的程序、資訊資產分類指導綱要

(4)人員安全管理作業流程及程序
如:聘雇合約、營業保密協定、競業禁止協定、教育訓練記錄...

(5)實體安全管理作業流程及程序
如:安全區域進出登記表、安全區域進出授權記錄、硬體(含網路)設備清單、網路架構圖
...

(6)操作安全管理作業流程及程序
如:變更管理程序、變更申請單、職務分工表...

(7)存取控制管理作業流程及程序
如:存取控制政策、使用者工作職掌與其存取權限比對、使用者申請/異動/註銷控制程序、單位人員與系統存在使用者對照表、使用者申請/異動/移除記錄...

(8)資訊系統開發與取得作業流程及程序
如:系統分析文件、採購合約、系統測試記錄、程式設計文件、資料輸入過程的日誌

(9)資訊安全事故管理作業流程及程序
如:資安通報程序、通報聯絡清單、獎懲辦法/記錄...

(10)業務持續管理作業流程及程序
如:營運持續計畫、定期測試的程序與記錄、責任分工表...

(11)符合性管理作業流程及程序
如:管理階層的定期審查記錄、矯正行動報告...

文件的分類標準很多,肥蝦是拋磚引玉,希望大家能貢獻更多的經驗與方式。

2009年6月4日 星期四

「電腦一開就會洩密」讀後心得


科學人雜誌 NO.88;96-101頁;撰文:W. Wayt. Gibbs;翻譯:王怡文

重點提要:
(i)即使最嚴密的網路安全系統,也無法確保你的電子資料不被有心駭客竊取。
(ii)研究人員已經證實,光是利用眼球反射的電腦螢幕影像或印表機發出的聲響,就能從中讀取資訊。
(iii)這類攻擊難以防禦,而且無法追蹤。最簡單的竊密管道是繞過網路安全系統偷窺,而且事後完全不留痕跡。

肥蝦先前曾經上過ISO27001跟CompTIA Security+的課程。感覺上ISO27001(Information security management system)強調資料分類、資料存取、人員、環境與實體、通訊與作業…等的安全規範。CompTIA Security+比較著重在網路與通訊的安全(雖然在資料存取、人員、環境與實體等議題上也有著墨。)。因此肥蝦心中對於資訊安全的定義與範圍,就是僅以ISO27001與CompTIA Security+為主軸。身為一個金融軟體系統整合商的員工,肥蝦僅是在意,程式碼與文件的安全控管,使用者身份鑑別與權限管理,資料存取與trace log的機密性,程式換版的作業管理,網路通訊的加/解密,PKI,目錄管理、Signal Sign-on、網路病毒、防火牆/UTM等有關議題。直到翻閱本文,發現自己像個"缸中之蝦",不知外面的世界是如此的寬廣。

在本篇文章中,提到了一些正在發展/已發展的一些竊取資料的方式-從電腦螢幕的倒影(眼球、杯子、眼鏡…等反光物體),鍵盤的電波,印表機的聲響,網路視訊,網路設備的閃爍訊號-等所謂旁通道(side channel)的資料竊取方式。雖然該文提到旁通道攻擊有一定的限制,如:必須要接近目標,而且必須使用者正在讀取資訊時行動。但所謂:「殺頭的生意有人作,賠錢的生意沒人作。」在肥蝦所專長的金融軟體資訊領域,不正是屬於「殺頭的生意有人作」的範疇嗎?

資訊安全在國內目前可說是在如火如荼的推展當中,就金融產業來說:除了政府內政部門的要求外,金管會銀行局與銀行公會也相繼推出新的資安要求與法令。其目的之一:就在保護消費大眾的權益,以及社會的安全。記得肥蝦在四月二十三日與二十四日參與的「2009台灣軟體品質與資訊安全研討會」。不少學者也提出:目前國內軟體廠商從軟體設計開使就忽略了資訊安全的要求,導致國內產品與國際大廠無法於市場角逐的要素之一。其實,肥蝦也深深感受到客戶端雖然有考慮資訊安全,但在業務導向下,也僅是遵照政府的法規行事而已。但對身為專案管理與系統分析的肥蝦來說,在產品設計之時就能考量資訊安全的需求與必要性,這是一個重要且必要的課題。

雖然如本文所說明的旁通道攻擊,真得很難有有效的防範方式,但是資訊安全是目前與日後的重大議題,背後的商機也是無限的龐大,值得大家一起來關注。

2009年6月2日 星期二

什麼樣的鋼琴老師才是合適我家的小朋友?-論學習專案管理


肥蝦的大女兒─肥肥嚕─從幼稚園中班,跟著現在的林老師學鋼琴,至今已有兩年,聽說程度為"拜爾中級"。上週六才在民權路的一處演奏廳,參加了林老師所有教導學生的發表會,演奏了一支卡門跟不知名的小步舞曲。小女孩學琴難免會有點懶散,自己很難主動練習,難免要我家老婆大人親自督促與要求。

而肥蝦的內人從事國小教職,對於教育的理念與學習的步驟有一定的堅持與要求。而肥蝦是個音癡,對於教育也是個門外漢,心中只認為小孩子只要快快樂樂學習,培養一點音樂的欣賞能力,就是我這個老爸心中所期待與所盼望的目標。

這二個月來肥蝦跟老婆大人一直對於林老師的教學方式與學習進度掌控上有所討論。老婆大人認為肥肥嚕的樂理基礎與識譜能力不夠紮實,雖然彈到"拜爾中級",可是對於應俱備的基礎能力太過欠缺。認為老師教學進度過於快速,造成小孩太大的負擔。當然老婆大人也跟林老師溝通過一次,目前教學的進度是緩了一些,但是老婆大人還是不滿意。

但肥蝦是以為,因為除了每週一次一小時的正式教學外,老婆大人幾乎每天都會要求女兒練習,對於女兒不懂或不會的地方,也會親自指導,勿必於林老師下次上課前練會。因此老師在每週在驗收上週的樂曲時,幾乎都能通過,因此很自然的就往下教。

為了鋼琴教學的問題肥蝦的老婆大人也詢問了她的同事(學校的音樂老師),以及住家附近的一家才藝班的小王老師(肥蝦的小女兒─肥肥皮─在此學跳舞),因此希望將肥肥嚕轉往才藝班學習。最後經由肥蝦與老婆大人進行面對面的討論,肥蝦逐一分析老婆大人的問題後,找出了關鍵的問題點-(1)教學程序:老婆大人認為要先從樂理基礎,開始再到彈琴。(2)老師的打扮:林老師比較敢穿,讓比較保守的老婆大人不能接受。最後肥蝦終於建議了一個方案,讓老婆大人接受-七月讓大女兒兩邊都學,再由她自己決定她要跟哪一個老師學習。

這個過程不禁讓肥蝦想起在坊間的補教業者學習專案管理的過程。還記得肥蝦在我的「專案管理(PMP)學習之路」的文章曾經提過我曾在前進國際、展頡跟遠景,上過相關的管理課程。每位老師均有自己的教學風格與邏輯,但重要的是學習者的自我認知:「您能否接受老師的教學方式?」就像在前進國際學習上「軟體開發專案管理實戰班」之時,一些有著豐富實務經驗的學員私下認為講課老師的經驗與授課實例都是侷限在小案子,對於他們的期望有太大的落差,無法實際應用。

現在很多的PMP補教業者所強調的都是如何快速考上PMP!雖然大家各有各的行銷花招,但就教學理念與方法也是有所不同的。有的老師教學方式是強調觀念的釐清,利用題目打通學員的盲點;有的老師教學方式是強調背誦,大量作題目、背題目,以求學員通過PMP考試;當然有的老師只是照本宣科讀完PMBOK…。但是肥蝦以為最重要的是學員自己要知道自己追求的是什麼?所想要學習的是什麼?

如果您想要學習的是PMBOK的思考邏輯與方法,那您當然需要的是一位強調觀念釐清的老師;如果您的記憶力好,要的只是快速通過,拿個證照,那強調背誦的老師也許適合您。

台灣目前的市場上,質疑PMP的聲浪不算小,肥蝦認為問題還是在根源上。到底每位學習PMBOK的學員心態!就算PMI把考試的難度提高,還是有方法把PMBOK當成應付指考的教科書教。

肥蝦以為專案管理在國內並不是顯學!您可以發現國外很多專案管理相關領域的書籍,但國內的翻譯作品多是集中在考試用書。這個PMP市場是由局勢所創造的?還是PMP市場創造了局勢?其實很難有定論。反正市場僅會朝向有錢的地方走!如果每個想學習專案的人都沒有追求自我不斷成長的自覺,想靠由外面的政策或公權力單位來主導,肥蝦以為這都不是一個良善暨有展望的作法。