程的專業(yè)人員)并非上策。給一個失控的項目增加人員如同“火上澆油”。
2.風險管理的正式程度
正式性不僅是指要編制許多正式文件，它的關鍵內(nèi)涵是結構，理解這一點有助于我們有效利用時間。風險管理過程的效果很大程度上取決于它提出正確問題的能力，而正式性、規(guī)范化正是為了解決這個問題而提出來的。
3.風險管理的組織
高級管理層的支持，對于發(fā)揮風險管理過程的作用非常重要。風險管理過程應該反映高級管理層的需求和關注。所有相關經(jīng)理人員，尤其是項目經(jīng)理需要在早期階段介入，保證相關的風險管理過程納入到項目管理過程中去。理想的情況是在這個階段任命項目經(jīng)理，讓他能夠積極參與到這些任務中，在更加詳細的設計與計劃階段之前確立風險管理過程的概念并闡明其作用。更多人員參與到任務中很有好處，這些人員包括組織職能部門中的個人、主要客戶、主要承包商或分包商、潛在的合作伙伴以及設計和引入風險管理過程的顧問。
而在這次項目實施過程中，我們應該從以下幾個方面進行風險管理的改進：
1、時間管控方面尚欠經(jīng)驗。在項目開發(fā)中為防止項目意外事件而導致拖延，故：
項目所需時間=項目預計時間*x (2<x<3)
本項目由于沒有作出此時間管控，而導致在項目意外時無法按時完成項目。
2、與客戶聯(lián)系不夠。雖然在前期中頻繁聯(lián)系客戶，也給客戶留下比較好的印象，但在后期中就很少聯(lián)系客戶了，不能及時讓客戶了解項目進行的情況。
3、本項目采用的新技術比較多，在既要學習新技術又要開發(fā)項目的時候，質量難以保證。今后如涉及的新技術比較多的話，應爭取更多的開發(fā)時間以保證項目質量；如項目比較急，應采用項目組比較熟悉的技術。
4、數(shù)據(jù)庫設計是比較關鍵的一點，若設計不當，將為后來的業(yè)務層編寫中帶來許多問題。故前期因對數(shù)據(jù)庫作充分的設計。
5、項目開發(fā)規(guī)范不足。如信息異常處理頁面跳轉方面不統(tǒng)一，格式化驗證不統(tǒng)一，Ation層編寫不統(tǒng)一，數(shù)據(jù)庫連接統(tǒng)一，頁面結構風格不統(tǒng)一。這些不僅影響了開發(fā)進的，同時也影響了系統(tǒng)的使用性與美觀。在今后的開發(fā)中因制定開發(fā)規(guī)范。
6、項目開發(fā)前期項目組人員未能靈活運用VSS，導致項目組人員頻頻下載新版本后都要對項目進行一些代碼的屏蔽才能夠進行自身代碼的測試。經(jīng)過幾個月的VSS使用，組員已經(jīng)可以很好的使用VSS，也增加了些默契。
7、項目服務器上需要人工進行項目更新，若是項目組修復了BUG而未去更新服務器的話，而BUGFREE上又標記了修復，測試公司在服務器上看見該BUG未改會誤會我們忽略該BUG。這種情況經(jīng)常發(fā)生，也給我們和測試公司帶來麻煩。在今后開發(fā)中，服務器因安裝類似ANT 這種自動編譯以保證服務器最新的項目版本。
8、每周一的項目會議效果比較好，不僅讓組員了解整個項目的進度，也促進了人員之間的交流，讓大家一起討論項目中的問題與分享各自的成果、技術與看法。這種做法應繼續(xù)維持下去。
9、項目組人員坐在一起開發(fā)效率遠比各自在宿舍開發(fā)要高，特別是在星期六日，因其聚的時間比較長，故開發(fā)的時候應盡量坐在一起。
通過這次項目，使我認識到，如果不實施正式的風險管理過程，使之成為項目管理的一個常規(guī)方面，就無異于“商業(yè)自殺行為”。日益加劇的競爭，更加挑剔的顧客、技術開發(fā)和其他變革速度的加快、商業(yè)機會日益增加的復雜性和新奇性，都對管理的不確定性和項目風險系統(tǒng)的成功提出了更高的要求。如果等到“觸發(fā)事件”(如主要項目的商業(yè)手段失誤或未能贏得主要合同)出現(xiàn)以后才接受這些信息，就太令人遺憾了。