政府單位在管控計畫時,面對瞬息萬變的利害關係人需求、迫在眉睫的專案進度、難以掌控的成本超支,這些壓力常常讓你感到喘不過氣?專案經理要能有效帶領團隊,不能只靠土法煉鋼與隱性知識傳遞,在資訊科技不斷推陳出新的今天,善用工具將能大大提升專案的透明度,並引領團隊以最小的力氣,達到最大的效益。同時在執行專案的過程中,自動收集並建立良好的組織知識庫,使企業不僅管好現在的專案,更提高未來專案的成功率。

孟華科技總經理陳威良,同時也是孟華的創辦人之一,他與幾位創業夥伴過去曾任職於美國的AT&T貝爾實驗室、IBM、以及華爾街的投資銀行,這群來自台灣的同好夥伴,觀察到台灣企業的工作流程與他們平日在美國習慣的工作方式有很大的差異,例如:在做大型系統開發專案時,美國企業會用嚴謹的開發流程執行工作,也因為國土幅員廣大,因此非常熟悉分散式異地辦公、跨地區工作的協作模式,同時運用各種資訊工具,讓團隊工作更有效率。反觀台灣,經常可見「一人專案」,從談需求、寫程式、測試、交付、教育訓練等都由同一人執行,即使有組建專案團隊,也常缺乏嚴謹的流程,而多由成員單打獨鬥。

由於計畫由單位內各承辦人員個別管理,在顧問訪談後,發現各承辦人員的管理風格、方式皆有些許不同,為降低計畫交接、傳承時的門他們也觀察到在溝通方面,台灣企業多依賴大量的Email往來,但受限於Email單向式的資訊傳遞,較難做到即時的資訊分享。發現流程面與溝通面這兩個主要落差,讓陳威良與夥伴產生創業想法,希望開發出一個能幫助企業提高團隊協同工作效率的工具,因此2002年他們共同創立孟華科技,推出第一代產品,而後持續不斷地改良,而發展出今天的ezteamwork協作平台,目標鎖定營運中需要專案活動的客戶,提供一個全生命週期的管理平台。

▲ ezteamwork專案管理及團隊協作平台,能滿足不同類型的管理需求


想在組織導入PMIS工具?先抓住團隊的心

但是,改變是最大的挑戰,無論再好用的團隊協同工具,都還是需要「人為」。組織對於導入專案管理資訊工具(PMIS)免不了有抗拒心理,面對這樣的導入障礙,孟華科技資深顧問龔竑漵建議,可以將組織內部區分成兩類對象來做導入前心態的調適與溝通,再執行三個階段性的系統導入作業:

第1類對象:組織高層

在完成流程重整後,第二階段係以搭配流程調整系統功能為目標,降低使用者學習門檻,並提升工作效率,配合流程說明與教學,系統在短時間內即迅速上線,並於上線後與使用者不斷互動,依據使用者需求進行系統調整,提升系統對於使用者的可用性與易用性。

第2類對象:專案團隊

導入專案管理系統後,因其具有跨平台、安全性、管理便利、可快速產生報表、協助規劃標準化計畫管理改變舊有思維,善用團隊協作平台提升工作的效益。例如:週報、月報等本來需透過Word、Power Point人工整理的資料,經由平日系統中的工作回報與專案資料保存,平台便能紀錄及自動彙整資訊,方便專案團隊成員管理及直接向上呈報,這些原本就在做的工作不僅不需要重工,平台又可以產出更多有益的資訊、提升整體工作效益,還可以將多出來的時間資源投入其他重要任務。

有企圖心導入專案管理系統的企業,專案管理本質都不錯,內部都有某種流程。」故只要調適好組織高層與專案團隊心態,接續在系統導入三階段就能加快步調,平均1~2個月便能幫助企業將專案管理流程強化跟優化。

— 陳威良總經理

ezteamwork系統導入階段


團隊協作平台對不同利害關係人的效益

專案團隊協作工具,到底可以如何幫助組織提升營運效益?龔竑漵分別就業主與協力廠商、個人與團隊、專案管理辦公室、決策主管四個層面,進一步說明團隊協作平台能為各階層帶來的優勢。

1.審業主與協力廠商

協力廠商透過平台分享與回報專案資訊,業主可掌握專案團隊的最新進度、了解整體專案狀況,而在請款時,也可縮短雙方所需的文件確認作業時間。

2.專案經理(個人)與專案團隊

透過平台系統提供的功能,進行各式各樣包含範疇、時間、成本的專案規劃,除此之外,還可由團隊進行進度回報、上傳交付成果以及執行過程中的專案文件,專案經理也可更專注於專案執行監控。

3.專案管理辦公室

與個人和團隊不同,專案辦公室是企業中高層級的專案管理組織(部門),可透過平台協助公司建置專案流程範本、標準作業流程(SOP)及組織專案管理流程制度,供未來專案開案時直接參考及運用,如此不僅能節省許多重新修改、調整、規劃的時間,並可確保不同專案執行可依循一致的流程並交付一致性的產出,以及保留完整的經驗法則、組織過程資產,另外也能透過平台彙整公司大大小小專案的績效,整合成為一個良好的知識管理平台。

4.各層級主管

功能部門主管可透過平台可妥善地進行人力資源管理規劃,不僅能一目瞭然資源分配狀況、更可進行資源撫平;企業的中高階主管則可透過系統呈現的專案績效資訊快速掌握全公司專案現況,以做為決策分析輔助。

透過系統平台的即時回報,資訊可以公開透明的展現在各個不同層面。不必靠人為打電話、發Email告知其他團隊成員,所有的專案資訊都可以即時存取。ezteamwork團隊協作平台提供明確的帳號概念,每個帳號可以存取的資訊有權限上區分,便可以做良好的分權管理。

— 龔竑漵資深顧問

▲ 中宇環保教育訓練

▲ 台中環保局教育訓練


專案型態多變 工具要求大不同

近幾年專案開始有越來越多種不同的新型態,除 了台灣較常見的瀑布式之外,敏捷式近幾年也開 始被嘗試運用,而更多的是並融兩者優點的混合式,一個工具是否具備彈性、可適應不同的專案 型態需求更顯重要,孟華科技另一位資深顧問陳 美螢將三種手法對工具的需求分析歸納:

1.瀑布式

對工具的要求是一開始可以制定時程跟成本計畫,且易於追蹤實際執行狀況並確保可貼近計畫,常用的工具如:甘特圖,如果專案預期進度與實際進度有落差時,系統可以自動警示,如果相符則代表中間浪費的資源越少,且如期完成的機率也較高。

2.敏捷式

一般期待一個可快速調整工作的可視化的工具,例如:看板且包含To do、Doing、Test、Done等狀態,並可以支援多個迭代的運作,在每個迭代進行多個工作項目的平行開發時,透過可視化的看板工具,專案團隊成員可分享彼此的進度,並快速進行調整以擁抱變化。

3.混合式

目前各界尚無一個明確的混合式定義,在ezteamwork中,混合式專案是基於一個主時程框架(Master schedule),但每個大項任務可能不使用工作分解結構(WBS)來拆解,而是用敏捷式迭代的概念實做。一開始先依瀑布式的思維排定計畫,但僅須排至一定程度之大項即可(現實上可能也無足夠細節往下展開),此時可於甘特圖看到專案的主要時程發展,但在實際執行時則採用敏捷手法,針對每個大項任務動態地訂定所需執行的工作項目,並透過看板進行協同作業。

▲ ezteamwork提供可視化的敏捷看板

▲ ezteamwork提供甘特圖自動產出與動態排程機制


專案型態多變 工具要求大不同

專案管理工具眾多,也許有人會質疑網路上亦有不少免費工具,為什麼還使用商業授權的工具呢?其中一個原因是許多免費工具常需要由自己的資訊部門來運作,如果無法自行維護,當遇到需調整系統以發展自己的工作模式時,或是需要某些功能升級時,就有可能無法獲得及時的支援,但商業授權工具則有廠商在服務客戶需求、定期更新及提供支援。陳威良提醒:「無論免費或付費工具都不是萬能的,還是要搭配公司流程跟制度運作才可達到效果。」才能將工具用的好、專案管的好,帶領團隊輕鬆協作,提升組織整體效益。

▲ ezteamwork個人化首頁呈現專案總覽

原文出處《專案經理》雜誌

緣起

政府單位在管控計畫時,須符合政府法規並同時考量完善的授權機制確保資料安全,計畫從起始階段開始,在資源分配、計畫初審、核定、通過到經費的切割與執行等各階段皆需妥善規劃,並透過層層把關來確保計畫執行品質,在此前提下,整個計畫管理是一個複雜又歷時久遠的一個過程。除考量執行完善性外,每年皆有大量計畫需進行管控,如何在人力有限的情況下,將過往計畫執行歷程與紀錄做為未來計畫管控的參考依據,有效透過系統進行系統化計畫管理,提升計畫管控效率提升,此為計畫執行的重點。

政府計畫管理案例

1.案例背景

以筆者所輔導一政府單位為例,單位內每個承辦同時負責多個計畫,多數計畫為各年度需定期執行之延續性計畫,且定期會有人員異動,經常有計畫交接與延續性規劃的需求。但因無共同系統管理,各計畫只能透過個別的資料儲存媒介;如各期報告光碟等進行資料儲存,希望能透過系統功能降低計畫交接時可能產生的人工作業困擾,並提升承辦人員日常作業效率。
同時,由於計畫執行單位來自各界,此系統需具備雲端服務特性,使用者只要透過瀏覽器上網連線至系統即可,單位內承辦人員可透過網路連線至系統管理計畫資料,相關廠商也可連線至系統回報工作進度與執行結果。

2.動機

為了有效管理計畫,客戶希望導入專案管理系統,達到承辦人員與各計畫委辦廠商計畫進度資訊同步的目標,並可依據各計畫之各類事務提供事件自動跟催、計畫進度數量回報與跨計畫資訊報表自動彙整功能、計畫罰則與交辦等資訊整合。

同時系統需提供集中存放計畫資訊,如:進度文件、結案報告、報告圖檔等,透過各計畫資訊的累積,紀錄計畫執行紀錄與經驗,達成計畫知識管理之目標,並期望能提高執行效率與績效。並經由系統平台資訊的統整紀錄,避免因各年度計畫人員、廠商的不同,所造成的經驗傳承困難、或不必要的執行缺失。

3.執行方式

由於計畫由單位內各承辦人員個別管理,在顧問訪談後,發現各承辦人員的管理風格、方式皆有些許不同,為降低計畫交接、傳承時的門檻,孟華在導入專案管理系統進行計畫管理時,分為流程重整與系統導入兩階段。
第一階段目標為依據單位內的計畫目標與現行作業方式來制定一套標準流程,且流程須以提高計畫管理效率與減低單位人員負擔為前提。透過不斷單位內承辦人員以及委辦廠商的訪談與協調過程,逐步調整流程內容以符合雙方需求,最後在雙方認可後定出標準流程。

在標準流程中,計畫分為三階段:建立、執行與結案。在建立階段的部分,計畫執行單位須將合約中規定之工作項目與請款標準等基本資料建置於系統中,並將建置完成的資料提交給承辦人員確認,承辦人員確認後,計畫便進入執行階段。計畫執行期間,執行單位須定期提交回報進度與文件供承辦人員審核,透過系統化的管理方式,確保資料的一致性與審核的公正性。計畫執行完成後,執行單位須於系統上繳交結案報告,並向承辦人員申請結案,完成計畫結案。

在完成流程重整後,第二階段係以搭配流程調整系統功能為目標,降低使用者學習門檻,並提升工作效率,配合流程說明與教學,系統在短時間內即迅速上線,並於上線後與使用者不斷互動,依據使用者需求進行系統調整,提升系統對於使用者的可用性與易用性。

4.效益

導入專案管理系統後,因其具有跨平台、安全性、管理便利、可快速產生報表、協助規劃標準化計畫管理流程、提供共用計畫管理平台等特色,為客戶帶來以下好處:

電子化管理

  • 工作執行證明相關文件,集中上載於平台、並關連相關工作項目,便利承辦人工作查核、資料保存、及資料搜尋。
  • 透過系統管理變更、紀錄、審核及稽催之功能,使承辦人及委辦廠商有共同行為依據。
  • 承辦人/委辦廠商所有的動作,均在系統上留下紀錄,從根本避免循私的可能。
  • 減少紙本文件,達到節能減碳效益。

文件管理

  • 計畫成員可將期中期末報告書、季報月報等各式報告之參考或產出文件上傳至平台,其他計畫成員可即時取得最新參考資料
  • 系統所納管文件可以進行審核,在審核通過後才正式發布。

審核流程

  • 提供產出文件、工作項目、時程變更、期中/期末報告等項目審核核流程功能,依事先定義好之流程規則,由權責者進行審核。
  • 可設定各關卡審核期限,到期前後若未進行審核,皆發送出email通知。
  • 審核關卡變換時即時發送審核email通知,通知相關人員審核進度。
  • 可設定流程email通知規則,在特定流程動作發生時,通知特定人員。

時間管理

  • 承辦人員可以透過排程排定工作時程:設定各工作項目的預定開始與預定完成時間,與工作項目間的相依關係。
  • 計畫相關人員可以透過甘特圖檢視工作時程,及預定的工作進度與實際工作進度狀態。
  • 承辦人員可設定工作到期通知,系統自動發送工作到期或逾期通知email以提醒相關人員。

問題管理

  • 提供計畫執行時的問題之記錄與追蹤,由使用者記錄問題並設定完成期限,並產生問題彙整報表,以追蹤未完成之問題。

個人化之專案進度檢視、工作回報及指派

  • 使用者依其授權,檢視相關之專案進度資訊,其內容包含專案名稱、專案預定開始與完成日、專案預定及實際進度等。
  • 執行單位可依其被指派之任務,進行進度回報,所回報之進度將由系統彙整至專案整體進度。

快速檢索

  • 透過搜尋引擎功能,以查詢資料庫及文件資料,並可設定搜尋範圍、資料建立日期、更改日期等,來縮小查詢結果。

統計報表

  • 為了使承辦人員能夠立即且快速的掌握每一專案的工作進度,可藉由建立計畫的工作項目及罰則、問題與交辦、請付款管理等報表來明確的顯示計畫的詳細資訊。
  • 在專案進度方面,提供量身打造之計畫進度與符合率報表,透過系統的運算明確的顯示計畫目前進行的狀態。
  • 針對文件控管提供文件準點統計報表,自動計算期間內文件繳交情形。

結論

在民眾期望增加與政策訴求持續改善的環境中,政府部門如何在有限的人力中,以最低成本考量、最快回應速度、有效達成計畫執行率並回應民眾需求,都是單位在運作時的主要目標。為有效達成此目標需要有執行力的流程規劃,以本案例來說,即是透過專案管理制度的建立以協助政府單位有效管理計畫。

結合制度的建立與系統化資訊管理,各單位在管理計畫時可具備揭示即時之資訊、提供全方位之管理架構、強化承辦人員與委辦廠商協同作業方式,提高整體計畫執行效率、有助於落實作業流程、提升資訊再利用效率、與保留計畫執行經驗等特色。

原文刊載於《專案經理》雜誌

知識管理(KM, knowledge management)是近幾年很夯的話題,許多企業積極推動知識管理背後的動機,主要是為專案經驗傳承與永續發展,對於面臨退休潮的企業或是人力異動頻繁的組織,如何把前人的經驗留下並讓後人無縫接軌,始終是一大挑戰。而專案都有結束的時候,不知大家都是怎麼保存專案的知識資產呢?

這幾年輔導不少企業進行研發專案管理,但發現會做的不會說、會說的不願意寫,這樣的情形比比皆是,造成企業內部知識管理無法落實。也許有人會說,我們有文件啊,我們都會寫結案報告作為組織流程資產。沒錯,結案報告當然要寫,而且越詳實越好,但好不容易經歷辛苦的專案奮戰,不少人最後就抱著「能過關」的低標心態在寫結案報告,遑論鉅細靡遺地紀錄專案過程的大小事了。

專案文件,例如計畫書、進度報告、各項交付物、以及結案報告等等,這些原本就會做,而且也會經過相關審核,所以大多數人會將這些文件納入知識庫(文件庫),這也是最容易做到的,但請大家也要思考或是回顧一下,這些文件的再利用率有多高呢?畢竟只收不用,也是一種資源的浪費。

但除了專案文件以外,個人認為最能具體呈現專案歷程也最能反應專案經驗的知識資產有兩類:

第一類是問題清單(Issue Log)

如果每件事都只需要照著計畫書按表操課,那專案成功率應該要很高才對,但為何總是聽到數不盡的專案苦水呢?就是因為突發狀況太多了,所以對於問題、異常或例外的處理能力,才能夠充分展現一個專案團隊的實力。而這些問題、異常或例外的紀錄就是Issue Log。Issue Log有兩個用途,一是追蹤列管(Tracking)、二是追溯省思(Tracing),追蹤列管顧名思義,就是追蹤每個問題的處理情形,以確保它有被及時妥善地處理,而追溯省思則是記錄每個問題的來龍去脈,找出真正問題發生的原因並避免日後再發。所以Issue Log絕對不能只是押個日期或記個狀態而已,而要能充分滿足上述兩個功能,這樣當日後其他專案遇到問題時,歷史專案的Issue Log才能有所助益。

第二類則是通聯過程

試想航空器為什麼有黑盒子,而黑盒子又紀錄了些什麼?同樣的,一個專案的通聯過程,可以幫助我們抽絲剝繭地找出這個專案從開始到結束,中間到底發生過什麼事、又是怎麼處理的。所以如果說專案的最大知識庫,其實就是LINE的聊天紀錄跟所有的email,大家也就無須訝異了。但LINE聊天紀錄實在太多太雜了,所以一般而言,重要的事情不會只在LINE說說而已,後續正式一點的就會再發個文,而非正式一點的則會補個email。問題來了,email的寄件者與收件者可以是專案的任何人,那要怎麼把每個人的信箱彙整起來變成一個整合的大知識庫呢?要做好這件事就有賴專案成員平常做資料整理與記錄的工作習慣,否則相信事後整理是誰都不想去碰的,更不用說要從何存取專案成員的個人信箱了。

十多年前我自創了一個名詞PKM (Project Knowledge Management),希望大家不要為PM而PM或是為KM而KM,在平常做專案管理(PM)的同時,就「順道」把知識管理(KM)做好,這樣不僅省事,也才是PKM的真諦。最重要的是能夠將專案的寶貴經驗完整且有效地傳承下去。

筆者另一篇文章談到近幾年在擔任國際專案管理學會台灣分會(PMITW)的專案管理大獎評審時,所觀察到的幾個值得思考的現象,今天來談談各參賽單位也很常提到的:「雖然我們採取傳統的瀑布式管理方式,但我們也融入敏捷精神,每天都開站立會議」。

為什麼不少人把開 站立會議 或使用 看板 就當作是「敏捷」呢?這代表還是不少人認為有其形就有其神,卻忽略了真正的敏捷精神是什麼?如果範疇不變(甚至還一直追加)、完成期限不變、甚至連預算也不變,那再多的站立會議也只是增加更多的待辦工作,而看板也只是換個追蹤進度的方式,但到最後仍然是靠妥協與爆肝來換取專案的順利結案而已。

要真正敏捷,客戶(包含甲方或老闆)的態度與參與就很重要,可惜今天多數的專案環境,還是落入「計畫趕不上變化、變化趕不上客戶的一句話」的無底深淵,因此所有形式上的敏捷,也只是為了搭上潮流而已,卻無助於專案本質的敏捷化,自然也不易達成敏捷的執行成果 – 快速產出、回饋改善。所以還是務實一點,想要實踐敏捷,如果短期間內無法改變外部客戶,那就先從內部做起;如果影響不了大老闆,那就從影響直屬上司做起吧!

在此並非認為站立會議對一般的專案沒用處,其實如果能夠透過站立會議使專案會議的步調加快,並在每日的站立會議更頻繁確實地追蹤專案進度,避免星星之火變成森林大火,這不就代表更有效率的專案管理嗎!而為了讓站立會議所呈現的資訊可視性更高,結合看板工具不啻為一個好的會議進行方式。只是,千萬不要再說有用看板、開站立會議,就是敏捷專案管理了!

最近專案管理領域最熱門的關鍵字應該就是「敏捷」了,當然這跟整個大環境的發展趨勢有關,無論是AI人工智慧、5G、IOT、雲端服務、雲端運算等,都是在高度變遷的環境下發展,因此以往軟體業所採用的敏捷開發方式,也被應用到許多新型態的專案中。

除了軟體開發或應用新技術的新型態專案,其他類型的專案又如何呢?讓我們來看一些例子:

營建業可說是目前應用專案管理最成熟的行業之一,由於營建工程在開工之後的重作成本非常地高,所以營建管理幾乎都是採用瀑布式(計畫式)的專案管理方式,也就是先進行周延的計畫,待計畫核定再向前推進。然而,EPC統包乃是目前工程發包的趨勢,其中設計階段不就是一個反覆修改的過程嗎?而施工後期的裝修工程,無論是風格、材質、甚至顏色,同樣的也可能歷經多次溝通討論,談到反覆修改或密集的溝通討論,這不正是敏捷的做法嗎?

再看看製造業,現今多數製造業都從OEM轉型為ODM(原廠委託設計),通常在一個ODM專案的前段會進行協同設計與開發,中後段則進行試做或小批量製造,等一切就緒後才進入量產前的準備。這類專案仍須對客戶承諾專案期程與目標,所以仍需排定計畫,但這樣的計畫往往無法涵蓋足夠的執行細節,例如:允許多少次設計修改、多少次打樣、多少試(實)驗等等,導致只能規劃粗略的計畫時程,試想當每個任務的時間都拉到一兩個月或更長時(想像甘特圖中每條長長的bar),這樣的計畫又應該怎麼管控呢?

最後回來看軟體業,多數軟體或系統整合服務廠商,仍以接受客戶委託之開發專案為主,所以不似開發自有產品可以有全然的自主性,並可採用高度敏捷的手法。由於每個受委託專案仍須滿足客戶的需求與範疇,也一定會有目標交期,所以最後又回到瀑布式的周期,但在執行瀑布式的各階段工作(例如:需求收集、系統分析與設計,甚至安排功能開發先後次序或準備測試計畫等),則仍以敏捷方式來進行較佳。

綜上可以看出,許多專案仍須以計畫為主軸(瀑布式),但專案過程的實施則可搭配敏捷手法,所以專案經理要能夠靈活地應用「混合式」的管理方式,才能滿足多變的專案需求。

瀑布式專案管理通常有嚴謹的流程,所以可搭配PMIS以將專案管理自動化;敏捷式專案管理則常使用數位看板將專案進度可視化以提高溝通效率;而混合式則兼具二者特性:主計畫的流程與管控要嚴謹、有異常時應預警並遵循變更流程,但細節的執行則要彈性快速,以在有限的時間內產出可接受的階段性成果,方可向下個階段前進,而欲取得混合式專案管理的靈活度,採用整合PMIS與看板功能的專案管理系統工具是重要關鍵。

孟華科技ezteamwork專案管理系統無縫整合敏捷看板於嚴謹的瀑布式專案管理流程,您可依不同專案特性靈活運用瀑布式、敏捷式、或混合式的管理機制。

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

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

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

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

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

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