IT管理项目论文

IT管理项目论文（共12篇）

IT管理项目论文 篇1

随着信息技术的飞速发展, IT企业作为推动信息技术发展的重要力量, 其地位在经济发达国家提到了空前的高度, 但经调查研究发现, IT企业项目 (以下简称IT项目) 的成功率不高、项目实施效果不容乐观。影响IT项目成功因素有很多, 但项目范围管理的失控是主要原因之一, 在实践中, “需求蔓延”是导致IT项目范围管理失控最常见的因素, IT项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能, 从而使项目在时间、资源和质量上都受到严重影响。由此可见项目范围管理的重要性。

一、项目范围管理相关概念

范围的概念包括产品规范和项目范围两方面内容, 其中产品规范指产品或服务所包含的特征或功能, 项目范围指为了交付具有所指特征和功能的产品必须要做的工作。

项目范围管理是指保证项目范围规定的工作得以顺利完成的所有管理过程。这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。简而言之, 项目范围管理就是:做什么?不做什么?包括什么?不包括什么?

二、项目范围管理的作用分析

在现实的IT项目管理中, 可以看到很多范围管理不到位而导致项目失败的例子。现从以下三个方面对项目范围管理的作用进行分析。

1、确定项目范围可提高项目成本、时间和资源估算的准确性。

如果项目的具体工作内容不明确, 项目的成本、时间和所需资源就不明确, 项目完成的不确定因素将大大增加, 面临巨大的危机。

2、确定项目范围有助于清楚地分派责任。

在明确项目包括那些具体的内容、具体有哪些要求、完成的产品应达到什么要求等内容后, 就为清楚地分派任务提供了必要的保障。

3、项目范围、时间、成本三个约束条件是相互影响、相互制约的。

时间、成本和范围构成一个稳固的三角形, 如图1所示。 (图1)

大多数项目都会有明确的完成日期、成本和范围的限制。时间、成本和范围三个要素被称为项目成功的三大要素。

在三角形中, 任何一边都不可能孤立地改变, 如果项目范围扩大, 必然导致项目成本增加和项目工期的延长。不成比例的变化与孤立的改变某一边是一样的, 都将破坏三角形的结构, 最终招致项目失败。因此, 有效的范围管理更像一门艺术, 可以帮助项目经理在已经确定的时间和成本下完成项目目标。

三、影响项目范围管理的常见因素分析

影响项目范围管理的因素很多, 经分析有以下几种:

1、IT企业没有完善的项目管理体系来指导项目管理工作。

此种情况下, 项目的成败完全依靠项目经理个人的管理、领导能力, 大部分项目都是以失败而告终, 因此建立健全项目管理体系是至关重要的。

2、项目范围的定义不够明确, 不能量化, 可验证程度低。

很多时候都是一些定性的要求, 例如“用户界面友好, 可操作性强, 便于使用及维护”等, 类似这些模糊的界定往往是导致后续项目扯皮的根源。对项目范围的明确定义, 有经验的项目经理及系统分析人员将起到关键性的作用。

3、客户本身原因造成项目范围管理上的困难。

主要包括两方面原因:一是客户本身无法确定清晰的范围定义;二是客户有意拖延明确的范围定义。

针对第一种原因, 要向客户方介绍或带领其参观已经完成的项目, 消除对方的疑虑, 清晰对方的思维。针对第二种原因, 如果处理不好, 不但无法做好范围管理, 还会影响双方的合作关系, 影响到可能存在的后续业务。此时, 项目经理要组织人员做好攻关, 软硬兼施, 让客户方负责人真心投入, 提高对方领导的重视程度, 加深项目干系人对各阶段性工作的印象, 扩大范围定义在客户方单位的认知度和影响面。

4、合同方面的原因造成项目范围难以管理。

在合同签订前销售人员为了能够尽快签单, 往往对客户会有一些不切实际的承诺, 在客户的印象中项目产品已经是无所不包了, 使得客户产生很多不切实际的期望。另外, 国内IT企业签订的合同一般都比较简单, 很少对项目范围有明确规定, 造成项目的范围存在很大的不确定性, 留下了很大的隐藏风险。合同签订后项目小组和客户要有一个渐进的项目范围交互、降低期望的过程, 否则容易出现观点冲突, 对项目的推进造成影响。

四、如何做好项目范围管理

要做好项目范围管理工作必须先了解项目范围管理的一些科学过程, 然后认真按照这些科学过程进行项目的范围管理。依据美国项目管理协会 (PMI) 项目管理知识体系指南 (PMBOK) 中给出的严格定义, 其中包括启动、范围计划、范围定义、范围核实、范围变更控制等内容。

1、项目启动过程。

项目启动是正式承认一个新项目的存在或一个已有项目进入下一个阶段的过程。该过程有一个重要的输出文档是项目章程, 项目章程粗略地规定项目的范围, 这也是项目范围管理后续工作的重要依据。项目章程规定项目经理的权利以及项目组中各成员的职责, 还有项目其他干系人的职责, 这也是在以后的项目范围管理工作中各个角色如何做好本职工作有一个明确规定, 保证后续工作可以更加有序地进行。项目一般是由市场需要、经营需要、客户需要、技术进步、法律要求等一个或多个需要而启动的。

2、项目范围计划过程。

范围计划的核心工作是编写正式的项目范围说明书和范围管理计划。范围计划编制是将产生项目产品的所需进行的项目范围渐进明细和归档的过程。做范围计划编制工作需要参考很多信息, 通常它对项目范围已经有粗线条的约定, 范围计划在此基础上进一步深入和细化。范围说明书在项目干系人之间确认或建立了一个项目范围的共识、作为未来项目决策的文档基准。在进行项目范围规划时, 必须慎重考虑与权衡工具、数据来源、方法、过程与程序, 以及其他因素, 确保为项目而付出的努力与项目的大小、复杂程度和重要性相称。

3、项目范围定义过程。

范围定义指的是把项目产出物进一步分解为更小的、更便于管理的许多组成部分。一个好的范围定义可以提高对项目成本、项目工期和项目资源需求估算的准确性;为项目的绩效度量和控制确定一个基准;便于明确和分配项目任务与责任。在这个过程中, 项目组要建立一个工作分解结构 (WBS) 。WBS的建立对项目的意义非常重大, 它使得原来看起来非常笼统、模糊的项目目标一下子清晰起来, 使得项目管理有依据, 项目团队的工作目标清楚明了。如果没有一个完善的WBS或者范围定义不明确时, 变更就不可避免地出现, 很可能造成返工、延长工期、降低团队士气等一系列不利后果。

4、项目范围核实过程。

范围核实是通过参与者的行为正式确定项目范围的过程。它要求回顾生产过程和生产成果, 以保证所有项目都能准确、满意地完成。这个过程是范围确定之后, 执行实施之前各方相关人员的承诺问题。一旦承诺表明你已经接受该事实, 那么你就必须根据你的承诺去实现它。

5、项目范围变更控制过程。

范围变更控制是指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行为与教训总结。再好的计划也不可能做到一成不变, 关键是对变更进行有效控制。

客户在项目开始之前不能明确所有的需求, 随着业务的发展、客户认识的提高, 客户的需求也在发生变化, 客户提出变更是不可避免的。变更并不可怕, 可怕的是随意的、没有控制的变更。为了使变更有序, 需要与客户一起, 建立变更控制委员会 (CCB) , 制定严格的变更制度、变更流程, 将一切非必要、非紧急、不合理、非高层领导意图的“无效变更”屏蔽掉, 同时采用变更申请表格和配置管理工具有效地管理变更。

五、总结

影响IT项目最后成功的因素是多方面的, 包括项目管理的九大知识领域。有效的IT项目范围管理对项目的成功运作具有重要的意义, 范围管理的成功与否直接影响到对项目进度、质量、成本的有效掌控以及对项目风险的控制。

参考文献

[1]吴吉义, 殷建民, 信息系统项目管理案例分析教程[M], 北京, 电子工业出版社, 2006.33.

[2]黄德业, 软件项目之范围管理[J], 福建电脑, 2007.9.

IT管理项目论文 篇2

论IT项目管理的风险分析

【摘 要】随着知识经济时代产业的飞速发展，IT项目管理中暴露出的问题也日益突出。风险管理作为 IT 项目管理的重要内容，是项目成功的重要因素。本文从风险分析的概念、过程以及方法出发，阐述了如何对对IT项目实施更加有效的风险管理，从而减轻项目风险所产生的后果，增加项目成功的机会。

【关键字】IT项目；项目管理；风险分析

一、引言

随着科学技术进步与发展、经济全球化，IT行业的竞争日益激烈。由于IT项目的研制开发需要新的技术，或使用许多已经过验证的技术和产品，但产品生产数目一般较少，这些技术和加工工艺不容易达到成熟或定型的程度。且一些大型项目的研制需要长时间大规模的组织指挥协调工作，以及漫长的研制周期等，使得难以预见的不确定性因素增多。这些不确定因素的存在使得项目能否按照预定的计划－－费用、进度和性能完成任务往往难以预料存在着失败的风险。

在我国，项目失败的现象尤为突出，大多是由于项目风险管理失误造成。从概念上讲，项目风险管理是为了使项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量等进行风险分析和管理的活动。而风险分析不但可加深对项目和风险的认识和理解，澄清各方案的利弊，了解风险对项目的影响，以便分散风险检查和考虑所有到手的信息、数据和资料，明确项目的各有关前提和假设批；还可提高项目各种计划的可信度，有利于改善项目执行组织内部和外部之间的沟通，编制应急计划时更有针对性；同时，为以后的规划和设计工作提供反馈，以便在规划和设计阶段就采取措施防止和避免风险损失。所以在进行项目管理时，风险分析是必要且重要的。

二、风险分析概念

（一）风险

风险是指活动或事件的消极的、人们不希望的后果发生的潜在可能性，指在特定的客观情况下、特定期间里，某一事件的预期结果与实际结果间的变动程度。变动程度越大，风险越大反之，风险越小。风险包含两个特征：不确定性，指风险的事件可能发生也可能不发生，没有发生的风险；损失，如果风险变成了现实，就会产生恶性后果或损失。

风险可分为以下几类：

1、已知风险，是通过仔细评估项目计划、开发项目的环境、以及其它可靠的信息来源之后可以发现的那些风险。

2、可预测风险，能够从过去项目的经验中推测出来，如人员调整，与客户之间无法沟通，由于需要进行维护而使开发人员精力分散。

3、不可预测风险，它们可能、也会真的出现，但很难事先识别出它们来。

（二）风险分析

风险分析是通过定性或定量的分析方法衡量风险发生的可能性和破坏程度的大小，对风险按潜在危险程度进行优先级排序和评价的一个过程。风险分析有狭义和广义两种，狭义的风险分析是指通过定量分析的方法给出完成任务所需的费用、进度、性能三个随机变量的可实现值的概率分布。而广义的风险分析则是一种识别和测算风险，开发、选择和管理方案来解决这些风险的有组织的手段。本文中所说的风险分析时，都是指后一种定义。风险分析包括风险识别、风险评估、风险管理三个方面的内容。

风险识别是指确定哪些可能导致费用超支、进度推迟或性能降低的潜在问题，并定性分析其后果。在这一步须作的工作是分析系统的技术薄弱环节及不确定性较大之处，得出系统的风险源，并将这些风险源组合成一格式文件供以后的分析参考。它属于定性分析的范围。风险评估是指对潜在问题可能导致的风险及其后果实行量化，并确定其严重程度，得到系统风险的综合印象。

风险管理则是指在风险识别及风险评估的基础上采取各种措施来减小风险及对风险实施监控。这也可以说是风险分析的最终目的。

三、风险分析的过程

（一）风险识别

风险识别是风险管理过程的第一步，是将项目中的不确定性及问题转换为具体的可以被描述和估量的风险，使团队可以在风险影响项目之前将主要风险揭示出来。风险只有被识别并被清晰地、明确地表述出来，项目团队才能最终达成一致意见并进而进行风险的评估和管理。风险识别过程的目标就是利用多种手段识别出尽可能多的潜在威胁，为团队创建一个面临风险的详细列表，该列表应是全面的、能覆盖项目的所有领域的、并通过提供足够信息使风险分析更具效果及效率的一个文档。

风险识别是一个反复的过程，第一轮可能是由部分项目团队或风险管理团队实行整个项目团队或主要项目利益相关者完成第二轮为达到公正，需要与项目无关人员参与第三轮。有时风险一被识别出马上就可以开发或实施简单有效的应对策略。

风险识别的方法主要有：

1．头脑风暴法，由项目成员、专家、客户等各方人员组成小组，讨论所有可能的风险；

2．专家访谈法，向项目相关领域的专家或有经验人员了解项目中会遇到哪些困难；

3．查阅历史资料，通过查阅历史资料了解可能出现的问题；

4．检查表法，将可能出现的问题列出清单，可以对照检查潜在的风险；

5．评估表法，根据历史经验进行总结，通过调查问卷判别项目的整体风险和风险类型。

（二）风险评估

在进行风险识别并整理之后，必须就各项风险对整个项目的影响程度做一些分析和评价，通常这些评价建立在以特性为依据的判断和以数据统计为依据的研究上。风险分析是详细检查风险的过程，目的是确定风险的范围和程度、它们彼此如何关联及哪些是最重要的。通过风险评估，可以制定有效的决策。

风险评估在风险识别步骤中所生成风险信息的基础上，并将该信息转换成为决策制定信息。在分析步骤中，项目团队同风险列表的风险项中新添加三个元素可能性、影响和风险值。团队可以利用这些元素来进行风险分级，并依其次序用最强的力量来管理最重要的风险。在风险评估过程中，主要注意的是由于团队成员具有不同的经验或观点，他们会对概率和影响做出不同的评定，因此团队不太可能在风险分级上完全达成一致。为了维护讨论中的客观性并减少争论，要确保在开始此步骤之前，确定作为一个团队应如何解决这种分歧。可选方案包括采取多次规则进行投票、选择最坏情况的评估或赞同对风险发生情形的处理最有经验人员的意见。

评估将风险数据转化为风险决策信息。分析为项目管理者专于管理正确的、重要的风险提供了基础。从经过排序好的主风险列表中确定顶级风险清单是一个非常有意义的工作，顶级风险清单是团队常用来跟踪风险的简单有效的技术。

风险评估的方法非常多，主要可分为定性和定量两种：

1．定性评估：定性风险评估的目的是界定风险源，并初步判明风险的严重程度，以给出系统风险的综合印象，定性地量化各种风险源可能对系统造成的破坏，从而判明系统风险大小。定性风险评价主要包括风险评估指数法RAC、总风险暴露指数法TRPC、直接风险评估法SCRAM等。其主要特点是对危险的可能性和严重程度做粗略的数值分析，大致将其划分为一些等级，然后把这两者用小同的方式综合起来衡量风险的大小及重要程度，并按大小和重要程度对风险进行分类排序，最后分别对小同种类的风险采取小同的措施，确定是接受风险还是改进设计、改善材料土艺、改变工作流程、加强人员培训以减小风险。

2．定量评估：定量风险分析是在定性分析的逻辑基础上，给出各个风险源的风险量化指标及其发生概率，再通过一定的方法合成，得到系统风险的量化值。它是基于定性风险分析基础上的数学处理过程。现发展较为成熟的方法有PRA（概率风险评估）,DPRA（动态风险概率评估）及仿真通用软件VERT（风险评审技术）等。

PRA和DPRA都是在FTA分析基础上的量化，在可靠性及运行系统风险分析领域内应用广泛。稍作改造，我们便可将其运用到项目风险分析领域。其分析步骤如下：（1）识别项目研制过程中的困难环节，找出风险源；（2）对各风险源考察其在项目研制中的地位，及相互逻辑关系，给出项目的风险源树；（3）标识各风险源后果大小，及风险概率；（4）对风险源通过逻辑及数学方法进行组合，最后得到系统风险的度量。如果是用DPRA进行评估，则尚须考虑它们在时间上的关系。

另一种被广泛运用于风险评估的方法是VERT。VERT是国外在八十年代初期发展的一通用仿真软件，它对项目研制构造过程网络，将各种复杂的逻辑关系抽象为时间、费用、性能的三元组的变化。网络模型面向决策，统筹处理时间、费用、性能等风险关键性参数，有效地解决多目标最优化问题，具有较大的实用价值。它的原理是通过丰富的节点逻辑功能，控制一定的时间流、费用流和性能流流向相应的活动。每次仿真运行，通过蒙特卡洛模拟，这些参数流在网络中按概率随机流向不同的部分，经历不同的活动而产生不同的变化，最后至某一终止状态。用户多次仿真后，通过节点收集到的各参数了解系统情况以辅助决策。如果网络结构合理，逻辑关系及数学关系正确，且数据准确，我们可以较好地模拟实际系统研制时间、费用及性能的分布，从而知道系统研制的风险。

（三）风险管理

面对风险评估后得到的风险决策信息以及风险清单，项目管理者需要对风险采取相应的措施并进行风险的监控。这一阶段的风险管理主要就是风险应对和风险监控。

应对风险时，主要有以下四种策略：

1．规避。通过变更项目计划消除风险或风险的触发条件，使目标免受影响。这是一种事前的风险应对策略。例如，在项目管理的过程中澄清不明确的需求、明确资源的需求量和时间、加强与各参与方的沟通，确保项目资金等。

2．转移。不消除风险，而是将项目风险的结果连同应对的权力转移给第三方。这也是一种事前的应对策略，如，将项目的成败交给监理方控制或与用户签定补偿性合同。

3．弱化。将风险事件的概率或影响力降低到一个可以接受的程度。例如，在项目正式实施之前在测试系统上多次演练。

4．接受。不改变项目计划，而考虑发生后如何应对。例如制定应急计划，当项目实施出现问题时，按事先制定好的应急计划执行。

仅仅对风险采取了相应的措施是不够的，项目管理人员还需继续进行风险监控：监视风险的状况，确定风险是已经发生、仍然存在还是已经消失；检查风险的对策是否有效，监控机制是否在运行；不断识别新的风险并制定对 策。无论项目进展的情况如何，都必须将风险管理的计划和行动结果整理汇总进行分析，形成风险管理报告。采取书面或口头、不定期的或阶段性的等多种方式，为项目的实施、控制、管理、决策提供信息基础。

四、总结

在IT项目中，风险总是和效益并存的。只有正确地识别风险、分析风险、应对风险，才能确保每一个项目的顺利实施和成功完成，并对项目的后续发展和企业的持续经营有着重要的影响，给企业带来更多的效益。

参考文献：

IT管理项目论文 篇3

关键词：IT项目管理；项目管理；项目经理

中图分类号：TP311.5 文献标识码：A 文章编号：1674-7712 （2014） 04-0000-01

20世纪，项目管理主要应用在工程项目中，但是在步入21世纪后，随着计算机的普及和网络的发展，也引起了IT界人士的高度重视。在IT项目管理中，项目经理起着至关重要的作用，对于项目的成功运行发挥着主导作用。

目前，学术界对于IT项目管理中项目经理的作用研究还处于初级阶段，这就需要学术界加强对于IT项目管理经理的研究，加深项目经理在IT项目管理上的作用的认识，开拓学术界研究视野，这也是本文的研究初衷。

一、IT项目管理及其特点

项目管理是在一个连续的过程中为达到项目目标，对项目所有方面所进行的规划、组织、监测和控制。

IT行业项目管理在具有其他的项目管理普遍特性外，其还具有本身的一些特殊性：（1）任务的明确性，无论是产品项目还是应用项目都要有明确的开始和结束时间；（2）管理工具的先进性，指的是IT行业中的计算机和从业人员的技术水平高，管理工具更新速度快；（3）信息沟通的及时性，项目管理人员可以通过网络及时传递；

二、IT项目管理中的项目经理的职责

项目经理是项目组织的核心和项目团队的灵魂，是实现项目目标的责任人，对项目进行全面管理。IT项目管理中项目经理主要担当着以下职责：（1）确保项目目标实现。项目目标的实现是IT项目经理的主要职责。（2）开发计划。IT项目经理的职责之一就是将项目总目标分解，制订项目阶段性目标和项目总体控制计划。（3）组织实施。主要体现在设计项目团队的组织结构，对于大型项目，项目经理应该决定哪些任务由项目团队完成，哪些任务由承包商完成。

三、项目经理的权力

实行项目经理负责制最重要的就是授予项目经理充分的权力，以保证项目的顺利实施。

（1）生产指挥权。IT项目经理有权按项目合同的规定，根据项目随时出现的人、财、物等资源变化情况进行指挥调度。（2）项目团队的组建权。项目团队的组建权包括项目经理班子或管理班子的组建权。（3）财权。I在财务制度允许的范围内，项目经理有权安排承包费用的开支，有权在工资奖金范围内决定项目团队内部的计酬方式和方案，确定奖金分配。

四、项目经理的作用

IT项目经理在项目管理中起着关键的作用，是公司执行项目活动并实现项目目标的责任人，全面履行公司所签合同中的所有要完成的目标。

IT项目经理担任着沟通、协商、解决各种矛盾、冲突、纠纷的关键作用。项目经理平常对于项目行使管理权，在这个过程中也要对项目目标的实现承担全部责任，可见项目经理在其中担任的重要的角色。同时IT项目经理是项目信息沟通的发源地和控制者，在项目实施过程中，来自项目外的重要信息、指令要通过项目经理来交涉；对项目内部，项目经理是各种重要指标、决策、方案、制度的制定者。

五、项目经理的能力

IT项目经理除了在对项目的计划、组织、控制等方面发挥领导作用外，项目经理还应具备一系列技能，来带领团队成员取得成功，赢得客户的信赖。

（1）获得项目资源的能力。项目经理通过树立自己的形象，借助各种关系和高层领导，通过正常途径获得项目资源。（2）消除障碍和解决问题的能力。IT项目经理应保持对冲突的敏锐观察，识别冲突可能产生的后果，尽量利用对项目有利的冲突，同时降低和消除对项目产生严重危害的矛盾。（3）领导能力和权衡能力。要想领导一个团队，必须首先学会领导团队中的每一个人。IT项目经理还要负责做出为了使项目取得成功所必须付出的权衡。（4）沟通能力。良好的人际交往能力是项目经理必备的技能。项目经理一定是一个良好的沟通者，他需要与项目团队、客户、公司高层管理者、承包商等进行定期的交流。

六、IT项目管理的案例分析

X先生曾经负责某一个地区的大型数据库项目。在管理这个项目的过程中，出现了各种问题。在项目开始前，X缺乏对整个项目的认识，同时由于在项目的开发过程中，与上下两个层面的沟通联系不够，造成了项目的及时情况不能准确获得。在这个项目实施的过程中，由于某些方面的失误造成了整个工程的额外工作量，这就很容易让人产生抵触情绪。X先生应该加强对整个队伍的管理，在管理过程中既要及时沟通，又要讲求方式方法。继而提高每个人团队配合意识，使得每个人都能够积极主动地参与其中，而不是相反。

从X先生的案例中，我们可以清楚的看到，在整个IT项目的管理中，项目经理在管理和沟通中，在沟通上下层关系中，起着非常重要的作用。当然作为项目经理在IT项目的管理中，X先生的案例只是向我们提供了在沟通管理上的分析，其他方面还有很多需要注重的方面。

七、建议与对策

IT项目经理作为项目管理中十分重要的角色，笔者认为IT项目经理应该在以下几个方面提升自己：（1）IT项目经理要拓宽自己的视角。（2）紧跟IT的未来发展，加强在IT行业方面的学习。（3）增加社交技能，增强与人沟通交流的能力。（4）注重提升解决问题纠纷的能力。

八、结束语

IT项目管理是一个全新的尚待开发的新领域，我国IT领域的投资规模一直保持在一个很高的发展水平，这也给了IT项目管理一个快速发展的环境。从IT项目管理的发展来看，人们对于IT项目管理的认识还不深刻，对于IT项目经理的理解还待深入，相信随着时间的推移，人们在IT项目管理中项目经理的重视程度会与日加深，对其职责会进一步划分。

参考文献：

[1]左美云，周彬.实用项目管理与图解[M].北京：清华大学出版社，2002.

[2]翟松涛.项目：如何进行成功的项目管理[M].天津：南开大学出版社，2004.

[3]林海，杨尊琦.IT项目管理中应该注意的几个问题[J].数码世界，2003（02）.

[4]马君.什么是IT项目管理[J].软件工程师，2005（01）.

IT项目风险分析及管理 篇4

1.1 IT项目风险有两个特征

不确定性——风险的事件可能发生也可能不发生, 没有100%发生的风险。

损失———如果风险变成了现实, 就会产生恶性后果或损失。

1.2 按风险类型来说, IT项目有以下几种不同类型的风险:

项目风险:项目风险是指潜在的预算、进度、人力、资源、客户、需求等方面的问题以及它们对项目的影响。

技术风险:是指潜在地设计、实现、接口、验证和维护等方面的问题。包括技术的不确定性、陈旧的技术、以及“过于先进“的技术。

商业风险:

几个主要的商业风险是:市场风险、策略风险、销售风险、管理风险、预算风险。

1.3 按风险方式来说, IT项目风险分为以下方式

已知风险:不现实的交付时间, 没有需求或软件范围的文档、恶劣的开发环境等。

可预测风险:人员调整, 与客户之间无法沟通等。

不可预测风险:政策风险等。

2 软件项目的风险分析及风险管理

下面以软件项目为例, 探讨IT项目中的风险分析及风险管理方法。对于软件项目主要存在以下风险。

2.1 产品规模风险

产品规模的可信程度如何;产品规模平均值的偏差百分比是多少;产品的数据库大小如何;产品的用户数有多少;产品的需求改变有多少;复用的软件有多少。

2.2 商业影响风险

对公司的收入有何影响;是否得到公司高级管理层的重视;交付期限的合理性如何;是否与用户的需要相符合;最终用户的水平如何;用户对本产品开发的约束;延迟交付所造成的成本消耗是多少;产品缺陷所造成的成本消耗是多少;如果出现了较大的百分比偏差则风险较高。

2.3 客户相关风险

以前是否曾与这个客户合作过;该客户是否很清楚需要什么;该客户是否已确定项目范围;该客户是否愿意建立与开发者之间的快速通信渠道;该客户是否愿意参加复审工作;该客户是否具有改产品的技术素养;该客户是否愿意你的人来做他们的工作;该客户是否了解软件过程;

2.4 软件开发产品的过程风险

是否已经拟定了一份软件过程说明;开发人员是否同意按照文档所写的软件过程进行开发工作;该软件过程是否可以用于其它项目;人员是否接受过一系列的软件工程培训;是否提供了确定的软件工程标准;是否为作为软件过程一部分而定义的所有交付物建立了文档概要及示例;是否定期对需求规约、设计和编码进行正式的技术复审;是否定期对测试过程和测试情况进行复审;是否对每一次正式技术复审的结果建立了文档;

有什么机制来保证按照软件工程标准来指导工作;是否使用配置管理来维护系统/软件需求、设计、编码、测试用例之间的一致性;是否使用一个机制来控制用户需求的变化及其对软件的影响;对于每一个承包出去的子合同, 是否有一份文档化的工作说明、一份软件需求规约和一份软件开发计划;

2.5 技术风险

该技术对于公司而言是新的吗;客户的需求是否需要创建新的技术;产品的需求是否要求采用特定的用户界面;产品的需求中是否要求开发某些程序构件;需求中是否要求采用新的分析、设计、测试方法;需求中是否要求使用非传统的软件开发方法;需求中是否有过分的对产品的性能约束;客户能确定所要求的功能是可行的吗。

2.6 开发环境风险

是否有可用的项目管理工具;是否有可用的分析及设计及测试工具;是否有可用的软件配置管理工具;项目组的成员是否接受过每个所使用工具的培训;是否有专家能够回答有关工具的问题。

2.7 与人员数目及经验相关的风险

人员在技术上是否配套;是否有足够的人员可用;开发人员对自己的工作是否有正确的期望;开发人员是否接受过必要的培训。

3 软件风险因素

为了识别和控制软件风险, 可以标识影响软件风险因素, 包括:性能、成本、支持和进度, 包括:性能风险、成本风险、支持风险、进度风险。每一个风险因素的影响均可分为四个影响类别--可忽略的、轻微的、严重的、灾难性的。下表列出由于错误而产生的潜在影响或没有达到预期的结果所产生的潜在影响。

4 风险预测

4.1 建立风险表

风险表是一种简单的风险预测技术。每个风险的概率值可以由项目组成员个别估算, 然后将这些值平均, 得到一个有代表性的概率值。

风险影响及概率从管理的角度来考虑, 具有高影响但发生概率很低的风险因素不应该花费太多的管理时间。而高影响且发生概率为中到高的风险以及低影响但高概率的风险, 应该首先考虑。

4.2 评估风险影响

如果风险真的发生了, 所产生的后果有三个因素可能会受影响:风险的性质、范围、时间。以下的步骤用来确定风险的整体影响:a.确定每个风险元素发生的平均概率。b.确定每个因素的影响。c.完成风险表, 分析其结果。d.项目组定期复查风险表, 再评估每一个风险, 以确定新的情况是否引起其概率及影响的改变。

5 风险缓解、监控和管理

所有风险分析活动都只有一个目的--建立处理风险的策略。风险管理策略要考虑三个问题:风险避免、风险监控、风险管理及意外事件计划。

6 总结

对于IT项目期来说, 如何进行风险分析、管理, 是应该重视的一个问题, 如何开展这项工作, 对于IT项目的实施具有重要意义。目前对于IT项目的风险控制, 大多数公司都在非正式地和表面地进行, 但还缺乏重视, 不能花更多的资源, 但可以这样说:花在标识、分析、管理风险上的时间可以从多个方面得到回报, 可以使项目进展过程更加平稳, 提高跟踪和控制项目的能力, 有这些周密计划可以使整个公司和项目组获得更大的信心, 以保证项目的顺利完成

参考文献

[1]罗耶 (美) .项目风险管理.北京:机械工业出版社, 2005

[2]栾跃.软件开发项目管理[M].上海:上海交通大学出版社, 2005.

IT项目管理复习 篇5

4.项目参数：范围 质量 成本 时间 资源5.项目管理的基本特征1．普遍性

项目作为一种创新活动普遍存在于我们人类的社会生产活动之中，我们现有的各种文化物质成果最初都是通过项目的方式实现的。2．目的性

一切项目管理活动都是为实现“满足或超越项目有关各方对项目的要求与期望”这一目的服务的。3．独特性

项目管理既不同于一般的生产服务运营管理，也不同于常规的行政管理，它有自己独特的管理对象（项目），有自己独特的管理活动，有自己独特的管理方法和工具，是一种完全不同的管理活动。

（如，关键线路分析和工作分层结构）4．集成性

项目管理要求必须充分强调管理的集成性特性。例如，对于项目工期、造价和质量的集 成管理，对于项目、子项目的集成管理等等。

分立的子项目之和不是上一级项目。5．创新性

一是指项目管理是对于创新（项目包含有许多创新之处）的管理，二是指任何一个项目的管理都没有一成不变的模式和方法可供参考，必须通过管理创新去实现对于具体项目的有

效管理。未必是管理思想的创新。

6.项目与操作（operation）的异同的分析

操作(operation)与项目(project)有许多共同特征，比如：·需要由人来完成。受到有限资源的限制。需要计划、执行、控制。

成熟的操作可以追求自动化运作1．工作性质与内容的不同

―操作中存在着大量的常规性、不断重复的工作或劳动，而―项目中则存在较多创新性的一次性工作或劳动。

2．工作环境与方式的不同

―操作工作的环境是相对封闭和相对确定的，而―项目的环境是相对开放和相对不确定的。3．组织与管理上的不同

一般操作工作的组织是相对不变的和相对持久的，操作的组织形式基本上是分部门成体

系的。项目的组织是相对变化的和相对临时性的，项目的组织形式多数是团队性的。

7.项目管理知识体系PMBOK（projectmanagement body of knowledge）含哪九个知识领域 PMBOK 把项目管理知识划分为九个知识领域（集成integration、范围scope、时间time、成本cost、质量quality、人力资源human resource、沟通communication、风险risk 和采购 procurement）； 8.一般项目的生命周期

启动、计划、执行、控制、结束

项目结束阶段与启动阶段的费用投入较少确定项目是否可行是在启动阶段完成的9.项目收尾及持续进步的意义管理收尾的概念是：项目或项目阶段达到目标或因故终止，需要进行收尾。

管理收尾包括：项目结果文档的形成、项目记录的收集、教训分析、项目成果归档。管理收尾应在每个阶段结束时进行，保证重要的信息不至流失。

输入：绩效测量文档、产品文档、其他记录。工具和技术：绩效报告的工具。

输出：项目档案、项目收尾、取得的教训。项目收尾：确认项目已经满足用户对项目产品的所有要求（已经确认接收项目成果）。10.项目干系人（stakeholders）项目干系人：积极参与项目或其利益在项目执行中或成功后受到积极或消极影响的组织和个人。

主要的项目干系人：顾客、项目经理、执行组织、项目发起者。—内部的和外部的、业主和资金提供者、供应商和承包商、项目班子成员及其家庭成员、政府机构和媒体、市民和社会团体„整个社会。11.项目当事人是指项目的参与各方。如业主、投资方、贷款方、承包人、设计师、监理,通过合同和协议联系在一起。12.组织形式的种类职能型组织：这种组织具有明确的等级划分，每一个雇员都有一个明确的上级。员工高度地依各人专长进行组合，比如生产、市场、工程、会计。

项目型组织：在一个项目型组织中，工作成员是经过搭配的。项目工作会运用到大部

分的组织资源，而项目经理也有高度独立性，享有高度的权力。项目型组织中也会设立一些

组织单位，这些单位也称作部门，但是这些工作组不仅要直接向某一项目经理汇报工作，还要为各个不同的项目提供服务。矩阵型的组织：这种组织是职能型和项目型的混合体，既具有职能型组织的特征又具项目型组织的特征。弱矩阵型保持了较多的职能型组织特征，项目负责人扮演的是协调者、协助者的角色，还算不上是一个项目经理。同样也是矩阵型，强矩阵型则具备较多的项目型组织的特征--有专职的权力很大的项目经理，有专职的项目行政管理人员。

矩阵型组织结构能充分利用人力资源

项目经理和职能部门经理必须就谁占主导地位达成共识

矩阵型组织结构能对客户的要求做出快速的响应13.领导和管理的区别领导主要涉及： 1）确定方向——预测未来并提出为迎接未来所做变革的策略。

2）协调思想——以语言和行为通知那些在合作中需要获得这种观点的人们。

3）激励和鼓舞——帮助人们激发自己以克服政治、行政和资源障碍进行变革。

领导型人才，他们有过人的眼光，决断的魄力，冒险的精神，杀伐的勇气和独特的魅力。他们的弱点是不注重过程和细节，也缺少相应的专业能力。管理：

管理型人才，他们的组织，沟通，实施，综合和专业能力都不同一般。他们的问题是缺

乏感召力,也鲜有不落俗套的开拓能力和敢于孤注一掷的牺牲精神。管理主要关心持续不断 地为项目干系人创造他们所明确期望的主要成果。两者之间不可或缺：只有一个而无另一个则可能造成不良后果。

14.启动是一个过程，一个软件项目启动有哪些内容 需求分析;项目建议书;可行性研究;项目评估;项目选择。

15.可行性研究要素（1）技术可行性；（2）组织体制可行性;（3）财务可行性；（4）经济可行性;

（5）生态和社会可行性;（6）风险和不确定性。16.WBS 工作分解结构，有哪两种形式，编码等工作分解结构WBS(Work Breakdown Structure）是根据树形图将一个功能实体（项目）先分解为子项目，再逐级分解成若干个相对独立的工作单元，并确定每个工作单元的任务及其从属的工作（或称之为活动）；以便更有效地组织项目的进行。

WBS 工作分解结构的目的是对完成项目的工作范围进行确定,也就是确定项目都要做什么工作项目任务分解结构WBS的作用

WBS在项目过程中究竟起到什么作用？这个问题涉及到项目规划和管理的几个层次。良好的项目管理必须具备以下因素：对项目的认知、为项目提供良好的协同环境和有效的控制。这几个因素环环相扣，前者是后者的必要条件。

项目变更控制的目的不是禁止变更，而是要评估被提议进行的项目变更可能会产生的结果。17.项目进度计划编制前的准备活动定义 活动排序 工期估计

18.用于PERT 网络的工期估计三个时间估计法的计算

PERT 对各个项目活动的完成时间按三种不同情况估计：a、乐观时间（optimistic time）--任何事情都顺利的情况，完成某项工作的时间。

m、最可能时间（most likely time）--正常情况下，完成某项工作的时间。b、悲观时间（pessimistic time）--最不利的情况，完成某项工作的时间。假定三个估计服从β分布，由此可算出每个活动的期望T：t=（a+4m+b）/6

活动的标准偏差:S=(b-a)/6

21.关键路径法（CPM）和PERT 图法在时间管理应用上有什么区别

两者的主要区别是：（1）CPM 假设每项活动的作业时间是确定值，而PERT 中作业时

间是不确定的，是用概率方法进行估计的估算值。（2）CPM关注关键路径上活动的监控，以便尽早发现和纠正任何延迟或资源无法得到的影响，如果要缩短整个项目的周期，就必须缩短关键路径；

PERT 图进行不确定性的预测，原则上关注有最大不确定性的活动。（3）到后来两者有发展一致的趋势，常常被结合使用，以求得时间和费用的最佳控制。

23.软件质量和等级

•ISO9000 的质量定义：

反映实体满足明确和隐含需要能力的特性综合。这里的实体是指可以单独描述和研究的事物，可以是活动或过程、产品、组织、体系、人或它们的任何组合。

等级的含义是：对功能用途相同、但技术特性不同的存在事务的一种分类或排序例如:低等级——有限的功能

低质量——错误百出、编排混乱的用户手册高等级——大量功能

高质量——无错误、可读性强的用户手册24.明确需要，隐含需要

–明确需要：指合同中用户明确提出的要求与需要–隐含需要：指由生产企业通过市场调研进行识别与探明的要求或需要25.测试的V 模式

V 模型中的过程从左到右，描述了基本的开发过程和测试行为。V 模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。26.何为白盒、黑盒、正向反向边界负荷测试白盒测试 在单元测试阶段，由于测试者对被测对象的内部结构、逻辑思路、接口关系等比较熟悉，一般采取白盒测试的方法，它是根据模块的内部

逻辑，进行测试设计的方法。有些集成测试也采用白盒方法，关键看集成阶段的划分。

黑盒测试 在集成测试以至此后的各阶段，测试设计和测试人员，对被测对象的内部结构不了解也不需要了解，他的目的是按需求功能进行确认。因此，黑盒测试是严格按软件需求进行测试设计的方法。27.集成测试又叫组装测试的主要内容

集成测试又称组装测试，它是在单元测试完成后，组装为一个子系统后，对下列只有

组装后才能发生和测试到的问题，进行检查：（1）组装后一个模块对一个模块的影响；（2）合并功能是否是预期的；

（3）独立的误差在合并后的变化，是扩大还是减小，是否在可接受的范围内；

（4）实际的接口测试；包括：模块之间对实际衔接的标准、时序（实时性）、应答响应、容错与错误处

理等；（5）模块间的资源竞争等。

29.α测试，β测试，正向测试，逆向测试的概念ɑ测试是由一个用户在开发者的场所，在开发者指导下进行的测试。开发者记录下问

题和错误，是在开发者―控制‖下的测试。

ß测试是用户的环境中，开发者可能并不在现场，由用户―”活用”系统情况下的测试。用户记录下问题，报告给开发者。

正向测试：按照用户正常的理解、操作方式、思维和使用习惯使用软件，得到的结果是否与需求一致。逆向测试：如果不按用户正常的理解、操作发生、思维和使用习惯使用软件，软件是否能正确地进行处理。如无效操作、错误的数据输入处理、非法进入等。32.理解马斯洛的需要层次理论，案例分析•1生理的需要 •2 安全的需要•3 社交的需要 •4 受尊重的需要•5 自我实现的需要

33.理解匹兹近格的双因素理论，案例分析健康因素是指那些与人们的不满情绪有关的因素，如企业政策，工资水平，工作环境，劳动保护，人际关系等

激励因素是指那些与人们的满意情绪有关的因素，如工作表现机会，工作带来的愉快，工作上的成就感，由于好的成绩而得到的奖励，未来发展的期望，职务上的责任感

34.理解佛罗姆的期望理论，案例分析

•弗罗姆认为，人们之所以采取某种行为，是因为他觉得这种行为可以有把握达到某种结果，并且这种结果对他有足够的价值。•用公式表示期望理论就是： 动机激励水平M=效价V（效果的可能性）*期望值E（效果的价值）35.理解亚当斯的公平理论

公平等价理论是美国亚当斯(J.S.Adams)，于六十年代首先提出来的。它又称为―社会比较理论侧重于研究报酬对人们工作积极性的影响。公平等价理论是建立在员工会把自己的报酬与投入之比与其它人的报酬与投入之比进行比较这一假设上。公平理论的基本观点是：当一个人做出了成绩并取得报酬以后，他不仅关心自己所得报酬的绝对量，而且关心自己所得报酬的相对量。因此，他进行种种比较来确定自己所获报酬是否合理，比较的结果将直接影响今后工作的积极性。公平等价理论认为，员工所负的责任、权职和员工所获得的薪酬、晋升等因素所造成员工的公平感对员工的激励起着重要作用。36.沟通:为了设定的目标，把信息，思想和情感在个人或群体间传递，并达成共同协议的过程。

37.风险的属性，概念，风险管理的目的是什么。风险是损失发生的可能性

1、损失

2、可能性风险的主体：

主动的（机会）被动的（风险）

来源组织外部的不确定性（1）目标不确定；（2）需求不确定；

（3）项目的外部干系人的影响和作用不确定；（4）自然、政治、经济、法律、技术等的环境不确定。

组织内部的不确定性

（2）管理不确定：由于项目内部的一系列管理处于无序状态，因此，项目运行在一个没有轨迹可循的盲目的状态下，项目的后果不可预测，造成项目的目标实现的不可确定性。

（3）技术不确定：项目关键技术、核心方案不是非常成熟的技术，项目以此技术为核心的实现，有很大的失败可能，项目成功的几率要依赖这个核心技术的成功。因此，项目成功与否，具有很大的不确定性。（4）变更不确定：项目实施过程中，随时可能发生需求的变更。项目组对于涉及到项目的重大变更，没有有效的控制机制，项目组在用户频繁、巨大的需求变更面前，随波逐

流，项目组生存在一个动荡的、没有保证的环境中。属性（1）普遍性：风险是普遍存在的，特别是目前我们的组织普遍地处于内外部的不确定环境下，风险的存在就具有普遍性。

（2）随机性：风险的发生是偶然事件，发生的时间、地点、形式和内容都是不可准确预知的。

（3）相对性：同一风险对于不同的组织、项目、不同的人，危险、处置、结果和承受能力都是不同的。

（4）可变性：在不同的组织和项目，对于风险的承受能力、处置能力的不同，风险 就会发生变化。（5）可管理性：我们这一章，就是介绍，风险作为一种事件，也是可预测、可识别、可分析、可跟踪和可管理的。管理的目的1.试图系统化地瓦解不确定因素对项目计划（质量、预算、进度、资源分配等）的威胁2.通过风险的管理变被动的面对风险，即消防状态为主动面对风险。

3.知道什么是紧急事件，让我们能够依据FIRSTTHING FIRST的原则处理紧急事件38.PMBOK 的风险管理过程（1）风险计划编制：决定如何采取和计划一个项目的风险管理活动。

（2）风险识别：确认哪些风险有可能会影响项目，并把这些风险的特性整理成文档。

（3）风险定性分析：对项目风险和条件进行定性分析，将它们对项目可能产生的影响进行排序。

（4）风险定量分析：测量风险出现的概率和结果，并评估它们对项目的影响。

（5）风险应对计划编制：开发和制定一些程序和技术手段，用来提高实现项目目标的机会和减少风险对项目的目标的威胁。

（6）风险监控：在项目的整个生命周期中，监视残余风险、识别新风险，执行降低风险计划，以及评价这些工作的有效性.39.项目采购的重要性

§降低固定和经营性成本

《IT项目管理》课程教与学研究 篇6

【关键词】IT项目管理；教师；教材；教学；学生

基金支持：湖南省教育科学“十二五”规划课题：“高校教师专业学习共同体的构建策略与运行机制研究”（XJK015BGD051）；湖南中医药大学优秀青年教师培养对象（青苗计划）资助

一、课程对教师的要求

《IT项目管理》既是一门科学，又是一门艺术，更是一种实践。做为教师，应当在充分实践的基础上，掌握管理基本的理论和方法，以此来指导IT项目管理的实践活动，并在实践的过程中提升计划、组织、领导、控制的方法的艺术性。

1.科学是对客观世界的本质与规律的反映。教师要充分掌握管理的基本理论和方法，应该对IT项目管理的本质与规律有深刻的理解，使学生认识到遵循和不遵循科学的管理规律会是工作产生两种截然不同的结果。

2.艺术是对客观世界的形象性反映。因为项目管理是一门艺术，所以在教学过程中如何形象的解析项目管理的规律以及如何来应用这些规律是教师应该具备的基本功。

二、课程对教材的要求

教材與课程的关系，就于战士与武器的关系。没有一本好的教材，就不可能教好这门课程，特别是《IT项目管理》这类理论与实践紧密联系在一起的课程，表现得尤为突出。

然而，现在有一种令人非常困惑和担忧的现象，有许多教师对教材的了解不全面，分析不深入，掌握不透彻。

以至选择的《IT项目管理》课程的教材与所要完成的教学任务不能有机的结合在一起，课堂上的授课内容不能真正指导学生IT项目开发与管理实践的要求。

甚至有的老师授课时和指导学生实践时，经常游离在教学计划和教材之外，找不到教材与教学的切入点。许多学生上课不带课本，下课不看教材，教材根本没有起到支撑和指导的作用。

因此，在教学过程中，教师要对教材的内容进行充分的理解，将教材中的理论转变为指导实践的方法，指导学生学习和理解教材的知识体系及内容，使教材在教学过程中发挥最佳的功能。

三、课程对教学的要求

1.教学的含义。当“教（jiāo）学”的“教”读作第一声（阴平）的时候，“教学”是动词，意思是教书，即：教学生学习功课。这里的“教”是动词，强调结果；当“教（jiào）学”的“教”读作第四声（去声）的时候，“教学”是名词，意思是教师把知识、技能传授给学生的过程。强调过程。

2.IT项目管理课程教学中的重点、难点、关键点。IT项目管理课程教学中的重点：反应的是IT项目管理的本质与规律，具有普适性。教学过程中对IT项目管理之科学、艺术和实践的特点要围绕重点来反复解析。教学任务的80%要在重点中体现。

四、课程对学生的要求

1.通过多年的教学实践表明，按照IT项目管理中团队管理的方法来要求学生是一种非常有效的教学方法。

明确教师是该课程的项目经理，每个同学都是项目团队的成员；明确项目团队成员的素质和责任要求，使学生认识到用项目团队角色管理的方法来要求每个同学参与课程学习和实践的重要性与必要性；要求每个同学在课程学习的过程中掌握团队建设、团队管理、团队沟通的方法和技巧。

2.实践证明，没有好的学习习惯，没有充分的学习准备，就不可能有好的学习效果。

项目管理属于管理类课程，因此，在教学环节中更应当体现管理思想和理念：

（一）课堂学习准备要求：老师和学生都要提前到达教室，带教材、带笔、带记录本。

（二）课堂互动要求：标记教材中的重点、难点、关键点；精心设计问题，有选择的点名让同学进行回答；对热点、焦点问题，形成感想和体会之警句和短语，并指导学生记录下来，提高学生的学习兴趣和参与度。

3.对于《IT项目管理》的学习，如何强调“会做”都不过分。应该明确“知道而做不到，就是不知道”。

会做的前提是要明白为什么要这样做，这不但需要理论的支撑，更需要经验的积累。使用实际案例，用场景再现和谈感想的方式使学生身临其境，是让学生“会做”的有效方法。IT项目管理课程最要紧的是让学生掌握软件开发和IT项目管理的标准、流程，学会使用项目管理模板和工具。国家标准化委员会颁布的《信息技术软件生存周期过程（GB/T 8566-2007）》和《计算机软件文档编制规范（GB/T 8567-2006）》是软件开发和文档编制工作的准则和规程。因此在教学过程中，帮助学生掌握规范，是教会学生做得基础。

五、结语

《IT项目管理》是一门实践性较强，强调软技能的课程，更注重培养理工科学生的管理技能，即计划、组织、领导、控制，及沟通、协调等能力，因此，在整个授课过程中应当更为强调管理理论及方法的应用，使用管理的方法提升技术型人才的软实力，做到理论与实践的相互促进与提升。

IT项目范围管理和风险管理研究 篇7

1项目管理

关于项目管理,对各种不同的观点和看法进行总结,就能够发现,项目管理其实就是各种资源被项目关系人实际应用到项目当中,继而对项目的目标进行实现,促进项目关系人从项目中获得更多的满足感。 在这个过程当中,项目管理和项目本身都得到了相应的发展,也不断地对项目管理的意义进行着充实。 在现代的管理工作中,项目管理是一种新兴的管理方式,被人们所逐渐重视,也成为了科学化管理的代名词。

现阶段, 随着我国社会经济的不断发展,IT行业也得到了大力的发展,但是实施IT项目的效果却始终不尽人意,对项目失败的原因进行系统的总结, 能够发现原因主要为以下几点:其一,项目需求频繁发生变化;其二,随着项目的规模不断增大,但是IT项目管理的范围始终难以界定。 由此可发现,导致项目管理失败的主要原因就是由于难以对管理的范围进行界定。 一般来说,在对IT项目及进行管理范围界定时,需要进行以下几个环节:规划范围、定义范围、分解工作的结构、控制范围,这几个环节之间有着密不可分的关系。 在实行项目管理的过程中,要反复对顶层进行应用分析和验证,将项目的需求渐渐转变为对应的系统型。 在进行验证的过程中,要对相关的物理管理结构和体系进行设计, 保证IT项目能够实现各项性能的要求。 对实际的项目管理情况进行分析,能够对管理范围进行流程的归纳,主要是以下几个方面:其一,项目章程;其二,规划范围;其三,定义范围;其四,分解WBS,然后对其范围进行确定。 在实际的工程操作当中,实施的流程具有较大的变动性,项目处于的环境始终都是变化的, 各种因素都会对其产生影响,项目本事同时也处于不断变化的状态。 对于这样的情况,实施项目管理的开展项目中各项工作的初始阶段,只有如此才能够对其进行有效的管理,对项目的发展工作进行推动。

2风险管理

(1)IT项目中的风险管理。 风险管理就是对管理方法或者方案进行假设,假设其中存在漏洞,随后管理其可能引发的负面影响,在实施项目的风险管理时,主要内容有五个方面。 其一,识别风险,就是系统和连续对客观的风险进行识别和归类,在识别的过程中,一般都形成一定的风险列表,识别风险的方法主要是事故数分析法、 财务报表分析法以及事件分析法等。其二,分析风险,就是在识别风险的基础上,定量和定性地分析风险,在这个过程中,主要的分析内容就是系统的分析和单项的分析。 单项的分析系统对过去的风险资料进行分析,从而对可能出现的分析进行预测, 系统的分析就是以单项分析为基础,对风险出现的概率进行预测。 其三,应付风险,在这个过程中,要对风险进行控制,对风险导致的负面影响进行消除、避免和降低,评估风险的发展,并根据评估的结果对应对风险的方案进行及时地调整。 其四,补偿风险,就是当风险出现在管理的过程中时,采取经济的手段对已经发生的损失进行处理,对风险导致的经济损失进行补偿,也就是在发生风险后,对其导致的后果进行相应的处理,降低风险所造成的不利影响。

(2) 规避风险的措施。 随着对经济市场的不断完善, 市场中的竞争也愈发激烈。 在开发IT项目的过程中不但要对技术进行有效地提高,还要对其中隐含的风险进行规避,可以从这几个方面来进行规避。 其一,制定项目章程,开发IT项目的工作是一个较为复杂的过程,具有较强的系统性与技术性。 其二,组建相应的项目团队,若要将整个IT项目进行完善,其中必须包含开发设计、测试安装和配置等多项活动和内容。 其三,增强技术培训, 有效地利用人才是完成IT项目最重要的环节。 其四, 对项目的实施过程进行存档保存, 在开发IT项目的过程中,要注重相关工程的规范性,为用户提供各个实施环节的相关资料,使得项目在开发过程中有实际依据,以免对正常的操作产生影响。 针对开发项目的过程,可以采取相应的规避风险的措施,保证项目的顺利实施和完成。

3结语

随着IT项目的不断发展, 参与项目的人员应当具有一定的风险意识,在制定管理制度的同时进行风险识别,并做出正确的评估,将风险造成的影响在最大程度上进行降低。

摘要：在IT项目的开发和研究过程中,存在着较多的风险,风险的发生会带来较为严重的影响,因此要进行相应的管理。文章对范围管理和风险管理进行了研究,并提出相应的规避风险的措施。

金融行业的IT项目管理 篇8

1 IT在金融行业中的作用

在信息化时代, 在中国入世、金融证券业向外资开放的巨大压力面前, 通过顶级的网络管理实现竞争手段与国际金融机构同步升级成为必然的选择。纵观国内金融业界, 无论是大型银行, 还是保险公司, 或 者是证券行业, 在这些机构内, IT成为有具体目标、为其业务需求服务的战略工具。比如, 花旗银行IT部门, 已经不再只是一个单一的IT部门, 而是一个向整个银 行业务提供业务管理与解决方案的平台, 在这一平台上实现业务运行, 实现资源调配, 实现业务变革。

随着业务的发展和金融业科技应用水平的不断提高, 金融机构启动、规划、开发的IT项目规模越来越大, 项目复杂度和管理难度随之不断提高, 项目团队能否有效解决项目执行过程中出现的各种问题已成为影响项目效果的关键。但是, IT在极大地促进了银行业的发展, 为金融业提供了巨大发展机会的同时也使之面对巨大的风险。

2 金融行业IT项目管理中存在的问题

在金融行业实施IT项目开发管理的过程中, 项目总是会遇到各种各样的困难和问题。例如, 因某些技术问题无法有效解决, 项目进度受到严重影响;开发环境管理不善, 造成项目前期资料和工作成果遗失, 出现IT项目中断或宣告失败, 或者某IT项目未按计划完成而不得不追加投资的情况, 严重影响了金融业务的正常运行。

(1) 对IT项目管理的重视度不够。

金融机构高级管理层的决策更多地是关注新产品、新项目的开发。而IT运营方面除非出现了重大的问题, 否则高级管理层极少触及。因此, 对高级管理层而言, IT运营风险相对于其它风险来说要疏远得多。存在的误区包括:认为在IT发展水平不高的情况下, 信息技术风险所造成的威胁也不大;信息技术风险基本上是小概率事件, 因此可以认为不会发生;建立质量最好的IT基础设施就可以防范风险等。

(2) 缺乏应急机制。

金融业IT系统大都是全国性集中的大型应用系统, 对设备、通信、电力、技术高度依赖, 具有很强的时效性、连续性、关联性。当有IT系统危机。或事故发生时, 仅仅依靠单个金融机构自身力量处置往往是不够的。

但是, 但从总体情况来看, IT系统应急预案还不够完善, 很多是在套用上级机构应急预案的基础上建立起来的, 没有很好地结合本地、本业务的具体情况;从形式上看, 现行的应急注重内部应急机制建设, 对外部因素估计不足;IT系统应急有别于公共应急, 具有很强的专业性。目前许多单位制定的应急预案以及在人员、设备、流程等方面的考虑只盯住了单位内部, 对外来的硬件、软件、非本单位管理的外部基础设施等问题考虑不够;风险评估机制、安全策略评估机制不健全, 不能为IT系统的运行提供有效预测、预警, 不能支持应急处理。

3 金融行业中IT项目管理的基本理念

IT信息管理与金融企业业务开展之间的关系越来越密切, 对业务开展的作用越来越重要。在IT系统建设和管理中, 除了要有先进的设备和技术外, 还必须有一套规范、可管理的IT服务管理流程。

(1) IT项目管理需要将IT技术与企业目标的整合, 并满足客户对IT服务品质和服务体验的要求。即在提供IT服务的时候, 首先应该考虑客户的业务需求, 根据业务需求来确定IT需求。

(2) IT只是银行运营业务流程的一种手段, 不是目的。IT服务管理必须强调根据客户的需求对IT进行“量身定做”式的管理, 通过提供高品质的IT服务提高客户的满意度。金融IT服务管理在实施每个管理流程时都应该从客户需求的角度出发。

(3) IT项目的风险管理主要体现在运营管理和安全管理两个方面。如何通过强化运营管理和安全管理, 最大限度地发挥IT系统的效率, 已经成为金融机构一项重要的工作。

(4) IT部门要侧重于从技术角度对基础设施进行管理。这种管理覆盖了IT基础设施管理的所有方面, 包括识别业务需求、实施和部署、对基础设施进行支持和维护等活动。通过良好IT基础架构管理, 可以在确保IT基础架构稳定可靠的同时能够满足业务需求和支撑业务运作。

4 金融行业如何进行IT项目管理

(1) 建立IT应急协作机制。

突发事件影响金融机构的案例越来越多, 严重影响了金融业务的正常运行。而且, 金融业 IT系统大都是技术复杂的大型 IT系统 , 要依赖多家厂商、集成商、运营商的产品和服务, 有极强的专业性。在灾害、事故发生的紧急情况下, 金融机构依靠自身力量往往无法完成对所有故障节点的控制。因此, 加IT系统应急管理工作成为当前金融信息化建设的一项重要工作, 应进一步加强应急管理工作, 提高应急响应、处理和故障恢复能力, 确保IT项目安全、稳定运行。

(2) 通过在金融信息化建设中引入信息系统工程监理。

金融信息安全直接影响着国家安全, 对金融信息化项目实施临理, 有助于严格执行国家有关的业务、安全及技术标准, 符合国家和金融企业的根本利益。金融企业可以利用监理单位技术与管理经验, 依托国家规范, 强化系统集成软件过程管理和项目管理, 控制系统建设过程中质量、进度、投资以及变更等问题的出现。而且, 有了信息系统工程监理, 可以力求实现以担各自的责任、权利与义务, 明确和保护各方利益, 规范项目操作, 区分各方责任, 进而提高项目的执行效率。

(3) 对IT项目进行问题管理。

在金融机构中的IT项目团队能否有效解决项目执行过程中出现的各种问题尤其重要, 因此, 在金融机构实施 IT项目的实践活动中, 有必要结合现代项目管理知识对问题管理作进一步的研究和分析, 通过制定一套行之有效的解决问题的方法和问题管理机制, 快速提高项目团队识别、分析、解决问题的能力。这对于提高IT项目管理水平和组织工作效率, 提高IT项目社会经济综合效益, 实现成功的项目管理具有十分积极的推动作用。

摘要：在金融行业的发展过程中, IT项目在推动金融行业发展和创新方面显示出日益重要的作用。现在, 金融业务对计算机网络和信息系统的依附程度越来越高, 因此, 加强IT项目管理工作成为当前金融信息化建设的一项重要工作, 应引起各方面高度重视, 进一步加强IT项目管理工作, 提高应急响应、处理和故障恢复能力, 确保IT系统安全、稳定运行。

关键词：金融行业,IT项目管理

参考文献

[1]彭涛.IT项目问题管理的方法与实践[J].中国金融电脑, 2005, (8) .

[2]Nigel Knight.让IT投资获取更大回报[N].科技智囊, 2005.

[3]周晓燕.IT系统应急管理存在的问题及应对措施[J].计算机安全, 2007, (2) .

IT管理项目论文 篇9

一、项目介绍

1.项目背景

深圳机场公司成立于1989年5月, 位于珠江口东岸滨海平原, 占地面积11平方公里, 飞行区等级为4E, 机场实行24小时运行服务, 拥有跑道 (3 400m×45m) 、滑行道各1条, 可供世界上最大型客货机起降。现有客货机坪总面积58.8万平方米, 候机楼总面积14.6万平方米, 可满足年旅客吞吐量1 500万人次、年货物处理70万吨的要求。

随着深圳机场业务经营的多元化发展, 与其相适应的信息系统、应用系统成为亟待解决的问题;同时, 为了迎接市场环境的挑战, 降低成本和风险, 提高管理水平, 提高效率和效益, 增强市场竞争能力, 公司管理层认识到实施信息化及建设相应的支持经营管理的各类信息系统已成为公司参与竞争、快速发展的根本保证, 加快发展信息技术 (IT) 能力成为目前的迫切需求。为配合深圳机场的总体战略发展规划, 深圳机场将全面开展信息化建设工作。

2.项目现状

深圳机场目前网络设备几乎全部使用的是华三产品, 核心交换机是两台S8512聚合链路, 分别下联至各个汇聚层, 再由汇聚层下联各楼宇及部门。业务层包括对内服务区 (数据中心服务器群、系统管理服务器区) 、对外服务区 (DMZ区) 。

3.需求分析

本项目的目标是为深圳机场信息大楼弱电项目提供数据中心小型机及存储、网络设备、UPS和机柜等相关设备建设;同时负责二办信息机房到信息大楼机房的顺利迁移。本项目需要完成以下内容。

第一, 信息大楼网络系统基础建设, 本次要完成接入约一千八百个信息点, 组成一个千兆链路作骨干, 百兆接入到桌面, 并实现与深圳机场现有办公网络的互联。

第二, 信息大楼数据中心系统基础建设。

第三, 配合深圳机场其他弱电项目的实施, 提供信息大楼数据中心、网络接入及相关弱电系统的基础软硬件环境。

第四, 完成信息大楼正常启用后对二办机房的搬迁建设。

第五, 机房搬迁工程中应用系统、存储及SAN网络的重新部署。

4.项目实施机构职责

考虑到本项目是一个综合性的集成类项目, 在本项目的实施阶段, 依据XX科技项目实施过程管理方法论, 并充分考虑本系统建设项目的具体特点, 为保证项目的顺利进行, XX科技将与用户有关部门共同组建项目实施机构, 运作良好的组织机构是项目成功的关键。项目实施机构主要负责内容如下。

(1) 工程质量控制。

在工程管理工作的各个阶段严格审查关键性过程和阶段性结果, 检查其是否符合预定的质量要求, 而且整个工程管理工作中应当强调对工程质量的事前控制和主动控制。

(2) 工程进度控制。

信息系统工程开始之前, 必须确定相应的进度安排, 在工程进行过程中严格审查工程进度, 确保工程的工期。

(3) 工程成本控制。

信息工程进行过程中, 严格审查和控制工程成本, 对工程中所出现的任何变更必须严格审查, 核定变更费用。

(4) 知识产权保护。

在工程进行中, 对双方有关设计方案及技术等涉及知识产权的内容进行保护。

5.管理机构的管理工作

第一, 工程实施方案是工程实施的指南, 工程建设参照该方案确定工程实施的工作流程和内容。

第二, 根据工程实施方案, 确定工程实施子阶段和进度控制点, 同时明确各工程实施子阶段的工作内容及查验方式。

第三, 为了保证工程进度, 工程建设管理者应及时主动地了解有关硬件设备的采购进度。

第四, 对采购的硬件设备, 工程管理者应安排有关人员进行验收, 查验设备的数量、质量、功能。

第五, 软硬件设备的调试, 应该记录调试的过程, 分阶段地验证调试的质量, 并及时记录相关结果。

第六, 对于复杂系统的建设, 可以考虑创建一个模拟环境进行相关试验。

第七, 对于各个工程实施子阶段的完成, 应该形成阶段性报告, 以便及时总结工程质量和进度。

第八, 对实施过程产生的工程变更, 应组织人员进行细致讨论, 并核算变更成本, 形成有关备忘录。

6.项目实施机构组成

第一, 针对本系统建设项目, XX科技将联合硬件厂商, 与用户方相关人员共同组建项目实施机构, 具体如图示。

第二, 项目实施机构中的职能分工如下。

一是领导层:由用户项目领导小组有关领导及XX科技的领导层组成项目领导小组, 主要负责项目的总体管理, 保证项目进度;为支持项目的实施调动各种相关资源, 处理各种重要的情况等。项目管理小组将听取项目经理的汇报来进行监管工作。此外, 在项目进行中的不同阶段, 会有部分专家参与到领导层中, 负责提供技术、管理、实施等方面的专家意见或建议, 包括技术专家、管理专家或用户内部工作人员及其他下属单位工作人员等。

二是项目经理层:由用户本项目总负责人及XX科技现场项目经理组成, 主要负责项目进行过程中的关键点控制工作, 包括关键点检查、环境准备、问题协商、变更管理等, 对项目阶段成果进行检验以确保项目按照计划进度、计划成本、计划质量进行。

三是实施层:以XX科技的技术人员以及厂商技术实施人员为主, 用户方技术人员及系统操作人员参与配合, 在各阶段现场项目经理领导下负责项目的具体实施工作, 质保组负责质量保证体系检查工作, 商务组负责软硬件厂商协调及用户方协调商务工作 (如付款等) , 用户方外聘的技术专家也将参与到项目的实施过程中, 对项目的进展提出参考性意见和建议。

四是实施组:根据项目实施的分阶段目标, 设立阶段现场项目经理, 由具有丰富的本阶段工作任务经验的项目经理担任, 负责组织相关实施人员, 完成本阶段工作任务。根据阶段目标任务的不同, 实施组将包括详细设计组、系统测试组、用户培训组、系统集成组等。例如在项目需求调研阶段, 现场项目经理调配需求调研分析师, 完成现场调研分析工作, 制定详细分析报告, 在与用户充分沟通后确认项目需求。

五是质保组:客观评价项目实施组的工作质量、用户的满意度, 持续监控项目后续推进的效果。

六是商务组:负责协调相关厂商, 获得技术层面和商务层面的有效支持, 例如设备、平台的技术要点交流及维护服务支持等。

七是技术组:由项目相关外围产品及自有产品专家和技术工程师组成, 负责解决与产品相关的关键问题, 在后台支持实施组的工作, 解决技术难题, 指导实施组技术人员完成项目实施工作。

八是用户方内部工作人员及技术人员:配合实施组人员完成业务到系统的转化任务, 提供初级需求, 并配合实施组人员将其转换为系统设计, 参与、监控系统的实施过程, 确认系统实施成果。

九是外围技术专家及政策专家:从技术及政策角度对项目过程提供支持, 对业务需求分析结果进行优化设计, 对关键技术路线进行判定和选择。

二、项目组项目管理计划

随着项目实施机构的组成, 机构的工作方法 (即项目的管理计划) 也将一并制定完成。主要的项目管理计划包括以下几项内容。

1.项目启动计划 (Project Initiation Plan)

项目启动计划作为整个项目中最重要的纲领性文件, 包括项目范畴、项目目标和要求、工程管理队伍组成、各方责任和工作定义、项目阶段性定义、评估标准等。

2.项目沟通计划 (Project Communication Plan)

项目沟通计划将包括各工程管理成员的联系方法、工程会议的召开和议题、工程问题的跟踪和升级、各厂商和代理商协调等内容。

3.项目实施计划WBS (Work Breakdown Structure)

按阶段实施的工程项目通常都需要划分不同的阶段并规定各阶段结束的标志和条件为里程碑 (Milestone) , 项目实施计划WBS将划分各阶段并制定各阶段的详细工作任务 (process) , 并规定各阶段的紧急路线以保证工程进度。

4.项目变动管理 (Change Management)

任何对上述计划的变更, 无论是人员、外部设施、工程目标、技术要求、实施进度或其他, 都将给实施带来不便与混乱, 项目变动管理将评估项目变动给工程管理带来的损失, 并制定应对措施。

5.项目风险管理 (Risk Management)

项目风险管理将评估诸如设备、外部设施、软件、变更、技术手段等存在的风险和不确定因素对项目造成的影响, 并预先制定应急措施和对策。

6.项目进展评估 (Progress Measurement)

项目进展评估在技术指标、安装指标、按照步骤实施、进度、文档等方面对阶段结束和阶段进行中的工作进行评估, 以保证工程的质量和进度。

7.项目验收和评估 (Closeout and Evaluation)

项目验收和评估, 在整个工程结束后将对网络系统进行测试和验收。其测试标准和步骤及系统的功能、性能等指标将作为验收和日后维护依据。

项目概念比较广泛。不是只有建筑、IT等大的工程项目才能称之为项目, 小到组织一场演出、搬一次家、举行一场婚礼, 都能称之为项目, 也都可应用项目管理的知识对这些项目进行科学的管理。 项目管理近年来在各领域运用非常广泛, 项目管理这门学科本身也在发展。在各行各业竞争越来越激烈的今天, 能够用项目管理这门工具, 整合各种资源, 有助于项目的范围、时间、成本、质量、人力资源、沟通、风险等方面采用科学的管理方法。运用项目管理, 无疑会大大提高项目的成功几率和项目的质量。

参考文献

IT项目管理中的风险认识 篇10

1.1 外部风险

外部风险主要是指那些超出项目经理乃至整个项目组织控制范围和影响力的干扰因素, 主要体现在: (1) 市场和政策的变化;一方面, 市场需求的多变以及新产品、新服务的不断更新替换可能导致IT项目建设方向的急剧改变, 这对绝大多数的项目来说都是致命的;另一方面, 与IT项目管理相关的政策从无到有不断涌现, 给实施项目的企业设置了越来越多的约束。比如金融项目的进行过程中的新金融政策的颁布就可能导致需求、设计及算法的彻底翻盘。 (2) IT行业的迅猛发展;IT行业被称为朝阳行业的根本原因就在于这个领域出现的时间不长而发展又非常迅速, 所以, IT项目必然面临层出不穷的新标准和新趋势。 (3) 自然灾害的出现;火灾、洪水、地震等自然灾害对IT项目的建设而言是不可忽视的客观存在, 其破坏力之大往往超出人们的想象, 而自然灾害的随机性使得项目组织一般很难做出预测。 (4) 威胁IT项目的安全因素;电力短缺、安全漏洞和黑客攻击等因素都会对IT项目管理造成重大的损失, 这些因素一般也是危害严重而又很难事先控制的。 (5) 相关法律问题。

1.2 成本风险

成本风险指因项目或项目组织的变化或失误从而影响项目成本控制的隐患, 主要包括: (1) 项目运营成本溢出;由于IT项目的人员组成复杂且流动性非常强, 项目人员良莠不齐, 既懂技术又懂业务的综合素质人才缺乏, 加上项目运营牵涉如客户的干预、客户沟通能力等不可控因素较多, 因此运营成本溢出的可能性非常大。 (2) 项目范围的改变导致成本上升;客户需求的反复变化和信息技术的不断发展导致IT项目范围的改变是项目经理经常遇到的现象, 随之而来的便是项目成本的不断上升甚至成倍增长。 (3) 出现未估算的项目成本;虽然IT项目在进行规划时就应做出精确的成本估算, 但成本估算毕竟是一项预测性的工作, 在实际操作过程中难免会产生错算、漏算从而导致未估算的成本项目的出现, 因而影响整个项目管理的成本和绩效。 (4) 项目预算超支。

1.3 进度风险

进度风险指由于错失或延误IT项目产品或服务的市场机会而导致项目失败的可能性, 其直接表现: (1) 项目进度估计不准确进度管理虽然是IT项目管理中非常重要的环节, 但往往在进行项目进度估计时需求还没搞清楚, 因此出现项目进度估计不准也是项目管理中经常碰到的棘手问题。 (2) 过多的技术、运营和外部问题牵扯项目进程。 (3) 资源短缺或变更导致项目进度拖延。

1.4 技术风险

技术风险指干扰项目达到预期功能或性能目标或期望的不可靠因子, 突出表现在: (1) 技术成熟度不够。 (2) 开发与管理工具选择不当。 (3) 项目测试不充分或不严谨。 (4) 软硬件的集成矛盾。

1.5 运营风险

运营风险指项目无法达到预期收益目标或期望的可能性。 (1) 对优势和冲突的理解不充分。IT项目组织和客户之间沟通的一个要点就是要确认项目的优势和冲突, 从而避免对项目认识和理解上的分歧, 以较好地调和项目的优势和冲突。 (2) 未指派合理的权限。在IT项目管理中经常强调的“一把手原则”经常在实际工作中被忽视, 而不能给关键人物指派合理的权限的后果是项目管理的混乱。 (3) 沟通不善。在IT项目管理中, 构建良好的沟通机制和渠道是项目经理的重要职责, 但很多项目经理忽视了沟通的作用, 甚至连基本的沟通计划都没有, 这不能不说是一种极大的隐患。 (4) 多项目管理。现代的项目管理型组织都是以项目为基础, 一般来说组织级别同时运行多个项目, 然而项目多、资源紧、任务重所带来的全面铺开但是全面滞后甚至全面失败的结果也是极有可能发生的。

2 加强IT项目风险管理的对策

2.1 I T项目风险管理计划的制定

风险管理计划是所有IT项目都必不可少的, 它应该作为一个独立的部分纳入项目的整体计划。计划的制定者可以是项目经理也可以是项目风险管理的负责人, 在制定计划时应该重点强调的几个因素包括:风险的识别、确定风险管理的范围、量化风险明确风险管理的时间要求和阶段目标、配置和计划用于风险管理的资源、制定风险管理应对措施和应急预案。

2.2 项目管理中风险的识别、评估和检测

识别IT项目潜在的风险是一项非常关键的任务, 一般来说, 可以采用特尔斐法和头脑风暴法识别可能威胁IT项目成功的绝大部分风险。在识别了风险以后, 可以从风险的可能性、严重性和可控程度三个方面来评估IT风险的破坏力, 使用可能性量表、严重性量表和可控性量表工具对风险进行定量分析后, 可以将其分为高、中、低三类并生成项目管理风险观测表。接下来要做的工作便是在整个项目管理过程中利用此文件对项目风险进行监控并定期召开例会或形成报告, 一般来说至少每周一次, 如果情况特殊, 会议和报告的周期还可进一步缩短。

2.3 项目风险管理资料的收集和整理

在实施IT项目风险管理的过程中收集和整理风险管理的资料和数据, 总结成功经验固然重要, 但更为可贵的是那些失败的例子和教训。收集风险管理的资料和数据不但有助于建立项目风险管理的知识库和模型库用于识别和评估风险, 更重要的是能为项目风险管理计划和项目风险应急预案提供反馈以促进其完善。

3 持续风险管理的步骤

3.1 识别项目风险流程改进机会

这一阶段的目标是选择适当的项目风险流程用于改进。例如, 工程实施中土地使用权获取、建筑设计、融资分析的关键环节和过程, 对整个项目前期工作的效果和目标影响重大, 因此作为关键的风险流程用于改进。

3.2 评价需改进的风险流程

这一阶段目标是选择有挑战性的问题及确定改进的指标。重点就是把需改进的项目风险流程的具体指标细化, 并确定改进的具体目标。

3.3 分析项目实施中存在的问题

这一阶段目标是识别目前风险管理中存在的原因, 充分利用有关工具和方法找出原因。

3.4 采取措施

计划并采取适当措施改正不规范的做法, 针对风险管理工作流程进行改正, 以达到目的, 消除存在的问题。

3.5 确认改进的结果

评价采取的风险管理措施是否达到了目标。

3.6 改进方法标准化

这一阶段主要目标就是确保项目风险管理的水平得到维持, 要确保已经改进的工作效果通过制定的管理流程图、程序、制度、标准等已成为日常工作的一部分, 并可以把这一阶段的规范化管理成果推广到其他过程或部门。

3.7 为下一阶段或未来项目进行计划

主要针对遗留问题制定计划并评价其效果, 通过学习其他部门的经验为下阶段工作和未来项目提供规范化管理的知识。

总之, 前风险管理在IT项目管理中并没有得到应有的重视, 因此从事IT项目管理的专业人员必须通过学习或培训了解风险管理的重要性并掌握风险管理的知识和防范风险的方法与手段, 也只有将风险管理的内容纳入正规培训日程才能突显其重要性。

摘要：在IT项目管理中, 应该任命一名风险管理者。从风险管理的角度对项目规划或计划进行审核并发表意见, 不断寻找可能出现的任何意外情况, 提出各个风险的管理策略及常用的管理方法, 以随时处理所出现的风险。

关键词：IT项目,管理,风险

参考文献

论IT项目团队激励设计 篇11

一、IT项目三阶段生命周期观

（一）IT项目的含义和特点

一般地，IT项目即为解决信息化需求而产生的软件、硬件、网络系统、信息系统、信息服务等一系列与信息技术相关的项目[2]。例如：为大学校园信息基础设施升级以使其能够提供无线上网服务、一个公司为增加销售而开发一个新系统、汽车工业开发一个Web站点等都属于IT项目[3]。一个典型的IT项目具临时性、紧迫性、独特性、智力密集性和不确定性等特点。

（二）IT项目生命周期的三个阶段

IT项目的生命周期描述了IT项目从开始到结束整个过程，这个过程一般包括可行性分析、业务重组、系统规划、系统需求分析、系统设计实现、系统测试、系统实施、系统验收等几个阶段。在项目实际中，根据项目自身特点对这些阶段可以有不同程度的裁剪。在这里，笔者将IT项目划分为初始阶段、中间阶段和最后阶段三个阶段（图1）。

初始阶段的主要工作是组织好可行性论证，组织好开工前的人、财、物准备。中间阶段的主要工作是保证项目的质量、成本和进度。最后阶段主要是评审、鉴定、交付和总结工作。IT项目生命周期内，项目耗费在初始阶段较低，在中间阶段达到最高，当项目接近结束时则快速下降；项目的不确定性和风险在初始阶段较大，随着项目的进行，不确定性和风险性随之减少，成功率随之提高，直至最后完成验收，项目结束。

二、项目团队激励相关理论

激励来自个体内部和外部，是一个由能够对个体行为产生影响的动力和关系构成的系统，它使人们按照一定的方式做事[4]　。IT项目经理通过运用各种激励因素，刺激团队成员的需要，激发其动机，使其朝着所期望的目标前进。常见的激励理论主要有维克托·弗鲁姆（V.H.vroom）的期望理论、伯尔赫斯·弗雷德里克·斯金纳（B.F.Skinner）的强化理论以及约翰·斯塔希·亚当斯（J.S.Adams）的公平理论等。

期望理论又称作“效价—手段—期望理论”，是由北美著名心理学家和行为科学家弗鲁姆（V.H.vroom）于1964年在《工作与激励》中提出来的激励理论。维克托·弗鲁姆围绕目标和需要提出基于“个人努力→个人成绩（绩效）→组织奖励（报酬）→个人需要”的激励模型，指出要激励员工，就必须让员工明确：（1）工作能提供他们需要的东西；（2）他们欲求的东西是和绩效联系在一起的；（3）只要努力工作就能提高他们的绩效。强化理论是美国心理学家和行为科学家斯金纳（B.F.Skinner）等人提出的一种理论，也叫“行为修正理论”。强化理论认为，可以通过运用“正强化”或“负强化”的办法来影响员工行为的后果，从而修正其行为。正强化又称积极强化，是用于加强所期望的个人行为，如奖金、晋级、表扬等；负强化又称消极强化，是为了减少和消除不期望发生的行为，如批评、行政处分、经济处罚等。公平理论又称“社会比较理论”，由美国心理学家亚当斯（J.S.Adams）于1965年提出。该理论是研究人的动机和知觉关系的一种激励理论，认为员工的激励程度来源于对自己和参照对象的报酬和投入的比例的主观比较感觉，在报酬（薪酬、奖金、晋升、荣誉等）的分配上，团队成员更注重自己和别人的横向比较，以及自己目前与过去的纵向比较。

三、IT项目生命周期各阶段的团队激励设计

（一）基于期望理论的初始阶段团队激励设计

初始阶段是团队的组建与形成阶段，许多规范和制度在这一时期被定义，项目经理和团队成员需要就项目目标达成共识。在共识的基础上，IT项目经理必须让团队成员认识到通过努力可以实现自己的各种需要，并就共同的IT目标对自己的工作做出承诺。在IT目标的导向下，团队成员为目标的达成而努力工作，往往会沉浸在对未来的美好期待中。在IT项目的初始阶段，项目经理一方面应当提高员工对报酬的偏好程度，提高效价；另一方面，项目经理必须帮助员工达成绩效，以便提高员工的激勵力。基于期望理论的激励设计如图2所示。

项目经理该阶段的主要工作是掌握团队个人的真实需要、确定满足个人需要的途径、为成员指定关键指标、确立鼓励或抑制其行为的原则等。为此，项目经理要与团队成员充分沟通，项目经理应了解到团队成员的需求期望是什么（奖金、福利、职位、职业培训等），从而找到团队成员的驱动点，使团队成员知道如果达到某一绩效水平，组织会给我什么样的奖赏或报酬，而这一绩效是完全可以通过努力工作实现的。

（二）基于强化理论的中间阶段团队激励设计

中间阶段是团队磨合、规范的阶段。团队成员执行初始阶段分配的任务，期间一般会遇到各种未预料的困难，项目经理和成员矛盾显露，成员个体之间也可能相互指责，并可能导致团队成员对项目经理和项目未来产生怀疑。保障项目的有效执行，确保项目的质量、成本和进度是摆在项目经理面前的首要任务。在IT项目执行过程中，项目经理应承担起领导者和资源提供者的角色，对项目的有利行为（配合默契、bug的减少等）及时奖励，对不符合项目利益的行为（进度拖延、投诉的增加等）及时修正，引导其完成预定的IT目标。基于强化理论的激励设计如图3所示。

IT项目团队成员属于知识型员工的范畴，一般都比较年轻，具有较强的自主意识、成就动机和创造性和流动意愿[5]。项目经理一方面需要尊重员工的个性与创造力，赋予员工更多的权限，更加人性化的管理；另一方面，项目经理还需做好一个重要但也是常被忽视的工作：记录团队成员的绩效表现。对团队的激励不仅是基于结果的激励，更是基于过程的激励，不仅要看最终的工作成果，还需要综合考虑团队成员的行为能力、工作态度、合作情绪，并且把这些记录下来，为强化实施提供事实依据，使奖惩更加公平、公正，更加具有说服力。

（三）基于公平理论的最后阶段团队激励设计

IT项目具有临时性，但团队成员往往不会随着项目的结束而从公司解散。做好项目后期的团队激励管理，能够避免在项目攻坚时期关键成员的流失，或为后续项目的开展埋下不利的种子，有利于项目的胜利验收和下一项目的顺利开展。公平理论认为，当一个人察觉到自己的工作与所得到的报酬之比同其他人的工作与报酬之比相等时就公平，否则就不公平。员工能否得到激励，不仅是他得到了什么样的报酬，更重要的是与别人相比，这样的报酬是否公平。

因此，项目经理在用报酬（薪酬、奖金、赏识、晋升、荣誉、休假、培训机会等）来激励员工时，要使员工感到在团队内部是公平的，在本项目组与其他项目组的外部比较中是平衡的。项目经理除了设计科学合理的绩效评估体系外，还应采用灵活的激励形式，如以薪资发放为例，良好的薪资发放形式能增强激励效果。目前薪酬发放形式主要有两种，公开发放和秘密发放。公开发薪可以减少薪资发放的暗箱行为，并能够及时从IT開发人员的反馈中得到建议，进而进行修正；秘密发薪则可以避免团队内成员互相攀比，消除某种程度上的不公平感，使高薪者不被非正式群体歧视，使低薪者不感到自卑。另一方面，公平理论表明，人们在心理上往往会低估他人的工作成绩，而高估他人的得益，由于这种感觉上的错误，就会产生心态的不平衡。所以项目经理应有敏锐的洞察力来体察员工的心情，如有不公，应尽快解决；如纯属个人主观上的认识偏差，也有必要及时进行解释说明，做好思想工作。

四、小结

IT项目涉及的因素很多，其中人是最重要的因素，如何设计有效的激励机制以提高项目团队的工作积极性一直是项目经理们追求的目标。项目生命周期理论已经引起了众多学者的注意，目前基于项目生命周期的激励尚未有成熟的行之有效的模型。把握IT项目生命周期固有的特点，针对IT项目生命周期的不同阶段应用激励理论分别进行激励设计，有利于提高项目经理激励管理效率。

参考文献：

[1] 谭武梁，等.　IT项目管理[M].北京：中国铁道出版社，2007.8

[2] 舒华英.　IT项目管理[M].北京：北京邮电大学出版社，2006.

[3] Kathy　Schwalbe　.　IT项目管理（英文版.第4版）.[M].北京：机械工业出版社，2006

[4] David　I.Cleland，Lewis　R.Ireland.项目经理便携手册[M].北京：机械工业出版　社，2007

[5] 张招存.如何激励知识型员工[J].社科　纵横，2006，21（3）：44-51

作者简介：曹立明（1982-），男，湖南湘潭人，讲师，工程师。从事管理信息化研究。

（湘潭职业技术学院）

集成类IT项目的特点与管理方法 篇12

近几年随着IT企业的快速发展, 宝信公司业务增长以冶金行业为基础逐步扩展到以信息化发展为基础的多个行业领域, 其中集成类IT项目的管理最为复杂, 也是企业发展的管理瓶颈, 因此急需探索和研究一套适合集成类IT项目管理的方法。分析集成类项目的特点有:

(1) 项目范围包罗万象

IT企业的集成类IT项目的范围一般包括:系统总体设计、硬件采购与集成、软件开发、设备集成、网络配套、运行维护等。这类项目不仅需要软件技术和软件管理知识, 还需要硬件、制造、采购、网络、服务等多个领域的知识, 因此要成功实施一个集成类IT项目将是相当复杂和困难的。

(2) 涉及行业知识面多

IT项目管理的书籍很多, 理论也很成熟, 很多软件企业的软件项目管理已经非常成熟, 甚至可以达到CMMI5的认证, 但是对于集成类的IT项目就很少有论述, 也很少有比较成功的案例分析。原因是多方面的, 其中主要原因是很少有企业能够既精通软件开发, 又懂得计算机硬件或电气设备集成;既能够进行信息化工程的系统设计, 还能够实施网络的安装和施工;既懂得不同行业领域的信息化流程, 还能够进行专业化的运行维护。

(3) 用户需求不确定

集成类项目涉及的最终用户很多, 很多最终用户在项目初期对自己的需求往往不可能完全认识清楚, 只有随着项目的逐步进展, 才会对需求越来越清晰, 并且各个不同最终用户的需求之间也会有相互矛盾的地方。这种需求难以确定的情况在集成类的IT项目中常常是不可避免的, 却会对项目的技术、成本、进度和质量造成很大影响。

(4) 对内对外的技术接口、管理接口复杂

集成类IT项目的接口非常多, 这些技术接口不仅有项目组织内部的, 还有项目组织外部的;不仅有与用户之间的管理接口, 还有与其他项目相关方的接口;这些项目的接口管理也是项目管理中不可忽视的环节。

(5) 工程的外包控制风险大

绝大多数软件公司在这类项目中不可避免的要通过外包的方法来解决本组织内部不能处理的部分, 这是解决组织内部资源不足的最佳途径。但是项目的外包部分一般是项目组织不熟悉的技术或业务, 加之对外包方的管理不同于项目组织内部管理, 所以外包部分是集成类IT项目的薄弱环节之一。

(6) 市场需求强烈

集成类IT项目是一个系统工程, 管理非常复杂, 项目的成败影响也非常大, 因此, 需要实现信息化工程的用户组织大多不愿意因为如此复杂的工程而使自己一头陷入管理的泥潭。所以, 他们的需求就是寻找到一家具有这样管理实力的公司, 然后采用总包形式, 用一纸合同搞定项目的所有问题。同时, 全球信息化的发展前景造就了这样的市场需求。

2 实施过程中的共性问题

本人直接参与过多个大型集成类IT项目的过程管理工作, 因此积累了一些这类项目在管理上的经验。从已经实施和正在实施的项目过程来分析, 集成类IT项目实施过程中存在的一些共性问题有:

(1) 项目干系人管理问题

很多IT项目失败的原因是最终没有满足某些关键项目干系人的需求, 一方面某些需求来源于对IT技术不甚了解的业务人员, 他们不能很好地理解IT技术转化后的业务形式的转变, 会感到不适应或担忧。另一方面, 当新建的系统打破了干系人某种习惯已久的工作方式, 甚至会涉及他们的权利和利益关系转变, 便会非常抵触。

很多项目的问题, 仅仅将项目目标聚焦在项目合同上或已经确定的功能需求上, 忽略了对干系人的潜在期望的管理, 以至于在整个项目过程中会不时受到各种不同干系人意见的困扰, 最后导致所实现的系统不能完全满足用户需求。

(2) 系统技术平台设计问题

系统技术平台是IT项目的基础, 这个基础在项目初期的依据是项目的需求、项目经费和项目初期的技术水平。但是最终的需求往往超过最初设计的系统负荷, 经费是不能增加的, 因为IT技术的飞速发展当初的技术水平到了项目后期已经变得落后。因此最后常常发现系统表现出来的性能使用户无法接受。

设计系统平台期间, 不能仅考虑项目的进度、费用, 在初期模糊不清的需求上, 匆匆设计定稿, 这无异于在一个不结实的地基上建立一个大厦。所有系统平台的设计应当对系统最大的负荷情况给出精确的度量数据、对系统的最终操作响应时间进行综合考虑, 最好能够给出计算的数学模型。

(3) 里程碑评审的策划和执行问题

每个项目计划阶段都会确定几个重要的里程碑阶段, 而里程碑阶段的评审却没有进行周密而详细的策划, 评审人员、评审人员的能力资质、评审的主要内容、评审后问题的跟踪解决。

主要原因是:用户方会因为担忧评审确定后会给自己今后的需求变更增加难度, 项目开发方因为某些细节在设计阶段无法完全确定, 也不坚持严格的评审。在这样的情况下, 项目的各个设计阶段的入口和出口就变得界限不明, 阶段工作产品的基线无法严格建立。

(4) 外包管理问题

面对集成类项目的复杂需求, 很少有软件公司能够全部包揽项目的所有工作, 分包已经成为集成类IT项目管理中一个必不可少的环节。而在集成类IT项目管理中每一个环节的工作产品都是整体的一部分, 都会影响整体的质量。如何保证分包商最终交付的产品质量、开发制造过程是否能够符合质量保证的要求, 都是集成类项目需要考虑的问题。

虽然很多项目对分包商的最终产品要求通过合同已经有明确而详细的规定, 但是整个过程的管理因为繁琐而困难, 所以往往过程中的管理被忽略, 寄希望于最终的合同约束。但是当产品交付时才发现问题, 为时晚矣, 成本和时间已经消耗, 对主合同的影响已经无法挽回。

(5) 变更控制管理问题

在IT项目中变更是绝对的, 但是变更必须控制, 对于每一项重要的变更都可以被追溯, 这样才能保证项目的最终验收。

由于项目组与用户为了共同的项目目标长期工作在一起, 逐渐放弃了看似繁琐而形式化的变更流程以换取工作效率。变更没有被记录、缺少可追溯性, 不仅在项目验收时缺少验收依据引起项目双方扯皮;而且在没有严格的变更影响分析的情况下实施变更, 很多变更会使项目向着不利的方向发展, 却不能及时发现, 最后引起返工。

(6) 配置管理问题

集成类IT项目涉及的技术面很广, 也很复杂, 因此整个过程中所产生的文档非常多;另一方面, 信息化项目的需求是逐步修正和细化的, 因此整个开发过程所产生的文档是需要不断进行版本更新。因此, 面对如此复杂、繁多、并且不断更新的项目文档, 必须有一个有效的方法或工具, 才能保持文档的有效性和可追溯性。

很多项目即使手头有很好的配置管理工具, 但是由于项目的进度压力、技术压力, 忽略了配置管理工作或虽然进行了配置项的识别和记录, 但忽略了配置项的维护工作。在这样的情况下, 项目各个阶段产品的有效性会下降, 很难进行严格的项目阶段性验证。

(7) 系统测试问题

从国内外大量的IT项目开发情况来看, 项目的进度压力在各个项目的后期变得越来越大, 如果用户方对于系统运行的时间点非常严格或合同执行要求严格, 前期的进度压力会推给测试阶段。然而多数项目的测试并不要求完全遍历的, 所以通过减少测试阶段的工作质量和工作量, 可以加快项目进度, 同时也有侥幸通过项目验收的可能性。

有些项目由于在后期测试阶段的工作质量不尽理想, 给项目留下不少隐患, 造成系统实际投运后, 合同保质期期间还不断发生用户投诉。

(8) 计划的监控问题

项目管理的最重要环节就是制定项目计划, 并且随着项目的开展, 对项目的工作性质有更多的认识之后, 应该分阶段对项目计划进行细化。并且按照这样细化的计划, 进行实绩跟踪, 以便于及早识别计划与实绩之间的偏差。一旦发现偏差超过警戒范围, 就应当分析原因, 然后进行计划的调整。只有这样才能确保整个项目是可控的。

但是很多计划不如变化, 造成项目经理对计划工作丧失信心, 觉得制定计划只要在项目开始阶段大家达成共识即可, 项目正式开始之后, 根据变化再见机行事。这样, 既不对项目计划进行阶段性的细化, 又不做实绩跟踪, 所以当发现计划与实绩的偏差很大时, 既无法分析原因找到针对性解决方案, 又不能及时弥补偏差, 因为较晚的项目计划调整, 所付出的代价会远远大于较早阶段进行调整所付出的代价。

3 集成类IT项目管理方法的思考

综上所述的集成类IT项目的特点和项目实施过程的现状, 已经可以感受到此类项目的实施难度。从整个IT行业来看, 真正有勇气承担此类项目的企业并不多, 而且最终完全达到项目既定目标而成功的就更加寥寥无几。即使在国外, 有专业的调查机构做过统计, 此类项目的成功率也是非常的低, 不超过28。的确这个市场对于IT企业来说是一种机遇也是一种挑战, 对于从事项目管理的专业人士来说就更是一个值得研究和尝试的领域。

图1已经直观地反映了集成类IT项目的管理特点, 需要综合多个学科的管理知识, 是一个系统化的管理过程。

相对而言, ISO 9000只能给企业或用户一把衡量整个企业质量管理程度的标尺, 而不能为具体的项目管理提供解决方案的指导。但是基于ISO 9000的管理思想衍生出来的软件质量管理方法为我们在控制软件过程质量和产品质量方面提供了比较具体而有针对性的借鉴。PMBOK项目管理知识体系指南确实给出了项目管理的一些具体方法, 它是美国项目管理协会在30多年来各种领域项目经验的基础上总结出来的项目管理的共性知识, 几乎适用于所有领域的所有项目, 集成类IT项目也不例外。但是PMBOK也强调, 在具体项目的执行过程中一定要在共性的基础上考虑个性问题, 这才符合PMBOK所定义的项目的基本特点:一次性、特殊性、渐进明细。IT项目管理的特点决定了仅仅套用PMBOK这套具有各个行业领域共同特征的项目管理方法不足以满足项目管理中的特殊需要, 必须要有一套符合行业特点的管理方法, 相互结合、互为补充才能真正有效地进行集成类IT项目管理。CMMI软件成熟度能力模型集成就是一个合适的选择。

可以通过CMMI过程评估的方式来分析组织的现状, 诊断组织项目实施过程中存在的缺陷, 同时这一环节对于组织进行集成化的过程改进是必不可少的。对照CMMI的过程域要求, 对组织目前按照PMBOK项目管理思想为主线形成的集成类IT项目过程进行评估, 就可以找到一个以集成类IT项目管理过程为基础的结合点, 将PMBOK和CMMI两者巧妙地结合起来, 用系统化的方法, 建立更加科学的、完善的、符合IT项目特点的组织定义规程, 这是成功管理集成类IT项目的一个基础。

摘要：以PMBOK项目管理思想为基础, 结合集成类IT项目的具体实践, 经过多个项目摸索, 寻找CMMI模型与集成类IT项目管理过程之间的映射关系。在此基础上进行归纳、总结、提炼, 提出了一个初步的、基于CMMI模型的集成类IT项目管理体系架构。

关键词：CMMI,ISO质量管理体系,PMBOK项目管理,知识体系指南

参考文献

[1]Dennis M Ahern, Aaron Clouse, Richard Turner.CMMI Distilled[M]北京:清华大学出版社, 2005.

[2]罗运模, 谢志敏.CMMI软件过程改进与评估[M].北京:电子工业出版社, 2004.6-8, 356-359.

[3]中国标准研究中心.GB/T 19001-2000质量管理体系要求[S].北京:中国标准出版社, 2000.