PMP達人-專案管理經驗成長與學習 IT肥蝦個人的專案管理經驗與心得記事與分享。

67愛的鼓勵 2訂閱站台

在臉書的社團中，好友八樓哥提了一個問題：MS project中，A活動duration=1 ；B活動duration=20 。在B活動開始3天時A就必須要完成。這樣子，任務連結要怎麼寫？我是直接把B切成B1+B2=3+17 ，然後把A設為B2的前置任務，A要在B進行3天時就要完成。A1要在B進行10天時就要完成。所以B的前置任務是A fs-3 B和A1 fs-10 B嗎？

接著，八樓哥又說了以下條件：

條件1.A以及A1的開始跟B有甚麼關聯?? -> 沒關係

條件2.A以及A1的完成條件跟B又有甚麼關聯? -> 沒關係

條件3.A是一個部件到?時間，需要一天處理。

條件4.A1部件是即到即用。

就上述的情境，依據PMBOKGuide，正確的答案應該是【Activity A FS -3 Activity B】，Activity B依賴Activity A，這是非常明確的。

但肥蝦這幾年來在執行專案，設定時程與申請資源調度，有兩點想跟各位朋友分享：

(一)               一個活動不要弄太長，並且中間又陸續整合或串接其他活動。

(二)               雖然依賴關係有FS、SF、FF、SS，但其設定除了絕對的因果邏輯外，還要對照合約，並且要易於說明。

就PMBOKGuide上，說明WBS的Package要以有交付物或可管理的基礎作為單位較好，activity則為執行的活動，並不一定要有交付物，但應以管理為依據。因此以八樓哥的例子，肥蝦一看，A好像是B開始三天後投入物！因此是否B的activity搞的太大了，稍為切一下會不會比較好？

當然，如果只是為了表示符號去切割單位package或activity是不太恰當！如果B不能切割，就該說明來看：「在B活動開始3天時A就必須要完成」，這只有B開始日，以及要求A一定要完成的日子。所以最遲是B開始的第二日A就一定要開始，(A要一個工作天)；此外又沒有其它對A的限制，A的完成條件跟B沒關係。因此保守起見，又或者沒有活動A資源調度的問題，那就讓A與B一起開始【A SS B】。

在PMBOKGuide上也說，FS的關係是最常用的，但是想想：「當活動A完成後要啟動活動B」，對照一下合約！現在台灣的環境有幾份合約會寫說：「簽約次日起三個月內完成需求確認；需求確認完成起三個月內完成系統開發…。」好像都是「簽約次日起三個月內完成需求確認；簽約次日起六個月內完成系統開發…。」又再想想，當向老闆報告時，如果太多的FS、SF…的老闆的反應會如何？如果向部門主管協調人力或資源時，會不會被以「前一項活動都還沒完成，等前一個要項完成了再來討論」的理由搪塞？

記得當the one-page project management剛出來之時，肥蝦也想學學來看看，結果被一位老長官當面批說：「那一頁密密麻麻的，我只在乎合約，以及合約上的milestone。」專案管理的資訊很多，不管以何種方式呈現，重點是在溝通！在溝通過程與專案內部的使用工具或語言可否具有相當的一致性！內部使用要求的具體與週延可否順利並迅速的轉換為外部溝通的簡要與效果！

因此就上述的問題，肥蝦以為當活動A一天可完成時，需要活動B先完成三天的進度，因此風險是是B大於A，加上A  independent on B；B dependent on A,，要是B前2天進度delay了，A進來的效果也有限。此外，若是從合約的主體與溝通的效果來看，A FS -3 B跟 B SS +2 A哪一個較能觸碰人的感知與警覺？因此肥蝦在考量活動之間的關係時，除了實際的依賴邏輯外，也會儘量考量每個活動在整體風險上的份量與合約規範主體，盡量把那些SF、FF轉成SS，然後加上每個活動的duration、寬限期與警示期，尤其是那警示日。

如果肥蝦把此問題的答案由A FS -3 B轉成B SS +2 A~~~也許您會問到：「那到時關鍵路徑如何標示？」CP是那完成專案最長時程，因此理論上就算把依賴關係稍微變化也不會有影響的。也許您又會問到：「那把依賴關係弄混了，就看不清楚那前因後果，看不到可能的專案瓶頸。」專案中的每個活動都是重要的，如果不重要也不會排進專案的範圍與時程之中，因此重點是在於那些為瓶頸活動的瓶頸在哪呢？是該活動可使用的資源有限？還是人力技能不足？還是時間不夠充份？就以肥蝦個人有限的經驗，瓶頸活動的瓶頸重點大多還是在是否有適宜的資源，所以使用SS的方式來溝通，也許能夠給予主管較為深刻的印象，看看是否能在專案初期的組織安排上佔得些許許的先機。

專案的目標在達成專案目標，WBS, Activity, CP, Schedule僅是工具，因此專案的任何作為還是要以合約為依據，以合約規定的方式與設定的milestone來作為專案進一步範圍、時程等等細部規畫。因此些許PMBOKGuide說明的方式，也許在實際專案執行上可以再稍為調整簡化一下。

以上蝦扯一通，純是個人的愚見，還請  各位多多包涵。