雖然不斷強調"確認專案範疇"的重要性,但專案實際運作上,免不了為了現實考量而必須迎合客戶需求,此時該如何應對?

最常遇到的情況是 : 當專案進入驗收階段,為求程序順利避免不必要麻煩(通常專案延宕對客戶端來說也會有很多paper work要做),客戶或審查委員常會放行行政結案,剩餘的交付標修改則同步進行。因為事先給了甜頭,加上時間壓力已釋放,客戶常在此時提出範疇之外的變 更。若如PMBOK所述,最佳解答應該要拒絕客戶的變更要求,然而現實生活中誰敢這麼做呢? 除非專案經理真有什麼過人的guts或靠山吧! 因此實務上我們必須多一份圓融,在不傷害雙方關係的前提下,做出適當的回應。

victor 發表在 痞客邦 留言(0) 人氣()

在專案管理上,通常會建議將工作拆解到80個小時,原因是因為80個小時是比較能夠掌握的工作量,且又不至於太過枝微末節。然而實際運作上並沒有特別的限制,WBS(Work Breakdown Structure,工作分解結構)要拆解幾層,拆解到多細,取決於管理者希望掌控的程度。當然,可以預期的是,若WBS分解過細,就會有太多的交付項目,並且需花許多時間進行驗收,這對於管理者來說是相當吃重的工作。上位者大小事都管,第一線執行的人必然會綁手綁腳,長久下來便養成"反正這件事也要由你決定,我何必先做"的心態,屆時管理者再大發雷霆也已無濟於事。

最好的方式,是將部分的工作委任於適合的成員,然而管理者要切記,委任不等於就此事不關己,例如A將工作委任於B,B有權進行必要的分工,但是當出現問題,A仍要負起失敗的責任!如果管理者因此而事必躬親,深怕部屬搞砸,那麼團隊就永遠無法成長,畢竟人外有人天外有天,一個人再怎麼神通廣大,工作成效也也不可能贏過一整個團隊。

victor 發表在 痞客邦 留言(0) 人氣()

為了確保產品品質達到一定的水平,也為了能夠讓客戶滿意簽收,在產品進入驗證範疇(客戶簽收)階段前,需先經過品質管制、品質保證兩道關卡。所謂品質管 制,簡單來說就是透過檢驗等方式(品管七工具:直方圖、柏拉圖、趨勢圖、散佈圖、魚骨圖、管制圖、流程圖)來確認產品是否符合標準,不符標準的產品當然就 得重新修正改善。至於品質保證,較難從字面上了解意義,此流程是在確認產品製作的過程是否符合標準程序,同樣可以透過品管七工具來進行檢查,找出可能出問 題的地方。

品保與品管的流程看似單純,卻是非常重要的一道關卡,尤其當專案牽涉的廠商越多,事情越變得越複雜。假設今天B承包了A公司的專案,並將它轉包給下游廠商C,那麼C將產品完成送交B驗收時:

victor 發表在 痞客邦 留言(0) 人氣()

專案是指暫時性、有目的性的工作,計畫(program)則是多個專案的組合。在嚴謹的組織裡,計畫辦公室或計畫經理負責管理與掌控各個專案及計畫的推動,在此講推動而非執行,是因為主要目的在於評估專案是否可行,是否符合公司的發展目標。

專 案的可行性評估,除了技術問題外,還包括了成本效益、回收期,其中成本效益就是所謂的利潤,回收期指獲利大於成本的時間。而另一個重要的考量因素,就是該 專案和其他工作的關聯性。如果某個專案的利潤高、回收期短,但卻不是公司主要的研發/服務項目,那麼勢必有許多資源是無法共用的,也就是說,該專案的成員 無法同時支援其他專案進行,或其他專案的成員無法支援這個專案的執行,資源無法調度,就有產品延遲、品質不佳的風險,而即使風險沒有發生,但執行專案的經 驗卻無法幫助其他工作的進行,這就好比雞排餐車卻賣起早餐一樣,完全是兩種不同的工作性質,只會讓自己更瞎忙而已。

victor 發表在 痞客邦 留言(0) 人氣()

R&R 就是指Role & Responsibility,角色與責任。在專案的一開始,或任何工作交付的時候,若能一併確認彼此的R&R,那麼將會有助於日後的協調,避免 雙方都以為某件事應該是對方要做的。若是一般工作交付,可利用口頭或信件的方式與對方溝通,確認對方清楚自己的R&R,但若是專案經理的任用,最 好還是說服sponsor能夠用較具公信力的管道發佈給其他相關成員,或許很多sponsor會覺得多此一舉,但對專案經理來說,附有宣告專案經理及 sponsor簽核的專案章程,簡直就如同聖旨般,特別是當專案經理必須與其他功能部協調取得資源的時候,有沒有這一道程序的加持,就顯得格外重要!

多數的企業組織,屬於弱矩陣式,簡單來說,就是資源落在部門經理手中,平常並沒有專門執行專案的部門,而是依據需要指派人員與專案經理,專案經理本 身的權限不高,凡是執行專案所需的人力、經費、資源,都必須透過部門經理的認可才可取用。這樣的組織架構對於執行專案而言是很困難的,畢竟每個部門都有各 自的權責與工作,一旦工作分配不均,將造成連鎖的影響。

victor 發表在 痞客邦 留言(0) 人氣()

  • Nov 02 Fri 2012 15:45
  • 溝通

溝通,幾乎佔了專案經理工作的百分之八十,當然,這是指理想的專案而言。在台灣,中小企業居多,因此專案的架構並不是十分完整,多數的專案經理工作並非著重在溝通與協調,反而是教練兼球員,而且是屬於主力球員的那種,也就是說,專案經理憑藉的是本身的專業知識,常因為某種特別出色的技能而被拔擢為專案的管理者,而非擁有"管理"的知識。這樣的模糊分工對專案來說可能暗藏隱憂,但換個角度想,卻對專案經理是個磨練的機會,學習如何跨越自己專案領域之外,進行有效率的整合。

溝通,並非單指人與人的對話,或是業務往來,而是在對的時間將對的資訊提供給對的人,資訊提供的方式包含面對面交談、電話、電子郵件或書面報告等等,在台灣,喜歡講究人情,因此多半的溝通就落在如何討好對方,而非如何完成專案。過度講究"人"而非"事",就會變成只出嘴不做事,過度講究"事"而非"人",就顯得不近人情難以親近,因此,如何取得一個平衡點,才是溝通最難的地方。

victor 發表在 痞客邦 留言(0) 人氣()

發展專案團隊,白話來說,就是提升團隊的能力與凝聚力。提升團隊能力的方式不外乎舉辦教育訓練或參加研習課程,至於凝聚力,老生常談的是適當的獎勵與懲罰,但有多少專案經理能真正握有獎懲的權力?我想應該是不多吧! 特別在台灣以中小企業為主的公司文化裡,在還未創造營收前,是很難有所謂獎勵的。

幸好組織中仍存在不完全只為了金錢而生的成員(或者雖然沒有即時的獎勵,但還可以接受當前的待遇),他們要的包括對自己的期許、工作的成就感...等,就如同馬斯洛(Maslow)的需求理論 - 生存、安全、社交、尊重、自我實現五大需求,不同的成員有不同的需求,最重要的是,如何滿足成員的需求,使他們能夠在安穩的環境中,發揮最大的能力。

victor 發表在 痞客邦 留言(0) 人氣()

很多人會覺得管理就是嘴砲與paper work的結合,會讓人有這樣的觀感,是因為管理者或高階主管太在意書面形式的報告,導致執行者除了要應付原本的工作外,還要挪出時間來製作一大堆的表格與文件。通常這樣的情況在大型企業(尤其國營機構)較常出現,在他們的眼中,似乎越多的文件歸檔就表示專案的管理越好,但多數文件事後被重新檢視的機率是微乎其微。多少人真的在專案出現問題的時候,認真去查過當時花費好一段時間建立的檔案?

 

victor 發表在 痞客邦 留言(0) 人氣()

所為採購,白話一點來說,就叫做外包或委外工作。以政府或公家機關的採購案而言,投標廠商稱之為賣方,招標單位為買方,買賣雙方透過合約來約束彼此的合作關係。就賣方而言,一個得標的採購案即可當成一個獨立的專案,而合約就等同於專案的工作條款,預計要完成給買方的成果,則是這個專案的交付標的。當此廠商再將專案的其中一部分委外執行,則此時廠商的角色成為買方,下游承包商則為這個子專案的賣方。

誰為買方誰為賣方並不重要,重要的是在專案執行過程中,必須針對產品品質進行有效之檢驗,確保品質符合客戶滿意度,嚴謹的程序包括了QA與QC等階段,而這往往卻是工程師的夢靨(不過相較於範疇的變更,這勉強還可稱為合理的要求)。

victor 發表在 痞客邦 留言(0) 人氣()

一個人手上絕對不會只有一個專案在進行,因此如何在對的時間做對的事情就顯得十分重要,個人如此,一整個專案的運籌帷幄更是如此。專案規劃期間,常需要針對時間與資源進行反覆的安排調整,但不比大型專案有人力調度或資金的限制,小專案若太著重事先的時程規劃及資源分配,很容易會變成多此一舉的嘴砲,或成為純粹滿足sponsor的paper work。

不過,相較於規劃期間,在執行與監控階段,就必須善用資源撫平或時程壓縮等方法。資源輔平的目的在於將資源放在適當的地方,說起來容易做起來卻有難度,何謂適當的地方? 以人為單位,是依據成員的能力委任工作,以事為單位,則要將資源集中,優先處理可能造成專案延遲或失敗的項目。

victor 發表在 痞客邦 留言(0) 人氣()

為了有效練習最近學到的知識,並且藉題抒發一些工作壓力,打算定期來個專案管理知識分享。首先分享的是管理利害關係人的期望....

何謂利害關係人? 顧名思義就是和專案有利害關係的人,其中又包含對專案成敗影響極大的sponsor,很多專案無法順利執行,常是因為sponsor沒有明確佈達專案經理與其權責,導致專案經理有責無權,日後在各部門穿梭調度資源的時候,處處碰壁。而sponsor眼中,資源的取得並不困難(老闆開口誰不聽話!?),因此他們無法理解專案經理所處的困境,自然會認定是下屬的無能。

victor 發表在 痞客邦 留言(0) 人氣()