it项目管理硕士论文

工程硕士培养质量评估是保证和提高工程硕士培养教育质量的一个重要环节。下面是小编为大家整理的it项目管理硕士论文，供大家参考。

it项目管理硕士论文范文一：项目变更管理

【摘 要】

近年来，IT产业以惊人的速度发展，从而使软件产业的地位在经济发达国家提到了空前的高度。虽然软件产业在国内外得到了迅速发展，但是软件项目实施效果却不容乐观。调查分析表明，大约70%的软件项目超出预定开发周期，大型项目平均超出计划交付时间20%-50%，90%以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高。

软件项目失败的原因主要有以下三点：一是需求的不断变化。二是开发的软件不能满足用户的需求。三是软件项目的管理问题，这包括两个方面：一方面是因为缺乏完善的管理项目风险的方法;另一方面是由于软件项目规模的庞大，项目的范围难以精确确定，从而在项目开发的过程中范围不断变更，过程控制的力度不够，因此导致成本估计难以精确，进度控制困难，可靠性无法保证。 1 项目变更的基本概述

项目变更意为项目实施过程中，因各种原因导致原计划发生变动的行为。项目的建设或应用环境是在变化的，需求和目标也可能是变化的，因此项目本身也是变化的。不管项目在准备阶段的工作做的如何细致、全面，在项目实施过程中仍然会遇到各种预料之外的变化。同时，这些需求和要求的变更在项目进程中出现的越晚，对于项目实施来说就越困难，项目成本消耗可能就越高。如果能有效地控制项目的变更，那么项目最终就能在变化的环境中成功实现。

1.1引起项目变更的因素

项目变更主要目的是为了保证实现建设目标，但就国内目前信息化项目建设状况而言，随意变更的现象占了很大的比例，究其原因主要来自两方面，一方面是项目从启动到结束，要经过漫长的过程，中间受各种因素影响会发生多次变动行为，过多的变动往往会改变项目实施结果，使不确定性成为大概率事件;另一方面是参与建设的主体过多，业务与技术脱节，需求不明确导致建设阶段变更内容过多，这点在软件开发服务项目这种现象尤为突出，经常是在业务调研阶段需求内容很少，但当项目投入试运行后，反而个性化要求源源不断，因此造成项目被动的局面。

引起项目变动的原因呈多样性，若按其来源划分，大致可分成主观和客观因素两大类，前者来自项目主体，如应项目建设方或是承建方要求进行变更;后者则是因为项目实施环境或部分项目要素变化带来的影响。

IT项目中引起变更的因素有两个：一是来自外部的变更要求，如客户要求修改工作范围和需求等;二是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。比较而言，最难处理的是来自外部的需求变更，

因为IT项目需求变更的概率大、工作量也大，特别是到项目的后期。

1.2项目变更的生命周期

项目从开始就处于不停的变化中，用户需求变了需要调整计划或者设计;测试发现了问题需要对错误代码进行变更;甚至人员流失了，也需要项目进行一定的调整以适应这种情况。Bug管理，需求管理，风险控制等本质上都是项目变更的一种。它们都是为了保证项目在变化过程中始终处于可控状态，并随时可跟踪回溯到某个历史状态。孤立的看单个变更(CR)的生命周期，那么它是比较简单的，大致就是提出-审核-修改-确认这么一个过程。但变更管理并不是单纯的一个数据库记录，做个备忘而已。在这么一个简单的流程中，变更管理要能体现出它的两个重要用途，一个是控制变更，保证项目可控;另一个是变更度量分析，帮助组织提供自己的开发能力。如(图-1)

图-1 项目变更生命周期的基本过程

变更生命周期中的几个主要过程和这些过程的要求 ：

提出—记录变更的详细信息，相当于一个备忘。需要记录的信息可能根据不同组织和不同项目的规定而不同。要点在于变更提出者能简明扼要的记录下有价值的信息，比如缺陷发生时的环境，要变更的功能等。

审核—审核者首先要确认变更意义，确认是否要修改;其次审核者要确认变更可能产生的影响，根据影响分析决定是否要修改下变更的内容以及对项目其它方面做同步改变;最后就是指派项目成员实施该变更。

实施修改—根据变更要求进行修改。首先要保证修改实施是完全而彻底的，比如提了一个需求变更，不能只改了需求文档而不改代码或者用户文档。在组织分工情况下，如何协调多个小组的同步变更保证工作产品一致性正成为一个很严峻的问题。 实现变更的一个初始目的就是为了项目的跟踪回溯，那么，针对变更而做的修改也应该被记录下来并被和变更关联起来，实现why、what的双向跟踪。

确认—确认验证变更确实得到了确实实施。查询和度量分析—项目管理者需

要了解项目中各个变更的当前状态，根据变更状态做出各种管理决定;度量分析变更数据，了解项目质量状况;定期进行复盘，寻找变更根源，进行有针对性，甚至是制度化的改进。

2 项目范围的变更

项目中不可避免的会发生范围的变更，不论是在项目的开始阶段或是项目的将要结束阶段，都有可能会发生项目范围的变更，而项目范围的变更会自然而然地对项目有影响，所以，怎么样控制项目的范围变更是项目管理所需要做的一个重要内容。项目所处的阶段越早，项目不确定性就越大，项目调整或变更的可能性就越大，同时带来的代价比较低。但随着项目的进行，不确定性逐渐减小，而变更的代价、付出的人力、资源逐渐增加，就会增加决策的困难度。

在实际工作中，项目实施阶段的变更原因尽管很多，但这些原因和其他阶段工作皆有密切的关联，并非在实施阶段才产生的。因此，要控制或减少实施阶段的变更行为，必须要从每个阶段工作入手，尽可能减少变动因素，尽早排除隐患，使各阶段工作成果具有稳定性， 才能在实施阶段降低项目变更的可能性，实现项目建设可控管理。

2.1 IT项目范围变更原因

范围变更的表现形式多种多样，如客户临时改变对功能需求的想法、项目预算发生变化等。在IT项目中，这些需求范围变更可能来自方案服务方、客户或产品供应商，也可能来自项目组内部。分析各种项目需求变更的原因主要包括一下四点：

(1)范围没有明确就开始细化。范围细化一般是由需求分析人员根据用户提出的描述性的、总结性的需求进行功能的提取并给出相应的描述。如果对用户的需求不明确、需求分析工作不到位;使得需求范围没有明确就开始细化，当需求进入实施阶段需求范围发生变化，就需要作出很大的变动。

(2)系统实施时间过长。在项目漫长的实施过程中，客户由于自身业务发生变化或突然产生新的想法会不断地向项目提出新的需求，从而造成需求的变更最终影响到项目整体的范围。

(3)用户业务需求的改变。由于客户竞争激烈，运行情况不确定，需要随时对业务户环境变化做出反应，用户自然会经常提出变更的请求。

(4)系统正常升级。由于开发方自身版本升级、性能改进、设计调整等要求会产生需求变更。

2.2 范围变更控制管理过程

为执行变更控制，必须建立有效的范围变更流程，它对管好项目至关重要。一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的，因此变更是不可避免的，关键问题是如何对变更进行有效的控制。IT项目的生命周期分为启动、计划、实施控制和收尾5个过程。范围变更的控制不应该只是项目实施阶段考虑的事情，而是要分布在整个项目的生命周期。

范围变更控制是指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行动与教训总结。再好的计划也不可能做到一成不变，因此变更是不可避免的，关键问题是对变更进行有效的控制。其过程如(图-2)所示

图2 范围变更控制流程

在发生范围变更时，首先需要向变更控制委员会(SCCB)提交范围变更申请表。并记录变更请求的相关内容。

然后由控制委员会对范围变更进行相应的评估;SCCB需要对范围变更请求产生的原因进行分析，精确的理解用户需求;评估系统对范围变更的接纳程度、变更的代价、变更系统总体架构甚至是产品发展的影响。在范围变更分析中还需要进行需求范围稳定性的分析。过于频繁的范围变更项目进程已经超出了需求变化范围。

SCCB根据项目现有进度，进行项目范围变更进度影响、费用及项目可接受影响的程度;对项目变更排列优先级，对变更请求采取应对措施提出建议，记录风险和风险应对计划。同时与项目赞助人协商项目变更影响、解决变更请求的条件相应的费用变化以及项目赞助人可接受程度等问题，从而决定是否实施变更。

实施范围变更主要过程包括有追踪所有范围变更影响的工作产品、确定是否调整需求基线、维护范围变更记录文档，此外范围变更还需要进行验证，对于未通过验证将取消变更请求。

2.3 范围变更控制管理原则

(1)建立需求范围基线。需求范围基线是指是否允许用户需求变更的分界线，在软件开发过程中，需求确定并经过评审后，课件里第一个需求基线。随着项目的进展需求基线也在变化;此后每次变更经过评审后，都要重新确定新的需求基线。

(2)制定简单有效的变更控制流程，并形成文档。在建立了需求基线后，提出的所有变更都必须遵循这个控制流程;同时，着个流程具有一定的普遍性，对以后的IT项目开发和其他项目都有借鉴意义。p副标题e

(3)成立项目变更控制委员会(SCCB)或具体相关职能的类似组织，负责裁定接受那些变更。

(4)需求变更一定要先申请然后在变更，最后经过与变更级别相当的评审确认

(5)需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保证和更新的需求一致。

(6)妥善保存变更产生的文档。

3 变更管理的控制与实施

变更控制不能仅在过程中靠流程控制，有效的方法是在事前明确定义。事前控制的一种方法是在项目开始前明确定义工作范围;否则“变化”也无从谈起。另一种方法是评审，特别是对需求进行评审，这往往是项目成败的关键。需求评审的目的不仅是“确认”，更重要的是找出不正确的地方并进行修改，使其尽量接近“真实”需求。另外，需求通过正式评审后应作为重要基线，从此之后即开始对需求变更进行控制。

变更控制主要任务包括：分析变更的必要性和合理性;确定是否实施变更; 记录变更信息，填写变更控制单;做出更改，并交上级审批;修改相应的软件配置项(基线)，确立新的版本;评审后发布新版本。

3.1 控制IT项目变更的基本措施

进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。为保证变更的规范和有效实施，通常项目组织会采取以下措施

(1)项目启动阶段的需求范围便跟预防

(2)项目实施阶段的需求范围变更

(3)项目收尾阶段的总结

3.2 变更管理流程

变更管理流程通过标准统一的方法和步骤来管理和控制所有对IT生产环境有影响的变更。其主要作用是安全、快速响应用户需求的变化、通过对所有变更的正确评估，可以维护IT生产环境的完整性、变更和变更实施得到正确记录，并提供审核统计、减少或消除由于变更实施准备不当等原因出现的对IT环境的破坏作用、提高资源使用率等。

变更管理流程始于变更的接收，结束于变更的实施和回顾。变更控制流程主要包括四个关键控制点：授权、审核、评估、确认。在变更过程中要跟踪和验证，确保变更被正确执行。变更控制流程(图3)

(1)提出RFC、评估、分类

变更申请人提出RFC，由变更主管负责检查和完善其内容，通过查询配置管理数据库，进行风险等级的初步评估;并尽量提出可能与业务发生的关联的影响，已供决策参考。变更主管并对变更进行分类;如为紧急变更，则按照紧急变更子流程执行;如为简单变更，直接制定变更计划，并安排实施。

(2) 变更主管负责组织制定变更计划、测试

变更主管安排并协调相应资源制定变更计划，包括实施计划、测试计划、回退计划、配置项更新计划等。应安排对实施计划和回退计划进行测试，随后将测试结果、实施计划、回退计划、配置项更新计划等提交给变更经理审核

(3) 变更经理评估、审批

变更经理接受RFC，如果确定是紧急变更，则快速完成评估、审批。对标准变更，确定变更风险等级，审阅变更实施计划、测试报告、回退计划和配置项更新计划，批准或驳回变更申请，如需要更高级别管理层的审批，则根据不同风险级别报批。

(4) 变更控制委员会(CCB)/紧急变更委员会(EC)评估、审批

变更经理将根据特定的变更请求成立特定的CCB/EC，成员包括对该变更的评估和批准提供应有附加价值的技术人员和管理人员，审阅工作包括变更的风险、对现有服务的影响、实施计划、回退计划和配置项更新计划等，并做出批准与否的决定。如为紧急变更，则快速完成以上评估、审批。

(5)管理层审批

对于风险等级为“重大”的变更，在变更委员会审批通过后，必须再由变更经理报请至管理层审批。

(6) 协调变更实施

变更主管负责协调资源，准备实施前相关工作，组织人员按计划实施变更，变更主管监控实施过程和结果，并在必要时进行协调或做出决定。在这阶段可能需要变更经理和变更委员会成员的帮助。

(7)回顾和关闭

实施变更后，变更主管确保配置项及时得到更新，并协同变更经理负责从技术、管理、业务角度去回顾变更，确保RFC得到了预期效果，并寻找改进机会或行动计划，在回顾过程中可能会需要得到变更委员会中相关领域的技术人员的帮助，随后更新变更记录并关闭RFC。

图3 项目变更控制流程

3.3 项目变更管理案例分析

在一个正在实施的系统集成项目中出现了下述情况：一个系统的用户向他所认识的一个项目开发人员抱怨系统软件中的一项功能问题，并且表示希望能够进行修改。于是，该开发人员就直接对系统软件进行了修改，解决了该项功能问题。

变更来源有两个方面，一是用户—信息系统项目需求的提出者。要求用户一次性地把需求讲清楚，并且不允许此后做任何变更，这是不现实的，开发方只能尽力减少变更，降低其影响。开发人员如何解决好自己的工作产品与变更的用户需求之间的一致性，是CMM2级需求管理这个关键过程域的主要目标。变更来源的另一个方面来自开发人员自身;在工作中可能发现前期工作中有些不妥当的地方，便要修改已经确定了的设计方案或是设计的细节。

存在的问题及可能产生的后果：

(1)对用户的要求未进行记录;缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握。

(2)对变更请求未进行足够的分析，也没有获得批准;缺乏对变更请求的分析可能会导致后期的变更工作出现工作缺失、与其他工作不一致等问题，对项目的进度、成本、质量方面也会产生一定影响。

(3)在修改过程中没有注意进行版本管理;在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原，造成成本损耗和进度拖延;另一方面，对于组织财富和经验的积累也是不利的。

(4)修改完成后未进行验证;修改完成后不进行验证则难以确认变更是否正确实现，为变更付出的工作量也无法得到承认。

(5)修改的内容未和项目干系人进行沟通。未与项目干系人进行沟通可能

会导致项目干系人的工作之间出现不一致之处，进而影响项目的整体质量。

【结束语】

变更管理对IT行业而言是一个关键的控制过程。它绝不是一个用于满足监管机构官僚控制的程序，事实证明对所有组织而言它都是有好处的，包括提高可用性、降低成本、服从管理、减少安全漏洞等。

在实际工作中，项目实施阶段的变更原因尽管很多，但这些原因和其他阶段工作皆有密切的关联，并非在实施阶段才产生的。因此，要控制或减少实施阶段的变更行为，必须要从每个阶段工作入手，尽可能减少变动因素，尽早排除隐患，使各阶段工作成果具有稳定性， 才能在实施阶段降低项目变更的可能性，实现项目建设可控管理。

对于软件开发项目来说，开发的过程中不可避免的会出现范围变更，发生变更的环节也比较多，因此变更控制显得格外重要。变更控制对项目成败有直接影响，项目开发之前要明确定义范围，开发过程中要严格控制范围。对变更控制的目的并不是控制变更的发生，而是对变更进行管理，以便更好的处理变更，确保变更朝着有利于项目成功的方向有序进行。

参考文献

[1]蒋国瑞.等编著IT项目管理(第2版).电子工业出版社.5

[2]罗伯特格拉斯，陈河南等译.软件开发的滑铁卢[M].北京：电子工业出版社，

[3]方德英，李敏强.信息系统项目监理机制的经济学分析[J].管理工程学报，(4):98-102

[4](美)凯西?施瓦尔贝，邓世忠等 译.IT项目管理(原书第2版)[M]. 北京：机械工业出版社，.11

[5] Davidnim.项目范围管理是项目成败的关键

it项目管理硕士论文范文二：IT项目管理风险探讨

【摘要】当前我国企业IT项目管理风险方面缺乏有效的控制手段，更多的时候是通过主观臆断和经验来控制项目风险，传统的项目风险控制方法显得捉襟见肘。为此论文试图探讨适合我国企业的，有效IT项目管理中的风险管理方法，以期为同行提供借鉴和参考。

【关键词】IT;项目管理;风险;探讨

一、引言

虽然现实生活中，项目风险管理失误而导致的IT项目失败的现象较为普遍，但是在很长一段时间内一直未受到人们的重视。其主要原因在于IT行业平均利润率远远高出传统行业，即使IT行业内存在巨大问题，但是也能保证盈利，从而使很多企业迷惑，甚至忽视了风险管理的重要性。IT项目风险是指由于IT项目所处环境和条件的不确定性，导致项目的最终结果与我们的期望产生背离，并给相关人带来损失的可能性。而所谓IT项目风险管理是对项目中潜在的风险进行预测并实行有效的控制，从而可靠地实现项目的总体目标的一种管理IT项目管理。

随着科学技术的进步、经济全球化进一步发展、IT行业的竞争日益激烈等等原因，使得企业不得不重视起IT项目的风险管理问题。

二、IT项目管理风险的来源分析

IT项目的风险越来越受到企业的重视，因此深入分析项目风险的来源，为采取有效措施控制项目风险奠定基础显得尤为重要。一般而言，IT项目风险主要来源于以下几个方面：

(一)系统风险

IT 行业发展迅速，产品更新速度快。IT行业是未来的朝阳行业，根本原因在于这个行业出现的时间不长但它的发展却非常迅速。所以IT项目必然会不断遇到新标准和新的发展趋势。并且同时，IT 行业内的竞争与合作也不断改变着 IT 企业或企业联盟的战略和竞争优势，从而影响 IT 项目的发展进程。

(二)技术风险

1、技术成熟度不够

在一个项目里，使用的技术种类越少越好，因为这样可以保证技术的稳定和成熟。无论如何，对我们来说，新的技术都是未知的，它们未必能像我们期望的那样发挥作用。

2、开发与管理工具选择不适合

开发和管理工具的选择对于IT项目有着非常的意义。一方面，正确的选择开发和管理工具有助于IT项目顺利的推进，另一方面，选择合适的开发和管理工具，可以减少再次开发同时缩短实施周期。

3、项目测试不缜密

在验收性测试中，这却是常常发生的事，因为一直到这个时刻，完整的方案才被集成在一起，实际的业务场景到了这个时候才第一次被放到方案里去执行。在测试里发现的堆积如山的问题中，其实很难把真正的缺陷找出来。当背负着这些包袱开始新的返工周期时，对抗的心态又会出现：方案供应商总是“带罪羔羊”。然而，只有在详尽的测试案例执行完成以后，功能修改的巨大任务负担才会完整地呈现出来。

(三)成本风险

1、IT项目运营成本存在不可预知性

一个实施成功的IT项目就会有比较少的后期维护成本。但通常在IT项目实施过程中的干扰因素非常多，项目的变更也时常出现，使得项目的执行结果通常与预期有着较大的偏差，这样就给后期的维护工作带来很多麻烦.而且一些新型的项目在实际的使用过程中通常会出现预先没有料到的问题，维护工作相当复杂，费用也就居高不下。

2、项目范围的变更，导致成本上升

多数的 IT 项目通常只有开始具体实施时，才能够通过详细的调研发现客户的真实需要，可能会出现与原先的设想出入很大的情况，因而项目就不得不进行变更。项目变更后，其成本范围就超出了原先的项目计划和预算，这样很不利于项目的整体控制，因此而产生沟通、协调费用.甚至项目返工等风险，都给成本的控制增加了难度，从而大大增加了项目的总成本。

(四)进度风险

1、项目进度估计不精确

进度管理作为 IT 项目管理中及其重要的一环，但估计项目进度与估算项目成本同样都是前瞻性的工作，所以出现估计项目进度不精确也是项目管理中经常碰到的难题。

2、资源短缺或变更导致项目进度拖延

资源，最主要的是人力资源。有时会出现某方面的人员不够或者在多个项目的情况下某部门的人员中途被抽到其他项目或身兼多个项目的局面，而对进度造成影响;同时预算的变更会影响到某些资源的变更，也会对进度造成影响。

(五)运营风险

1、对项目认识和理解不充分

IT 项目开发者和项目业主之间沟通的一个要点就是要做出一份详尽的计划，从而避免在项目认识和观点理解上的冲突，以较好地协调项目认识和冲突。

2、未合理授权

在 IT 项目开始之前，项目团队的每一个角色都必须明确下来，并为每个角色找到最合适的人。要用既明确无误又容易理解和接受的方式告诉每一个成员，他(她)担当什么角色，这个角色的涵义是什么。非常重要角色同其他项目组成员之间的关系在团队内部必须作出正式的说明。防止造成由于授权不合理造成管理模糊之处，而造成项目管理的混乱。

3、沟通不畅

IT 项目管理中，项目组内部需要以规范形式进行管理信息的沟通，因为这可使各个管理层能直接、有效地了解项目情况。在项目持续的过程里，规范的沟通确实非常重要。但是，我们还要明确，沟通并不是单向的，如果有新的信息出现，那么就应该让全体成员及时了解，以免造成巨大的损失。

三、控制IT项目管理风险的对策

市场经济环境下，各个行业都会遇到各种各样的风险，对于IT项目而言也如此，如何在具体运营过程中，准确把握项目风险行动路径，然后根据具体步骤，制定科学合理的方法减少和消除风险。此外我们还要考虑管理成本，防止避免风险产生的成本远远超过风险实际发生时的成本。我们可以通过以下途径来控制应付各种IT项目风险，具体如下： (一)选择适合的项目经理

在 IT 行业里面，随着具有项目经理头衔的人日益增加，取得 PMP(Project Management Professional，项目管理师)证书的人也逐步增多，但使得项目管理达到最终目标的人才却非常稀少。所以选择什么样的项目经理更加适合于企业的真正需求就越加重要，同时对于一个 IT 项目的风险管理也日益突出。一般来说，从四个方面来进行考虑与评判：知识、经验、能力和性格。在这里需要特别强调对行业的了解，不仅是对 IT 行业的深入了解，而且还需要对其他行业的经营理念也有所相关认识。知识掌握得是否牢固，是否全面，是否应用自如，最终决定着项目经理的水平和水准。在项目开发中，项目经理要对风险管理负责人阐述潜在风险和管理风险并起着重要的参谋作用，并且也要让所有涉及到项目开发的人员关心和关注风险问题，所以选择适合的项目经理是成功的关键因素之一。

(二)建立风险管理计划

IT 项目的风险管理作为项目管理的一部分，需要形成一个完善的和全面的风险管理计划。应包含四个阶段：风险识别、建立风险物化结果、理解风险形成的驱动因素、以尽量减少风险，达成共识。按照上述的风险分类方式，运用聚焦的方法，提出相应的风险问题，进一步形成项目的风险评估问卷，这有利于帮助风险管理负责人考虑主要风险或目前存在的相关风险。然后进行检查风险物化后的结果或问题，它为规避风险提供指导，其次要进行全面检查风险的驱动因素。如果能理解好这些因素，那么在风险管理方面，风险管理负责人就可以能够在预防和避免风险方面发挥出重要的作用，最后根据上述步骤建立和实施适当的行动方法和方案。在这个过程中，应注意避免风险而造成的成本不能超过解决风险物化后造成的结果成本。

(三)对项目参与人员进行业务培训

由于参与者对相关业务不熟悉或不完全理解而构成业务风险中很大一部分，尤其是项目经理。因此，有必要在 IT 项目实施之前对他们进行必要的业务培训，使参与者能够对业务流程有充分的理解，并有必要安排考核的方式和方法，进而组成精干的开发团队。

(四)建立定期风险审查的审计计划

IT 项目的风险管理过程中会面对各种不同的风险管理环境。所以，除检查风险管理计划以外，定期检查或审计风险水平也是非常重要的。在国外 IT 项目开发中普遍使用风险评估和审查技术来做此项工作，这样便可以在进行项目风险分析时为项目管理人员提供一整套有效的方法和措施。

参考文献：

[1] 禹莉.基于实物期权的BOT项目风险分析及管理研究[D].西南交通大学

[2]吕斌.海洋工程项目的风险管理研究[J].中小企业管理与科技(上旬刊).(01)

[3]甘华鸣主编.项目管理[M].中国国际广播出版社，

[4]李圣凤，李新碗.IT新产品研发项目中的风险管理[J].项目管理技术.(05)

[5]李辉，张爽.IT项目管理者行为风险的四种情形及其应对研究[J].现代制造工程.(03)