規(guī)避軟件項目投標風險的策略
軟件開發(fā)是一項高風險的活動,在項目開發(fā)過程中的任何一個階段都可能存在風險。但采取積極的風險管理策略,是可以使項目規(guī)避風險、轉(zhuǎn)移風險或緩解風險帶來的不利影響。因此,規(guī)避風險特別是規(guī)避投標風險更是軟件項目管理的第一要點和關鍵之處。
(1)樹立投標風險意識,建立風險管理體系
目前許多軟件企業(yè)的風險管理意識比較淡漠,往往是"等出了事情再說吧"的被動性管理。實際上,當缺乏主動風險管理意識時,是或多或少的都會給項目留下不同程度的隱患。因為風險無處不在,無時不有。為此,企業(yè)必須牢固樹立風險管理意識,把風險管理作為項目管理的重要內(nèi)容之一,要建立風險管理體系,以做好風險防范。特別是要明確在投標時應要對各種風險因素進行排查,做到知彼知己,百戰(zhàn)不殆。
?。?)根據(jù)風險評估流程,確定風險事件清單
這是軟件項目投標風險管理的核心一步,主要是指在投標前要把項目根據(jù)風險評估流程走一遍。把風險因素和事件影響按重要程度進行排序,主要包括以下兩個步驟:
?、購娀蛻粜枨蠓治雠c評審
客戶需求不明確是軟件開發(fā)過程中經(jīng)常遇到的問題。這類問題主要表現(xiàn)為需求范圍未界定、需求未細化、需求描述不清楚、需求遺漏和需求互相矛盾等多個方面。這類問題不但會導致需求變更頻繁,嚴重時更可能會導致雙方發(fā)生糾紛,必須要盡早盡可能的解決。因此,必須要強化客戶的需求分析與評審。例如,首先是要引起足夠的重視,并分配充足的時間和人力,要讓有經(jīng)驗的系統(tǒng)分析員負責,切忌讓新手或經(jīng)驗尚淺的人負責。其次,要進行需求評審,盡可能讓用戶參與需求評審,不要讓需求評審流于行式。
?、趶娀夹g方案的可行性評審
越是技術復雜度高的項目,就越應該盡早地處理技術可行性難題。因此,第一步就是要對投標風險進行識別。因為如果在項目中期或后期才發(fā)現(xiàn)技術上有問題或是關鍵技術難題不能解決,則為時已晚。因此,強化投標方案的技術可行性評審是減少投標風險的重要環(huán)節(jié)。技術評審可包括會議評審、專家評審和案例評審。在風險識別和評估的基礎上,根據(jù)項目的特點和企業(yè)自身能力以合同為依據(jù),建立《項目投標風險評估清單》。其實建立風險清單的過程也就是風險評估和分析的過程。例如,風險評估清單應該要包括發(fā)生概率的估量、風險損失大小的估量、風險影響的范圍估量等。最后,應該還要定量確定風險損失值的大小,并按照損失值的大小分為重大損失、中等損失和輕度損失。
(3)根據(jù)風險清單,建立應對措施
企業(yè)投標團隊在確定風險因素和風險事件排序后,應積極建立具體的應對措施來規(guī)避風險。具體應對措施如下:①風險規(guī)避:就是從根本上放棄使用有風險的資源、技術方案等,從而避開風險。如不投標價格過低或招標文件中有許多對投標商不利的條款的標,不提交或不采用不成熟的開發(fā)技術方案等。②制定化解自留風險的計劃:風險自留是指將風險留給自己承擔。但這種風險自留必須是主動的、有意識的、有計劃的選擇,是在經(jīng)過正確的風險識別和評估后做出的風險對策。 “軟件開發(fā)的項目管理是很重要,但規(guī)避項目的投標風險就更重要。”這一個月的折磨使我深刻的認識到這句話的真正含義。上月初公司委派我負責一個軟件項目的投標工作,一切的活動都按部就班,項目也正如我們期望一樣順利的簽約。但在本月項目要啟動時,才發(fā)現(xiàn)原來在項目中存在著許多風險和陷阱,在簽約的那一刻正是我們踏入泥潭的第一步。
這個軟件項目最初參與競標的公司很多,經(jīng)過層層篩選,最終只有三家公司回去做方案、做標書、做預算。在考慮到一旦投標失敗,就意味著全部的投入都會打了水漂。因此,我們從購買招標文件到編制預算、方案設計和制作標書都盡量以滿足客戶要求為準則。但沒有想到的是為了中標,我們忽視了風險的存在,結果現(xiàn)在是得不償失。本文與大家分享我們在這次軟件項目投標的風險管理總結和經(jīng)驗教訓。
一.什么是項目投標風險的規(guī)避
風險管理是項目管理公認的一個至關重要的組成部分。但是在這個項目啟動時遇到阻礙后,讓我們大為驚訝的是這次投標在風險管理上所得到的重視卻非常有限。而且,據(jù)我們了解目前風險管理在許多軟件項目投標中所扮演的角色大都也只停留在表面,這無疑是一件很危險的事情。原因是大多數(shù)項目經(jīng)理并沒有意識到有效的投標風險管理對于項目能否成功完成具有最重要的影響。有一句俗語說:如果在一個軟件項目中只能做一件事情,那么最應該做的事情就是投標的風險管理。因為務實、全面、主動地處理了投標風險,就掃清了項目的重要障礙。
(1)什么是投標風險的規(guī)避
軟件項目投標風險規(guī)避是指通過分析和預測軟件開發(fā)項目的風險而采取相應的風險規(guī)避措施和風險規(guī)避力度。簡單來說,就是指在軟件項目投標過程中設置幾道防線和采取必要的措施。因為如果我們不知道在投標過程中有哪些風險因素,我們就不能有效的防范。所以,風險規(guī)避的關鍵是要建立一張隨著投標進度不斷動態(tài)更新維護的風險清單(Risk List),并制定出防范其中所有主要風險的預案。
一般來說,投標風險分析可用定性和定量相結合的方法來分析風險的影響程度,例如先是列出風險影響程度的排序表,然后再一一對應采取相應的防范措施。常用的分析方法有如下三種:①層次分析法:是指采用主觀判斷與客觀分析相結合的方法,通過構造風險因素的遞階層次結構,把無法量化的風險按照大小順序。層次分析法的結論質(zhì)量取決于專家的知識經(jīng)驗和判斷。②調(diào)查和專家打分法:是一種主觀判斷法,其評價結果主要取決于專家打分的客觀性和評價標準的合理性。③模糊數(shù)學法:是把定性問題轉(zhuǎn)化為定量描述,用數(shù)學語言去分析和解決問題,增加評價結果的可靠性和科學性。
(2)規(guī)避投標風險的一般對策
投標風險管理對策是指對項目的投標風險進行識別、分析和評價后,風險管理人員根據(jù)風險的性質(zhì)及其潛在影響采取的防范與控制的措施。一般包括四種方法:①回避風險:指考慮到風險存在和發(fā)生的可能性,主動放棄、躲避可能發(fā)生的風險。但回避風險的同時也放棄了獲得收益的機會,例如放棄投標。②風險轉(zhuǎn)移:這是一種在風險不能回避的情況下,將風險部分或全部轉(zhuǎn)移給其它主體來承擔。方法可以是尋找第三方外包商通過簽訂合作方式將風險轉(zhuǎn)移。③風險緩解:是指努力降低風險發(fā)生的概率和一旦風險發(fā)生時努力降低其造成的損失。主要形式有風險分離、風險分散和風險抵消。④風險自留:是指將風險留給自己承擔,利用自身的管理水平與能力來控制風險。主要用于控制那些風險損失較小,開發(fā)團隊能夠承擔的風險。
二.常見的軟件項目投標風險分析
投標風險無處不在。這次項目給我們投標組的最大教訓是:“如果只想拿下項目而忽視了投標風險,那么只會得不償失。'在總結這次投標失誤經(jīng)驗時,我們發(fā)現(xiàn)軟件項目的投標風險主要有以下幾種:
(1)低價搶單心切,但中標反而得不償失
合理報價是軟件開發(fā)項目投標的一個重要部分,因為報價過高不能被客戶接受,但過低的報價則只會讓自己得不償失,而且過低的報價往往會埋下在項目驗收時和客戶發(fā)生糾紛的禍根。因此,只有既滿足客戶要求,同時又能滿足自身合理利潤的投標報價才會最大程度的減少投標風險。
(2)沒有準確理解需求,技術方案可行性差
一般來說,在投標時我們會根據(jù)客戶需求做出一個投標方案。因此,這個技術方案往往是根據(jù)客戶需求一一對應而設計的,還未真實確認能否在技術上完全實現(xiàn)和能滿足用戶的需求,而且在某些競爭激烈的投標中會有部份開發(fā)團隊會過度承諾。那么,這該怎么辦?在經(jīng)過反思和檢討后,我們認為可以用模擬測試這一方法來進行驗證。雖然對目前的這個項目已經(jīng)于事無補,但前事不忘,后事之師也。因為只要嚴格按照投標風險對投標的技術方案進行模擬測試的話,是有機會盡早發(fā)現(xiàn)問題的。
例如,模擬測試可以是繪制軟件需求視圖與風險范圍,如果投標團隊的成員沒有對要做的產(chǎn)品功能達成一個清晰的共識,則很可能沒有準確的理解客戶需求。因為當投標組的技術人員對需求有不同理解時,不但可能會帶來理解差異,也將會最終導致產(chǎn)品無法滿足客戶需求。而且,由于客戶一般只會強調(diào)產(chǎn)品的功能性要求,容易忽略非功能性的需求或有一些隱含的期望要求并未說明。因此,最好在項目投標時就寫一份項目技術視圖與風險范圍,全面的把客戶需求涵蓋在內(nèi)。
?。?)開發(fā)團隊是否具備開發(fā)能力
雖然在投標前,客戶都會有對投標企業(yè)資格預審的環(huán)節(jié),但作為投標企業(yè)還是需要衡量自身能否勝任項目要求,而不是只在資格文件上下功夫,或千方百計的體現(xiàn)出比其它競標人更能勝任這個開發(fā)項目。因此,在開發(fā)能力上投標企業(yè)必須要找到這個項目的技術困難特性,分析每項實現(xiàn)技術的可行性,以確定自身是否有能力按計劃開發(fā)。否則,一時意氣用事,過度承諾只會帶來后患無窮的隱憂。
?。?)投標時要考慮客戶的信譽程度
客戶信譽差,那么投標就等于是自己往火坑里跳,除非開發(fā)團隊有錢并愿意花時間與客戶去扯皮,但這已經(jīng)和以盈利為目的的投標意愿相差甚遠了。因此,在軟件項目投標前首先要對客戶進行考察。例如,客戶是否有投資此項目的經(jīng)濟實力,如果客戶根本沒有準備好預算資金來建設,那么這樣的標就沒有必要去投了。還有,還要審查客戶的付款辦法,因為付款辦法中規(guī)定了付款的比例、時間及付款的形式,這都需要在投標時仔細衡量墊資的可能性以及出現(xiàn)墊資情況的額度及時間,這必須要與開發(fā)團隊的流動資金進行權衡后,才能決定是否進行投標。
三.規(guī)避軟件項目投標風險的策略
軟件開發(fā)是一項高風險的活動,在項目開發(fā)過程中的任何一個階段都可能存在風險。但采取積極的風險管理策略,是可以使項目規(guī)避風險、轉(zhuǎn)移風險或緩解風險帶來的不利影響。因此,規(guī)避風險特別是規(guī)避投標風險更是軟件項目管理的第一要點和關鍵之處。
?。?)樹立投標風險意識,建立風險管理體系
目前許多軟件企業(yè)的風險管理意識比較淡漠,往往是"等出了事情再說吧"的被動性管理。實際上,當缺乏主動風險管理意識時,是或多或少的都會給項目留下不同程度的隱患。因為風險無處不在,無時不有。為此,企業(yè)必須牢固樹立風險管理意識,把風險管理作為項目管理的重要內(nèi)容之一,要建立風險管理體系,以做好風險防范。特別是要明確在投標時應要對各種風險因素進行排查,做到知彼知己,百戰(zhàn)不殆。
?。?)根據(jù)風險評估流程,確定風險事件清單
這是軟件項目投標風險管理的核心一步,主要是指在投標前要把項目根據(jù)風險評估流程走一遍。把風險因素和事件影響按重要程度進行排序,主要包括以下兩個步驟:
?、購娀蛻粜枨蠓治雠c評審
客戶需求不明確是軟件開發(fā)過程中經(jīng)常遇到的問題。這類問題主要表現(xiàn)為需求范圍未界定、需求未細化、需求描述不清楚、需求遺漏和需求互相矛盾等多個方面。這類問題不但會導致需求變更頻繁,嚴重時更可能會導致雙方發(fā)生糾紛,必須要盡早盡可能的解決。因此,必須要強化客戶的需求分析與評審。例如,首先是要引起足夠的重視,并分配充足的時間和人力,要讓有經(jīng)驗的系統(tǒng)分析員負責,切忌讓新手或經(jīng)驗尚淺的人負責。其次,要進行需求評審,盡可能讓用戶參與需求評審,不要讓需求評審流于行式。
②強化技術方案的可行性評審
越是技術復雜度高的項目,就越應該盡早地處理技術可行性難題。因此,第一步就是要對投標風險進行識別。因為如果在項目中期或后期才發(fā)現(xiàn)技術上有問題或是關鍵技術難題不能解決,則為時已晚。因此,強化投標方案的技術可行性評審是減少投標風險的重要環(huán)節(jié)。技術評審可包括會議評審、專家評審和案例評審。在風險識別和評估的基礎上,根據(jù)項目的特點和企業(yè)自身能力以合同為依據(jù),建立《項目投標風險評估清單》。其實建立風險清單的過程也就是風險評估和分析的過程。例如,風險評估清單應該要包括發(fā)生概率的估量、風險損失大小的估量、風險影響的范圍估量等。最后,應該還要定量確定風險損失值的大小,并按照損失值的大小分為重大損失、中等損失和輕度損失。
(3)根據(jù)風險清單,建立應對措施
企業(yè)投標團隊在確定風險因素和風險事件排序后,應積極建立具體的應對措施來規(guī)避風險。具體應對措施如下:①風險規(guī)避:就是從根本上放棄使用有風險的資源、技術方案等,從而避開風險。如不投標價格過低或招標文件中有許多對投標商不利的條款的標,不提交或不采用不成熟的開發(fā)技術方案等。②制定化解自留風險的計劃:風險自留是指將風險留給自己承擔。但這種風險自留必須是主動的、有意識的、有計劃的選擇,是在經(jīng)過正確的風險識別和評估后做出的風險對策。
(4)明確投標風險責任的控制和權限
最后,明確投標風險的責任也是關鍵一步。因為只有明確了風險控制的權限,在投標時才不會過度承諾,或在某些需要現(xiàn)場拍板的投標過程中不會意氣用事。因此,在對風險清單采取措施后,也需要時時對投標風險防患于未然,絕不能抱著僥幸心理。
溫馨提示:因考試政策、內(nèi)容不斷變化與調(diào)整,信管網(wǎng)網(wǎng)站提供的以上信息僅供參考,如有異議,請以權威部門公布的內(nèi)容為準!
信管網(wǎng)致力于為廣大信管從業(yè)人員、愛好者、大學生提供專業(yè)、高質(zhì)量的課程和服務,解決其考試證書、技能提升和就業(yè)的需求。
信管網(wǎng)軟考課程由信管網(wǎng)依托10年專業(yè)軟考教研傾力打造,官方教材參編作者和資深講師坐鎮(zhèn),通過深研歷年考試出題規(guī)律與考試大綱,深挖核心知識與高頻考點,為學員考試保駕護航。面授、直播&錄播,多種班型靈活學習,滿足不同學員考證需求,降低課程學習難度,使學習效果事半功倍。
發(fā)表評論 查看完整評論 | |