風險在所有的項目中都是存在的，在這些風險中有些是項目失敗的罪魁禍首，下面列舉五種最常見的，對項目的成敗有著巨大影響的風險。

1. 從一開始進度的安排就是錯誤的。

　　人們總是傾向于樂觀的估計，常常無視那些“可能需要作”的工作，盡管你可能對項目規(guī)模作了認真的估算，但是估算的結(jié)果仍可能太小，這也就直接導致進度的安排常常比應(yīng)有的更緊張，在這種情況下能夠產(chǎn)出的成果也很有限。但是人們常常被這種看上去激勵人的進度安排所蒙蔽，失去了對這項風險的警惕。

　　盡管對項目規(guī)模作完全的估算并不能保證進度的安排是準確的，但是起碼不會使它和實際相差太遠。對那些無法估算出的工作量作好準備能是你在風險出現(xiàn)時不至于手忙腳亂。

　　對于大型項目來說，進度安排失誤的風險比較小，因為大型項目一般都對項目規(guī)模作了大量的估算，再者，這樣的項目更有機會重新進行估算，調(diào)整進度。

2. 需求膨脹或變化。

　　從項目的角度來說，需求總是向著膨脹的方向發(fā)展，即使是去掉已有功能的要求也是一種膨脹，因為這增加了工作量。我們總要“擊中移動的目標”，那種在項目一開始就試圖將需求固定下來，不允許任何變動的想法無異于刻舟求劍。例如一個為期兩年的項目，可能在開發(fā)的過程中用戶的業(yè)務(wù)發(fā)生了變化，我們就必須對軟件作出相應(yīng)的改動。

　　我們需要有一個可以接受的變化的范圍，這樣在客戶要求變更需求的時候，我們能夠確定將增加多少工作量，對進度產(chǎn)生多大的影響，告訴客戶他將增加多少成本，得到什么樣的結(jié)果。

3. 項目人員流失。

　　常常會有成員在項目進行過程中離開，也許他沒有留下任何文檔，也許除了他沒有人掌握項目的某些細節(jié)，也許新人不能很快的掌握項目所需的知識。對付這項風險的最好的辦法就是留住團隊成員，人腦比任何文檔都精確，更高效。如果你不能作到這一點，就要讓知識在團隊中廣泛的傳播。而過去，我們總是認為有了足夠的文檔就可以使每個開發(fā)者都是可替換的。

4. 規(guī)約崩潰。

　　這種風險不同于其他幾種，它要么不發(fā)生，要么發(fā)生，直接導致項目失敗，不會對項目產(chǎn)生不同程度的影響。

　　在項目啟動的時候，雙方會坐在一起確定需求的范圍。如果在這個過程中大家談不攏，那么最好取消，這樣雙方都不會有什么損失。但是，這樣的情況很少發(fā)生，很多時候，雙方得到的是一個可以勉強接受的結(jié)果，于是項目帶著一個不明確的，含混的目標開始了。      

　　被掩蓋的問題雖然一時不會打擾你，但不會是永遠。當交付一個帶有缺陷，含糊不清的產(chǎn)品時，雙方付出的時間，金錢都已經(jīng)無法挽回，當任何一方已不再有耐心繼續(xù)下去時，項目就只有死路一條。也許這還是好的，更糟糕的是雙方在進行了多次的修改和談判后項目依然無法走出泥潭。當認識到“缺乏共識”是根本原因時，項目已經(jīng)無藥可救。

5. 生產(chǎn)效率低下。

　　開發(fā)者的工作效率存在著很大的差異。如果從團隊的角度看，這種差異將會有某種程度的弱化。很少情況下，這種風險會對項目產(chǎn)生致命的影響，更多的是對項目進度產(chǎn)生影響。

　　可以看到，在這五種風險中，真正和效率有關(guān)的只有第五種，而且，很明顯的，前面四種風險對項目產(chǎn)生的影響要大的多。所以，不能認為風險管理導致了低效率，而是認識到這些風險的存在，為這些不確定因素作好準備，預留好足夠的資源，真正敢于直面困難，而不是為自己的逃避尋找借口。