如何在小專案取得成功

「如何在小專案取得成功」

本篇文章依據本人驗收過的小型專案為例，絕非虛構

l  古有明訓 : 割雞焉用牛刀

有一天，孔子到武城，聽到武城一片弦樂歌聲，便微微笑說：「割雞焉用牛刀？」意思是：殺雞何必用宰牛的刀，以此來調侃子游，治理武城這麼一個小地方，還須大費周章地動用禮樂教化嗎？子游聽後則回答說：「我曾經聽老師您說過：『做官的學道，就會愛恤人民；老百姓學道，就會容易接受指揮。』」孔子立即向同行弟子表示子游的話是對的，自己剛才不過是說笑罷了。後來「割雞焉用牛刀」被用來比喻處理小事，毋需大才。

翻譯:

小專案需不需要動用牛刀?
看來連孔子都認同不論大小專案，要成功，該做的還是得做。

l  管理專案大不同

專案管理者一般來說依據訓練養成不同，具備了不同類型的專案管理觀念/專案管理工具/專案管理心法等。同樣的，每個專案依據不同的目的，也會有不同類型的專案目標/專案範圍，專案一般而言可大可小，100萬的案子有100萬案子的做法，而1000萬的案子當然也有不同的挑戰。

舉100萬的小案子(相較1000萬的案子)來說，麻雀雖小，但五臟俱全，該有的專案流程與控管該有的一個都不能少，但畢竟是個小案子，因此當專案管理者接到這類任務，要思考的事情大概是以下幾項:

ü  專案控管好，不要讓小案子長成大案子，無法收山

專案控管好，其中主要的原因是因為案子越小代表專案成員不會很多，大概就PM(可能兼職SA)、SD、PG等三人，因此當專案工作開始展開的時候，首先我們需要盤點人力，確定我們的子彈有多少，舉本人先前驗收的小專案為例(60日曆天的專案，以下稱”本小案”)，大致上可以將人力成本依專案期程比例分為:

l   PM (100%參與)-約是專案從頭到尾60個人天成本

l   SA(30%參與)-約是專案初期起算20個人天成本

l   SD(50%參與)-約是專案初期/中期起算30個人天成本

l   PG(60%參與)-約是專案中期/後期起算36個人天成本

l   QA…沒辦法期待有QA專職人員，大部分都是誰有空誰做

那怎樣叫做控制專案? 具體來說PM談好的需求項目盡量控制在5個大項左右，SA的需求分析文件控制在3份(7天一份)左右，SD的系統分析文件控制在5份(6天一份)左右，而PG的開發控制在12項左右(3天一項)。

ü  風險確認越前期越好，尤其是有第三方廠商或業主

專案的風險無所不在，除了專案本身的風險控管是PM的基本功外，特別要注意的是否有藏鏡人，舉本小案來說就需要三個甲方單位+三個乙方廠商一起合作才能成功上線，在磨合與配合的時間資源耗費不算不高，而且還要在當中確保非自身專案的問題實屬不易(到底是多險惡的專案~~哈)，這些風險在一開始PM就要掌握清楚，畢竟我們是賺小錢，任何的風險沒掌握住有可能都會有需求/開發擴散的風險(是的，本小案我也是踩了地雷，程式重構多花了一個星期…)。

ü  例行會議的次數越少越好，不要行禮如儀做表面功夫(小專案沒那個時間…)

例行會議的多寡，決定了PM需要準備的會議資料與開會時間多少，一般來說PM與需求單位於專案初期會談到專案的”溝通計畫”如何被設計與確認，大專案因為期程長、長官多、被注目機會高，因此在溝通計畫的會議項目一般會比較多，而小專案則反之。因此PM的職責很重要，不需要的會議要協調去除或減少，記住小專案的時間不多，除非有特別要求(例如結案會議、高層會議)，否則最好減少會議的時間資源來增加產出。

                                                                專案溝通計畫表

ü  報告資料越少越好，盡量控制在一、兩份報告就可以通用各種例會

舉本小案例子來說，在專案初期就已經跟需求單位約法三章，每週例會與每週進度報告，使用同一份文件來呈現，一來每週的會議紀錄可以清楚記錄，二來專案狀態與專案進度資訊也可放進此份文件，頂多就是每週視專案進度多update一次，所以本小案從開始到驗收，呈現出來的僅有唯一的一份 ”每週報告”。

這份報告我也同樣用來與內部專案團隊做溝通，目的有兩個，一個就是我懶得弄另外一份資料，第二個就是保持專案資訊一致，對於管理一個小專案的PM來說，這樣的方式對我來說是非常受用的，整個專案只有一份報告，是不是很酷?

ü  設定驗收條件，並咬住驗收條件，盡快驗收!!!。

專案初期的第一場會議，只有一個目標，就是設定驗收條件，這個可以拿到錢的里程碑必需第一場會議被設定及確認，因為就本小案來說，這個里程碑除了拿到錢以外，更重要的是專案WBS、專案時程、專案風險控管的錨點設定，先前有提到，本小案要上線，除了專案本身，還要其他廠商的配合才能完成，因此如果不守住驗收條件，無可避免的是有可能會被其他廠商拖累進度，甚至無法驗收(你老闆在你後面很火!)。

本小案於第一場會議後，確認專案驗收條件與產出文件與其他廠商脫鉤(建立第一道驗收防火牆)自行驗收，但天底下沒有這麼好康的事情，在驗收條件設定的同時，我方也答應後續上線期間應協助處理”我方專案發生的問題”(建立第二道驗收防火牆)，也因此在達成驗收條件後本案順利完成驗收。

l  團隊溝通

小團隊有個好處是溝通非常的快速，但要達到暢通則需要一些手法，以下是本小案我覺得進行的還不錯的部分:

l   建立溝通共識與模式，尊重每個角色的定位與建議

l   建立溝通工具，保持專案資訊通透

l   每天與專案成員聊一下，了解目前的專案狀況與需要協助的部分

l   每週與甲方例會前，先行開個小組會議，確認資訊一致

l   密切注意與跟催第三方廠商的建置進度，避免被影響

l   保持需求分析/系統分析/程式開發/測試報告進度超前，預留彈性

l   適度鼓勵團隊，請喝咖啡之類的…

l  結語

小專案需不需要動用牛刀?

看來連孔子都認同不論大小專案，要成功，該做的還是得做。

但，可以規模小點，更有效率點。

祝大家大小專案都如魚得水，順利驗收~~