這個問題可由三個簡單的數學公式來回答。

因為軟體專案主要為人工成本。所以，成本=工期 X 單位人工成本(這是第一個公式)。
造成本超出預期的變數只有單位人工成本和工期。先假設單位人工成本不變，那麼，成本超出預期就表示：工期超出了預期。所以，軟體專案要能“成本如預期”，先要能“如期”。那要如何能如期呢？看看工期的公式吧！

工期 = 工作量 / 生產率(這是第二個公式)
所以，工期超過有二個變數，第一個是工作量超出預期；第二個是生產率不如預期；只要有任何一種情況發生，就會造成工期超出預期。如果在一個專案裡，兩個情況都發生時，就很慘啦！要改善第一種情況一定要做好需求管理，使工作量如預期。要改善第二種情況，就要進一步了解生產率為何物了。

生產率 = 完成的有效工作 / 所花費的時間(這是第三個公式)。簡單的說就是：單位時間內完成的有效工作。所謂的有效工作，就是合乎品質需求的工作。所以從這裡又可以知道，要能“如期”的完成工作，先要能“如質”的完成工作。

到這裡其實已經很明白了，不過在下結論前，先檢查一下，當初的假設：“單位人工成本不變”，是否合乎實情。我個人認為這是合乎情理的，因為没有一個老闆會笨到將員工的薪資調高到使它成為“專案成本超出預期”的主要因素。

因此，最後的結論就是，專案的成本總是超出預期的因素有：
1. 專案開始前，對工作量的低估或漏估；
2. 專案開始後，未有效管理需需求，因而需求膨脹，造成工作量的增加；
3. 專案開始前，對生產率的高估或根本不知道而亂估；
4. 專案開始後，未能有效管理品質，造成許多的重工，使得生產率低於當初的估計。

所以，軟體專案先要依序做到“如質”、“如期”，最後，才能做到“如預算” (“成本如預期”的另一個說法)。

軟體品質協會資深管理師 周茂松

承包商在投標時，儘可能要預留一定比例的風險準備金，買方越不成熟或 RFP 內容越不清楚，風險準備金的比例要越高，但是也千萬不可忽視品質管理與文件的成本，以下就是一個實例 :

三年前，國內有一家資本額上億的軟體公司承包某軍方的大型系統專案，RFP 中書明要求廠商須交付 IEEE 12207 所規範的所有技術文件，結果廠商得標後才知道軍方是玩真的嚴格要求，原想請某顧問公司幫忙撰寫，但報價一千多萬元，只好改請幾位教授指導撰寫(約幾十萬元)，但最後還是未被軍方驗收，這家公司現在已經解散，負責人因債務已遠居國外 ...

我相信像這樣的例子一定很多，總而言之，承包商在投標時，RFP 一定要仔細研讀，千萬不可掉以輕心啊 !

身為規劃階段的【業務、決策部門】人員，避免將所有的錯誤都推到執行階段的【專案部門】人員，老是怪「專案經理」沒有能力精確估算專案的執行成本，也沒有詳細分析潛藏的風險成本，老是怪【工程技術部門】沒有專業技術能力。

確實有些公司決策錯誤的主管及奧客都是瞎子，只顧自身利益而不考慮專案風險及員工生涯(制度規章只是欺騙善良勞工用途)，專案搞垮後只會驅離非皇親國戚身份人員，有些人真的以為軟體架構可以蓋好地上五樓地下一樓(大象)，業務、決策員後續擴充為地上十樓地下二樓(大耳朵的象)，天才的客戶更將規格膨脹為地上十五樓地下三樓(飛象)，只能說甲乙雙方，一個願打，一個願挨，甘願做，歡喜受。瞎子主管為了鞏固地位，明明知道漏洞百出的產品有問題，仍依舊不願對交付標的物負責，當一天和尚敲一天鐘，過一天算一天，欺騙公司及下屬，不斷增加員工離職率(成本↑)，到處騙錢(成本↑)。

精確估算的成本分析提案給【業務部門】後，幾乎先幫公司老闆壓低成本(內部打七折)，提給客戶前為了展現良好的業務能力、鞏固客戶關係，再幫客戶打了七折(風險、加班、獎金、營運成本、營業利潤都被折扣)；這樣惡劣的環境下，逼得執行人員【PM、PE、SA、SD、SE、PA、PD、PG、PE、UI、DE、QE、RE、TE…】天天表演特異功能，如果「專案協理、經理」角色本身的背景不是一路從UI、RD、PD、PA、SD、SA、PreSale 過程晉升的話，又沒有軟體工程、CMMI的品質實務經驗(高學歷不代表全部都懂)，根本不需用大腦評估，就可知道是一個爛的軟體品質專案。

在買方市場條件下(廠商輪替原則，避免將所有的雞蛋投入同一個籃子)，大多賣方只重維持良好客戶關係，而買方的資訊專業幾乎停留在CMMI-1的水準，漸漸養成只要我喜歡有啥不可以的老大心態；兩方從來不去改善正確的異動流程管理、關心交付品質。畢竟軟體產業是無形的，不像房子、車子可以定義明確的工資與材料，以跑一百公尺的短距時間去估算一百公里的長距時間方法，用在軟體產業，忽略體能及突發狀況，是大錯特錯，當然最後結案階段，往往專案成本總是會超出原預期，不是這樣嗎？

專案經理沒有「說不的權力」? ... 其實不是吧，根據我個人過去曾在幾家大型系統整合公司擔任業務主管的經歷，事實上是專案經理沒有「說不的能力」吧 !

畢竟這是一個買方市場，通常軟體公司的專案經理沒有機會事先估算合理的專案成本，去影響客戶編列合理的預算，多半是業務部門拿到客戶專案RFP回來後，專案經理沒有能力精確估算專案的執行成本，也沒有詳細分析潛藏的風險成本，因此決策者在業績考量下，又缺乏精確量化而具有說服力的專業估算報告支援，彷彿像勇敢的瞎子冒險過河，其後果當然可想而知，而最後收拾爛攤子扛責任的往往還是專案經理，但是這又能怨誰呢 ?

「殺頭的生意有人做，賠錢的生意沒人做」! 但是為什麼有這麼多軟體公司總是在做賠錢生意呢 ? 因為是瞎子嘛 ! 如果專案經理能夠在事先提供給決策者精確而專業的成本估算報告，丟掉賠錢的業績也比最後虧損好啊 ! 但如果決策者還是執意要承做，這份專業的估算報告可能還會是專案經理事後究責的護身符呢 !

　　專案經理沒有「說不的權力」，我想這個可能與公司所採取的績效制度--利潤中心制有關，這個看似不錯的制度，卻容易造成公司內部的勾心鬥角，進而影響到公司整體績效的呈現。有些公司的績效制度裡，業務只要到接案就有績效，卻不必管專案執行單位做不做得來，所以，業務單位會為了自己的績效而去遊說決策主管把案子接下來。因此，管理者在設計制度時，應多費心思量，到底是部門個別績效比較重要，還是公司整體的績效比較重要，當然，也有人會考慮到「案子是資金的來源」而持不同的看法，所以這個問題是見仁見智的。

　　當然案子接不接，專案經理可能沒有辦法掌控，另外，能用多少錢做案子，同樣也不是專案經理可以掌控的。尤其當一個案子裡埋藏了太多不確定的需求時，通常專案經理在受命時才發現都為時已晚，因為那種案子公司根本就不該接。但是，既然已上了賊船，專案經理可以做的事情，應該是去做好專案成本估算，以及將現有專案預算做合理的分配，務必使專案內的關鍵工作，都能分配到可以使工作順利進行的預算，而不足的部分要明確指出來，那些項目不足，不足多少，提供給決策階層、業務單位及會計單位。讓公司能夠有足夠的時間去思考解決的辦法，例如籌措資金、變更合約執行的方式、或者再找其他的案子來養這個案子。

----------------
引文:

Dear All,

其實很多時候專案經理是沒有權力說不的! 要不就是業務單位的權力大，要不就是決策主管要求，總之有很多緣由導致專案經理即便建議不要接某個專案，也被逼的非接不可. 在專案過程中或結案的時候，對於一些可能對成本影響的變更或要求，如果原堅持要接該專案的業務單位或決策主管能夠對客戶發揮影響力也就罷了，不然下場就是很悽慘的.

如果捨棄前面所說的人為因素，其實專案要做的好, 不管是一些標準或是 CMMI 提供的一些想法，對於專案成本是否可以不超支都有不錯的參考價值. 但有兩個因素可能可以使專案的成本可以比較好控制：
1. 要清楚的讓客戶知道並同意專案團隊預計管理專案與管理需求的方式.
- 專案團隊做得再好，如果客戶不認同，不跟著規矩走，那也沒意義了。
2. 最初的範圍可以越完整越好, 因為要讓客戶 buy in 專案團隊的專業以及技術成熟度, 但是成案的時候一定要縮小範圍, 將專案切成不同的階段來執行。

當然這只是建議(就像一些標準流程一樣)，如何將它真正的發揮出來，達到我們的目的，還是要看個人或是公司或是專案團隊的能力了.

----------------
Thanks

此外，(1)須對客戶之作業流程、資料使用及管理方法非常瞭解，即專案組員中須有Domain Expertise; (2)若以打零工的方式任何客戶皆來者不拒，或對客戶需求"想當然爾"也必難結案。

相信大多數的軟體專案經理都曾有這樣的經驗，那就是軟體專案總是無法如期、如質、如預算的執行完成 !

當軟體專案經理看完客戶RFP時，多半很難準確地估算專案的工期與人力需求，即使估算出了工期與人力，也常會在對客戶RFP不求甚解的情況下，忽視了許多的風險成本與品質成本，以及相關的罰則，以致於最後專案做下來，總是很少有賺到錢的。

這能怪罪於客戶嗎 ? 客戶嚴格要求難道是錯的嗎 ? 不，這完全應是專案經理的失職 ! (若客戶的RFP內容不合理或風險太大就不應承包，因為專案失敗的結局是兩敗俱傷)

因此，在此奉勸各位軟體專案經理們，拿到客戶RFP時，一定要仔細研讀分析，包括交付的內容、SOW(Statement of Works)、合約條款、品質或服務水準要求、相關的文件要求(系統分析文件、需求規格書、設計說明書、測試計畫及報告、使用手冊 ...)等等，千萬不可掉以輕心，現在時代已經不同了，若還抱著到時後再跟客戶硬ㄠ或矇混過關的心態，下場都會是很悽慘的 !