里程碑
1994年，美國Standish Group對于IT行業(yè)8400個項目（投資250億美元）的研究結(jié)果表明：項目總平均預(yù)算超出量為90％，進(jìn)度超出量為120％，項目總數(shù)的33％既超出預(yù)算，又推遲進(jìn)度，在大公司，有9％的項目按預(yù)算、按進(jìn)度完成。1999年系統(tǒng)分析員考試下午I試題的第一題也是類似的話題。
造成項目周期拖延或費(fèi)用超過預(yù)算的原因很多，但沒有好的階段和里程碑劃分無疑是其中最重要的原因。下面的圖可以形象地說明這一點(diǎn)：
圖中，項目的成功需要走很長的路程，從開始到成果完成之間并沒有現(xiàn)成的路可走（項目的一次性），如果項目經(jīng)理追求一步到位而不做階段劃分，因為距離目標(biāo)太遠(yuǎn)，難免走不少的彎路還不容易覺察（不好比對），當(dāng)感覺到偏離目標(biāo)的時候再進(jìn)行校正便走了很多的彎路，校正后可能又偏離到另外一個方向，同樣不易覺察，如此反復(fù)，便形成圖中這條藍(lán)色的軌跡。如果把項目的實施過程分為若干個階段，每個階段都有標(biāo)志性里程碑，那么，每個階段都有明確的目標(biāo)，雖然每個階段仍免不了走彎路，但由于目標(biāo)相對較近，不至于繞很大的彎子，這樣便形成圖中紅色的軌跡。顯然，這兩條軌跡的長度是不相同的，藍(lán)線比紅線要長出很多。這意味著什么？意味著前者比后者要多花很多費(fèi)用和時間！意味著項目費(fèi)用超出預(yù)算和進(jìn)度大大拖延！ 做項目的人很容易成為溫水里的青蛙，在不知不覺中被置于死地，要時刻警惕近期目標(biāo)不明的風(fēng)險。
◆ 過程評審
項目的過程評審是質(zhì)量保證的重要環(huán)節(jié)，一個很簡單的道理--質(zhì)量是做出來的而不是查出來的。以軟件項目為例，軟件的可靠性取決每個模塊的可靠性，模塊的可靠性在模塊的的概要設(shè)計、詳細(xì)設(shè)計、編碼、測試等環(huán)節(jié)鑄成。我認(rèn)為軟件項目需要項目組成員有最求完美的精神和聞過則喜的境界，因為軟件是人做的，人總有疏忽的時候，在開發(fā)過程中，即使追求完美做出的軟件還不可避免的存在缺陷，才勉強(qiáng)達(dá)到可以使用的水平；不用最求的精神開發(fā)的軟件，很可能就不能使用。
下面是一個軟件的缺陷產(chǎn)生階段、缺陷修改階段以及修改成本間的關(guān)系圖，圖中表明，缺陷被發(fā)現(xiàn)并修改越晚，修改的代價越高。需求分析階段造成的缺陷在產(chǎn)品發(fā)布后修改所要付出的代價是該問題在需求分析階段就能及時修改所付出代價的50－200倍！這僅僅是一個統(tǒng)計結(jié)果，實際上，有些損失再發(fā)布了以后是無法挽回的，Windows2000的沖擊波漏洞所造成的損失就是如此。
過程評審的意義就在于及時發(fā)現(xiàn)問題，及時糾正，階段評審不僅是為了保證質(zhì)量，還可以達(dá)到控制項目成本的作用。CMM二級就有一個關(guān)鍵過程域叫SPTO（Software Project Tracking and Oversight），強(qiáng)調(diào)過程的跟蹤與監(jiān)控，遺憾的是，不少開發(fā)人員認(rèn)為階段評審浪費(fèi)時間，草草了事，卻愿意花很多的時間修改BUG！華為公司規(guī)定在過程評審和代碼監(jiān)視中沒有評審發(fā)現(xiàn)的評審是無效評審，評審要重新進(jìn)行。
隨著市場的規(guī)范和業(yè)主的成熟，建筑項目的監(jiān)理制度也逐漸被IT項目所采納，這是社會的進(jìn)步，項目管理中稱為第三方項目管理。
項目經(jīng)理勝任力免費(fèi)測評PMQ上線啦！快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html
