筆者近幾年擔任國際專案管理學會台灣分會(PMITW)的專案管理大獎評審,觀察到幾個值得思考的現象,今天先來談談幾乎每個團隊都會強調的:「我們每個專案都會建一個LINE群組來管專案,可以把專案管得很好」。

談到「建LINE群組=用LINE管專案」,難道曾幾何時,LINE變成專案管理系統(PMIS) 了嗎? 不可諱言,良好的溝通是專案成功的一大關鍵,而LINE確實是個很方便的溝通工具,似乎只要建個群,把相關利害關係人邀進來,重要訊息都往群一發,就不用擔心遺漏誰,從此專案溝通順暢沒煩惱,但事實又是如何呢?

LINE的群發跟email的群發,其實是異曲同工:我們常常發一則訊息給很多人(因為怕某個「應該知道」的人沒收到),並期待某些人應該會回覆。差別在於,現代人手機不離手,所以發LINE比發email方便多了,但email裏一則一則分得很清楚,而LINE群組最後幾乎都變成訊息的大雜燴,相信很多人對漏訊或洗版,也都深感其累。

個人以為,LINE的價值之一是「方便」,但就像任何工具一樣,真正的關鍵仍是人,沒有盡責又頭腦清楚的專案經理及團隊,再方便的工具其幫助仍是有限,注意這邊的重點是「盡責」,至於「頭腦清楚」,或許還是可以依賴一套完整的專案管理系統 (PMIS)來輔助,畢竟再清楚的頭腦也有疲勞的時候,這時電腦的作用就可以體現了!

此外,無論用LINE或email,千萬別忽略了他們更大的價值其實是「組織流程資產」,很可惜卻幾乎沒人談怎麼發揮他們在這方面的價值,好像事過境遷便船過水無痕了。平常大家談專案管理時都高聲倡導專案經驗學習(Project Lessons Learned)的重要性,卻常常把結案報告當作專案經驗學習的代名詞,我們會再另外針對這個題目來探討一下。

結論:LINE當然可作為專案溝通的工具,但就如同使用電話或email等其他溝通工具,「人」才是專案溝通的靈魂之所在,再搭配專案管理系統(PMIS)的使用,才能使專案管理事半功倍。


歡迎分享文章至

常有人在問有沒有哪套「比較好」的專案管理系統? 或是哪套專案管理系統比較多人用? 這讓我不禁想到小時候跟老爸打乒乓球,我每次擊球出界時總是「牽拖」球拍不好,而老爸卻總是傷口撒鹽地說會打的拿木屐也能打。這個故事告訴我們,基本功很重要,否則工具再好也沒用,但話說回來,當雙方功力相當時,工具就有可能是致勝差異之所在了。

專案管理的基本功有哪些呢?從標準方法(例如PMI的專案管理知識體系指南PMBOK ®Guide)的理解到各種最佳實務(Best Practices)的運用,還有各種軟技能(soft skills)與硬功夫(hard skills),相信大家對這些並不陌生,在此就不贅述。

而專案管理的工具當然就是專案管理資訊系統(PMIS)了,在我擔任各類型企業輔導顧問近20年來,看過各式各樣的專案管理工具,從各種免費軟體、到最普及的Excel (是的,非常非常非常多人用Excel在管專案!)、到價格高昂的商業軟體,到底哪套專案管理系統或工具最適合我呢?

暫時撇開功能層面(別忘了有本事的人拿木屐也可以打桌球、打球棒也可以打高爾夫球),我們先來思考一下架構面。相信大家認同專案的成功有賴於良好的團隊協同運作,而您的專案團隊是定點(co-location)為主還是遠距分散呢?專案人員會需要經常移動嗎?專案形成是源自委託與契約(甲方-乙方)或是內部專案(發起人提案、長官指示等)呢?專案管理方式是瀑布(Waterfall)、敏捷(Agile)或混合(Hybrid)呢?專案利害關係人之間又是如何進行資訊傳遞(階層式、點對點、集中、分散、混亂)呢?

定點的團隊在內網(Intranet)協作可能方便些,但對外網路頻寬足夠時,直接上Internet協作也無不可;至於遠距分散或移動性高的團隊,當然Internet會是理想的選擇。瀑布式的專案環境通常其分工及階層較明確,而敏捷式的專案組織則相對較為扁平,再考量是否牽涉外部人員(無論是甲乙方),因此不同的運作方式下,所需達到的權限管控程度也不一樣,這時可能商業軟體的支援就較完整。

功能方面,與其問系統有什麼,還不如思考自己需要什麼?但偏偏這是一個普遍的盲點,大家似乎在評估的時候都希望系統可以無所不能,但真正在用的時候卻又只想用最簡單的部分。想想大家所熟悉的文書處理軟體,我們到底用了幾成的功能呢?所以除了基本功能外,系統可提供多大的彈性與擴充性,在我們需要某些進階功能時,系統是否可以快速調整來滿足需求,這才是重點。

把上面這些問題想清楚,再看看哪套系統的架構最適合自己的專案環境來運作,這樣應該就不難找到適合的專案管理系統了。但還是要提醒,系統只是輔助工具,真正的關鍵還是人。馬雲說過:「複雜的事情簡單做,你就是專家;簡單的事情重複做,你就是行家;重複的事情用心做,你就是贏家。」,在此重新詮釋這三句話:

  • 複雜的事情簡單做:找系統幫你;
  • 簡單的事情重複做:用系統助你;
  • 重複的事情用心做:一切都靠你!

歡迎分享文章至

敏捷管理常見的迷思

在尚未了解敏捷的精神和應用之前,有些人對敏捷會有一些迷思,其中最主要的一個迷思是,把敏捷跟專案畫上等號。雖然我們經常看到 ‘敏捷專案管理’ 這個名詞,但其實更嚴格地講,應該稱為敏捷式管理或敏捷式手法。敏捷管理不見得是只用來管專案,在之前孟華顧問的線上系統教學影片中,我們是以產品開發專案為例,為了做好這個產品交付,我們與其花一段較長的時間做出一個很龐大的產品交付,我們採用敏捷管理,用更頻繁多次(亦即多個迭代)做出更小的交付,同時,每次交付都是使用者可以看到、可以用的,所以我們更早推出產品讓使用者能使用、提供回饋,進而持續改善,經過多次迭代產出來做出更滿足使用者需求的產品。

講到這裡,對敏捷迭代式的交付,希望很多人都能了解到敏捷的效益。不過,從敏捷的宣言裡,或許也有很多人認為敏捷都不需要寫文件、敏捷也不需要計劃,甚至很多人說我們有用看板、我們有站立會議,我們就是敏捷,這些想法其實都是問號。正確的說法應該是,看板(Kanban)是敏捷的一個很好的工具,而站立會議是進行敏捷式溝通的很好的方式;但反過來說,並不是用看板來管理就一定是敏捷式管理,從我所觀察到,很多公司雖然有看板工具,但其實還是以瀑布式專案的管理思維和作法,這麼一來反而會有疊床架屋的情形。


敏捷管理的成功關鍵

如何推行敏捷式管理比較容易成功?大概可以分成幾個重點:

  • 第一點,產品負責人跟開發團隊要非常密切的互動。不論是在站立會議或是平日的溝通,產品負責人不能像一般瀑布式裡所謂的計劃主持人,等到查核點的時候才出現。敏捷式管理中這個密切的互動溝通是很重要的,這樣才能夠確保在每一個迭代能夠做一個快速的交付,或是迭代與迭代之間能做快速的決策和改善回饋。反過來說,如果在敏捷管理執行中,產品負責人還是等到查核點才出現,中間那些迭代的交付搞不好在最後又被全盤推翻,如此就完完全全失去了敏捷的精神。
  • 第二點,是攸關產品工作清單 (Product Backlog)的取捨與排序。常常大家都覺得,每個工作項目都很重要,但是當我們什麼都認為很重要、什麼都想做,最後就會變成什麼不知道要從何開始,甚至無法做出來。所以在這裡特別強調,Product Backlog的取捨及優先順序,對敏捷管理的成功交付是非常重要的。
  • 第三點,是關於每一個工作項目(Work Item)的大小。一般而言,每個迭代的執行期間是1~2週,多數人以兩週為單位,我們不希望一個Work Item的內容在一個迭代中做不完。因此,若是真的有這麼大的Work Item,請務必要把它切割成比較小的Work Item,否則就很難完成迭代的管理與交付。
  • 第四點,是不要怕做錯,而是要能快速回饋修正。剛開始應用敏捷管理時,多數人會想迭代這樣規劃,做得不好會怎麼樣。如前面所提,每一個迭代的期間是1~2週,所以如果這一個迭代的交付做錯或不如預期,能夠在下一個迭代快速把它修正過來,這才是敏捷的重點。

綜合以上所說的敏捷成功關鍵,第一點是Product Owner與開發團隊的密切互動;第二點是Product Backlog的取捨和優先順序,這是很困難的一件事,因為大家都覺得什麼都很重要、什麼都要做,最後很可能又會回到今天的一個惡性循環,什麼都要做、卻又甚麼都做不好,時間又一拖再拖,因此,取捨和排序非常重要。第三點是要切割work item為適當的大小;最後一點是在在迭代與迭代之間,能快速的回應與修正,快速回饋、持續改善是敏捷的精神,也是敏捷成功的關鍵之一。


歡迎分享文章至

甚麼是混合式管理?

企業專案最為傳統的管理手法為 瀑布式管理,又稱預測式或計畫導向,是針對需求明確專案而進行的管理模式,近年來,為了回應需求的變動,敏捷式管理也成了專案管理手法的新趨勢。然而,為了滿足更廣泛的專案管理需求,混合式成為了專案管理手法的新選擇。

再談混合式(Hybrid)管理之前,要先定義一下,甚麼是混合式?其實,混合式並沒有一個明確的定義,它可以是用幾種不同的模式執行實務上的操作。

  • 第一種:前期透過敏捷式做需求的收斂+後期透過需求訂下的計畫執行瀑布式管理
  • 第二種:前期依瀑布式執行固定的工作階段+後期依敏捷式逐步完成小型任務
  • 第三種:主體依瀑布式掌握專案時程,階段任務利用敏捷式管理的方式輔助推進
  • 第四種:主體依敏捷式進行管理,細項由瀑布式做輔助推進

以上四種不同的專案生命週期,只要管理手法包括 瀑布式(Waterfall)、敏捷式(Agile),嚴格來說就為混合式。那對於混合式中最常見的實務操作模式(第三種),其實就是主體藉由瀑布式定義出每個階段的時程、里程碑需要交付哪些東西,然後依照敏捷式執行每個階段中的工作細項,透過站立會議來快速的回顧工作項目的進行狀況,而階段中不需要再細分若干個迭代,只需要一個看板管理階段內所有的待辦,那這樣的模式如何在ezteamwork上做管理呢?


如何用ezteamwork管理混合式專案

首先,第三種模式是瀑布式包敏捷式,所以在建立新專案的時候會選擇瀑布式,透過新增階段任務(WBS)規劃出整體的主時程,和一般的瀑布式專案一樣,能看到專案的時程、預定完成日、里程碑與甘特圖。

不一樣的是,在混合式中的階段任務不會劃分的很詳細,可能會是一階或兩階的WBS,且WBS底下的細項也不需要去訂定時程,而是個別設定對應的工作項目,這些工作項目同樣也能做排序。只要任務對應的工作項目能夠在階段時間內完成,工作執行的先後順序就不是那麼重要,也不需事先訂定哪個工作項目應該在階段內的哪一個時間完成。

所以這個是目前我們使用 ezteamwork瀑布式做為管理混合式專案的一種應用方式。那目前ezteamwork 全新升級的9.0版本中,看板是獨立在敏捷式管理模組中的工具,瀑布式中目前沒有看板功能,不過,在不久的將來,ezteamwork將會推出混合式專案管理模組,屆時就能夠在大規模的時程、甘特圖中,看到敏捷式看板中的工作項目,進而採用更廣泛、彈性的方式進行專案管理。


歡迎分享文章至

企業對於不同的專案有著相對應的管理模式,而常見的專案管理方式類型大致上可分為三種:瀑布式(Waterfall)、敏捷式(Agile)、混合式(Hybrid)。而面對不同規模、內容、需求及類型的專案,選擇合適且正確的專案管理方式,會是促使專案邁向成功的重要關鍵。以下我們就依照不同類型的專案管理方式,說明其適合哪一種專案的內容。


瀑布式

最廣為人見的管方式 — 瀑布式(Waterfall),也有人稱為計畫導向(Plan-driven)指的是需要事先把專案的計畫給完善,然後再依照計畫安排去進行,或亦稱為預測式(Predictive),因為當專案的內容都規劃出來了,勢必代表當下能預測到未來將要進行那些項目,像是時程、甘特圖都是瀑布式管理常見的工具。所以瀑布式、計畫導向或預測式,我們將它們視為是同義詞,也同時是ezteamwork協作平台中最主要的專案管理模式。那甚麼時候適合用瀑布式呢?如果說一個專案的需求相當清楚、流程也很明確,而且過去的經驗可做為現今的參考,過往精準的計畫能夠做為一份重要的依據,這樣的情況通常就會採用瀑布式的管理方式。比如說,營建工程就是非常典型的例子,從設計、發包到施工,專案的運作有著十分明確的流程,這類型的專案就會採用瀑布式的管理方式。想了解更多關於瀑布式專案管理的時程、甘特圖功能與機制,請見「時程管理」。


敏捷式

敏捷式(Agile),也有人稱迭代式(Iterative)或是增量式(Incremental),源自於軟體工程,早期的開發專案常在最後交付時,面臨到產品無法回應需求變化而導致重工的情況,因此才發展出敏捷式的管理方式,它是透過流程的簡化、頻繁的溝通,使整個專案團隊聚焦在產品上,以達到產品持續優化的一種管理模式,而最常見的敏捷式管理工具就為看板(Kanban)

甚麼時候適合用敏捷式呢?當面對的專案其需求十分不明確、變動性也很大,專案運作的流程、技術也不確定,且過去經驗的參考性也不足,那敏捷式的管理方式就會是一個可以參考的選擇。例如,軟體開發產業、行銷團隊等等,都很適合運用敏捷式的管理方式。想了解更多關於敏捷式管理裡的看板功能及效益,請見「敏捷式管理」。


混合式

混合式(Hybrid),顧名思義,就是混合了以上兩種管理方式來應用在專案之中。而混合式其實沒有一個明確的定義說是以哪一種模式呈現,有可能會是專案的前期透過敏捷來收斂需求,後期再採用瀑布式進行,又或是專案前期利用瀑布式完成主要階段任務,後期再依照迭代逐步完成小型任務。混合式可以說是提供了彈性的管理空間,在應用層面上更具廣泛性,是一種兼容並蓄的管理方式。
因此,混合式並沒有說適合哪一類型的專案,或是說混合式適用於廣泛的專案,結合瀑布式+敏捷式的管理,能夠互相彌補彼此的限制,在專案運作之中依照不同任務特性適當調配管理模式的方式,利用這樣彈性的機制,能夠強化專案管理的有效性。

因此,身為一個優秀的專案經理人且想獲得專案成功的重要基礎關鍵,就是先了解不同的專案管理方式,以及知悉專案的內容及屬性,再依此選擇一個適當的管理方式。


歡迎分享文章至

敏捷式(Agile)這個概念,其實源自於軟體工程。因為一個軟體在實做出來之前總是有很大的想像空間。如果軟體開發的結果不符合客戶或市場需求,那麼從前面的系統分析、系統設計,到程式撰寫、測試等等所花費的時間,最後可能又會重工,所以才會發展出敏捷式開發的做法。

了解敏捷式開發之前,我們先很快的來回憶一下常見的專案管理方法,也就是所謂的瀑布式(Waterfall)專案是怎麼管的。如果各位對孟華的專案管理協作平台ezteamwork很熟悉的話,首先會聯想到系統呈現的甘特圖。整個瀑布式專案的概念,就是希望盡可能、盡早地把專案計畫時程(Scheduling)排出來,而且希望專案計畫越精準越好,因為我們要依此時程計畫做成專案的Baseline基準,將來在執行這個專案的時候,我們要根據這個基準時程,來衡量專案的執行是否符合基準? 是超前或是落後? 也就是說在一個瀑布式專案裡面,它的源起都來自一個理想的計畫時程,而且計畫愈詳細越好,而我們最常使用的工具,就是大家非常熟悉的WBS (工作分解結構) 及甘特圖,所以WBS還有甘特圖是瀑布式專案裡面最常用的工具。


敏捷式管理

回到敏捷式管理這個主題,在討論其作法前,首先必須先談一下敏捷的宣言,敏捷的宣言其實有四個重點 :

  1. 互動大於流程
  2. Working software,也是就是可以正常運作的軟體,比寫一大堆文件來得更重要
  3. 跟客戶的協同合作會重於合約跟協商
  4. 我們要能夠回應變化,而不是一成不變的照計畫來做

上面第二個重點,是指開發出能正常運作的軟體,比花時間製作詳盡的文件來得更重要。如前面所提到,敏捷的概念源自於軟體工程,早期常常花了很多時間進行系統分析、設計,做了Prototype,而等到整個軟體開發出來之後才發現並不是符合客戶的要求。因此,第二個重點是強調,與其一開始花很多時間寫文件,最後把文件改掉重寫,還不如盡快把這個軟體雛形先做出來和客戶溝通討論來得更重要,因為我們知道在開發的過程,需求會不斷的修改、變化,所以才會有第四個宣言,也就是我們要回應變化,而不是像在一般傳統專案管理裡面,要透過繁雜的計畫變更程序才能回應變化,因為這樣的流程反而是沒有效率的。


敏捷式專案

一個敏捷式專案要怎麼管?敏捷式的管理方法有很多種,最常被多數人採用的方法,就是建立一個產品的待辦清單,也就是我們常聽到的 Product Backlog。Product Backlog通常會用User Story的方式來呈現。那接下來,我們會把專案裡的Product Backlog透過建立一個或多個迭代去執行,當然這個Product Backlog裡面的待辦清單是需要經過排序的,通常我們會把最優先、最必要的待辦清單放到第一個迭代裡面去,從每一個迭代裡面去做一個增量式的進展,而每一個迭代就會有其待辦的產出交付。正如前面的敏捷宣言中提到,可用的產品比文件更重要,因此每一個迭代的交付就要透過產品使用者來做驗證,也就是為何我們需要透過跟客戶或使用者的密切互動,來驗證產品、得到回饋,把得到的產品回饋投入下一個迭代進行持續改善。一個敏捷式的專案是以這樣的概念來進行,而不是花很長一段時間規劃設計、經過很幾個階段後才做出一個大的交付。

正如前面的敏捷宣言中提到,可用的產品比文件更重要,因此每一個迭代的交付就要透過產品使用者來做驗證,也就是為何我們需要透過跟客戶或使用者的密切互動,來驗證產品、得到回饋,把得到的產品回饋投入下一個迭代進行持續改善


敏捷和迭代

以手機APP的開發為例子,大家是否有注意到APP經常在改版,或許有人會想:為什麼APP開發者不一次做好,而是隔一段時間就會發布一些新功能,或是一些新修正呢? 其實現在市面上多數的APP開發都是使用敏捷式的概念來發展,我們認為的為什麼不一次做好、做完整的這個概念,是一個永遠不存在的理想,所以還不如趕快做出讓使用者可以看得到、可以使用的功能,然後以蒐集使用者的回饋來持續改善,這樣的作法比傳統的作法來得更實際有效。

更進一步探討,敏捷式專案管理的方法是透過一個一個迭代去滾動執行。在迭代與迭代之間,以及每一個迭代的裡面,團隊人員之間、以及和客戶之間都需要做很密切的互動,因此敏捷式專案團隊需要一個可視化的工具,看板(Kanban 或 Board)是敏捷式管理中最常用來進行人員溝通互動的工具。


敏捷團隊

敏捷團隊到底包含哪些角色? 根據敏捷的精神,敏捷團隊是一個扁平化的組織,和一般傳統瀑布式專案團隊組成有所不同。首先,敏捷團隊會有一個產品負責人(Product Owner),產品負責人是最了解這個專案或產品需求的人,其次是開發團隊(Developer),最後是促進者 (Facilitator),這個角色在不同的敏捷方法裡也可以叫做Scrum Master,接著來看這些不同角色做什麼事情。

前面所提到的產品待辦清單Product Backlog,主要是由Product Owner和Developer共同自訂,重點是共同自訂,而不僅是由Product Owner自己訂定。

這些Product Backlog裡面會包含不同的工作項目,而且也需要依其重要性、必要性做排序,優先排序的待辦清單Work Items則會先指派給開發團隊來執行。同時,每一個迭代的Work Items和產出,同樣要由產品負責人來做確認驗收。因此,產品負責人和開發團隊,是整個敏捷團隊裡面非常重要的兩個角色。
至於團隊的促進者或是Scrum Master,在孟華專案管理協作平台ezteamwork裡叫做迭代管理者(Iteration Master)。這個角色顧名思義,就是促進整個團隊運作的一個角色,這個角色的任務,可以說是為了確保在整個執行過程、及團隊溝通是非常有效率地向前推進,這和一般瀑布式專案管理中的專案經理角色有所不同。


迭代管理

其次,迭代的執行過程中會有一個Daily Standup Meeting,也就是每天的站立會議。這裡用Standup是強調團隊成員是站立著開會,因為希望每一個會議是小而精簡,大家站著希望比較能夠聚焦、專注,所以Daily Standup Meeting 通常是個十五分鐘左右的小會議,最長不會超過三十分鐘。

最後,我們來談一談在一個迭代裡面要怎麼樣來進行管理。首先,在每個迭代的開始會有一個迭代的規劃,又叫做Iteration Planning,主要是根據Product Backlog裡面的所有待辦清單 (或工作項目)去做排序,排序優先的就會進入該迭代要執行的工作項目。

在這個會議之中,團隊成員建立微承諾 (Micro Commitment),也就是說,每一天會議中,團隊成員接收新的指派工作項目或既有項目執行上的回饋時,代表是一個短時間內可以承諾或完成執行的。

接著,當一個迭代結束時,會做這個迭代的Demo,也就是展示迭代的成果。最後,會做一個迭代的檢討(Review)和回顧(Retro),檢討和回顧中所產生的工作項目,會再回饋到新的迭代,如此滾動需求、持續回饋改善。
至於團隊的促進者或是Scrum Master,在孟華ezteamwork平台裡叫做迭代管理者(Iteration Master)。這個角色顧名思義,就是促進整個團隊運作的一個角色,這個角色的任務,可以說是為了確保在整個執行過程及團隊溝通是非常有效率地向前推進,這和一般瀑布式專案管理中的專案經理角色有所不同。


歡迎分享文章至