首頁 PMP證照後進修 PMP考試園地 書籍推薦 專案管理知識平台 志工專區

2010年1月19日 星期二

PMI_TW電子報創刊號_專欄文章




Risk is defined in two dimensions: uncertainty and effect on objectives. ...

Risk is defined in two dimensions: uncertainty and effect on objectives. It is common to use the terms “probability” and “impact” to describe these two dimensions, and assessing the significance of any given risk means considering both. It is relatively simple to assess effect on objectives, since this merely requires defining the situation after the risk has occurred, and then imagining what happens: “If this risk occurred, what would the effect be?” Probability is not so easy however. Risk practitioners and project teams alike experience repeated difficulty in assessing the probability that a given risk might occur. There are a number of reasons for this.

•Language. In English, different words are often used interchangeably to describe the uncertainty dimension of a risk, such as “probability”, “frequency”, “likelihood” or “chance”. In fact these do not mean the same thing, and confusion can arise if the terms are misused. For example “frequency” describes how often an event or set of circumstances is expected to occur based on previous experience, either in a period of time (e.g. once per year) or in a number of trials (e.g. seven times out of ten). So frequency really applies to repeatable events. This is not the same as “probability” which is a statistical term describing how likely a single uncertain event or set of circumstances is to occur. One solution is to use a more general term such as “likelihood”, and recognise two variants called “probability” (for single events) and “frequency” (for repeatable events).
•Format. The uncertainty dimension of a risk can be expressed in several ways, including both numerical and textual formats, such as: 35%, “once per month”, 2:7, “unlikely”, “one in six times”, 10-4, “low probability”, 0.2, and so on. Most people have problems interpreting different numerical formats, and even the textual phrases can mean different things. This problem can best be overcome by education, as well as using a set of agreed definitions which everyone understands.
•Subjectivity. Assessment of probability requires forming an opinion about a future event or set of circumstances which have not yet happened. Different people will take different views about the future, and there is no “single right answer” since the future has not yet happened. Risk probability cannot be measured, only estimated. Assessments of the uncertain future are influenced by many factors, including perceptual filters, motivational bias, cognitive bias, or subconscious heuristics. The solution here is to take a team-based approach, exploring different perspectives, examining underlying assumptions, and reaching consensus wherever possible. Sources of bias should also be understood and corrected where possible.
•Lack of data. Some risks have never been experienced before, especially those relating to the unique aspects of projects. In other cases, even though a risk might have been encountered previously, there may be no record of its existence due to absence of a learning mechanism (such as a knowledge base or checklist). As a result there is no body of evidence to assist in estimating the probability of occurrence of these novel risks. Addressing these shortfalls requires acknowledging that some areas lack relevant previous experience, as well as implementing an effective lessons-to-be-learned process (e.g. a post-project review).
All this matters for two reasons:

•Faulty probability assessment means risks will be wrongly prioritised, leading to a failure to focus on the most significant risks, selection of inappropriate responses, inability to manage risks effectively, and loss of confidence in the risk process.
•Sound assessment of risk probability improves the understanding of each risk, allowing appropriate prioritisation, better response selection, enhanced risk management effectiveness, and more reliable achievement of project and business objectives.
We need to understand the problems associated with assessing probability, and take action to address the concerns, by using appropriate language and formats, identifying and managing sources of bias, learning lessons to improve the effectiveness of the probability assessment process, and monitoring risk management performance to determine the accuracy of assessed risk probability.


--------------------------------------------------------------------------------

風險是以兩個向度:不確定性與對目標的影響來定義的,一般用「機率」與「衝擊」描 述這兩個向度,而評估風險的嚴重性意指同時考慮兩者。評估對目標的影響是相對容易的,因 為只需要定義風險發生後的情況,然後想像:「如果這個風險發生,其影響為何?」然而,機 率就不是那麼容易了,風險實務專家與專案團隊在評估某特定風險可能發生的機率時都會一再 碰到困難,以下是一些這些困難的原因:

•語意 通常會交替使用不同的詞彙來描述風險的不確定性向度;如「機率」、「頻率」、「可能 性」、或「機會」,事實上這些詞彙代表不同意義,如果誤用了會造成混淆。例如「頻率 」是描述基於過去的經驗,預期一個事件或一組狀況多常發生,可以是在一段期間(如一 年一次)或數次嘗試中(10次中有7次),因此頻率是應用在可重複的事件上的,這和用 以描述一個單一不確定事件或一組狀況有多可能發生的統計名詞「機率」是不同的。一種 解決方法是用更一般化的詞彙如「可能性」,並認知兩個相異的詞彙「機率」(用於單一 事件)與「頻率」(對重複事件)。
•格式 風險的不確定向度有7種表達方式,包括數字及文字格式,如:35%、「每月1次」、2:7 、「不可能」、「6次中1次」、10- 4、「機率低」、0.2等,大部分人有解讀數字格式的問題,既使是文句也可能代表不同意 義。這種問題最好是由教育來克服,並且使用大家都能瞭解的定義。
•主觀 機率的評估需要對尚未發生的未來事件或一組狀況形成一個看法,不同的人對未來有不同 觀點,由於未來尚未發生所以沒有「單一的正確答案」。風險機率無法衡量只能估計,對 不確定未來的評估被許多因素所影響,包括感知的過濾、動機偏差、認知偏差、以及潛意 識的直覺。解決方法是採取一個以團隊為基礎的途徑、探究不同的觀點、檢驗內在的假定 、以及盡可能取得共識,偏差的來源也應該盡可能瞭解並改正。
•資料缺乏 有些風險是過去從來不曾經歷過的,特別是和專案特殊面向有關的風險。另外,既使風險 可能之前經歷過,也可能因為缺乏學習機制(如知識庫或檢查清單)而沒有其存在的紀錄 ,因而導致沒有具體證據可用來協助估計此一新風險的發生機率,應付此種缺失需要瞭解 某些領域缺乏之前的相關經驗,並且實行有效的教訓檢討程序(如一個專案的結案後檢討 )。
以上這些之所以需考慮是基於以下兩個原因

•錯誤的機率評估代表風險將有錯誤的優先等級,導致無法專注在最嚴重的風險上、選擇了 不適當的風險回應、沒有有效管理風險的能力、以及對風險程序失去信心。
•健全的風險機率評估,可增進對每一個風險的瞭解、得到適當的優先等級、選擇較佳的風 險回應、增進風險管理效益、以及更可靠地達成專案與企業目標。 我們需要瞭解關於風險評估的問題,並採取行動來因應,經由使用適當的語意與格式、 辨識並管理偏差的來源、從教訓中學習以改進機率評估程序的效果、以及監督風險管理績效以 決定評估風險機率的精確性。


……(閱讀全文與回應)

2010年1月18日 星期一



引言 67 期 電子報
內容 敬請期待
發佈文章

……(閱讀全文與回應)

2009年11月6日 星期五

棋語:從【卒】蛻變成【車】的菜鳥工程師





本文首載:ZDNET/CIO的天空

卒子挺過河,臭蟲變成龍。


   【卒】是一盤局棋中最不被看重棋子,還沒有挺過河前,說它是臭蟲,一點也不為過。
以行動力來說,【卒】一次只可以走一步,在攻擊上並沒有【車】、【馬】的迅速,再加上【卒】的位置是在第一線,它的緩慢的行動力常會阻礙後方主力(【車】、【馬】)的前進;且【卒】過河前,只能往一個方向前進,因此,又被歸類為無法靈活變通的一群。


若以IT專案來看,【卒】這樣一個角色有點像是菜鳥工程師,因為技術能力尚淺,他無法像技術經理(【車】)有著十足的行動力以及洞見,能滿足客戶的需求。

就像【卒】未過河前一樣,菜鳥工程師沒有靈活應對與處理事件的本能,只會一步又一步的照著標準作業程序(SOP)往前走,若是碰到突發狀況,多半只會站著不動、等著被吃(指被客戶罵)。

另一方面,由於其欠缺專案經驗及客戶應對能力,是故,若讓菜鳥工程師獨自與客戶溝通,不僅會導致許多(美麗的?)誤會,還會把專案導向不可知的未來。

所以在專案初期,大部份的菜鳥工程師都待在客戶端支援(因為技術經理或是專案經理,手頭上可能都有多個專案在同時進行),技術經理或專案負責人多半不會派菜鳥工程師與客戶溝通。

事實上,極多數的專案Leader對菜鳥工程師的心態就如同多數的棋手會直接忽略位處兩軍對戰第一線的小【卒】子:可以用就用,如果不能用,就直接讓它被犧牲掉…


從卒變(半個)車

但【卒】在整盤的棋局中,真的那麼沒有用?

【卒】或許阻礙了我方的【車】、【馬】的前進,但它相對地也阻礙了敵方兵馬的前進,特別是當它被挺過河的時候。不相信?讓我來舉個例子給大家聽。以我的下棋習慣,如果有機會,我一定會把【卒】挺到對方的家中,先不論攻擊力的部份,一隻【卒】基本上至少可以壓到一隻【馬】的前進。

菜鳥工程師也是一樣。

確實沒錯,我相信一開始不大有企業客戶會願意將自家主機交由一個菜鳥工程師維護。比較常見的狀況是,菜鳥工程師因本身的局限,甚難直接「挺」到客戶端去,需要業務、技術經理、或專案經理的護航或保證,企業客戶才有可能對菜鳥工程師產生信任。

不過,隨著信賴程度的增加,菜鳥工程師也有機會一步一步的挺進客戶的核心業務,進行系統主機維護服務。理由在於,雖然菜鳥工程師一開始維運的系統多為非核心系統,但隨著維護時間的加長,技術經理、專案經理等同仁的情義相挺與協助,客戶將慢慢地認同菜鳥工程師的能力,並且將再更重要的核心系統交給其維護。

上述這種發展脈絡其實與下棋有點像。

一隻小【卒】子(菜鳥工程師),隻身在敵方(企業客戶端)是很容易陣亡的,但如果有【車】(技術經理)在後頭提供支援與協助,那該名菜鳥工程師的影響力也將相對加成。


當菜鳥工程師逐一了解、上手非核心與核心系統後,其將變成最有機會接觸與了解客戶的整體主機系統架構與狀況的人員,必要時,還可因時制宜地依客戶需求(系統狀況),提供合宜的系統調整規劃與議建。

成功向客戶展現能力並取得客戶認同後,菜鳥工程師在企業客戶的眼裡機乎等同於半個技術經理,而這正如同棋局:一隻【卒】只要挺過河,幾乎就等同於半隻【車】。

當然,若直接派遣技術經理到客戶端,也有相同效果。只不過,技術經理的成本較高,且一個組織中不大可能有太多位技術經理(就如同棋局中,【車】只有兩隻,而【卒】確有五隻一樣)。

如此看來,您是不是也認同菜鳥工程師(【卒】)的投資報酬率較高。

大家可以想一想,如果我成功的把五個菜鳥工程師挺過河,等於我一口氣多了2.5 (5 X 0.5) 個技術經理,若再加上原先的那兩個,我擁有的技術經理人數將遠超過競爭對手(可能還是只有原來的那兩個),而這意味著我的敗落機會將小上許多。


如何助卒變車?

但該如何將菜鳥工程師挺過河?是不是只要跟菜鳥工程師說一聲,他就可以自己游到對岸去?我想這肯定是專案管理者(或企業)最常犯的錯:叫一個菜鳥工程師在沒有任何資源(支援)下,自己游到對岸去(美其名是在鍛鍊他)。

在我的經驗中,這類做法最終結果多不外乎…小【卒】子在過河的當中就溺斃了;除非,這個小【卒】子本身就據有技術經理的潛能。

若真如此,這個小【卒】子游(經)過這次後,他的等級也幾乎會躍升成一個技術經理。

而且,其若沒有被合理地升級,這個從菜鳥工程師(【卒】)蛻變成技術經理(【車】)極可能會選擇走人。而這絕對是公司不樂見的情況,因為,公司除得承擔損失一個人才的風險,還得做好因此連代損失客戶的心理準備。

我以為,讓菜鳥工程師順利挺過河的前提是,有技術經理(【車】)、專案經理、或者是資深技術工程師的護航(有時候,還可以利用聲東擊西的方式,讓小【卒】子一不小心就過了河)。

換句話說,要做好護航、或者說培育菜鳥工程師,公司必須有很好的資源調度能力,尤其是多個專案同時進行時,如何利用少數的高級資源(【車】、【馬】、【砲】)讓公司內部眾多的小【卒】子都可以挺過河,皆是挑戰公司資源調度(佈局)的能力。

你呢?能成功的讓你的小【卒】子過河嗎?還是因廉價而把它犧牲掉?

……(閱讀全文與回應)

棋語:如何佈個好局(專案) by 杜奕鋒, PMP





本文首載:ZDNET/CIO的天空


       能佈好局,多半也能順利經營專案團隊。

       認識我的人,或多或少都知道我喜歡下棋,以前辦公桌的位子後面,也有個可以隨時擺上一盤棋的圓桌。常常在午餐過後,招呼幾個同事,便開始對弈,快的時候,午休結束前便能結束一盤棋。

但高手過招總會有僵持不下的狀況,無法在午休前結束的棋局,便成了我下午調劑身心的工具─做事做累了,便轉過身來獨自思考尚未結束的棋局,疏緩一下因公事而打結的大腦;往往棋結未解,腦結就鬆了,再重新組織一下公事的架構,即可再繼續奮戰下去了。

很多人以為我喜歡下棋是因為我是箇中高手,其實不然,勝敗仍兵家常事,棋之所以引人入勝,在於棋勢的變化與下棋者的用人、用兵能力有關……說穿了,不外乎一個字─局。

【車】之所以會成為一盤棋中最容易且最常被使用的棋子,與所有的人都會希望自己可以五隻○車打這個天下有關,但很可惜,棋盤上永遠只允許兩隻【車】。那如何善用這兩隻【車】?讓他能盡其才的發揮最大效果?我想,這也是吸引下棋人的真正關鍵。

又或者有人真可以擁有五隻【車】,但要如何避免每隻【車】陷入單打獨鬥、孤獨地戰死沙場的狀況?

一盤棋代表的並不單單只是一盤棋,它的內涵往往是一個專案團隊的經營、人才/人力的運用及掌握:一個局。

此話怎說?

以技術經理為例,技術經理的好用,眾所皆知。在專案無法順利攻下來前,技術經理可以憑藉著其在技術上的熟悉,以及身兼pre-sale的身份,贏得客戶的信心、進而托付專案。

在專案進度落後時,技術經理則可憑藉著其對技術的熟練設法追上工程師等人延誤的進度。至於在專案遇到技術瀕頸時,技術經理則會以其獨特的嗅覺發現問題所在、找到解決方式。

有技術經理從頭到尾的參與協助,沒有什麼案子是攻不下來的,也沒有什麼案子是解不了的;校長兼撞鐘,只要技術經理一個人就可以通包了─其實,技術經理就是那一隻【車】。

但一盤棋到底能有幾隻【車】?一個公司又能聘僱幾個真正有能力的技術經理?(也是有公司一輩子都沒辦法錄取到的!)技術經理太好用了,但若一家公司只錄用技術經理等級的人物,其它的一概不錄用,會是怎樣一個光景?我想最有可能的情況有二:

第一,這家公司只找到了兩個人,然後就找不到人了;最慘的是,這兩個技術經理可能每天都還要自己倒拉圾。

第二,這間公司真的是攻無不克,沒有打不下的案子、結不了的案,但因為技術經理們每天都要自己倒垃圾、洗廁所、打掃辦公室等,造成太多無謂人力成本的浪費,最後,這間公司因為付不出薪水而倒了。

一個優秀的員工可以幫一家公司打天下,這並不特別,因為那個人本來很優秀,而不是那間公司有什麼獨到或厲害的地方。真正厲害且獨到的是,公司能讓看來不怎麼優秀的人才協助攻估天下(例如:麥當勞,用90%的工讀生,打遍了世界每一個角落)。

是的,我的意思就是,專案團隊之所以能順利營運,重點往往不在於【車】、或者是技術經理,而是那一個局。試想,當我的【車】被犧牲掉時,或者我根本就還沒有找到心目中的【車】時,我還有機會贏嗎?

作者現任CSC集團台灣澳圖美德(AUTOMATED)資訊長。中央大學數學系畢。專精於商業流程設計、資料庫系統維管理及系統整合,並分別在企業及IT業界有過資料庫規劃、ERP系統導入經驗。也曾授課於崑山大學、永達技術學院、關渡基督書院。



……(閱讀全文與回應)

2009年9月2日 星期三

test

引言123
內容456

……(閱讀全文與回應)

2009年9月1日 星期二

文章測試

這是引言
這是文章內容……

……(閱讀全文與回應)

拯救PMP的價值(上)

作者:熊培霖博士
我這一生最慶幸的是在30世代(30~39歲)的黃金歲月中,能在完成碩士學位返國後隨即躬逢其會地(以使用者的立場)參加一個超大型的「國家級」的計畫-【IDF戰機的發展】,以及陸續負責及參與重要武器系統獲得之大型專案。我40世代的前半段又有幸再度赴美完成「科技及研發 管理 博士學位」,是為了要投入「下一代戰機研發」。該計畫雖因某種原因未繼續進行,卻也使我後來有機會選擇了以更寬廣的方式來發揮我的專長與對國家社會的貢獻-一是作育英才、二是成立專業組織推動專案管理。回顧當年,我們參與專案的每一個過程與細節是完全美式的專案管理(包括所有的規範、制度、流程、文件、表單等),連選合約商及相關系統採購都是遵循美國聯邦獲得法規(FAR) 以非常嚴謹及公平的方式來執行,且整個計畫全程都有許多美籍顧問的參與及指導。所以我所認知的「專案管理」並不只是前後三次在美國接受訓練,在課堂上所學 的,而是真正在專案中所運用、所領悟到的工作邏輯與紀律,並形成思維理則與工作態度的一部份。我當時確曾是把那些知識、技術與流程與當作是「放諸四海皆 準」的規範(記得我在1996年第一次接觸PMBOK Guide時,還覺得其內容是相當地簡陋,其所述的方法論只是我們當年所用的一小部份而已)。
 
我在19985月從美國拿到博士及台灣第一張PMP(#13591)返 國後才正式開始與台灣的業界與其他政府單位接觸。那時才發覺我們在專案中所用的「專案管理」在台灣除了一些知名外商有所遵循之外,幾乎對其他組織則完全不 是這麼回事──毫無章法的到「不可思議」的地步──連我們「政府採購法」所說的『專案管理』也只是侷限在「營建工程管理」的範圍。這個驚人的發現,乃是促 使我當年願投入推動「專案管理」發展的最大動機。現已邁入50世代中段的我,更要把「導正專案管理在兩岸三地的發展」當成為終身的志業與理想。
今年2009年,當我們PMI台灣分會正在準備迎接成立十週年的盛會、及積極規劃籌辦一系列慶祝活動之際,及當台灣的PMP已於今年3月底已突破6,600位之時;我們在感到興奮之餘,卻產生了另外一股反思與檢討──〝我們在台灣推動「專案管理」這十年來,除了PMP這個屬於鑒定個人「專案管理專業知識與技術能力」證照越來越熱門外,到底對政府與產業創造了甚麼更具體的價值?〞其實,我個人覺得,除了不斷成長的PMP數字對許多PMP個人與培訓公司是有意義的之外,多數的企業與政府單位對「專案管理」仍還是相當地冷漠,或是不全然地接受。而真正令人遺憾的是台灣已有這麼多的PMP及包括本會在內已有若干個「專案管理」專業社團組織,但為什麼仍無法有效改變整個台灣長久以來「積弊成習」的「商業環境」及企業主及其員工許多錯誤的思維與行為?就算再歷經個1020年,即使台灣未來有幾十萬人甚至於平均每一個組織有相當大比例的人有PMP,若這些PMP們無法改變自己的基本思維與價值觀,以至不能改變其整個組織的文化,則一個既不能「兼善天下」(甚至於還「隨波逐流」)亦不能「獨善其身」的PMP們還有甚麼價值可言。
要探索這種PMP無法產生其應有價值的原因,重新檢視一下我過去所提出過的一些想法與預言就不難找到答案(如我在2003年寫的《葡式蛋塔、速食麵與專案管理》)。絕大多數的人都是在「形而下」的層次找答案,但大部份的問題都是產生在「形而上」的層次。以下列出五項我認為是造成今天PMP價值不斷被貶低的主要原因:
主因一:過度商業化的包裝及不實的宣傳-無人能否認PMP的認證考試與課程是一個「商品」,但以「PMP年薪四五百萬」來炒作它的價值絕對是不應該的,PMI總會以及台灣分會不但從未如此宣傳過,也曾不段地提出指正與澄清。要拿那樣的高薪不是不可能,但絕不是靠那紙PMPPgMP的證書,而是靠您真正能「實戰」的本事。現今,全球有超過33萬個有效PMP只是說明PMP僅是確保個人職場競爭優勢的一個「護身符」而已,而絕非高薪的保證。由於上述的不實宣傳確實造成許多人考上PMP對期望的回報產生一些失落。間接地,就質疑這個證照的價值。再加上,自己若又不知如何把所學能「身體力行」地發揮在實際專案上;當然,也就被別人懷疑拿這個證照的意義。
主因二:「炒短線」與「速食文化」式地培訓方式- 以我個人過去學習及現在教專案管理的經驗,我從不認為這種強調理論與實務結合的「顯學」是可以在 一兩 週內「速成」的。就算純粹以通過考試而言,也不應只重「考試技巧」,而是「導正觀念」,更不是急就章地只重表面而不重實質內涵。任何一個有責任的培訓公 司,無論是用甚麼方式來包裝與行銷課程,不應只是視能「多快考上PMP」為重點,而是以學員能「多紮實地學到知識」為使命。也就是因為目前許多培訓公司只在乎「多快」、「多高」(通過率)的風氣使然,而誰又在乎學的有「多好」及「多實用」,長此以往,又有誰認為PMP是有價值的?而以速成方式考到PMP的人又該如證明自己有作專案的能力?至於,〝顧問與培訓公司屬於知識性的產業,它強調的不是量而是質,不是只顧營利,而是對客戶的承諾;它的進入門檻看似不高但隱藏在內的專業能力、道德責任與智慧財產的問題卻始終被許多人所忽略。〞
《待    續》

作者: 熊培霖博士為現任專案管理學會台灣分會理事長,已於兩岸培養逾萬位專案管理人才,並持續擔任企業與政府機關的內訓講師,所領導的PSIG集團榮獲『中華民國傑出企業金峰獎』、『消費者頂級商品金鑽獎』、『顧客滿意度金質獎』與『國家品質卓越貢獻獎』。詳閱http://pmp-tw-test.blogspot.com/2009/06/pmp_11.html

……(閱讀全文與回應)
 
LAYOUT DESIGN BY [ Duncan ] modified from [BLACKCAT 2.5.0]
Released by Creative Commons License