一個在乎專案管理的組織，有很大的機率也會在乎流程。跨部門之間的溝通是否清楚、需求是否明確、執行與交付的時機點是否合適…這類問題的答案，很多時候可以透過流程來回答，而這些，也正是專案被管理的內容。
然而，在職場中我們時常聽見這樣的抱怨：「這公司怎麼一點流程也沒有…」「流程好亂啊，怎麼每個人講的不一樣…」「流程文件怎麼這麼久沒更新了？」「流程跑到哪裡了？怎麼這麼久都沒下落？」
於是，管理階層介入，也許指派屬下成立特別小組，或是透過外部顧問，開始規劃、輔導、導入該產業所公認的最佳流程標準。這些流程小組於是將雷達打開，開始對公司內部作業進行掃描，運轉中的專案也往往會成了最直接的標的。
只不過，對專案經理來說，流程究竟是造就時程，還是拖垮時程？
推動流程，可降低出錯的機率，剔除反覆或無謂的工作，為公司省下產品開發與重置成本，這是管理階層所在乎的；但是對正如火如荼執行著的專案來說，有時強硬導入標準流程，卻意味著專案團隊可能失去了創新、走出聰明捷徑的機會。在軟體界這樣的思維，也反映在近年來 CMMI (Capability Maturity Model Integration) 與敏捷開發這兩大議題的爭辯上。但是，軟體開發者也慢慢梳理出了兩者相輔相成的脈絡，從開發團隊當下的規模與運作狀況，找出合適的答案。
導入清晰俐落的流程、定期審視並持續優化，這些初衷都是好的，相信專案成員以客觀的角度來看也會認同；但是對於一個正透過既有流程、行雲流水順暢前進的專案來說，則有可能會干擾了現有的節奏，延遲了專案的進度。
我們相信流程的制定與施行，最終將為團隊生產力帶來改善，只是是否適合以手上的專案來進行，卻值得專案經理與流程改善團隊共同思考。
例如：
- 是否有其他替代的內部專案可以先施行，再複製到外部專案以降低對企業營收的影響？
- 是否有尚未啟動或處於規劃初期的專案，適合用來導入新的流程？
- 若確認必須針對執行中的專案進行流程優化，有沒有什麼方法能將專案延誤降至最小？新的流程能為專案帶來哪方面的好處？可以縮短哪個階段的時程、降低哪些成本？
透過思考找出共識，流程可為專案時程打好穩固的基礎；若兩方為達到各自目標，而淪陷為團隊間的衝突與內耗，那就有極大可能成了彼此的絆腳石了。
