論文常用來指進行各個學術領域的研究和描述學術研究成果的文章，它既是探討問題進行學術研究的一種手段，又是描述學術研究成果進行學術交流的一種工具。以下是小編爲大家精心蒐集和整理的it項目風險管理論文，希望大家喜歡!
“風險”一詞的由來，最爲普遍的一種說法是，在遠古時期，以打魚捕撈爲生的漁民們，每次出海前都要祈禱，祈求神靈保佑自己能夠平安歸來，其中主要的祈禱內容就是讓神靈保佑自己在出海時能夠風平浪靜、滿載而歸。在長期的捕撈實踐中，他們深深地體會到“風”帶來的無法預測的危險，認識到，“風”即意味着“險”，因此有了“風險”一詞的由來。
現在，風險一詞的意義，已大大超越了“遇到危險”的狹義含義，而是“遇到破壞或損失的機會或危險”。經過了兩百多年的演義，風險一詞越來越被概念化，並隨着人類活動的複雜性和深刻性而逐步深化，被賦予了從哲學、經濟學、社會學、統計學甚至文化藝術領域的更廣泛更深層次的含義。不管如何定義風險一詞的由來，其基本的核心含義是“未來結果的不確定性或損失”，也有人進一步定義爲“個人和羣體在未來遇到傷害的可能性以及對這種可能性的判斷與認知”。
一、風險的定義
風險有兩種定義：一種定義強調了風險表現爲不確定性；而另一種定義則強調風險表現爲損失的不確定性。
若風險表現爲不確定性，說明風險產生的結果可能帶來損失、獲利或是無損失也無獲利，屬於廣義風險，金融風險屬於此類。而風險表現爲損失的不確定性，說明風險只能表現出損失，沒有從風險中獲利的可能性，屬於狹義風險。
廣義的風險展現出來的是機會，雖然這種機會可能讓我們的項目變得顆粒無收，但如果一旦機會有利於項目，則可以大賺一筆，風險投資家們心中的風險正是廣義的風險，所以風險纔會吸引他們投入巨大的資金。而作爲項目管理者來說，風險對他們意味着失敗的危險，因此必須將任何風險扼殺於搖籃之中。
二、IT項目風險的特徵
由於軟件本身的特點，導致IT項目與傳統項目有很大差異，因此IT項目的風險管理難度要比傳統項目大。
1.需求不穩定
軟件項目的需求多變已成爲軟件業界的共識，正因爲需求的多變，才讓瀑布模型一直遭受到軟件工程界的抨擊，因此誕生了原形模型。在IBM的RUP和衆多的敏捷方法論中，一直將需求不確定列爲軟件項目的最大特點，因而出現了擁抱變化一說。
當一個IT項目開始實施的時候，如果客戶連他需要做什麼，要實現一些什麼功能都不能確定的話，那麼做軟件實施的工程師他們又如何能夠知道自己要開發一個什麼樣的軟件系統出來呢？所以他們只有在漫長的等待過程中，不斷遭受到客戶的“批評”，在經歷了“九九八十一次磨難”之後，才恍然大悟，原來就是要做一個這樣的系統啊！
這有點像盲人走路一樣，盲人根本就不知道前面是什麼，因此他往前走一小步，如果不是路，則向左旋轉一點點，再次用腳探探前面，如果是路的話，則可以往前邁一步。如果這個盲人運氣不好的話，第一腳就在懸崖邊上踏空，那麼他將跌入萬劫不復的深淵。我們的項目也如同這個盲人，稍有不慎就可能讓自己走向失敗，這是一個多麼大的風險啊。
2.項目規模估計不準確
當老師給我們佈置作業的時候，如果他多佈置了幾個題目，下面的同學便會大聲地噓嘆，開始私下的嘟嚕：“又要做一個多小時了！”。學生們在很短的時間內就能夠準確的估計作業量大不大，他們的估計憑藉着他們每天一次的做作業的經驗和那一瞬間對題目的印象，雖然他們並沒有做過剛佈置的這些題目，但是估計得仍然是那麼的準確。
任何一個建築工程的項目經理都能對自己的項目進度掌握準確，在他們的眼中，只要資金到位，則進度就可以得到保證。工地需要多少人，什麼時候需要開始進行什麼工序的施工，什麼時候需要加班，這些都在他們的心中掌握着。資金就是他們最大的風險。
而軟件項目與之不同，在軟件項目開始後，很少有缺錢的。只看到過資金沒有到位的“爛尾樓”，但是從來沒有看到過由於項目資金沒有到位的問題而導致未完成的軟件項目，就算是缺錢也是因爲籤合同的時候要少了。
再優秀的軟件項目經理，他也無法預計好自己的`項目什麼時候能夠完成，因爲在他進行估算的時候，客戶的需求還沒有搞清楚呢！再者，建築工程可以透過預算很準確地得出整個建築的工程造價，而軟件項目卻很難，因爲不管是代碼行估算法，還是功能點方法，都遠不及“我猜，我猜，我猜猜猜”中猜得準確，這些方法很多時候甚至不如算命先生算得準。
3.人的因素對項目影響很大
人可以說是整個軟件項目的靈魂，軟件項目不需要鋼筋、水泥和沙石，也不需要任何的施工機械。軟件項目的原材料就是人的思想和智慧，而計算機和CASE軟件則是項目的施工工具。透過鍵盤和鼠標，無數的程序代碼在程序員手中誕生了。如果要問軟件項目最大的成本在哪裏，那麼答案只有一個，就是人力成本。
一個優秀的程序員的工作效率要遠遠高於一個蹩腳的程序員，一個程序新手甚至根本就不能夠產生任何生產效率。不僅如此，新手的錯誤行爲，將讓熟練員工犧牲很多時間來幫助新手糾正他們的錯誤，甚至可能導致降低軟件開發的效率。
雖然軟件項目已經實施角色分工和管理，但是相對於其他工程的分工來說則分工比較單一。軟件項目中，一般分有：系統分析師、架構師、設計師、程序員、測試工程是及配置管理人員和項目經理等。這樣的分工並不能有效地降低他們工作內容的複雜度。如果能像建築工程中的砌牆、澆注混凝土、搭腳手架那樣分工細緻的話，則培訓軟件藍領也不會需要費如此大的力氣了。
三、古語話，唯有小心，小心駛得萬年船
經常可以見到有人不小心，踩到或者碰到什麼東西而摔倒的情況。相反，盲人卻很少會因爲自己的疏忽而摔倒。他們總是很小心的走着每半步路，對於前面的未知世界，他們總是要探了又探，在確認能夠行走的情況下，才小心的邁出半步。
由於軟件項目的太多不可確定性，因此管理軟件項目，猶如盲人走路一般。在未來還不確定的情況下，可以將自己的經驗列出來，如在什麼時候最可能出現什麼風險。盲人在聽到汽車聲音的時候，總是會更加小心，當軟件項目中開始出現一些問題的時候，我們需要考慮這些問題背後所隱藏着的更深的威脅。發現危險總是需要憑藉自己的靈敏的直覺與豐富的經驗。
聰明的經營者，絕對不會是技術方面的專家，越是技術專家，就越不能容忍技術方面的缺陷。而經營者所需要考慮的不是技術是否無可挑剔，而是在乎項目是否盈利，讓別人去承擔風險，讓自己來享受利潤，是聰明的經營者的決策指南。