在哈米尼斯的天空看到〈專案管理：Change Management〉，作者提到軟體專案 change management 的重要，而對於專案無法掌控的部分，引用《與熊共舞》這本書所說的可以向上丟給 sponsor 或運用專案假設來限制它。但喲哪桑學長卻認為：
「不要被自己的假設所矇蔽，也不要被其所愚弄。記住，所有的假設在被證實之前，假設既不是對，也不是錯。假設，就只是假設而已」。
我蠻認同學長所說的。沒錯，假設往往是風險的主要來源，在專案風險管理中，最簡單而且最常拿來做風險分析的工具便是敏感性分析，它是用來評估當專案的假設與限制改變時，對專案的影響會受到多大的衝擊。所以不能過度依賴假設，假設是需要被管理的呀！
哈米尼斯的天空的這篇文章的作者還認為專案假設事實上是比較徧向法律層級的一種手段，這與PMI 對假設的定義很不一樣，PMBOK 2000 版中提到：
假設是因應專案規劃而生，其被認為是真的、實際的或確定的事情。假設會影響專案規劃的所有面向，並且是專案逐漸細化的一部分。專案成員常常把識別專案的假設、並將之文件化及驗證它們是否仍然成立當作是專案規劃過程的一部分。
由上面定義我們可以發現，其實專案的假設是無所不在的。而徧向法律層面的手段，看起來比較像專案限制，亦即影響專案成果所適用的約束，一般而言，專案合約書的條款就是一種合約的限制。在專案規模定義過程時，必須列出與描述與專案規模關連的假設及當它不成立時所造成的專案衝擊，也必須列出與描述會限制專案成員意見的與專案規模關聯的限制（PMBOK 3rd）。所以不管是假設與限制都是在規劃過程中的產物，而不是只是為了拿來和客戶對簿公堂的武器。要用它們來防止對方翻案、改變需求，那是非常不切實際的，專案成功是雙方的成功，沒有互信為做基礎，專案再怎樣都不會得到善終的，所以，變更需要管理而非凍結。
至於 change management，做好 change control process，可以參考我之前對軟體專案變更控制的看法，簡單的說，就是一定要先評估對專案的 triple constraint 的衝擊，然後要確認變更是有正面的影響，而且影響變更的因素已發生，最重要的就是好好地管理變更。
Hi 同人您好：
很感謝您也引用了我的文章，也針對我文章中某些觀點提供了很好的意見
我之所以會用「徧向法律層級」，這個只是我對於「專案假設」在應用上的一個看法而已，倒也不是說用這種方式去「凍結」客戶的需求。
如果我文中所提的這一個假設「專案執行的過程中，兩方所簽屬的任何文件，皆屬有效文件」，這樣的說法並不是說客戶不能改變Scope(事實上我做過的案子很少有驗收時的規格會和合約完全一樣的)
而是為改變提供一個正式的法源，至少不要在驗收時落人口實說變更Scope的程序是有問題而被卡來卡去。
如同您所提到的，專案是建立在互信的基礎上，不過老祖先也說啦「防人之心不可無」
在我看法這只是一種自我保護的手段，而且再說，專案不必然一定會成功，先在最壞的打算上預做準備，我也不認為一定是完全不好的方式，畢竟「合約」這東西，是一個保障雙方的最後底限，在上面加註一些限制來自我保護，我是不覺得很過分啦…
不過也很謝謝您的意見，讓我發現我在文章中沒有把一些東西交待清楚，我會針對「專案假設」這個主題把我的看法盡可能完整的陳述一次，屆時也希望您多多指教。
自動引用通知: 同人的生活派對 » 評論「專案假設」的相關討論