[PMP]何謂成功的專案？
PMP開宗明義就提到，一個成功的專案準則是符合專案鐵三角的限制(Triple Constraints)，這鐵三角分別是：Scope、Time、Cost，分別掌控了專案要做哪些東西，完成的時間、驗收的時間以及整個專案的成本，所以若要定義一個成功的專案，我們往往會要求一個專案在『如期、如質、如預算』的狀況下完成。 
(老師：專案鐵三角若Stakeholder沒有特別要求，則三者同等重要。)
專案鐵三角，只要異動，最少都會影響一個面向，因此做好變更管理將變成PM非常重要的一項工作，變更是一定會發生的，但如何有效的管理則是很重要的一門學問了。
根據統計85%的專案是在超過時間、未達品質標準、耗用過多費用的狀況下被完成，這也代表著，要完成一個專案已不容易，但要完成一個成功的專案就更難了，依我自己的經驗，我認為這三個面向中，若在一開始沒有構想清楚，在過程中也沒有很好的做變更管理的話，通常最後都會讓人很不愉快，為了趕交期，可能犧牲了品質，可能要求同仁加班，而墊高了成本。
很少有專案是能在一開始就將整個全貌看清楚的，也沒有人規定說一定要全都看清楚才能開始進行專案，但在專案開始前必須要先將基準(Baseline)給建立出來，Baseline一旦訂出來，在專案執行時，除非通過專案的關鍵人員(Key Stakeholder等)同意才能做變更基準的動作。
在專案發展過程中有個很有意思的概念叫Rolling Wave Planning，代表的是專案的全貌，會隨著專案的發展，細節愈來愈清楚，因此當專案被分成5個Milestone，剛開始時後面兩個Milestone的細節可能都不太清楚，但專案一邊發展，PM與專案成員應該要對這兩個Milestone的細節有更深入的了解並確認，否則這個專案的需求是有很大問題的。
就我們自己做軟體開發的經驗來說，維護產品Scope非常的重要，一旦偏掉，後續花費的Time與Cost都非常可觀，不得不慎。
下面這一篇雖然不是原文，但是我找到人家轉錄的文章：
談軟體專案失敗的六大關鍵
1. 過份樂觀和沒有經驗的主事者
2. 低估軟體開發的複雜度及忽視許多不可抗力因素
3. 來自各方的不合理壓力
4. 不能以專業態度來 say『no 』
5. 有多加人手來解決問題的心態
6. 收尾無法作到『收斂』的功夫
這一篇講的六點講的比較空洞一點，會給人家有種『好像有點感覺了，然後呢？』的感覺，比起來我還是比較喜歡專案會受到EEF、OPA兩因子還有Stakeholder影響的說法，熟知EEF、OPA還有辨識關鍵的Stakeholder是在專案一開始就要做的事情，但我們常常發現很多案子都是在出現問題後才回推回上面六點，我覺得這個程序有點顛倒了，專案經理應該往前看得更遠一點，有那些未知的規範、哪些隱藏起來的關鍵Stakeholder都可能形成專案的風險啊，要提早獲知。
根據我自己的經驗，一個專案要跑成功，一開始就先找對關鍵的人員，並問他：『是否你說了就算？』，如果是的話就找這個人確認需求，並將範圍訂出來，時程押上去，開始開發，過程中若有變更，要明白的告知在鐵三角的限制下，我們會做什麼樣的變動，若同意就變更，不同意的話就再談，我自己認為大多數的人都是理性的，只要你足夠了解他，對方是不太會刁難你的。
過程中，白紙黑字跟記錄是一定要的，不然隨時有機會被翻盤，這邊需要較多的軟功夫，就看PM的手腕了。
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
