行萬里路...向前邁進

自2009年3月進到公司,開始接觸到與其它公司不一樣的專案管理
以前待的公司,因有Sales在第一線接觸客戶,PM做的主要是中後半段的專案管理
在這裡沒有Sales,PM要從起案,備案,標案,承案,需求分析,系統分析...
文件撰寫,教育訓練,系統上線,客戶服務,系統驗收,到結案保固,除開發以外的事全包
除PM的角色,也兼Sales,SA,QA,SE的角色,好處就是PM能完全歷練,確實完全掌握專案
比較累的是PM身兼多職,除專案管控外,還需要花更多的心力做客戶服務,系統處理及文件撰寫
所幸到職之初就考量到這點,房子租在公司旁邊,可以節省通勤時間,有更多心力做好每個專案
回顧2009年接手的專案:海健網,紓壓網,填報,管考,爭審,中英文,這六個專案在上週總算全部結案
把一些專案心得寫下,做為自己專管能力成長的紀錄:
1.海健網-讓我深刻瞭解與客戶互動的重要,若急功近利未充份顧及客戶感受,反而會事倍功半
唯有重頭好好與客顧談起,瞭解客戶心裡真正的需求,讓系統達到客戶需求,才能成功結案
2.紓壓網-這是自己第一次接到全新的專案,當然也是十二萬分的投入,但一開始錯估行銷預算,差點讓公司賠錢
之後一路戰戰兢兢,全力以付把每件需求及交辦事項做好,跟客戶建立非常好的互信關係,就像家人好友一樣
在這裡我把自己當成也是客戶單位的一員,客戶每次提的需求,都是我責無旁貸要做好的責任
到年底結案,除了專案結果非常好外,也持續下年度的維運擴充;總體平衡下來,也達到公司獲利的目標
3.管考-這是即將上線的救火專案,在上線前三個工作天由我接手PM,並更換駐點人員
在相關資訊不充足的情況下,要在短時間內完全掌握此一專案並完成上線任務
困難度不在於技術,而在於PM的掌握度;這個緊急接手的專案,上線後二週系統趨於穩定,客戶態度也從負轉正
在此案體認到專案團隊一起協同合作的重要,有Jimger駐點做好客戶服務,Jimmy做好功能開發
Josh,Edward負責視覺設計,我做專案整體規劃進度掌握及資源協調;此案今年已續約完成,下年度也可望持續
4.填報-這是接手需求不定的專案,此專案已過了1/3的時間,仍未取得與客戶的共識,做出的雛型系統客戶很不滿意
接手此案後,我從專案的角度來與User討論現況與問題,瞭解User至今對系統規劃有哪些不滿與疑慮
傾聽客的需求及不滿後,從新紮紮實實的做好需求分析,系統規劃與分析,最後獲得客戶的信賴,系統也成功上線結案
此案雖然成功上線及結案,卻嚴重超支,在與主管的衝突下,自己瞭解到公司看的是專案能否結案,以及是否有盈餘
中間過程中發生哪些問題,誰有功,誰有過,誰搞砸,誰努力,他們也不明瞭
即使中途接手的案子,接手的PM就要負全案成敗之責,不儘要讓專案結案,成本也要控制在預算之內,才能算成功專案
冷靜之後想想也對,公司求的是利潤,有利潤公司才能生存,員工也才有工作
5.爭審會-這是使用落差的專案,已進行到2/3,各功能都已開發完成,但因使用者想法的落差,讓前PM沒有信心再繼續
我接手後想其原因,應該是PM與客戶互動不足,以致產生溝通不良的問題,之後連續一數週密集與客戶互動
除瞭解需求落差加以彌補外,最重要的是在多次互動下,與客戶建立起信賴關係,這才是專案成功的第一關鍵要素
6.中英文-這是已維運五,六年的成熟專案,今年只要做好維運項目碓保系統穩定不出事,就能順利結案
在十二月初接手之際,要先撰寫下年度的建議書,這是公司代表性客戶,重要性不在話下,建議書當然也不能隨便撰寫
在Regina,Isode的資料提供與建議下,我重新撰寫建議書綱要及架構,Fairy重整資料內容,交付的成果算有一定的水準
但在順利承案之後的二,三週,系統接連發生許多狀況,有網路連線問題,網路設定問題,系統連線問題一一發生
連續二週忙著分析Log找問題,好在整個專案團隊-駐點同仁,開發同仁,網管同仁,一起合作克服問題,系統總算穩定
 
以上六個專案陸續在十一,十二月進行結案及下年度續案,在平常就已努力持續之下,都能順利結案
只是花在問題處理,文件撰寫,專管事項這些鎖碎事情下,每天仍需忙到三更半夜
上週最後一個案子順利驗收,其它的專案順利下年度承案,總算是能告一個段落
這一年對專案管理體認到,要做好專案,需在客戶關係處理,專案管理,團隊運作這三個構面都要做好
同時進行的六個專案,不管全新起案,或中途救火,或後期接手,都能把專案狀況由劣轉佳
瞭解自己抗壓力,承受力,原來可以到這樣的程度,對自己的專管能力也有更多的信心
2009年忙了一整年,2010年年初在各專案結案之際,自己也需要好好休息充電一番
開始規劃人生的第二次壯遊-西藏,絲路,新彊(北疆,南疆)自助旅行六個月
期待人生有更精彩的旅程~
 

年底到了,一堆案子等著在十二月驗收結案或是起案備案
原本我手上就有四個專案在Run,因上個月同事離職,又接了二個燙手山芋
變成管考,填報,紓壓,海健,爭審,中英文,六個專案擠在這一,二個月要結案
壓力大到不行,加班做到三,四點,在身體上與心理上都是一次考驗
好在每個Team Member都能做好自己的那一部份,並takecare我一部份的工作
忙到上週,各專案也順利進入最後階段,總算能鬆一口氣,也知道自己的能耐又長進不少
不過後遺症還是有的,頭痛,肩痛,腰酸,嘴破,爆肝,腎虛.....不能常態如此
上週勞委會委托我們後製剪輯兩段影片,效果挺不錯的
在忙碌之餘,也可調劑身心
 
http://testsite30.24drs.com/cla/media/88water1_1218.wmv
 
http://testsite30.24drs.com/cla/media/88water2_1218.wmv

上週接手一個進行到2/3的專案,系統各功能都已開發完成
但因User使用上的落差,讓前PM沒有信心再與客戶繼續下去
我接手後想其原因,應該是PM與客戶互動不足,以致產生溝通不良的問題
因此接手後先找承辦人瞭解此案目前現況,在聽完承辦人的抱怨後,也得到其寶貴的建議
知道是因為使用單位需求不定,讓前PM無法把功能規格限制在一定的範圍內
在需求不定,又有時程限制的情況下,只好先行進行系統開發,但也造成系統與使用上的落差
 
這種情況,叫做"使用者的抗拒",因為對新系統的不熟,所產生抗拒的心理
最好的解決辦法,就是親自去教User操作系統,並且先行寫好操作手冊,紮紮實實一步步的教使用者系統操作
所以接手步驟如下:
1.先聽前PM講述此案概要及現況
2.深入操作系統,瞭解系統每一項功能
3.比對之前的訪談規劃(客戶的想法)與現行系統的落差情況,讓黑洞現行
4.準備黑洞的替代方案
5.趕工撰寫操作手冊
6.製作RFP功能對照表
以上事項完成後,就是向User進行系統操作教學
在這種情況,操作手冊跟RFP功能對照表非常重要
因為操作手冊可以讓User感到有實際的功能項目,並把需求限制在即定的範圍內
而在講解完所有的功能操作後,接著就是要逐一核對RFP功能對照表,讓User做確認
當然最重要的還是在操作講解過程中,如何與客戶"友善"的互動,取得客戶的信賴,這才是PM的價值
在進行完3小時的操作講解互動討論後,之後的RFP功能對照花不到十分鐘的時間
"因為互動的過程才是重點"
 
在資訊軟體業界,目前有二大證照,一是CMMI,二是PMP
CMMI講的是企業組織專案進行的管理制度,PMP講的是專案經理在專案進行中的管理方法
但不管CMMI或是PMP都是專案管理的外功,大部份通過CMMI的企業,或是有PMP的專案經理,都是花槍
有CMMI的管理制度,或是PMP的專管方法,是能讓70分的專案做的更好,達到90分的程度
但要讓專案成功,或致少達到70分能夠結案,光有CMMI或是PMP認証是做不到的
 
真正能讓專案成功的關鍵因素在於人
在於PM能不能掌握專案,能不能與客戶溝通,能不能取得客戶的信賴
PM的身段要軟,技術要瞭解,系統掌握要紮實
具備這三點後,多與User互動,就能獲得客戶的信賴
從三月進公司至今,第一個專案是全新的案子
第二個是接手[即將上線專案]
第三個是接手[需求不定專案]
第四個是接手[使用落差專案]
對於全新的專案,或是半途接手救火的專案大致能掌握到相關的重點
內功心法具基礎後,接下來想先嘗試把CMMI應用在手邊專案,讓專案進行更有制度化

手上四個案子,其中難度高的二個專案,終於在今天送出交付文件,算是正式結案
雖然在接手之際就一步步紮實做好,挽回顧客信心讓顧客滿意,系統也成功上線正式使用
但在上線後結案前,有著心力憔悴,提不起勁的無力感,總覺得再也撐不下去
想其原因,投入時間過長,無後援部隊,成果不受重視,等等
都是心理建設不足,自我信心軟弱所致
在完成文件交付的動作之後,所有壓力得以釋放,信心及動力重獲而來,宛如重生一般
 
大部份的公司都是業務負責掌握前端客戶,PM負責專案執行
這裡沒有業務,而是PM從開案到結案完全負責
這種制度的好處就是PM能完全掌握,但責任也要一肩扛起
考驗就是PM的能力與信心需要不斷的強化充實
在這裡還不到一年,考驗很多,受挫很多,但也成長很多,收獲很多
明天過後 太陽昇起  希望再來~

專案管理三要素:Scope,Schedule,Cost
前二項Scope,Schedule在這半年來大致都已可以掌握
唯獨Cost這個關鍵要素沒有掌握到
三個專案,其中二個重頭到尾完全handle的案子
在即定的時程,人力,及範圍上,都能大致按規劃如期進行完成
成本也能掌控在原定預算範圍之內
但另一個中途救火接手的專案,因為投入大量時間人力
雖然扭轉劣勢,讓客戶對我們完全改觀,十分滿意
但在結案尾聲時結算人力成本,卻是大幅超支
在專案會議上,檢討砲火讓我非常的氣憤
專案團隊用盡心力救回此專案,卻換得這樣的指責
不幹走人的念頭在上週不斷的浮在腦中
前天再與主管Meeting,我的不滿也爆發出來
PM幹的這麼不爽,委曲,無耐,無力,實在有夠氣憤
結果換來主管一頓臭幹讓我對此事轉換不同的觀點
 
專案團隊的努力與辛苦內部主管看的到,能明白
但上層的經營者,監理人,看的是專案能否結案,以及是否有盈餘
中間過程中發生哪些問題,誰有功,誰有過,誰搞砸,誰努力,他們也不明瞭
即是是中途接手的案子,接手的PM就是要負全案成敗之責
不儘要讓專案結案,成本也要控制在預算之內,才能算成功專案
冷靜之後想想也對,公司求的是利潤,有利潤公司才能生存,員工也才有工作
很現實的條件與考驗,這樣的道理我工作到現在才真正體會
 
專案團隊的成員有RA,SA,SD,PG,QA,FAE,MM,PP,PM
各人有各人專長與職責,彼此分工合作達成目標任務
PM要負責做好客戶關係,緊縮需求項目,掌握專案進度與狀況
也要讓所有專案成員瞭解降低成本支出是每個人的責任
專案能結案,有賺錢,才是成功的專案,才是我們的Performance
以前的工作,Sales把案子拿下後,由PM接手專案管控與結案,會有成本責任不清的問題
現在這裡,PM從接案到結案全程負責,要掌握好客戶,要帶領好專案團隊,要交出好成績給公司看,是很大的一個考驗
PM做的很累,很幹,很不爽,很不滿,很無力,很受氣
表示是自己的程度不夠,能力不足,有待努力
知道這條路很漫長,很難走,也明白不過此關一切將會成空
PM之路,是在做心的粹煉
 
 
 

專案管理的內容以性質區分業務面與管理面
業務面從客戶接觸,備案,接案,專案規劃,需求分析,系統分析,程式設計,系統測試,系統上線,到驗收保固,大致上是依專案流程而進行
管理面則是平常不斷的持續發生處理項目,如客戶關係,與專案成員的溝通協調指派管控,與上級的回覆達交等
要完成一個專案,並獲得好的績效表現專案成果,是需要公司及所有專案成員的支持,齊心協力以達成專案目標為使命
 
而連繫與維持整個專案團隊的運作並朝一定方向前進,需要有一個人來負責帶領,這就是專案經理的職責
"帶領"兩個字看起來簡單,卻是最難,因為牽捗到人與人的相處,信任,期望,協調,衝突......
其中,"衝突管理"更是專案經理的重要學分
 
對於衝突,協理給PM六字建 "納諫、傾聽、包容"
 
待續...
 

專案規劃要預估專案範團,時程及成本
專案範圍確定後,就依各種方法來度量專案規模,再來規劃開發時程及限制成本
 
在軟體專案管理裡,有講到很多種專案規模的度量方式,如:
-程式行數
-Function Points功能點(業界最常談到)
-Number of Classes and Objects
-Number of Requirements
等等....
 
但是,這麼多有理論基礎的專案規模度量方法
軟體界到現在最常用的還是"土法煉鋼"式的度量方法
-依個人經驗值來估算專案規模
 
為什麼Function Points或其它具理論基礎的專案規模度量方法無法套用在實務
這就回到度量專案規模的前一個步驟:專案範圍沒有確定清楚
因為客戶需求未能確定清楚,不明確
所以當然任何估算方法也就算不精準
 
--------------------------------
 
專案範圍(或客戶需求)未能確定清楚又分二種情況:
1.客戶清楚自己想要什麼(需求其實明確)
2.客戶自己想要什麼也不清楚(需求的確不明確)
 
第一種:客戶清楚自己想要什麼,但開發公司卻未抓到客戶需求
這就是專案經理的問題,因為沒有做好需求分析,所以無法確定客戶需求
這在我上一個"接手需求不定的專案"已經遇過且已解決
 
講一個老師談到需求明確而成功的案例:
國內某一個政府專案,整價約六億,一開始甲方規劃一個三仟萬的規格標
由得標廠商把該專案需求,功能項目,邏輯規則條件都規劃出來,甚至連操作畫面都拉出來,這樣需求明確後,再發包開發標
這樣開發標的得標廠商就有明確的依據,之後確定執行就能依據需求分析與規劃順利的把專案完成.
 
 
第二種:客戶自己想要什麼也不清楚,這種專案最令人頭疼
假設客戶的預算是一百萬,專案目標就是增修現有的應用系統功能符合到實際作業流程
但哪些功能不合適需要修改,或哪些功能有缺少,現在還沒使用到那裡所以不知道
要等到有用到該項功能時發現少了什麼功能沒有就去加,遇到哪個功能不好用再去改
遇到這種專案,在一開始做專案規劃,WBS的時候,再怎麼想,也預測不到客戶的想法
(這倒有點像供應鍵管理的CPFR-協同規劃、預測與補貨,理論很充足,但實務上很困難)
依Standish Group 1995調查8000個軟體專案
- 84%在時程落後,預算超支,功能不全的狀況下完成
- 30%的專案在半途被撤銷
- 70%的專案逾時完成,超出預算189%
- 撤銷的專案成本高達81b美元
上述軟體專案不成功的根本原因,就在需求不明確,掌握度不夠
國內大部份的軟體專案也是這樣,客戶想要一開發一套專屬系統,但需求並未分析的很完確就發包
或是客戶自己也不想把需求講明確,因為需求一白紙黑字寫下來,將來系統開發完成後就少了彈性可以大修改
(雖然有15%的增刪空間,但常常會因為沒有好好分析,而要大改功能,客戶承擔不起這樣的責任)
軟體公司接案就只能靠運氣,看是否遇到澳洲來的客人
或是PM要在專案進行當中不斷掌握目前開發情況,不斷與客戶溝通釐需求,把客戶期望拉回與現實相符,讓專案完成結案
同時,在規劃與執行時儘量(標準化),(文件化),把每個環節弄清楚
這是專案管理最困難的地方
 

進入公司前四個月在專案執行上克服許多困難,成果尚佳
在第六個月在做新專案的規劃上卻撞上一堵無形的牆壁
 
專案執行的內容,是明確的項目,明確的時程,明確的任務執行成員
做好任務的協調分配,預估及避免可能遇到的問題風險,確保專案朝目標前進
大致上抓緊項目範圍,時程,按進度安排執行即可
 
專案規劃的內容,則會是不明確的項目,不明確的時程,但有明確的任務執行成員
因為項目範圍的不確定,連帶造成時程不確定,成本不確定
做專案規劃就像瞎子摸象,難以確實及精準


另外各功能項目的預估時程,也不是PM自己想,自己規劃就好
必須讓專案成員瞭解專案背景,專案目標,時程及成本限制,與專案成員溝通協調,獲得共識才行
但受限於專案成本,必須壓低專案工時,這樣的預估工時,會與實際執行上有不小的差距
要靠管理手段來讓現況向計畫趨近,以達到公司預期的利潤目標,這就是PM的難處
 
這個無形的天花板,有待突破
 
 
 
 
 
 
 

PM除了對外處理好客戶需求,獲得客戶信賴
對內掌握專案範圍,專案時程與專案成本外,還要掌握專案全員的協同情況,加以溝通協調
但遇到能力有問題,態度有問題的Member,除了軟性的溝通協調,硬性的管理壓制
要徹底解決PM與PG間的GAP,唯有PM跳下去掌握開發的技術關鍵
跟PG一樣瞭解技術,但更瞭解專案系統架構,才能正面面對Member的挑戰
 
PM,就是要跳下去做,用實力來證明
 

此專案4月初啟動,10月底要結案,至今已過了1/3的時間,仍未取得與客戶的共識
上週接手此案後,我先瞭解此系統需求,功能架構,自己畫出此系統的業務流程圖
在對系統有整體性的瞭解後,分別探訪承辦單位User及業務單位User
純粹從專案的角度來與User討論現況與問題,瞭解User至今對系統規劃有哪些不滿與疑慮
許多專案問題來源都是使用者需求不定,但需求不定的原因點在於未深入且正確的與User溝通
在第一次分別與兩方User討論,傾聽他們的需求及不滿後,我也把握到問題的癥結與解法
首先,除了之前準備好的系統業務流程圖,我到網路上找遍類似的系統,研究別人成熟系統的功能流程
歸納出共通性系統特點,如管理面,業務功能面,統計報表面,資料匯入匯出面等等,整理成一個系統規劃重點表
接著在與開發人員就以上功能需求詳加討論,瞭解之前規劃與此新規劃的差異性與可行性
再來就是就可行的部份,與開發人員討論出具體的系統開發進度與上線,結案時間
有了(系統業務流程圖),(系統規劃重點表),(時程進度表),整個專案的範圍及時程也就完善
完善的專案管理有三要素-Scrope,Schedule,Cost(外加品質,但品質是靠前2S及PM的積極性造就的)
接手此案一週後,有以上具體充份的準備與規劃後,今日我再找之前PM搞不定的承辦單位使用者
就以上準備內容詳細討論了二小時,離開時,User跟我講:你準備的很充足,很有心,這樣我就放心多了
 
從上一個接手即將上線的專案,到此案,我覺得愈是難搞的User,愈是要用心,盡力去做好準備與主動溝通
努力與用心的破冰之後,換來的是User百分百的肯定與信賴
通常這類的使用者都是KeyUser,對專案的成敗及未來與該單位的長久合作都是重要關鍵