見前文

專案風險的迷思

那麼，這種無法正視專案變更要求的信仰從何而來呢？依據筆者對許多專案經理的觀察，我發現，為了減輕自己對未來不確定性的恐懼、焦慮，很多專案經理的作法是，不去正視專案變更要求，但，事實上，該種作法不但無法降低風險，還可能造成一般人對專案風險的迷思。

當專案經理接受專案變更要求時，意味著增加開發工作，而這，當然會影響專案時間表，甚至是為專案帶來一些風險。

因為，如果時間表的最後期限改變，自然會導致完工時間與預算等事項的不確定、衝擊，進而造成專案風險。

即使最後期限不改變，時間表的調整，還是有可能造成要徑（時間內的任務一旦延誤，會進一步影響專案完工日的工作量）數目增加的風險。

變更專案時間表(大多是往前提而非向後延)，專案成員為趕進度、或工作內容有所重複，而省略稽核品質等作業流程，進而導致重工率增加或專案品質低落等風險出現，這些都是接受專案變更可能帶來的風險。

既然接受專案變更要求會增加專案風險，那拒絕或延後專案變更要求，是否意味著，專案風險不會因此而增加？當著眼點處於整個專案成敗的高度與視野時，我們會發現，答案是否定的。

如同《專案管理之美學》提到的，專案應該兼顧並協調各種觀點的平衡，這些觀點包括了技術面、客戶面與營運面。技術開發對於專案很重要，但除此之外，客戶需求與營運策略更是不可偏廢。

換句話說，因為技術觀點而拒絕或延後專案變更要求，很可能會影響客戶的滿意度、信任度、或是因為產品推出時效的問題而影響到該產品的市場競爭力，這些影響，可能都比技術所造成的風險，來得嚴重而深遠。

就以筆者過去曾參與過的大型軟體專案為例，一個規模上億的政府部門的公共建設BOT計劃，包含了十幾個子專案。

每當一個專案的設計、開發，到一個段落的時候，筆者必須負責與業主及顧問，商討該如何制定軟體程式設計規格等標準。

其次，因為由我們負責開發的系統很多，彼此又有相當的差異性，使得我們在釐清一致性的標準等過程，面臨到相當大的挑戰。

雖然這些問題很複雜，但整合起來卻不是這麼的困難，真正困難的地方是，業主對我們的不信任，使得筆者藉著技術專業，無法說服他們按照我們的意思去做。(請按下一頁繼續)