對專案假設的看法

在哈米尼斯的天空看到〈專案管理：Change Management〉，作者提到軟體專案 change management 的重要，而對於專案無法掌控的部分，引用《與熊共舞》這本書所說的可以向上丟給 sponsor 或運用專案假設來限制它。但喲哪桑學長卻認為：

「不要被自己的假設所矇蔽，也不要被其所愚弄。記住，所有的假設在被證實之前，假設既不是對，也不是錯。假設，就只是假設而已」。

我蠻認同學長所說的。沒錯，假設往往是風險的主要來源，在專案風險管理中，最簡單而且最常拿來做風險分析的工具便是敏感性分析，它是用來評估當專案的假設與限制改變時，對專案的影響會受到多大的衝擊。所以不能過度依賴假設，假設是需要被管理的呀！

哈米尼斯的天空的這篇文章的作者還認為專案假設事實上是比較徧向法律層級的一種手段，這與PMI 對假設的定義很不一樣，PMBOK 2000 版中提到：

假設是因應專案規劃而生，其被認為是真的、實際的或確定的事情。假設會影響專案規劃的所有面向，並且是專案逐漸細化的一部分。專案成員常常把識別專案的假設、並將之文件化及驗證它們是否仍然成立當作是專案規劃過程的一部分。

由上面定義我們可以發現，其實專案的假設是無所不在的。而徧向法律層面的手段，看起來比較像專案限制，亦即影響專案成果所適用的約束，一般而言，專案合約書的條款就是一種合約的限制。在專案規模定義過程時，必須列出與描述與專案規模關連的假設及當它不成立時所造成的專案衝擊，也必須列出與描述會限制專案成員意見的與專案規模關聯的限制（PMBOK 3rd）。所以不管是假設與限制都是在規劃過程中的產物，而不是只是為了拿來和客戶對簿公堂的武器。要用它們來防止對方翻案、改變需求，那是非常不切實際的，專案成功是雙方的成功，沒有互信為做基礎，專案再怎樣都不會得到善終的，所以，變更需要管理而非凍結。

至於 change management，做好 change control process，可以參考我之前對軟體專案變更控制的看法，簡單的說，就是一定要先評估對專案的 triple constraint 的衝擊，然後要確認變更是有正面的影響，而且影響變更的因素已發生，最重要的就是好好地管理變更。