在一般的Project中, 最常遇到的就是客戶對專案時程的要求比PM所預估的更緊, 對於一般的PM(東方)來說, 不外乎就下列幾種作法:
1. 加班
這是最常被用到的手法, 反正只求達到客戶的要求, 其他一概不管. 當然, 以加班來補正常工作日的不足是一種手法, 但在東方社會往往被濫用, 導致為了完成Project, 但犧牲Project Team Members的個人生活
2. 投入更多的資源
包括用更多的人力, 但這意謂著需要更多的成本, 但往往客戶並不理會, 導致PM必須自行想辦法吸收. 在Internal Project中, 這無形侵蝕企業本身的獲利, 只是組織內的員工不知情罷了. 但若屬於Contract Project, 則吃虧的是廠商. 但多少錢能作多少事是不移的定律, 也沒有什麼廠商能長期自行吸收所增加的成本, 最後可能會導致Project無法驗收, 或驗收的品質不佳, 造成雙輸的局面.
這個問題在PMP的概念中, 是有些不同的解法:
在PMP的觀念中並無Over Time(加班)的作法, 所以必須從下面幾種方向出發:
1. 變更Project Scope
這並非不可能的事. 直接找客戶談是否能把原先要作的所有工作區分出優先等級, 把最重要的先完成, 其他的再以下一個Phase或新Project來進行.
2. Crashing
看到這裡, 放心, 不是要你把宣告整個Project失敗. Crashing在這裡的意思就是嘗試以增加成本的方式來換取較短的完成時間, 也就是上面提到的投入更多的資源. 只是這必須與客戶的付出取得一個平衡點, 畢竟虧本的生意不是沒人作, 而是不能長期一直在進行虧本的Project
3. Fast Tracking
這是把一些原本需要循序漸進處理的工作調整成同時處理, 但這隱含幾個問題, 就是工作間是否有前後關係? 以及進行這些工作時是否同時會使用到某些相同的Resources? 如果萬一真的同時使用某些相同的Resources, PM可能還是得再花費額外的Cost來增加Resources
4. 與客戶討論降低驗收品質的可行性
例如: 軟體開發, 可以將完整的測試暫時取消, 因為完整的測試往往需投入大量的使用者端的人力, 物力, 且花費的時間也較長, 如果可以與客戶取得共識, 同意在開發團隊初步測試沒問題後, 先行上線使用, 就可以提前達交該軟體
這些方式都是有機會在Project Schedule固定情況下, 可以完成原先預估完成不了之工作的作法, 但是否真能如此使用, 仍得視企業的文化是否能接受
留言列表
