專案管理工具(PMIS) (二) 協同合作不只是共同編輯

專案管理工具(PMIS) (二) 協同合作不只是共同編輯

前段時間,去看了某間公司自行開發的專案管理系統。

那天會議中,解說的技術人員在台上簡報時,強調的並不是專案中資源管理或是排程等方面的功能。 反而自己先承認在他們的系統上這兩模組不是很強,轉而一直強調以他們開發的觀點來看,他們覺得一般專案真正需求的是並非工作排程、而是「協同合作」的工具。 也因為這樣的思維,他們的系統僅開發了一個堪用(雖然從我的觀點來看,連堪用都還稱不上)的排程介面,而花很多心思在協同合作這領域。 簡報中還舉了他們自身的經歷,強調專案維基(Wiki)、新聞發布(News)、議題追蹤(Issue Tracking)、還有討論區(Discussion Board)等功能才是最重要的。

他們老闆稍後提到:「反正實際上很少人用甚麼實獲值,PMBOK那一套不適合台灣啦!」 「以我自己的經驗來看,專案重要的是溝通。 是溝通啊! 討論區、Issue Tracking、與共同編輯才最重要!」 也因此,他特別強調「每個專案可以有自己的Wiki區域以及討論區!」然後展示這些功能是有權限鎖定的,除了專案成員以外,別人一概看不到也無法編輯。

我是同意台灣沒甚麼公司真的想用實獲值(也沒那條件用),也同意很多公司所謂專案管理只是徒具形式,但我不完全認同設計專案管理工具時就可以完全忽略這一塊。 絕不能因此把排程、資源管理、或成本計算的部分隨便做做。 畢竟從我的觀點而言,當任何人想用專案管理工具時,若連專案全貌都無法隨時展現下,那不就根本上的失去了使用專案管理工具的目的了嗎?

至於溝通。 我是同意專案經理需要花很大量的時間做溝通,但對於很多人追求「專案溝通平台」的概念卻常常覺得不可思議。 先說,我不是說溝通平台不好,只是我覺得那是Priority較低的一個需求。 它有太多替代方案可以用,而不需要優先花錢電腦化。

因為就我的經驗而言,如果是真正緊急不可的事情,一般人可能直接且當面的去找當事人溝通。 就算今天是一個分散在各地的遠端團隊,也還有電話、視訊、簡訊、甚至Email這些工具。 在這情況下,誰也不會去選擇「討論區」這種東西。 好吧,若是不這麼有急迫性的事情、比方說技術問題的討論好了,我一樣不太可能會選擇使用討論區。 Well,最少不會選擇鎖住權限別人都不能進來的「專案討論區」。

這部分我的一個朋友Chris說的好:「一個專案裡頭能有多少人? 有時候分工很細,搞不好你就是自己領域最強的了。 你還怎麼跟案子內部的別人討論? 甚至貼在全公司的討論區都沒甚麼意義,了不起幾百幾千人。 我真有技術問題要問或討論,我寧願找個甚麼知名論壇。 隨便可能就是幾萬人看,這些人才有可能幫忙回答出些甚麼來。」

確實如此。

只有專案內部才可以看到的討論區,既不能增加溝通的時效性、又不能期待議題能被充分討論,自然沒甚麼人會利用這功能。 其實有內部討論區的公司,幾乎都沒太多人會好好利用這類的功能。 把這功能拿來當軟體功能或許很炫,但卻一點也不務實,所以何必花錢建構呢? (除非你是有幾萬人的大公司)

專案維基(Wiki)也是類似的東西。 知識管理很重要,我非常肯定。 但我不認為這是專案內的事務,相反的這是一個企業層面的事務。 而且,我一直認為,知識管理是必須「專人專職」的。 如果只是期待「有人自發性」的放些東西,而且還能成為有組織、可被使用的知識庫的話,這期待恐怕有些空泛而且天真。

而且,誰都可以上去編輯的狀況,必然沒有整合性、必然可能有些內容是錯的。 熱心的同仁,不表示他最清楚做法的人;清楚做法的人,也不表示他做的方式是最符合專案利益或是公司整體商業利益的。 而且專案根據尺度大小,小案子可能根本不需要從頭做一遍這些流程與規則(只要Follow別人定好的規則就好)。 而大案子,有可能人人都忙,也未必有空或是心力自動自發的做些甚麼。 也因此,這類專案維基的概念雖好,但最後一定也是空蕩蕩的毫無內容。

唯有專人專職的從公司整體來做規劃,每次專案結案後的資訊都整理,隨時按照狀況、按照公司政策、按照能支援政策的做法統籌調整流程。 這才可能產出一些有用的「知識」,這也會比期待有人自發去編輯來的更實務且可行。

這也是為何我對於專案Wiki這類的平台也不是很以為然。 畢竟若能專人專職,以中央管控的概念來定流程時,這些流程或知識就算需要一個平台,那其實也可以是個任何的平台。 只需要注意不要流出去,內部的權限設定不一定會很複雜,在不需要User編輯下,甚至只是個靜態的網頁都可以。

至於新聞發布,這當然有其必要性。 但是可取代的工具一樣很多,而且新聞發佈不至於有敏感性,Email或是一個公布欄也都可以取代,沒道理花大錢買個可以鎖權限的工具。

也因此,對於想建構PMIS的公司而言,我是還滿反對把重心先放在這類事情上。 畢竟花了錢購買系統,應該要解決的是「真正」該被解決的問題、或是「迫切」該被解決的問題。 當然,如果一間公司排程、文管、版本控制、資源管理、成本管理、風險管理等各面向都有解決方案時,錦上添花的建置溝通平台,我覺得無可厚非。 但若這些都沒有,優先弄個溝通平台,那我覺得就有點本末倒置。

喔,對了。 Issue Tracking或許是唯一在這類「溝通平台」上我覺得有必要,而且可以帶來明確成效的一個功能。 但這類東西卻不一定是所有專案類型都一樣重要,某些產業對此需求重於另外的產業。 而且,最重要的關鍵在於,Issue應該是要能跟Activity結合而非跟討論區結合(如此PM或其他管理者才能理解為何某些工作Delay,並反向追蹤原因、以及解決的狀況)。

但無論如何,這部分的需求要Case by Case的評估(比方說Issue Tracking的功能,工程專案的需求就比研發專案來的小)。 但無論哪個產業,一開始建構PMIS都應該要重點放在排程、資源管理、成本管理上。 工作做不做的完若都沒人知道、發生問題會影響多深遠算不出來,卻只是有個小園地讓大家在上面留言、寫字、或塗鴉。 這根本上是對於管理輕重緩急的不理解啊!

 

延伸閱讀
關於專案管理工具(PMIS) (一)三大類型

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
張國洋 Joe Chang

現為識博管理顧問執行長,也在台灣百大上市櫃公司擔任管理講師與專案顧問。歷年客戶包含工研院、台積電、廣達、富智康、光寶集團、台灣大哥大、遠傳電信、中鼎工程、建國工程、台橡公司、大同公司、三陽工業、TVBS、特力屋集團、城邦集團、誠品集團等。 為了對抗雙魚座的感性,一直在努力強化理性思維與邏輯思考。 相信邏輯發展能解構任何事物,並讓我們找到合宜的人生策略與方向。

Joe G+ ICON Joe LInkin ICON