2011年12月30日 星期五

MTP課程後心得與感想

十月底,肥蝦報名了學校傳管所吳美娥老師所開設的MTP課程,從十一月二十日起,連續五個週日到校上課八個小時。每次上完MTP課程後回到家總是累得晚上呼呼大睡,上整天課使得身體勞累?,這八小時課程對於從事IT整合工作的我豈能造成負擔!而是心累跟腦袋累。「作事要用科學的方法,帶人要以啟發激勵的方式。」老師這句話不斷地在腦袋裏盤旋,不斷回想自己在職場、在生涯上過往的種種;努力思考自己在工作、在生活上未來的走向,讓自己腦袋一直轉個不停,真得好

MTP課程主要區分為「管理的基礎(4)」、「變革的管理(2)」、「管理的流程(4)」、「培育與發展(2)」、「信賴關係的形成(3)」、「良好管理的推展(2)」。

一路從界定有關的事與人,說明相互之間的影響與運作講起;到定義問題,發揮團體與個人創意,強化與改善工作流程;經由計畫、命令、控制與協調,誘導正面動力、發揮指數綜效、促進循環回饋;配合整體與成員目標,進行自我與團隊的協同成長;引發由內在態度到外在行為的改變,調和氛圍,建立360度的溝通介面;建立正確、強韌、柔軟的態度,營造周圍的影響能力,確立自我風格的領導,進而促使正面良好的管理。這短短五天的課程,交待了完整的管理輪廓,介紹了正確的管理行為,雖然課堂上未能再有充分的時間來詳細引導有關的有效工具與作法,但講義中諸多的檢核表與評鑑表都可實實在在的應用在自我態度與管理行為的辨別與確實認知上,並可藉由每個回合中的案例瞭解到課程的精髓,審視自己在工作職場上的態度與作為。

MTP課程中首重為達成組織目的與目標下,「事、物、人、職、權、責」間有效的匹對與平衡。正所謂「事在人為」!但如何讓團體與個人去勇於任事,貢獻所長?就在於個人與團體的態度!只有良好的態度,才能進一步去引發知識與技能的學習,並且表現於外在的行為。外在的行為所企圖解決的就是實際或可預測未來與目的暨目標間的不一致(救火問題、發現問題、預測問題) 。經由「狀況的共有」,利用「5W1H」的處事方法,遵循社會與組織既有的法規,以及依據財務、顧客、流程、學習四個層面設定基準與進行管控。設定完善的計畫,在確定的目標下,擬定執行的策略與對應的戰術,並且畫分到各成員,在基準與可容許誤差下,進行動態的管控,並強化成員彼此間的合作與溝通。

部門成員間的技能與知識的發展及成長,在公司既定的目的(存在的理由)與目標(生存之道)下,也需要循序的培育與啟發。除了成員目前工作職務所需外,也需要進一步考量其未來的發展性,更重要的是建立起成員向上的動力與欲求,就發展行動力、思考力與團隊力所需具備的要項,逐步誘導,尤其在技能與知識的分享與傳承上,更需要經由在職的訓練,將新成員的新知與新觀念內化入原有的團隊,進一步促進團隊的成長與茁壯。

人比事更難以處理,事情是靜態的,事情跑不掉,但是事情隨著人員的參與(顧客、主管、成員…)以及大家不同的認知,不同人之間的不同作為,常將事情轉變為動態的問題與危機,隱藏了更大的風險,造成了更嚴重的後果。顧客的態度與行為我們只能臆測(可經由統計、資料探勘等科學方法),主管的想法與著眼我們可以揣測或詢問,但是成員的態度與行為,以及對於事情與問題的第一線處理,常常疏於掌控與協助,有時導致了不良的直接與立即影響。因此建立部門間信賴關係的重要因素,在於讓成員們有著良善與正確的態度與行為,協助與疏導成員人際間的互動與糾紛,確立暢通與正面氛圍的溝通環境。

接著就是個人領導能力的培養與展現。領導力=個人的態度+影響力。只有鍛鍊自我堅卓的意志,並如賈伯斯說的:「Stay hungry, Stay foolish」,藉由自己的正面態度,散發而外去感染部門的同仁,加上「說、教、做」,對於公事要求謹記「嚴以律己,寬以待人」,協同部門同仁達成組織設定的目標,才能發揮自己的影響力,推展管理的作為,。

MTP這六部分類對應到肥蝦的內心,深切的反省,真得有諸多個人作為與心態亟需改正。【管理的基礎】-讓肥蝦再次溫習二十年前大學所上的管理學,並更深的體會組織與人在管理上的重大影響。【變革的管理】-體會到問題的解決與工作的改善應立求先見之明,更應培養自我的創意與創新的思維,「時刻觀察、時刻瞭解、時刻關懷」,啟發部門同仁一起「發現問題、解決問題」的認知心態。【管理的流程】-PCCC(計畫、命令、控制、協調)應與PDCA(規劃、執行、查核與行動)應一同整合,並且落實到部門與個人的工作生活之中。在命令的流程中,切記沒有”…等字眼,隨時自我警醒,在不同的時機與重點下,自己與同仁溝通的方式(吩咐、請託、徵詢、暗示、徵求)。【培育與啟發】-除了自我與部門的能力培養發展之外,也要整合考量組織與個人、目前與未來間的協調與平衡,尤其是團隊力中的「表達、傾聽、柔軟、狀況把握、自律、抗壓」五種能力中的傾聽與柔軟,更是有迫切的需求。【信賴關係形成】-最重要就是自我態度的調整,時刻謹慎處理人際與政治的關係與互動,並且開放自己的心胸,積極的傾聽,以友善但堅定的態度去建立部門間大家的彼此信賴。【管理的推展】-領導力的養成與訓練自己深感還有待更多的努力學習的地方,隨時要能謹記:「整體部門的表現必先於個人的表現。」的重要性,並要徹底的展現出來。

上完這短暫的課程,在老師精彩的講解、舉例,同學踴躍的發言分享自己職場心得下收穫良多,但也深深感受到中階主管的為難。所謂是「上有聖意,下有民意,部門之間恐怕又有敵意」真是處處難為。作為中階主管不但要體察上意,體諒民意,身先士卒,奮勇殺敵之外;軍令與政令還要設法內化到部門同仁的態度,轉化其行為;要能主動分享,建立起「狀況與問題的共有」的認識,更要大家都能切身體認。就肥蝦所能體會到MTP精神要落實到工作中,真得對肥蝦自己是一個很大的挑戰,但是為達「正道」,肥蝦一定要努力改變自己,確信並秉持「知難行易」的精神,「just do it」就對了!

2011年11月29日 星期二

專案經理的自我管理-專案管理日誌


2011年開春以來,可說是事務纏身,戎馬倥傯!除了負責原有的系統分析與產品開發,又多了個負責部門管理與對業務部門支援的工作,真得讓自己忙得手忙腳亂,更甚者四月底得標案件在諸位上級長官的禮讓下,被執行長指定為專案經理,因此學校的論文只得請老師與老婆大人讓肥蝦通融延後畢業,那就遑論紓發與記錄自己對學習上的心得感想。

公司這一個四月份專案的總金額雖然不小,但規模更是金額的雙倍以上,面對的利害關係人又大過規模的雙倍,在目前臺灣這一個乙方弱勢的市場型態中,執行本案已註定要遭受一定的範疇、時程與成本的風險。在長官「讓嫌」下,肥蝦擔任該案的專案經理,在專案初始階段,肥蝦就認真思考過在目前公司缺乏完整的專案管理工具,以及大多同仁對專案管理較為守舊的觀念下,如何進行本案的專案管理工作。

目前公司基本上有制式的工作雙週報,同仁填寫本週已進行與下週預計的工作項目。但在考量此次專案的特殊狀況,因應以往專案團隊的成員只單獨填寫自我自身工作項目下,如何喚起大家一同注意本案目前遭預或感覺到的問題與未來可能的風險,肥蝦就將原有的工作雙週報新增了【問題/風險】與【心得/建議】兩個欄位。為了不讓專案管理工作變相增加原有成員的負擔,原本的應填寫的預計下週工作內容就請成員不用填報,因為就專案工作項目與成員的配置表,以及下一週的工作週報,肥蝦只要動點小手腳還是可以提供出公司所要求的工作雙週報。

本篇的重點不在闡述專案成員必須配合的專案管理工作,肥蝦想說明的是專案經理自身的管控作業。當然專案經理就公司的編制來說,也是公司的員工,因此也要填寫工作週報或工時單,但是肥蝦以為這只是最基本的工作,工時單與工作週報可以配合輸入到專案管理工具作整個專案進度與成本的掌控,但是對專案的整個發展變化,思考與預防專案可能風險與問題,瞭解專案進行的整體動向,尤其是日後僅依憑繁多的專案RecordsLogInformationDocuments資料進行Lessons Learned也並不容易。因此肥蝦就每天記錄專案上的工作與發生事情,寫下專案管理日誌。

肥蝦以為專案管理日誌有幾個重點:一、記錄每日發生與專案經理工作重要項目。二、註記專案已有的問題與未來風險考量。三、記錄待辦事項與今日所作所為所想的心得與感想。四、串連其他相關的專案文件,如收發信函文件、會議記錄、交付的文件成果等。

肥蝦個人的專案管理日誌僅是用Excel工具列表管理,目前肥蝦的專案管理日誌主要有以下的欄位:日期、重要事項、進度狀況、溝通狀況、收發文件、會議記錄、郵件通訊、風險考量、待辦事項、心得/感想。其中收發文件、會議記錄、郵件通訊三個欄位是作為連結其他文件註記使用。

雖然有時候會漏打一些資料或隔個倆天再來補登,但整體來說,當肥蝦在編寫工作週報或者專案管理會議報告之時,只要copy一下專案管理日誌的內容,再稍加潤飾就可以交差,因此這個方法對肥蝦個人而言還蠻實用的。

2011年4月26日 星期二

「胡適雜憶」讀後心得與專案管理


記得大年初五在家裡跟家人聊天之時,小妹說到她先前看電視介紹胡適的節目,她覺得胡適的小腳夫人根本配不上胡適。肥蝦自己對於胡適的生平、研究與家庭實是所知甚少,除了年前看了唐德剛先生所寫的「胡適雜憶」外,家中也只有那本以前讀過「四十自述」,對於胡適的豐功偉業都是在以往的教科書中所得之。只是就夫妻相處來說,以肥蝦個人的感受是覺得外人應該沒有任何立場去評論夫妻兩人有沒有配不配的問題,因此回了一句:「說不定胡夫人剛好就是胡適生活中不可或缺的伴侶。」

個人以前已讀過唐德剛先生所著的李宗仁張學良兩人的回憶錄,也曾在【傳記文學】中看過一些先生的文章,對於先生在專業上的學養有一定的瞭解和崇敬,此「胡適雜憶」之中,先生以亦文亦白的文筆,亦尊重亦詼諧的態度,從胡適所言的:「哲學是他底職業,歷史是他底訓練,文學是他底娛樂。」中,評論「胡氏『中學』也止於『乾嘉』,西學亦未超過『赫胥黎』」的看法,來探討胡適先生的治學與生活態度,一路看來真得讓人興會淋漓,大呼過癮。

就肥蝦從該著作中所接觸到唐德剛先生對於史學研究的變遷;對於拉丁化語文與歷史的互動;經濟在史學中的角色;對於中西文化與中人西化的分類;「自傳」與「傳記」的界定,等論述,實是非常佩服,使肥蝦這個以歷史為生活娛樂的人有無比的收獲。個人將書中一些字句,斷章取義的整合為肥蝦目前個人所感受到「專案管理」此門學問在台灣發展境況的體認,以及個人附會穿鑿的初淺想法!

()台灣目前『專案管理』的境況

「胡適雜憶」摘錄:

須知胡先生那一輩的知識分子,是我國三千年婚姻史上,可以選擇三種不同的婚姻制度,和三種不同底婚後生活方式的唯一的一輩!這三種制度便是:一,純粹農業社會所特有的「舊式婚姻」;二,工業文明社會裏的合夥制的西式婚姻;和三,「轉移時代」(transitional period)裏,半中不西的所謂「新式婚姻」。這是三種不同時代的不同制度,談不到孰好孰壞;更談不到在某種制度下,哪些家庭生活就會更「幸福」。他這個皮球最後總算被踢到那個「三從四德」底古老堡壘裏去。在這個古堡裏,他是絕對的主人。他那「較好的一半」是死心蹋地的「相夫教子」,為他而生存,為他而服務;使他在學問上、事業上、橫衝直撞,而無後顧之憂。

肥蝦的想法:

目前,台灣的IT軟體產業也是碰到相同的狀況:(1)「舊式婚姻」:以前沒有搞那勞什子的「專案管理」,就照著原有方法把專案做完就是了。(2)「西式婚姻」:找人去考個PMP之類的證照,把國外的專案管理知識與工具原封不動的搬進來。(3) 「新式婚姻」:把自家公司的流程改一改,呼應一下國外的專案管理,套些專案管理工具。值此之際,最可怕的是一心要打破舊規,也不管自己的背景與需求,認為只要新的就好,不管原先的配偶是否能旺夫就先休了再說,那反而為物所役,因管理而專案,那就捨本逐末了。

那我們再採用那種作法呢?其實也同於唐先生的見解,不管是用原有公司的方式,或是整套把專案管理流程與工具搬過來,或是因應自己公司或專案的需要來參考專案管理的Know-How,只要所有一切的管理都是因應專案的需求,真的對專案進行規劃與管控,真的去解決專案的問題與困境,得以讓專案的執行團隊能無後顧之憂地去作專案,那就是一個好的方式。

()『專案管理』訓練的處境

「胡適雜憶」摘錄:

那也就說明他沒有把「語言文字」看成一種與社會變動息息相關的人類思想上的「交通工具」(communication tools)。工具是決定於社會對它的需要。一個大電斧對一個老土木匠來說不但不是個「利器」,而且是個大「累贅」。胡氏把語言文字的變動和社會發展的程序孤立起來,以單純研究語言文字本身的變動為其研究的重點所在。

二次大戰後的西方史學已經走上所謂「以社會科學治史」(social science approach)的途徑,因而當年專搞帝王將相的名史家像哥大老教授卡頓海斯(Carlton J. H. Hayes, 1882-1964)這時已不太叫座。所謂現代史學已經由研究「英雄」轉而研究「時勢」;而個人英雄們所造的時勢-也就是海斯教授所著重的政治史-已退位讓賢。那製造群眾英雄的時勢-也就是社會經濟變遷史-則由一次大戰時的旁門左道一變而為二次大戰後的史學主流。所以要寫一個「英雄」的「傳記」首先就要找出這位英雄成長過程中的社會背景,寫傳記的人如果把他底英雄和社會「隔離」(alienated),那這英雄便不再是個活人,他只是「蠟人館」裏的一個「蠟人」罷了。

肥蝦的想法:

目前台灣的一些教育訓練單位在推廣專案管理之時,太過於把專案管理抽離於實際現況與運用思維之外,而單純講授專案管理本身的工具與那PMBOK上的ITTO,以考取證照為惟一指引,忽略了專案管理肇生的「時勢」以及現在國際與臺灣現況的「時勢」,因此現在考取一張PMP證照所獲得外界的懷疑與批評大於肯定與讚賞。目前有非常少數的顧問公司開始以教授企管案例分析與訓練的方式進行與學員間的互動,這是一個非常可喜的現象。肥蝦一直以為專案管理的理論不可脫離於實務,實務也應要能回饋到理論,在如此良性循環之下,臺灣的專案管理能量才能不斷壯大,並進而影響周遭,匯聚成流。

()『專案管理』的用途

「胡適雜憶」摘錄:

荀子說:「登高而招,臂非加長也,而見者遠;順風而呼,聲非加疾也,而聞者彰。君子生非異也,善假於物也!」

一個學者如對新興的經濟學基本的概念不清楚,那他對現代的政治問題本來也就無置喙餘地。「經濟學」是十八世紀以後才興起的第一門社會科學,也就是人類知識史上一門嶄新的學問。經濟史家-尤其是偏向經濟史觀的學者,認為傳統史學過分看重政治故事了。其實「政治」不過是「經濟」的附庸而已。經濟學者們老王賣瓜,自賣自誇就逐漸地搞出個「經濟決定論」(economic determinism)來。馬克思也是個經濟學者,他搞起來就更為專門化了。他認為「經濟決定論」還不夠徹底,他搞的是「生產關係決定論」。什麼是「生產關係」(relations of production)呢?那就是社會上出勞力的「生產者」和掌握生產工具(包括「資本」)的「所有者」之間的「關係」。奴隸主的社會行為就是「唯利是圖」,奴工的性質則是「其工非強迫不做」。做生意和開工廠農場的人都知道,圖利並不太容易;迫人做工尤難,你要付出大批管理費。同時,在一個農業社會裏,並不是每項農作物都可以利用奴工圖利的。

肥蝦的想法:

「沒有PMP事情一樣也可以做好,有PMP不見得做事都會是零缺點。」 這是【專案管理的生活思維】論壇上Klaus大大的留言。肥蝦非常認同這句話,因為瞭解跟實作並未有完全的一致性。但是瞭解專案管理的一些觀念與工具,並進而引用,目的就是希望能在專案管理上能更加的完善與妥適。人說:「上智者悔前,中智者悔後,下智者無悔。悔者,思也!」一本PMBOK或者相關的專案管理知識,其實就是經由有系統的整理前人的經驗,協助我們在專案前、執行中、結束後,去思考的脈絡與工具,而也正是PMBOK為什麼是四年一改版的原因:「專案管理知識是需要與時俱進的!」

很多主管或長官都認為「只有接不到的案子,沒有作不完的案子!」、「只要關係好,政治運作正確,沒有結不了的案子!」這個想法不能說是錯誤,「政治」確是非常必要的!雖說:「政治不過是經濟的附庸而已」這句話或許過分誇大了「經濟」的影響力,但金錢利益的糾葛往往就是政治背後的主因。如果妨礙到客戶的「經濟」利益,客戶也不會就憑著以前的良好關係就讓廠商無條件過關的!

而且專案管理的真正目標,肥蝦以為並不完全是「如期、如質、如預算!」而是要創造專案相關利害關係人的最大利益!專案管理教科書與相關理論,是在專案的產生就是基於比較後最大利益的基礎假設上,因此提供一系列以為能順利、妥善的完成專案的方法與工具,以為只要專案能「如期、如質、如預算!」就可獲得假設中的利益。因應此假設的限制,在專案管理理論中載著不斷要求審視專案的整體效益是否如預期一般,一旦發現苗頭不對,應該要中止專案。

()學習『專案管理』應有的警惕

「胡適雜憶」摘錄:

時代和環境限制了他們的成就;時代和環境也寵壞了他們,沒有逼著他們教而後知困,自求上進。

胡先生沒有梁任公那樣憨直。對自己思想挑戰的文章,在胡氏著作裏是找不到的。

可是胡先生治史最大的弱點也就是他以偏概全。第一,他把這門新興的學問完全當成玄學來處理而忽略了它「社會科學性」的另一面!第二,他把強調「生產關係」這一派當成「社會經濟史學」的全部而加以輕視;第三,是他傳統士大夫的頭巾氣,只重正統學說,而把「怪力亂神」全部抹殺,對他們的抗議,充耳不聞,認為「不值一駁」。

好的詩人應該是情感多於理智的,而胡氏卻適得其反。胡先生的文章是清通、明白、篤實。長於說理而拙於抒情。作家要有豐富的生活經驗,和根據這經驗所發出的玄妙底幻想和見解。那一直躲在象牙之塔內的胡適之,一未失戀、二未悼亡、三無憂患。生活十分單純的人,斷然寫不出情節曲折動人底文學作品。

須知「博士」這個東西,基本上是騙人的。我國自秦始皇的驗夢博士起,在科舉時代被它騙了兩千多年。西學東漸之後,洋博士又繼起騙人。筆者不是說「博士學位」一無是處,只是-且引用胡適名言-「社會對它的報酬,遠大於它對社會的貢獻。」

肥蝦的想法:

肥蝦以為專案管理學門的知識還在發展之中,在PMBOK 2004年版中的圖1-2描繪一個專案管理團隊應具備:應用領域知識、標準與規範,瞭解專案環境,一般的管理知識與技巧,個人技巧,以及專案管理知識的專門技能;而且也特別說明了PMBOK所載的內容僅是這其中的一小部分。因此讀熟PMBOK並不代表就瞭解了專案管理的全貌,更不可以偏概全。作專案除了從書中學,也要從實作中學,從他人的經驗中學,是學無止境的。

()『專案管理』中的人際互動

「胡適雜憶」摘錄:

「現代西方文明」裏的「生活方式」是以「契約」、「合同」、「利害」、「力量」、「鬥爭」等深入人心的概念為基礎的。所謂「民主」,所謂「容忍」 (這是胡氏晚年政治哲學的精髓)只是力量、鬥爭、利害等均衡以後的契約行為。

胡先生在中國未做過官僚,在海外也未嘗與洋人共事,因而他沒有看出今日西方的社會-這個陳獨秀所說的「以小人始,以君子終」的社會裏面,那些人與人之間有禮無讓、刻薄寡恩的「小人」的一面。

「無讓」不一定就是「不仁」。美國社會也是有仁有義的。不過他們重義行仁卻是行有餘力以後的善行。在他們各為己利相競爭、餘力不足之時,大家相處則是絕對的「在商言商」(Business is business),所以「人不為己,天誅地滅」這句話,在一般西方人看來,並無大錯。「為己」是他們商業道德的百善之首。大家都為己,所以他們的口頭禪變是「如果你不保護你自己的利益,誰替你保護呢?」(If you don’t protect your own interest, who will?)如此,則社會上愈是性存侵略,能得寸進尺的貪夫,便愈有辦法,也愈為社會所稱許。人與人之相處如專以「侵略」(aggressive)相尚,則同事同夥同僚之間有利害衝突者,則防友如防賊。你一不小心,你的「利益」就要被人家「剝削」(exploited)了。

肥蝦的想法:

「人不為己,天殊地滅!」對於一個專案的承包商來說,這真得是金言玉語。從專案前、中、後,政治的運作是不斷在進行的。把規格內的需求作好,這個僅是基本的下限,甚至也還可以調整!重點是到底專案的運作有沒有達成一個是「力量、鬥爭、利害等均衡以後的契約行為。」因此專案的啟始與結案需要好的業務高手,在專案執行中,也需要與業務人員有完善的密切互動!如果專案經理能夠專注於專案本身,並且依循的適當方法與步驟執行與溝通,而讓這達成「力量、鬥爭、利害等均衡」由業務高手來處理,相信對於專案目標的達成應該有著最佳的助力。

()『專案管理』的應用

「胡適雜憶」摘錄:

五十年代中期筆者在哥大口試。有位教授問我「林肯是不是奴隸解放者?」我知道這問題不易回答。因為我如說「是」,他一定要引經據典說「不是」;我如說「不是」,他也可用同樣淵博的學問來證明他底「是」。不管「是」與「不是」,我都要不及格。這時幸好我情急智生,反問了他一句:「照足下看法,美國史上有沒有一個所謂『奴隸解放者』呢?」這位慣於考人的人,一旦被考,情急智不生,只好馬虎地答了個有。因而我再追問他一句:「如果有的話,那個人比林肯更夠資格呢?」

筆者幼時便聽說我族中有個老祖父,他老人家每年批撥兒女學雜費時,總要把女孩子的預算上的「游泳衣」一項「劃掉」。女孩子們氣死了,背後把這個老頭子形容成「頑固」、「守舊」、「陳腐」、「落伍」但是「游泳衣」還是買不成。後來她們聰明了,把「游泳衣」改寫成「夾層連衫圍裙」,這一來老祖父欣然同意,閤家皆大歡喜。

肥蝦的想法:

專案管理不是一成不變的,就如那PMBOK 2008年版1.6在專案經理角色中所說的:「執行力-This refers to what the project manager is able to do or accomplish while applying their project management knowledge.」知識的運用需要技巧,在能得知專案管理的精義後,如何來運用?肥蝦以為需要因地、因人制宜!有時候「山不轉,路轉;路不轉,人轉」是非常要緊的!轉個彎,只要能達到目的與要求,也許有些地方也不用過於拘泥!

()『專案管理』是否為專案成功的萬靈丹

「胡適雜憶」摘錄:

但是一個人的成就,單靠主觀條件是不夠的那些偶然性很大的客觀條件也要決定一個領袖人物事業成敗的一大半。只有客觀條件與主觀條件發生了密切的配合,才能使一個未來的領袖逐漸從群兒之中脫穎而出從而變成個實際的領袖。「才不才,人也!遇不遇時也!」文學革命原有是和政治革命一樣地有其「階段性」。次一階段的「革命對象」往往卻是前一階段的「革命元勳」。在現代世界文學發展史上,中國文學的發展原比西洋文學的發展遲了一個階段。因而胡適之這個美國文學革命運動中的「反革命」,回到中國,正好「階段」巧合,因而一舉成名,竟做了中國新文學運動中的「革命元勳」,豈不是時也運也乎哉!

肥蝦的想法:

具有專案管理證照,通過CMMIISO等認證,確實依照專案管理方法施行,使用完善的專案管理工具,這所有的一切一切,並不代表專案就一定成功!所謂「盡人事,聽天命!」雖然很悲觀,但有時就是如此。時間移轉,環境在變,很多事都是無法精密預估與計算的!但是有著一定的法則與規章,盡力作好能作的,應該要比瞎貓去撞死耗子的機率高很多!

2011年3月31日 星期四

愚人節的愚人之見-呼應Mia大大的TOC單一專案規劃方法


肥蝦在【專案管理的生活思維】看到了Mia大大的專作「該如何改變(Part 2) TOC單一專案規劃方法」(http://www.projectup.net/blog/index.phpoption=com_content&view=article&id=4027:to-what-to-change-to-part-2-toc&catid=8:pmp-pm&Itemid=18#yvComment4027)因此也來呼應一下TOC

經濟學中很多理論都引用物理學的觀念如最有名的"彈性"TOC的創始人Eliyahu Moshe Goldratt(圖片來源:http://en.wikipedia.org/wiki/Eliyahu_M._Goldratt)正是一名物理學家!當初看到TOC理論,就覺得好親切!

經濟學把生產資源區別為土地、資本勞動力跟企業家精神,對應到一個軟體專案,就好像是軟硬體設備、資金、勞動力跟專案管理精神一般!在生產要素有限之下,為達到目標如何加以組合?這就是企業家精神或專案管理精神的重點所在。

因為在constraint下追求MaximumMinimum幾乎是經濟學中個體經濟的基礎,因此TOC一下子就擄獲肥蝦的心意。

因此針對目標所安排出來的schedule必須在因應constraint下重新安排,取其最適解,但這最適解糾就悠關了兩個重點:

(1)目標

Target經濟學很強調目標的明確性,就是可測量性。因此如何界定目標,設定量測的標準與方法,就很重要!經濟學知道一個目標的量測很難用單一方法或Metric就可以掌握,因此有所謂的先驗指標,落後指標,同步指標;以及資料的正確性(資料的掌握,瞭解,取樣,估計,機率,正也是統計的重點)!這在衡量專案時也是要注意的!PM教科書中一再強調EVM,但PM應謹記:「每個呈現數值中得組合成份與數字的特性!」, (基本上現在所有的PM Tool所提供的EVM都只能算落後指標!)

(2)限制

在經濟學中所強調的限制式,主要在生產資源,但除了軟硬體設備,資金,勞動力,跟專案管理精神之外,也應該可以呼應PMBOK的九大知識領域中的時間,成本,品質,人力,等要素!因應限制,感覺上TOC強調:一是緩衝的使用,二是限制的突破!

在緩衝上TOC提出了:

(i)資源緩衝:針對資源有限性。

(ii)接駁緩衝:針對步驟依存性。

(iii)瓶頸緩衝:針對必要程序限制性。

(iv)專案緩衝:針對整體專案性。

在突破限制上,TOC強調

(i)確認制約。

(ii)有效剝削制約。

(iii)其他一切遷就制約。

(iv)鬆綁制約。

(v)重新檢視。

這五個重複循環的流程!

Mia是一位TOC的專家,在此篇中的舉例也正呼應了TOC的精神,雖然例子中Mia以資源為主,(PMBOK也以為TOC主要在資源)但肥蝦以為Mia的重點是在限制,限制的範圍涵蓋遠大於資源!但講資源一般人比較有感覺,講流程,講人際關係等無形的限制,可能就不好說明了!

此外,PM的觀念中都是估完範圍後再來確認資源,就經濟的觀點(或肥蝦認為的TOC)限制是一開始就存在的!甚至在範圍之前就存在!因此Buffer的增加也要遵循這限制!

因此專案最好的思維應該是在限制中保留Buffer,因此一開始就要設法以最精省的方式來達成目標,然後(限制-最精省的方法)就是Buffer!為了確保目標的達成,再來安排Buffer

經濟學從十九世紀中從追求靜態的均衡解到強調動態的均衡!關鍵就在時間,物換星移,因此就算環境如您所料,但隨著時間的經過,市場的變動,原先的架構也會脫離當初的均衡解,再經過調適,而最後這均衡解是收斂還是發散,就決定了這目標能否達成!(就因為太複雜,所以經濟才會強調:其他條件不變下,但這在現實當然是不可能的!)

因此肥蝦看到了很多的軟體專案的流程都follow一些開發方法論,從簽約、kickoff會議、需求訪談、規格確認、程式開發、單元測試、整合測試、驗收測試,等程序均是一成不變!心中有時覺得是"讀書反被讀書誤!"

就像Mia所舉例的流程可以調整的!就專案層級而言,不變的只有目標跟限制;若就Business來說,這目標跟限制也是會變的!因此一個PM必須隨時注意目標跟限制,並且要常「眼觀四面,耳聽八方!」所有的流程都要能因應實際的限制而去動態的調整!

還有這目標!到底是MaximumMinimum,很多人一開始都不清楚到底是要Maximum?還是Minimum?在經濟中,雖然認為在大多的情況下Minimum CostMaximum Profit的必要且充份的條件!但肥蝦印象下,有些就不會是如此了!

因此一個專案的目標,大家都說是要『如期,如質,如預算!』但沒有這麼好的事啦!目標還是要先弄清楚!

還有‧‧‧‧

今天愚人節,肥蝦就寫些愚人的看法,來逗大家開心!!!!

2011年2月24日 星期四

殺雞儆猴-新官上任是否要燒火?


肥蝦上任,一下子除了自己原有的專案外,還要作一些Presale的工作,過年前就這樣一直忙到了2/19,好不容2/20有個空檔,跑去聽了金融研訓院開辦的「中小企業授信產品風險管理實務」課程。看了金研院的網站,想不到身為IT人員的我,在金研院也是花了將進一、二十萬,唉!只能怪自己的好奇心太重。

在課堂中,老師提到了中小企業在信用評分的項目,以及事前的實勘與後續的複審之中要特別注意一些企業異常警訊及癥兆,其中在管理上的重點有著:負責人或重要主管辭職、重要主管調動反常、員工出勤情況不佳、人員離職率高、士氣低落等項。這就讓肥蝦想起前陣子,在FaceBook上也看到一個在User Side工作的年輕朋友,說她的處境艱困,委外廠商駐點的工程師每個都掛什處長經理之類的,可能他們這些人欺負她年輕,所以壓不住陣腳,使得她公司內外遭收煎熬。另外,上週一個哥們告訴我他們公司的狀況,以及他自己也要離職。其中最大的導火線就是一個剛上任的專案經理跟公司高層報告說團隊中有老人不願跟他配合,希望能殺雞儆猴一下。我朋友可說已是該公司的創業元老,更是這新初任專案經理的指導前輩,因此我這換帖的就成了那隻雞。

殺雞儆猴、陣前立威!?一個專案經理或是部門經理,當然都希望專案團隊的成員,部門內的同仁,個個都要聽命於他,以他馬首是瞻;在與公司其他部門溝通,以及與專案利害關係人的互動中,大家都只以他為窗口,只有他說了才能算數;在面對專案贊助人或公司高層,他就代表這個專案、整個部門,所有光芒都在他身上。當然,以上所寫應該是每個專案經理或部門經理所想的;但說實在的,確也是最不應該發生的!

記得2009年寫過一篇「專案經理追求的修為-"Pursuing the Perfect Project Manager"讀後感」,在Permalink這一篇文章中所載明專案經理的特質中,第一項-自我與無我(Total ego/No ego);第二項-獨斷者/委託者(Autocrat / Delegator)第三項-領導者/管理者(Leader/Manager);第八項-急迫/耐心(Impatient/Patient)的說明,特別可以說明肥蝦對於【殺雞儆猴、陣前立威】目前的想法-「有功不必在我」,才能使您達到「我在必成功」的終極目標!

權力使人意亂情迷,奪權爭利是一般人性的寫照,在工作職場上更是如此!身為一個專案經理或部門主管,身處人與人溝通互動的要徑之中,有幸者,更是在權力角力糾葛拓樸的一個Node,因此如何妥適的利用,並且有效的擴大與渲染,以利於執行專案與部門的工作,實在是一門高深與艱難的學問。肥蝦在職場渾渾噩噩十幾載,這門課一直修得不好,自我的工作因此跌跌撞撞,一路走來也是備嘗艱辛!在此也只能分享自己的慘痛經驗,以供各位先進作為前車之鑑!

當進入一個新的專案團隊,首先會遇到的人際緊張,可能來自資深前輩、既得利益者、團隊內藏鏡人的同仁挑戰;但一方面,也可能有原先弱勢者、既有小團體的拉攏與示好;最可怕者,為別有居心者企圖利用您一時情況未明時趁時誤導您,讓您來個威信盡失、天恩不在。因此要能如何解套呢?

有些朋友會趁著天眷正隆之時,來個新官上任三把火,殺雞儆猴,馬上立威,勢圖以恐懼管理為立基,再進而圖以小恩,攏絡人心。此等作法,早已是古有明訓,就如大陸劇那『雍正皇朝』中的康熙於彌留之際,降能臣、黜幹吏,為得就是鄔先生所言的:「不致使這些棟樑因皇位鬥爭斷喪;更使得繼位者得以恩駕馭,不致有以下犯上之虞。」因此我這淪落為雞的哥們,就成為此劇本下的龍套!當然在更深一層上,上位經營者也是另有他圖,只是這後果如何都與上位者無關,因為這是新任專案經理的建議!

再來,殺雞是否可以儆到猴,還是落得個人心盡失?這也得要看您要殺那支雞!俗話說得好:「打狗也要看主人!」但是很多時後不打老虎,是收不到人心;打了老虎,卻是虎患依舊,個人徒留身後名,記得小蔣貴為太子也曾吃過這個排頭,那非為皇親國戚的我們豈可不慎!但是很多時後,那許多狐假虎威的,這個打了不但大快人心,收效宏大,對自身威信的建立是有加分的效果。肥蝦去年當社區主委之際,就是用了這招,後續也較少有刁戶來叨擾!

而最常的狀況,大多就像前陣子看的「萬曆首輔張居正」,書中所寫的張居正與那馮保都是為了奪權隱忍長久的環境壓迫,惟有與權勢者虛與委蛇,待那日身處權力核心,才能展現作為。但要「忍人不能」這哪是一般無知小民的肥蝦作的到呢?德川家康的那招「等到鳥自己叫!」難呀!

因此遇到團隊成員或同仁執意的挑戰你,就要衡情酌勢的處理,先行分析局勢與人員的重要性與可取代性,看看Networking以及每個人Power的大小與其來源!再來藉著建立Ground Rules來建立一些最低與最基礎的遊戲規則,利用Interpersonal Skills以及Recognition and Rewards來建立向心力與您的鐵核心,再藉由鐵核心的成員來加乘人際網路與人員互動。這C n2的溝通管道,身為專案經理要儘量去依其利害性排出每個點之間的最短路徑,進而推演出樹狀的架構,如此能有效的駕御專案的溝通管理。

那要是被臨危授命,接手一個分崩離析的團隊呢?當然安內才能攘外的政策是第一優先選項。惟有安定了團隊,才能建立客戶與您之間的信賴與安全感;除非,原有團隊的價值盡失,人人唾罵,那大動作的作為才有必要。就如那講授中小企業的老師所言:「管理上的負責人或重要主管辭職、重要主管調動反常、員工出勤情況不佳、人員離職率,都是客戶評價您這團隊與專案是否能如質、如期完成的重要指標。」

每個人都喜歡享受權力,有些初任專案經理,以為自己是大權在握,盼學著那歷史先例,來個「殺雞儆猴-新官上任三把火!」也許換個角度,重新思考!想想在「自我與無我;獨斷者/委託者;領導者/管理者;急迫/耐心」要如何取捨!如何進退!才是「明哲保身」的正道呀!

2011年1月31日 星期一

專案經理 Versus 部門經理之第一步


「有點權力之後,執行專案應該就會更順手。」執行長口吐裊裊白煙的回應著肥蝦所說的:「我喜歡當專案經理,可以享受帶兵打仗,征服的快感。」對於以往支援業務與專案作業需要而將技術人才名義上有個歸屬的部門,在以往長官的長期忽視下,其實可說是名存實亡已久,執行長的一句話,想著兩年前的輸尿管事件(請參看:看醫生我會怕!-專案的風險回應與品質控管”)之時執行長相挺地讓我放了近兩個月的病假,也只能摸摸鼻子硬著頭皮上任去!轉眼之間,從人事佈達到今日也快滿一個月了!隨著名片上名稱的變更,這近一個月的時間裏,會議、會議與會議,長官談話、指示與詢問,加上公司歲末的尾牙、聚餐與聚會,幾乎佔了一天中最精華的時光;以部門經理協助其他專案經理,以及其他日常的行政作業,又佔據了其他鎖碎的時間;對於自我負責的專案進行更深入與完整的思考,以及與專案成員一同閒情逸致的聚在一起暢談對專案技術想法的時間幾乎是不復存在。(更遑論塗鴉些自己心得感想的時間!)

記得去年中買得一本上奇出版的「走出軟體工場」,肥蝦雖然也是一心希望我們這在公司中的小小部門也能「走出軟體工場」,創造點績效。但是就如約耳在那一本「Joel on Software」的導論所說從程式開發人員到專案經理的角色變換一般,從一個專案經理到兼任部門經理(更嚴格地說,應該是部門經理兼專案經理。)其間模式作業的變化也是讓肥蝦一時無所適從。以前專注的焦點與範圍變得更多樣化了!以往互相競爭資源的專案經理間也多了些不同的衝突!以往對肥蝦頤指氣使的行政人員更是加上了些資源與權力上的糾葛!先前不需要互動的部門變得密切起來!往常不需要出面應付的迎合場面變得被交代要出席與會!正是所謂「未蒙其利,先受其弊。」部門經理所要克服的困難,以及要挑戰的目標,與當自己是專案經理之時所推想的「開開會、回回mail、喝喝酒」是有所不同的!

如同專案需要績效,部門也有績效上的壓力!如同溝通在專案管理上的重要性,跨部門與部門間的溝通也是一門大學問!如同專案團隊內與利害關係人間的政治運作,公司的政治力道也是不遑多讓!專案管理所遭遇的問題,部門也一樣會有,差別在於目的、範圍、對象、時間、地點、程序,更慘得是除非肥蝦被換掉、部門被裁掉、或者公司,不然部門經營是沒有明確的結束日期,是沒法咬牙硬撐的!

就拿一上任讓肥蝦最頭痛的問題-部門績效!一個技術人員為主,以支援業務與專案為目的的部門,部門的績效該如何看待?就拿平衡計分卡中的學習與成長構面來說好,此一構面著重在讓企業能確認長期變動的能力。在人力有限之下,現有的人力所有的技能來自於以往的訓練與學習,隨著IT科技的日新月異、市場環境的變化,部門必須著眼於人員與新技能的培訓與養成。但是業務部門所承接到專案內需要的技能!專案經理對於部門所派遣過去人員的安排與訓練!這一切是否都能跟部門的規劃一致?業務求得是賣出既有的產品,求得是承接所有能接到的案子,要得是能要對他所聽到客戶的任何需要(wants)都能說可以做的答案;專案經理期盼的是給他已有經驗的人員,要得是充分足夠的人力,不要的是新手,不肯的是部門抽回可能稍為閒空的人員。那部門要如何配合公司目標的人力規劃,著手人才的培育,業務經理跟專案經理說:「那是部門經理要做的事!」

講到專案經理與部門經理間的政治角力,記得以前肥蝦說過:「專案要人有時必須從高層施壓!」現在當了部門經理就回頭吃到這個苦楚!除此之外,又因為自己還兼著負責原有的專案,搞得自己裡外不是,在Bryan and Joe的部落格中落下這一句話:「以前可以抱怨部門派來的人素質太差!現在都不敢講話!以前會想搶高手,現在反而不敢把高手調到自己的案子!」原因就在-怕落人口實!增加與其他專案經理間的衝突!記得在漫畫「家栽之人」看過桑田義雄說過一句話:「犯的罪大,處罰就重;犯的罪輕,處罰就輕,這是基本常識。不管判得罪再重,他還是得回到社會上生活。」同樣地,身為一個部門經理也會直覺得以專案的金額與壓力去作判別-「那個案子金額大、重要性高,就派遣能力強的去;那個案子金額少、不具有未來性,所派出的人力跟該專案經理所要的人力就有點落差,這也是基本常識呀!而且專案中的人員,要是在專案參與中沒有離開,那他還是會回到公司裏來。」因此部門經理所期盼的是專案經理帶回來的人,不管是新手或老手,都是再經過歷練成長的。但以肥蝦身為專案經理的經驗,專案經理都會以為自己的專案具有獨特的重要性與未來性,專案所需求的人力與其能力都應該是充分足夠的,因此就造成了部門與專案間的衝突!

此篇文章是肥蝦上任一個月的小小心得,往後在推動部門管理,以及身兼專案經理應該還有一段路要走,屆時再來popo自己的看法與想法,還請 各位先進給予指導!

2011年1月11日 星期二

軟體專案管理第十六週課程心得_什麼是configuration management

什麼是configuration management

光就譯名,Configuration Management這在台灣有人翻譯成建構管理、組態管理、構型管理、或稱之為型態管理;在大陸則稱為配置管理。Configuration Management這個管理作業,因為台灣專案管理環境尚未成熟使然,常常使得光看字意而缺乏實際運作經驗的人很難瞭解其中的要義,或者與version control很難界分清楚。

本周的第十五章型態管理,因為焜安同學有事未能與課故由老師代打,老師在課堂直接就指出現實環境中因為軟體專案的成本與期限壓力,台灣地區甚少有軟體公司會於專案團隊中安排專門的Configuration Management人員與工具,加以Configuration Management也會增加程式開發人員開發作業的複雜度,因此一般有規模的公司也僅僅是作到版本控管(version control)。接續報告的子嵐同學因為並未實際接觸到軟體的開發與維護,因此對於此部分有著些許的陌生。幸而代興同學於銀行的資訊單位工作,無私的與大家分享了銀行在資訊系統的維護或者建構上,對於系統維護與變更的流程規定與實際經驗,其中從需求的提出到確認,以及程式變更的分析、申請、測試與上線都有著一套秩序井然的規定。

說實話,肥蝦也是身處在台灣的軟體產業之中,雖然也過使用單位,但對於Configuration Management也是僅有初淺的認識,尤其是對應到PMI所出版的”Practice Standard for Project Configuration Management”這一本內文僅有26頁,加上附錄也才共51頁的手冊,更是顯得所知有限,在此就只能以管窺天的向大家報告肥蝦的認知與心得,還請 先進們不吝指正。

()型態管理的標準定義

PMBOK的第三版與第四版中,就Configuration 這個字眼的落點處主要在Enterprise Environment Factors中的PMIS(Project Management Information System)Organizational Process AssetsOrganizational corporate knowledge base、第四章整合管理、第五章範疇管理,以及第八章8.1.3品質規劃的產出中的程序改善計畫(Process Improvement Plan)有著Process Configuration。就內文來說兩版間最大的差別在於第三版2004有強調PMO(Project Management Office)Configuration Management中可扮演的角色5.5 control scope 4.3Develop Project Management Plan的工具與技能Project Management Information System中都明列了Configuration Management System。但在第四版2008就將Configuration Management Plan明示於專案管理計畫十二個子計畫與三個基準之中。在PMI所出版的”Practice Standard for Project Configuration Management”第一章介紹中,開門見山所說的定義「Project Configuration Management (PCM) is the collective body of processes, activities, tools, and methods used to manage certain items during the project life cycle. These items are normally referred to as Configuration Items (CIs). Configuration management (CM) typically describes the mechanisms for managing the physical state of these items during their life cycle.」此說明除了集合美國國防部與IEEE的定義外,更加上的生命週期-專案跟型態項目。大陸的機械工業出版社出版,韓萬江姜立新兩位先生在其著軟件項目管理案例教程第九章軟件項目配置管理計劃中對於配置管理所下的定義:「配置管理是在整個系統週期中對一個系統中的配置項進行標識和定義的過程,這個過程是通過控制某個配置項及其後續變更,通過記錄並報告配置項的狀態以及變更要求,證明配置項的完整性和正確性實現的。」

肥蝦對於【軟體專案管理】第十五章開頭列示美國國防部對於型態項目(以下為方便暨與書本一致起見,將Configuration統稱為型態),以及IEEE對於型態管理的說明描述實在是不太認同,不認同的原因是型態項目說:「軟體或硬體的組合元件能夠滿足使用者的需求,而且能夠應用在型態管理上之用途者。」而型態管理定義為:「在整個軟體生命週期中,針對型態項目予以定義與控制各種變更、記錄與報告型態項目的實際狀況,以確保其整體性(Integrity)與可追蹤性(Tractability)的管理過程。」如此把型態項目的說明推到說是要能夠應用在型態管理上之用途;型態管理又說是針對型態項目,那到底什麼是型態?什麼又是型態管理? 對於僅有接觸過版本管理、變更管理,而沒有實際執行過完整型態管理的肥蝦來說,這些說明實在是更令人感到玄上加玄。

()從軟體開發遭遇到的問題看型態管理的定義

因此肥蝦建議,我們從實務現狀中,去瞭解現在一般在開發專案之時容易碰到的問題,也許對於型態管理會有一番不同的體會。肥蝦把我【軟體專案管理】與軟件項目管理案例教程中對於軟體開發工作碰到屬於型態管理可協助改善的問題整理如下表:

項次

問題

出處

1

多人同時更新某一個軟體。

【軟體專案管理】

2

多人共用一個程式碼,部分程式已被更新,但是仍然有些人不知程式內容已經更新。

【軟體專案管理】

3

使用的版本不一致。

【軟體專案管理】

4

發現程式的錯誤原因,無法有效通知相關的人員。

【軟體專案管理】

5

許多設計人員原本可以共用一支程式,但是設計者卻自行開發相同的程式。

【軟體專案管理】

6

找不到某個文件的歷史版本。

軟件項目管理案例教程

7

開發人員使用錯誤的版本修改程式碼或文件。

軟件項目管理案例教程

8

開發人員未經授權修改程式碼或文件,或修改的結果不能及時反應到各個相關部分,導致研發過程不一致。

軟件項目管理案例教程

9

人員流動,交接工作不徹底造成關鍵程式遺失。

軟件項目管理案例教程

10

已修復的錯誤在新版本中出現。

軟件項目管理案例教程

11

沒有保存歷史版本的相關文件,無法重新編譯歷史版本。

軟件項目管理案例教程

12

因協同開發或者異地研發,版本變更混亂。

軟件項目管理案例教程

肥蝦綜合以上的問題,自大的定義了一個針對型態項目的定義:「從專案開始到專案結束之間所有專案進行的文件、開發環境、開發流程、開發工具、程式碼、界面、產出,攸關軟體專案完成的一切要項。」在不考慮多人共同開發之下,就比如由您一人獨挑大樑,從老闆或業務簽下合約開始,到交付出產出,這一連串過程中所要的需求訪談、確認、評估,決定平台、架構、模組元件等設計,工作分派與時程基準,開發過程的溝通記錄,會議與追蹤稽核的記錄,程式與變數的命名規則,程式的版本、品質管控,後續的單元、整合、系統、驗收測試案例與結果,這以上的種種一切有關於專案都應該加以控管;但是一個專案經理或管理團隊,應就公司與客戶的環境與文化、專案成本與時程負擔、專案成敗關鍵等內外在因素進行取捨,就是要於型態管理之前要先行確認型態項目。換言之,就是要先確認專案開發中有哪些要項是在攸關專案成功的!我們所必要與利害關係人溝通的!必須保有正確性、完整性、可見性、協調性、可歸責性、可追蹤性、可重複性、可回溯性、與可控制性的重要項目!

圖一】

參考【軟體專案管理】圖15.1所繪的軟體開發程序,肥蝦把從硬體需求分析到硬體型態項目測試的硬體型態項目發展過程曲線移除,因為硬體型態項目,也應從系統分析需求中的非功能需求開始管控起。因此從系統需求分析到安裝的過程中,都應該有必須被列為型態項目的重要元素。

為了達成專案目標,確保專案努力的成果與方向的正確性,對於認定為型態項目要特別在意變更管理的提出、評估、確認、修改、測試與釋出過程的一致性與充分性,因此對於型態項目現今的狀態,變更的管理,都要能確實的掌控,因此肥蝦以為應該參考”Practice Standard for Project Configuration Management”加上型態管理規劃。何為?因為要確認何種項目為型態要項,型態項目的命名規則,型態變更的流程,型態檢測的頻率與指標,型態項目的存放實體與位置等這一切,應該要有一個先視、全面觀的計畫。因此【軟體專案管理】圖15.1型態項目的管理工作肥蝦修改後繪製如【圖二】。

至於專案管理、專案型態管理與專案變更管理,三者之間的範圍與相關性,可以圖三】表示:

上圖正說明了PMBOK第三版(2004)把型態管理系統(Configuration Management Sysytem)與變更管理系統(Change Control System)納進於專案管理資訊系統(Project Management Information System)之內的原因。

雖說廣意的專案型態管理工具應該包含型態管理系統,但說實話,也可能肥蝦的經驗有限,目前市場上主流的專案管理資訊系統對這一塊均是非常Weak甚至付之闕如。現行實務上,大多使用CVS作為版本管控與文件的管控,【軟體專案管理】書本上所提到的Rational ClearCase因為要價不菲,除非身為IBM的協力夥伴,不然甚少使用;就像那微軟的協力廠商多用Visual SourceSafe一樣。現在已有把專案管理、軟體開發與版本管理整合的趨勢,就如微軟所提出Visual Studio 2010藍圖一樣,這麼的宏大,但是價格也跟這圖四】藍圖一樣的偉大。

()產品型態管理與專案型態管理

最後,肥蝦要進一步說明產品型態管理與專案型態管理間的互動與關聯。專案的產出可能是產品、服務或結果,假設一個研發新網路下單資訊應用系統的專案,專案結束後將交付一套網路下單系統,該系統也會對應一個產品的生命週期,在以專案所產生的網路下單系統必須以產品的Business Idea為始,引發出資訊開發專案,因應專案的型態項目,產品推廣中也將印製與提供系統的操作手冊予公司的客戶與業務人員;同時也將交付系統維護與管理手冊予資訊部門;也將交付系統網路配置圖與維護手冊予網管部門,這將成為也將對應將該產品型態管控的項目,因此產品與專案的流程整合如圖五】

再以Institute of Configuration Management2003年所提供的BUSINESS PROCESS INFRASTRUCTURE,以及焜安同學預擬報告的期刊” Combined application of Product Lifecycle and Software Configuration Management systems for ITER remote handling”為例,肥蝦把兩個重要圖型整合如下圖六】。

因此在商業觀點來看型態管理,將呈現出”Practice Standard for Project Configuration Management”第二章所說明的圖七】架構。

記得肥蝦網站中有一位匿名的先進問了一個問題,肥蝦將其中對於Configuration Management的陳述摘要如下:「其實一直不是很懂Configuration Management,看了一些您的文章後...有點了解 它是屬於PMIS系統中版本或變更相關的部分,是這樣解釋的嗎? 不過..... (1)在第四版P 94中又提到"focus on the spec of both the deliverables and the processes" 覺得 越來越混亂 (2)Product Configuration又是什麼呢? 是指功能性嗎? 可以舉個例子嗎? 謝謝您!! (3)在第四版P 110中又提到configuration management activities such as how changes to the product, service, or result requirements will be initiated, how impacts will be analyzed.....怎麼又跟版本不太像呢??」這位先進已把第四版(2008)中對於描述Configuration Management的頁次都明白標示,可見該位先進對於PMBOK的精研程度。但是肥蝦以為PMBOK4.5 Perform Integrated Change Control(9495)中對於Configuration Management的說明僅是以整合變更控制程序(integrated change control process)中所涵蓋的Configuration Management加以說明;在5.1 搜集需求(Collect Requirements)產出中的Requirement Management Plan(110)所說明的Configuration Management actives也僅是就Configuration Management中對於需求處理部分的活動。

因此肥蝦在網站上回答了如下的言語:「基本上CM包含了所謂的版本控管,更遠大於版本控管,不只是程式碼,文件,開發的SDK....都包含在CM之內!(開發的工具版本當然也要控管,不然團隊中有人用JDK1.1,JDK1.2,JDK1.6,那不就亂套了) PMI中又把它分為Project Configuration ManagementProduct Configuration Management(如產品技術手冊等)! 然後中間又有CM Interface.」意思是,除了專案開發所對應的Project Configuration Management之外,對於Project完成所交付的產品也有著Product Configuration Management並且彼此間有著緊密的關聯。

以上是肥蝦對型態管理的初淺認識,還請 先進們多多指正!