風險在所有的專案中都是存在的，在這些風險中有些是專案失敗的罪魁禍首，下面列舉五種最常見的，對專案的成敗有著巨大影響的風險。
1. 從一開始進度的安排就是錯誤的。
人們總是傾向於樂觀的估計，常常無視那些「可能需要作」的工作，儘管你可能對專案規模作了認真的估算，但是估算的結果仍可能太小，這也就直接導致進度的安排常常比應有的更緊張，在這種情況下能夠產出的成果也很有限。但是人們常常被這種看上去激勵人的進度安排所蒙蔽，失去了對這項風險的警惕。
儘管對專案規模作完全的估算並不能保證進度的安排是準確的，但是起碼不會使它和實際相差太遠。對那些無法估算出的工作量作好準備能是你在風險出現時不至於手忙腳亂。
對於大型專案來說，進度安排失誤的風險比較小，因為大型專案一般都對專案規模作了大量的估算，再者，這樣的專案更有機會重新進行估算，調整進度。
2. 需求膨脹或變化。
從專案的角度來說，需求總是向著膨脹的方向發展，即使是去掉已有功能的要求也是一種膨脹，因為這增加了工作量。我們總要「擊中移動的目標」，那種在專案一開始就試圖將需求固定下來，不允許任何變動的想法無異於刻舟求劍。例如乙個為期兩年的專案，可能在開發的過程中使用者的業務發生了變化，我們就必須對軟體作出相應的改動。
我們需要有乙個可以接受的變化的範圍，這樣在客戶要求變更需求的時候，我們能夠確定將增加多少工作量，對進度產生多大的影響，告訴客戶他將增加多少成本，得到什麼樣的結果。
3. 專案人員流失。
常常會有成員在專案進行過程中離開，也許他沒有留下任何文件，也許除了他沒有人掌握專案的某些細節，也許新人不能很快的掌握專案所需的知識。對付這項風險的最好的辦法就是留住團隊成員，人腦比任何文件都精確，更高效。如果你不能作到這一點，就要讓知識在團隊中廣泛的傳播。而過去，我們總是認為有了足夠的文件就可以使每個開發者都是可替換的。
4. 規約崩潰。
這種風險不同於其他幾種，它要麼不發生，要麼發生，直接導致專案失敗，不會對專案產生不同程度的影響。
在專案啟動的時候，雙方會坐在一起確定需求的範圍。如果在這個過程中大家談不攏，那麼最好取消，這樣雙方都不會有什麼損失。但是，這樣的情況很少發生，很多時候，雙方得到的是乙個可以勉強接受的結果，於是專案帶著乙個不明確的，含混的目標開始了。
被掩蓋的問題雖然一時不會打擾你，但不會是永遠。當交付乙個帶有缺陷，含糊不清的產品時，雙方付出的時間，金錢都已經無法挽回，當任何一方已不再有耐心繼續下去時，專案就只有死路一條。也許這還是好的，更糟糕的是雙方在進行了多次的修改和談判後專案依然無法走出泥潭。當認識到「缺乏共識」是根本原因時，專案已經無藥可救。
5. 生產效率低下。
開發者的工作效率存在著很大的差異。如果從團隊的角度看，這種差異將會有某種程度的弱化。很少情況下，這種風險會對專案產生致命的影響，更多的是對專案進度產生影響。
可以看到，在這五種風險中，真正和效率有關的只有第五種，而且，很明顯的，前面四種風險對專案產生的影響要大的多。所以，不能認為風險管理導致了低效率，而是認識到這些風險的存在，為這些不確定因素作好準備，預留好足夠的資源，真正敢於直面困難，而不是為自己的逃避尋找藉口。
專案的風險分類
維度 事項 干係人終端使用者干係人沒有全程參與專案 干係人支援少的可憐或乾脆沒有，缺少專案的發起人 干係人需求不清晰 移交後，使用者干係人參與不主動 干係人使用不同的制度 模板 資訊管理系統 財務制度，它們彼此之間不相容 專案溝通和干係人溝通不足 商業論證 初始的商業論證經不起推敲 商業論證惡化 在...
專案的風險管理
即使天氣預報告訴我們明天是晴天，但也不能百分之百的保證一定豔陽高照，因為再精密的觀察與計算也會有發生意外的可能。同樣的，在乙個專案中，即使你本著豐富的經驗和周密的調查計算來制定了專案戰略，也不得不花費一些精力應對無法完全避開的專案風險。既然不能完全避免，那就只能將其對專案的影響降到最低，下面我們來看...
軟體專案風險
軟體專案風險是指在軟體開發過程中遇到的預算和進度等方面的問題以及這些問題對軟體專案的影響。軟體專案風險會影響專案計畫的實現，如果專案風險變成現實，就有可能影響專案的進度，增加專案的成本，甚至使軟體專案不能實現。如果對專案進行風險管理，就可以最大限度的減少風險的發生。但是，目前國內的軟體企業不太關心軟...