項目風險管理案例分析

1、項目風險管理案例分析1 公司背景簡介河北 H-A 會計師事務所是河北省財政廳對國有大中型企業(yè)進行社會審計的試點所，承擔省直大中型企業(yè)的審計工作。 具有豐富工作經(jīng)驗， 擁有一批具有豐富實踐經(jīng)驗的注冊會計師。河北省某研究所是省直科研單位， 現(xiàn)有 50 多位員工。在基于 WINDOWS 平臺開發(fā)軟件方面，具備較豐富的實戰(zhàn)技能。河北 H-A 會計師事務所在審計工作中發(fā)現(xiàn)，很多企業(yè)都采用了會計電算化軟件， 對審計工作提出新的要求。 社會審計工作的需要， 對開發(fā)計算機輔助審計軟件的愿望越來越強烈。 所以就聯(lián)合河北省某研究所進行聯(lián)合開發(fā)2 實際項目分析項目介紹該系統(tǒng)基于 windows 和 sql serv

2、er 進行開發(fā)，開發(fā)工具是 powerbulider。項目開發(fā)過程中，共生成程序源代碼約數(shù)萬行， 項目開發(fā)的難度和源代碼行數(shù)都比預計的要多。計算機輔助審計軟件具有工作底稿制作能力和查證功能； 數(shù)據(jù)可傳遞，能自動生成和人工輸入相結合， 產(chǎn)生合并抵銷分錄； 能自動產(chǎn)生勾稽無誤的審計報告和會計報表附注；有靈活開放的系統(tǒng)，方便用戶進行二次開發(fā)等特點。開發(fā)隊伍的風險開發(fā)團隊維持在 10 人上下，事務所提供 3 人，開發(fā)單位 6-7 人，有一些人員只能部分時間工作，開發(fā)人員能夠自始至終地參加整個項目的工作。開發(fā)人員的流動基本能保證工作的連續(xù)性。技術風險數(shù)據(jù)結構復雜，關聯(lián)比較多。需要創(chuàng)建新的算法或輸入 ,輸

3、出技術；軟件需要與其他軟件產(chǎn)品的數(shù)據(jù)庫系統(tǒng)接口； 客戶能確定所要求的功能是可行的。 同時，由于當時審計軟件在國內(nèi)的應用尚處于起步階段， 開發(fā)人員普遍對該系統(tǒng)比較陌生，這也帶來了相當?shù)募夹g風險?？蛻粝嚓P風險用戶對自己真正的需求并不是十分明確，他們認為計算機是萬能的， 只要簡單的說說自己想干什么就是把需求說明白了，而對業(yè)務的規(guī)則、 工作流程卻不愿多談，也講不清楚。 有的用戶日常工作繁忙， 他們不愿意付出更多的時間和精力向分析人員講解業(yè)務， 這樣加大分析人員的工作難度和工作量，也可能導致因業(yè)務需求不足而使系統(tǒng)風險加大。項目按時完成的風險另外，這個項目也像許多其它軟件項目一樣，面臨著竣工日期帶來的巨大

4、壓力。3 實際的風險管理狀況憑借公司在以往的經(jīng)驗， 在此軟件項目的整個生命周期中， 任何階段都有可能有風險存在， WBS 是完整表示項目，且伴隨整個項目生命周期的項目要素，所以以 WBS 為基礎進行風險管理，既可以方便地識別，標識相應的風險來源，又方便和項日其他工作一起，統(tǒng)一管理。在軟件項目中，各階段主要工作簡述如下：啟動階段：進行項目預研， 以確定項目是否立項， 并對項目的范圍進行比較清晰的定義；計劃編制階段： 進行初步的需求分析， 詳細定義項目的范圍， 并對項目涉及的所有相關活動，做盡可能細的詳細計劃；執(zhí)行階段：詳細分析需求，保證軟件開發(fā)生命周期各階段中不同需求的來源是可追溯，并按需求進行

5、設計、編碼、測試，以確定軟件產(chǎn)品達到計劃給定的范圍和標準，并做相應的部署測試；控制階段：該階段貫穿計劃和執(zhí)行兩個階段，主要進行各種控制T 作，如需求變更、進度、費用控制等；收尾階段：項目的收尾工作，主要是安裝和維護；在軟件開發(fā)生命周期的四個主要階段中， 通過研究不同階段側重點不同的階段目標以及衡量不同階段目標的標準， 在軟件開發(fā)的各個階段中， 即需求分析階段、軟件設計階段、 編碼階段和測試階段， 我們可以發(fā)現(xiàn)存在于各階段中的風險項。并由項目經(jīng)理在啟動、計劃、執(zhí)行、控制、結束五個階段予以控制。需求分析階段、風險識別表 1 需求階段識別的主要風險、風險分析表 2 需求階段風險定性分析、風險解決表

6、3 需求階段風險解決方案設計階段、風險識別表 4 設計階段識別的主要風險、風險分析表 5 設計階段風險定性分析、風險解決表 6 設計階段風險解決方案4 實施效果與總結分析實施效果此項目開發(fā)的目標是為了向審計公司提供輔助審計管理系統(tǒng)。 開發(fā)流程也是比較遵從軟件工程的規(guī)范的。 但是最終的結果卻不盡人意， 投入了比預料多幾倍的人力物力。根據(jù)當時參與項目的同事的分析，失敗的原因主要是：、需求不明確由于出發(fā)點和利益不同， 系統(tǒng)開發(fā)者與用戶對于同一問題常有不同看法， 這樣需求分析的風險就逐漸加大了。 另外對需求變更的控制做得不好。 需求的改變，就會產(chǎn)生連鎖反應， 有時候這種反應會導致程序的不穩(wěn)定， 嚴重的

7、時候， 一個錯誤的修改引起另一處程序的錯誤， 而新的錯誤的修改會導致更新的錯誤， 更嚴重的情況，不是所有的錯誤都能被修改。、技術風險此軟件數(shù)據(jù)結構復雜， 邏輯關聯(lián)性比較強。 軟件需要與第三方財務軟件產(chǎn)品的數(shù)據(jù)庫系統(tǒng)接口。 帶來了相當?shù)募夹g開發(fā)困難， 阻礙了項目的進行。 由于以上原因到了測試階段， 未確定的需求和不斷發(fā)現(xiàn)的 bug 成了災難。結果測試當天就因為一個 bug 導致數(shù)據(jù)被誤刪和數(shù)據(jù)混亂。 于是暫停測試， 改為封閉式開發(fā)， 并且繼續(xù)增加人員， 第二次修改時是才發(fā)現(xiàn)整個數(shù)據(jù)結構也要發(fā)生變動， 這就意味著無異于從新開發(fā)一次，所以最后不得不投入大量的人員予以彌補。分析原因，為什么這個項目會失

8、??？看來好像是需求沒有做好，其實是沒有把風險放在整個項目這個大系統(tǒng)下來對待，沒有建立一套完整的風險管理機制，這樣一來風險因素就容易被忽略。然而，軟件項目前一階段的失誤會對下一階段產(chǎn)生嚴重的影響。一旦發(fā)生了變化，就不得不修改設計、重寫代碼、修改測試用例、調(diào)整項目計劃等等，為項目的正常的進展帶來不盡的麻煩。所以，沒有切實可行的風險管理過程機制， 就很難有效地保證風險管理活動的效率。建立切實可行的風險管理過程機制是軟件風險管理理論研究成果最終在實踐中得到應用的最根本保證軟件項目風險管理改進IT 項目管理從某種意義上講，就是風險管理。從理論上講，雖然 IT 項目風險管理開始于項目開發(fā)生命周期的可行性研究階段， 但實際上風險管理應該貫穿于項目的始終， 并需要持續(xù)的關注和評估。 因此實施項目風險管理就要建立風險管理機制，從制度上加以保障， 只有這樣才能夠及時識別風險并且能采取降低風險的好措施，從而減小 1T 項目的不確定性和偏差， 最終順利地把項目引向成功。根據(jù)實際情況， 也可通