it项目管理

前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇it项目管理范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。

it项目管理范文第1篇

【关键词】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].西南交通大学 2010

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

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

it项目管理范文第2篇

[关键词] 项目管理 客户管理 客户角色

一、前言

作为以软件开发和实施为主的IT企业，其项目管理的主要工作就是能够合理的利用企业研发、服务、销售和客户等各方资源，在总体成本和工期的控制范围内，能够按期或者提前完成项目建设，满足甚至超越客户需求，完成项目验收和回款。项目需求来源和最终结果好坏的裁判就是客户。所以客户作为项目最重要的干系人，对软件项目的影响至关重要。项目管理中的客户管理包括客户甄别、客户需求管理、客户沟通、客户投诉管理等各个方面的内容。

二、软件项目客户

为了提高客户满意度，现代的软件项目管理方法都向以客户为中心、客户驱动、客户参与的项目管理方式转移。所以我们必须认识到客户是软件项目成败的核心因素。正确的识别和定义软件项目的客户，这是IT企业客户管理成功的基础。

比如，某IT企业的软件开发类项目，其项目目标是针对电信运营商的网络管理中心和运行维护部门的实际生产和管理需求，需要解决他们的实际工作问题:自动化网络维护工作，规范化工作流程管理等。因此，该企业开发出来的产品，能否解决客户的实际工作问题和困难，最终用户是否满意，项目直属领导是否满意，能否解决实际的网络维护和保障问题，给运营商创造了多少直接和间接的价值，是否能落实客户领导的管理思路，是判断该产品或项目是否成功的标尺。由于企业的产品需求来源是客户，最终评判也是客户，所以要做好软件项目的管理，就要在需求调研、需求评审、验收软件项目流程的几个关键环节上明确具体客户和客户责任，包括哪些是最终客户，哪些客户负责提需求，哪些是决策客户，哪些是验收客户（验收客户最好与提需求的客户是同一个团队或个人）。同时客户也要明确相应的职责，明确他们在项目中的地位和角色，才能提高企业产品的针对性、准确性，促进项目顺利进展，促进项目验收和回款，甚至衍生出新的或者下一期的项目。

所以，在软件项目中，需要明确以下四种客户角色：

1.要明确最终使用部门和用户，要去了解他们现有的工作方式，要让他们知道项目的目标框架，知道项目要解决他们的哪些困难，但绝对不是全部困难，这样可以较好的控制项目范围。

2.要明确需求的提出者，他或者他们要能够代表最终客户群体。提出产品需求的这类客户要具有一定的技术、业务能力和权威，能够真正代表最终客户团队的意愿和想法，最好有IT基础，能够用IT语言描述问题和需求，以利于双方的沟通、协作，避免产生歧义。

3.要明确做需求确认的中层领导,他要把握方向。软件开发项目是解决实际生产或者管理问题，同时也是领导系统建设的具体实现,做需求确认的客户领导,既要了解高层领导的系统建设要点和方向,又要谙熟具体业务和生产管理实际。如果是这样的客户领导来把握和决策，对企业软件开发项目的顺利进展作用非凡。

4.要明确谁来对成品提意见，谁来验收。项目验收环节，是项目的收尾环节,如果验收的人对项目初期的需求目标不了解，会从态度和产品实际使用效果上对验收产生负面的影响，对提品的企业关闭项目非常不利。根据实践总结,由需求提出人和确认人来做项目的验收工作,能够促进项目的顺利完成,避免延期。

三、软件项目各阶段的客户管理

IT企业软件项目的实施较之于其他项目，有其特点。也决定了该类企业的客户管理工作的独有特性。在通常情况下，软件项目分为四个阶段，分别是:需求识别阶段、制定方案阶段、实施阶段和结束阶段。

由于软件项目的各阶段具有不同的特点，所以始终贯穿于项目各阶段的项目客户管理在不同的阶段实施的内容也有差异。

1.需求识别阶段。需求对于软件项目来说是一把双刃剑，它既可能让一个项目成功，也可能让该项目失败。对于项目组织而言，该阶段非常重要，需精确识别客户的真实需求。因此，在该阶段，项目经理应充分与客户沟通，组织内其他与项目相关的成员也必须频繁活动，通过一切渠道充分获取关于客户的所有信息。随后，项目团队应对收集到的信息加以汇总并进行深层次、多角度的分析，随时将不明确之处反馈于客户，以期客户解答，并要求客户审核需求分析书，达到与客户的真实期望高度一致。同时，项目方还要做好需求和需求的变更管理，切实捕捉客户的真正需求，避免开发资源的重复劳动，缩短开发周期。因此，我们需要在以下几方面做好管理工作：

(1)需求沟通和描述的规范化。要用标准化的工作方式和工具与客户沟通并描述需求。一些规范的需求调研与沟通手段，诸如随工、问卷、原型展示等，都可以针对实际情况来使用，其主要目的是更准确的把握客户需求。需求描述文档要针对不同的需求部分，比如界面应用、处理逻辑等，通过标准化的文档模板来描述和表现，并和用户确认落实，填平需求和功能之间的鸿沟，同时给后端研发提供可管理的开发点介入。

在理解和认同客户需求方面，我们需要把握以下几点：

①能够站在客户的角度，知道什么需求是对的，什么需求的应用是更适合的;②客户了解业务语言，开发人员了解IT语言，应用需求和开发之间的鸿沟，有时需要产品经理去填平;③提倡以草图或者可视信息化的方式和用户沟通，确认界面、业务需求;④要学会换位思考，针对不同层面的客户提供最适合的操作界面，用户觉得好用的才是真正好的软件产品;⑤要抓住重点需求，尤其是客户方领导关注的创新类和实用类需求。

(2)需求变更的规范化管理。需求变更在软件开发类项目中是正常的也是可以理解的，对需求变更需要做规范化的管理。一方面避免出现需求反复无止境的风险，另一方面可以一步一个脚印的落实资源调配和项目实施。需求变更需要经过统一的接口人提出，并且要用户需求的审核领导认可，需求变更要定期而不是随时的提出，我们要做好详细的记录，让客户能够了解需求变更的实际情况，了解客户自身和我们为之付出的成本代价。

2.制定方案阶段。该阶段项目团队的主要任务就是与客户一起制定一个以前期明确的需求、双方的资源、项目开始实施的时间约定、项目费用限制等为基础的具有可操作性的项目计划，从本阶段开始争取客户全面参与项目的管理，需要双方共同考虑项目实施的具体计划落实和风险规避。

3.实施项目阶段。在该阶段，软件项目团队应该与客户共同领导项目的实施。同时，项目团队应实时评估客户满意度，并通过持续改进提高客户满意度，还应要求客户参加必要的培训，以及在必要时检查项目产品。在出现客户的需求变更前，应主动与客户沟通交流，使客户充分了解项目的每个环节，以及变更带来的影响，减少需求变更。如果出现客户需求变更，应与客户一起共同解决由变更引起的成本、进度、质量变化；如果与客户发生冲突，应与客户坦诚相待，以项目的最终目标和实现双方的利益最大化来权衡，化解矛盾。在项目执行过程中，促进双方人员的认识和了解，记录客户的个性要求和特点，建立合作伙伴关系。

想在项目实施和管理过程中，获得客户的持续满意，并最终达到双方的共同目标，软件项目组织的相关岗位人员应从以下几方面加以关注和改进：

(1)在获取项目过程中，相关销售人员不要过分承诺。如果过分承诺，会给后续的项目实施带来困难；一旦承诺没有兑现，也会降低客户满意度，影响今后合作。如果有附加承诺，一定要让实施项目经理知晓并传达给项目组成员。

(2)项目组要充分理解售前投标书或建议书的内容，并在项目正式开始后就项目需求范围以文档化的形式与客户确认。

(3)项目经理要切实履行自己的职责，做好项目规划和人员管理，并时刻铭记项目目标。

(4)项目经理要定期与客户方相关负责人召开项目会议，介绍项目进展情况以及项目过程中遇到的问题。

(5)项目实施过程一定要规范，质量控制要到位，项目资料编写规范和齐全。

(6)项目组成员要努力工作，利用过硬的技术本领和规范化的实施，赢得客户的信赖。

(7)项目阶段成果要让客户参与评审并听取客户的意见和建议，并在里程碑点交付客户。

(8)销售人员要保持与客户的联系，了解项目进展和问题，在项目组和客户有意见分歧时起到缓冲的作用，不要等到项目收款时才露面。

4.结束项目阶段。在项目结束阶段，软件项目团队应组织项目经验或教训总结会，邀请客户参加。评估客户满意度，并加以全面分析，请客户评估项目组织各个环节的工作，提出建议和批评。在项目结束后，仍需和客户保持联系，建立长期合作关系。

四、客户沟通

客户沟通是软件项目客户管理中的“剂”。在明确了项目中的各种角色和目标客户之后，接下来需要在项目的各阶段，做好贯穿项目始终的客户沟通工作。结合软件项目需求调研、方案评审、项目开发和结束验收等不同的阶段，客户沟通会涉及到以下内容：

1.和需求提出者（或者最终用户）的沟通。要尽量深入他们的实际工作，了解项目需要解决的实际问题的关键点。要使用不同的沟通手段和沟通工具来和用户沟通，比如手绘界面或者图片界面、原型法来和客户沟通应用需求；比如用例图、流程图等方式来和客户沟通业务逻辑和流程需求等，争取把IT语言和客户语言能够很好的在表述上达到一致，切忌自以为是，答非所问。

2.和决策者或者客户领导的沟通。项目产品基本定型和相对完整的产品需求，需要经过客户领导的认可，以确认项目建设思路和方向没有偏离，利于投入更多的资源来细化和付诸开发实现。和客户领导要定期汇报沟通项目进展，及时修正项目目标偏离，争取客户更大力度的协调配合，裁定项目范围需求边界。和客户领导的沟通要主动和及时，要坚持到项目结束，贯穿始终。每周的项目进展周报也是很好的沟通方式，主动及时的汇报项目状态，促进项目进展。

3.和负责验收的客户的沟通。验收客户最好就是需求提出者和最终客户。由于软件开发项目的产出是面向生产和管理实际的系统，验收要考虑到功能、界面、性能、数据和用户容量等多个方面。为了实现分阶段建设，成熟一步运用一步，对于暂时有问题的部分，需要和客户做详细的书面或面对面的沟通，达成后期阶段实现的共识，避免建设“大而全”且工期漫长的系统。

五、客户抱怨处理

客户对企业的抱怨，主要来自于对我们软件产品方面和服务方面的期望落差，要预防和处理好客户的抱怨，需要从以下两个方面重点做工作：

1.产品方面。在产品功能方面，我们要尽量使得我们的产品能够符合客户的业务实际、工作实际和管理实际，能够符合用户的部门职责分工和工作流程，能够给他们的实际工作带来创新性的改善和提升。用户在产品功能方面的抱怨，很可能是我们提升产品价值的宝贵信息和财富。在产品可用性方面，由于软件所运行的主机、存储，既有数据量和用户使用量的不同，又有软件产品的设计阶段和实际运行阶段的不同，所以我们如果想做好的产品，从设计、开发到现场部署只是完成了一半，我们还需要密切跟踪现场的运行环境，不断改进和优化我们的软件产品，在容错性、运行效率等各个方面付出努力和代价，才能使得我们的产品在用户的工作中扎根，真正和客户形成长期的战略合作。

2.服务方面。服务方面的抱怨主要由专业技术和工作态度引起。客户针对这两个方面的抱怨或投诉，需要我们能够具体甄别,对症下药。我们可以通过建立“学习型组织”、通过实行“导师负责制”等具体方式提升团队的整体技术水平和实力。同时,还要统一服务形象、标准化服务流程、加强员工工作礼仪培训等,全面提升员工的自身修养和素质,从而提升企业在客户现场的服务形象和公司形象。

在IT企业中,无论是集团群组项目还是本省本地开发项目，在项目管理的诸多环节中都需要以客户为指向，切实做好客户管理，为项目的成功运作打下坚实的基础。作为企业的各相关人员，尤其是项目经理,能够做好客户管理,意味着项目已经成功了一半。

it项目管理范文第3篇

关键词:大型IT项目；管理方法；研究

在美国协同管理的计划书中对“项目”一词进行了相关性定义。它主要是一种针对新型产品的临时性任务。而项目管理的最实际领域则是IT大型项目。由于IT行业的信息化、技术化水平突出,所以它与项目管理的结合方式也是非常先进的,其项目管理的知识性与科技性也远远超过其他行业。

1大型项目管理的定义以及特点

1.1大型项目管理的定义

在美国的管理策略中说明,大型项目管理就是运用多种综合性解决方式,在人员最优组合的基础上,从多个学科、多个领域的范围进行的一种管理活动。一般来讲,大型项目的管理时间应该超过一年,并且操作人员能够从中看出其巨大的风险性。一个大型项目可能不仅仅是由一个单位进行操作,它通常是应用于创新性的项目当中,并且由无数个子项目构成。另外,大型项目的阶段性体现得较为明显,研发者需要对各类产品以编号的形式呈现出来,并且以产品说明为基础,在实验环境下对产品进行测量。通常来讲,企业需要建立一个自身条件非常突出的团队去进行,并且要花费上一到两年的时间来完成。如果新产品的集成性非常高,并且各阶段的连贯性较强,其中会涉及到许多实际应用的环节,那么项目的制定与管理的时间可能会更长。

1.2大型项目管理的特点

相比中小型项目管理来讲,大型项目管理的特点是非常显著的。第一,它有着明确的任务性。管理者会在项目启动之初就进行时间设定,并且规定负责人在相应时间内完成的任务数量与顺序,对项目开发任务进行有效的编制。各项目的阶段管理者应该按照实际要求进行有效实施。第二,管理工具的先进性。提到IT项目管理,大家首先想到的就是高科技性与计算机的应用。从业人员不仅要有编订任务的能力,还要能够将任务管理过程与计算机相结合,能够对计算机进行灵活使用。第三,信息沟通的及时性。在大型项目管理当中,各项目负责人的信息一定是连贯的、统一的。现代通信技术扮演着二者的纽带与传递角色,它能够时时进行信息交互与分享,使沟通方式做到相对完善。第四,资源提供的必要性。资源是保证软件开发与信息交流的前提,IT行业中的信息资源相对完整,并且能够以很高的效率加以利用。文件服务器可以与第三方软件系统相连接,并且在数据库与语言编程系统的协作下完成高质量的工作[1]。

2大型IT项目管理方法研究

2.1沟通管理

在大型IT项目的管理之中,良好的沟通性是非常重要的。在项目管理中有这样的一句名言“客户只会针对你的问题进行回答,而不会将他们心中所想对你进行倾诉”。这句话也正说明了沟通管理的重要性与前提。从IT行业布局的至高点来讲,沟通交流甚至能够决定一个企业的项目管理成败,并且在一定程度上影响企业的发展[2]。第一,与客户进行沟通并且及时解决问题。IT项目中,客户会参与到企业的发展全过程,并且与管理者进行及时的交流。不管是在方案制定、实施还是评价方面,客户都希望能够完成得相对全面。所以,操作者要明确以上几点要求。在与客户交流时,要以他们的实际需求为导向,并且将每一点都以文本的形式制作出来。同时将制作后的文档发送给客户,让他们对以上总结的几个方面进行查看,以避免二次改进的情况。这是项目设计与成功转变的关键,也是能够将项目规划理论迅速传递给用户的主要手段。另外,信息交流中还包括一些非语言式的要求,这需要制定者进行详细的分析。项目制定中的一些问题客户可能不会考虑到,而其中的隐患是显而易见的。在这种情况下,设计者要将此部分内容列入到规划过程中,并且拿给客户查看,以保障方案的相对完整性与健全性。第二,沟通计划的制定非常重要。首先,各部门经理要对预案进行编制。预案编制的过程中要以建设项目框架为主,定期制定项目例会,根据项目的总体流程设定可视化测评报告与问题协调商议组织。从需求性出发,编制每天的任务表格,建立整体化的沟通协作体系。其次,在实际实施的过程中,要建立客户与方案制定者之间的关系,在每个子项目下进行分组,每个组员负责不同的项目内部评价系统的反馈,将执行情况在第一时间进行疏通。第三,项目经理对整体任务进行分管。他的主要工作是对各部门的交流情况进行汇总,了解各子项目的进度与资源需求,并将他们的成绩予以报送。项目经理根据执行因素与指令,进行及时的补救与完善[3]。

2.2风险管理

大型IT项目本身就存在着很大的风险性。管理者实施措施之前,要对风险进行预测,并且做到管理水平的完善性。从IT项目的特点中也可以看出,高风险、高收益是其主要形式之一。项目的规划与建设过程中往往会存在着一些不确定性与无保障性。管理者要能够正确地识别风险的性质。一般来讲,IT行业的风险会分为直接与间接两种。虽然管理者不能够将风险完全剔除,但可以适当地预防,并制定最及时的控制手段。IT项目风险根据种类的不同可进行划分。其中分别是需求风险、编制计划风险、组织结构设置风险、环境规划风险、客户评估风险、设计产品风险以及管理运维风险。IT项目的风险管理要经历一定的过程,它并不是一蹴而就的。首先,管理者要将可能出现的风险一一列举出来。根据相关资源进行整合,在风险数据库评价的基础上进行过程运维。其次,制定风险检查表。衡量风险所能够出现的最大临界值与最小范围,对风险状态进行整合与规划。最后,根据风险的实际情况对各部门的相关工作进行改进,在监督考评的基础上加大实施力度。IT项目管理的具体风险管理方式如下:第一,对项目文件的制定规则进行审核。其中包括文件的形成、项目的设计流程、人员的职位设定、项目成本测评、风险中的假设条件等等。从IT项目的实际规划情况入手,才能够将风险进行全面性预防,并且在文件中识别这些相关风险。第二,专家调查法。根据项目的实际情况与建设过程寻找相似性,找出比较贴近的项目进行探访与查询,与相关的技术规划专家进行协商,询问此项目中容易出现问题的关键点所在。第三,管理者可以将各部门的人员进行集合,将他们所认为的一些风险预估结果进行归结,进而形成风险预估的系统性管理方式。第四,类推比较法。企业管理者可以建立风险测评软件,将项目的具体说明与注意内容都输入到计算机中,将相似项目的评估结果也予以录入,在建立数据统计库的基础上完善评估方式。系统可以根据相似性数据进行对比、核算与分析,进而将这些数据转化成图形的形式呈现在管理者的面前,管理者可以更加清晰地看出其中的缺陷与问题所在[4]。

2.3创新管理方式,建立虚拟的管理途径

对于IT项目的管理手段而言,创新才是当前企业的出路,也是彰显企业独特管理手段的方法之一。第一,计算机系统上建立完善的人员评价与考核机制。在数据库中输入各部门人员的数量与相关职责,系统会对组合方式进行模拟,进而制定出一个最佳的组合策略。有效团队的形成是科学化项目管理形成的前提。在系统内部,各部门管理者要将每天的组员工作量进行编辑。数据库会进行自动计算,并且将月工作总量统计出来。但这只是人员评估的一个方面,评估总成绩是将任务的完成数量与质量相结合。所以其中还包括客户对每阶段任务的满意程度,系统会将这两个方面进行综合,最后形成合理化的考评结果。在每一小区域任务完成后,管理者可以根据总成绩进行评价,给予成绩优秀员工以物质奖励,调动人员的工作积极性,创新管理方式[5]。第二,建立大型IT项目管理的信息化平台。首先,将多个子项目的相关信息进行统计,并在一个平台上进行核算与管理。多项目信息管理系统可以在单独模块评价的基础上进行综合评估,建立相关子项目之间的联系。这样的统一化平台更方便项目的整体化管理与工作的协调发展。其次,多信息项目管理平台能够根据IT项目的设计方式,对每一阶段的过程进行跟踪,将项目时间、项目流程与项目的质量进行优化,及时采集现有的项目执行数据,在信息的整体把控上做到综合性监督与管理。最后,多项目信息网络平台还可以将各部门的数据传到企业的主页面当中,通过数据库的建立与实时报告的形成规则进行资源的传递与共享[6]。

3结语

综上所述,该文以大型项目管理的定义和特点作为切入点,从沟通方式、风险系统评估与多项目信息平台建立的3个方面来研究大型IT项目管理内容。从而得出:在大型IT项目中,管理手段的科学性与先进性能够调动员工的内部协作性,实现信息之间的整合与共享,有效地对风险进行抑制,为企业的经济效益提升奠定良好基础。

参考文献

[1]张生.大型交通建设项目关键要素集成管理方法研究[D].长沙理工大学,2005.

[2]班宏宝.汽车企业实施ERP项目可行性分析与风险评价研究[D].南京航空航天大学,2004.

[3]陈海艳.大型工程项目管理组织结构评价指标体系及其度量方法研究[D].国防科学技术大学,2009.

[4]陈琼.大型集群项目管理的流程知识表示方法及其应用研究[D].华南理工大学,2011.

[5]杨婧.大型工程项目网络化建模及关键节点分析方法研究[D].国防科学技术大学,2012.

it项目管理范文第4篇

项目的选择是项目生命周期第一步，它是对单个或多个项目进行评估，并选择其中一些进行执行从而保证项目承担方完成任务的过程。简而言之，项目选择是评估所承担项目的优点和缺点的过程 。项目的选择是对未来做出承诺，选择投入一个正确的项目，对于项目实施方的长期生存而言，是一个至关重要的决定。

William（2009）认为，项目管理领导应该参与项目的选择过程，对于IT项目来说也是一样。面临着更大的需求，较少的预算和迫切需要证明的业务状况，组织必须优先考虑他们的IT项目，并对目前的最佳实践进行再创造（Boyer，2003）。

识别好项目并确定它们的优先顺序，组织需要遵循一些标准。根据Gray（2010）等人的研究，项目选择标准通常分为财务类和非财务类：对大多数经理人，财务标准是评估项目的首选方法，在对未来现金流有较强信心的情况下，它是非常合适的选择。当然财务收益尽管重要，但并不总是反映战略重要性。因此，当组织为恢复企业形象或提高品牌认知度而支持项目时，可能使用非财务、多准则选择模型，即检查表模型、多加权计分模型等等。Grey还指出，无论在不同类型的项目中存在怎样的标准差异，最重要的选择标准始终是项目应当适合组织的策略，并对提高业务具有战略影响。

1.研究方法

通过查看文献报告和公司白皮书，实地考察等多种方法对不同类型的IT企业进行了信息收集。将调查中收集到有价值的数据和信息进行对比分析，我们列出了影响项目选择过程的重要因素。基于对在不同的IT企业中主要影响因素的识别和实际观察，确定项目选择的基本流程框架。

系统动力学（System dynamics，简称SD）是一种描述、建模和模拟复杂系统的动态行为的方法，由麻省理工学院教授Forrester于1958年提出。系统动力学是基于系统行为与内在机制间的相互紧密的依赖关系，并且透过数学模型的建立与操作的过程而获得的，逐步发掘出产生变化形态的因果关系。

“影响图”是单决策人基于不确定信息表示和求解复杂决策问题的图模型，它记录系统运行的方式，是用来建立SD模型系统的基本工具。动态行为的原因不在于一个系统中个别组件的细节，而在系统中组件之间的相互作用。影响图列出有关变量的名称，并用箭头连接它们，箭头的方向表示因果关系的方向。箭头处的标志，显示影响的效果。

在确定影响系统的所有因素后，我们能够绘制出SD影响图，它是由这些影响因素这中的不同因果关系以及这些因果关系形成的因果。通过该图，可以将诸多因素选择过程的影响直观地表示出来，便于理解。

2.项目选择的影响因素

Meredith和 Mantel（2003）指出，选择项目中不同影响因素，包括生产、财务、营销、人事、行政和多方面因素。生产因素包括设施和生产设备的要求、原材料的可获得情况等；市场因素包括消费者接受程度、产量的市场份额、产出的预计周期、对当前生产线的影响等；金融因素包括盈利能力、现金需求，对现金流的影响，投资需要的规模等等；人事因素包括培训需求、劳动技能需求、所需劳动技能的可获得性、当前劳动力的抗拒程度，对工作环境的影响，外部和内部团体的沟通需求等等；行政及其它因素包括对信息系统的影响，对客户、供应商、竞争对手形象的影响，专利与商业秘密保护，对新工艺的管控能力。

从调查结果中发现，对于一个中型公共IT机构（以下代称为A机构），当用户请求A机构的服务，以获得IT解决方案，A机构的技术人员会去用户有关部门研究现有系统的问题，然后提出建议来提高工作流的性能。在进行完包括团队成员和用户在内的若干次会议后，关于预计成本、持续时间等细节的项目文档，和针对用户方所需的资金和财务状况的建议一起，应当完成并提交给用户方。当用户接受这个提议后， A机构评估自己的内部功能设施，包括劳动力的可用性、技能和技术等，从而选择利用自身的资源或项目分包的方式来完成项目。

对于中小型私有IT机构（以下代称B机构）而言，调查显示，项目人员会接触客户以了解他们的问题和需求，研究后提出建议。为此，开发人员会事先分析他们是否有足够的资金储备，和其它所需的资源投入，以确保如果获得该项目。如果需要额外的人力和非人力资源，由于是小型私有机构，他们可以相对容易和迅速地雇佣额外的资源。但在A机构或政府组织等，很多程序和政策必须遵循，这种为获取资源而采取的行为不可能像在私有机构中那么简单。

从上面的讨论中，已确定6个显著变量构成并影响“项目选择”子系统，包括：

（1） 项目的需求和价值

（2）用户主动性

（3）组织主动性

（4）项目财务分析报告

（5）财务能力

（6）项目预计成本

3.项目选择活动的流程

任何组织机构，在寻求一个特定项目实施之前，需要从解决组织问题的实用性角度，评估项目的需求和价值。一旦组织相信该项目具有较强的实用性，就开始考虑这个项目的费用。对于IT项目，不同的评估技术，如COCOMO（构造性成本模型）、功能点分析等，都会被使用。在寻求IT解决方案时，企业会先组织一部分擅长估算的IT人员，基于以往项目的详细评估资料，对当前项目做出一个大概的估计。

在粗略估计IT解决方案的成本后，组织需要计算从项目中获得的经济效益。在此之上，当组织认可其收益，它会检查资金储备以便开始实施该解决方案。如果它可以确保有足够的资金来满足开发费用，组织会把实施IT解决方案的任务作为一个成熟项目。否则，组织会出于经济问题的考虑，放弃这个开发项目的计划。

上述项目选择的过程可以用一个流程图表示，如下图所示

图1 项目过程的框架

4.项目选择过程的系统动力学模型

根据上文中列出的影响项目选择活动的显著变量，这些变量之间不同的因果关系也可以被确定，从而建立了SD因果循环模型。

当某一产品或服务有良好的市场需求或实用价值，用户和开发单位有足够的资金来源，并且对项目有兴趣时，就会进行产品或服务的开发。鉴于此，从“项目的需求/价值”和“财力”这两个变量关系分别连接到变量“组织主动”和“用户主动性”的因果关系，可以被视为积极的因果关系。而用户和开发组织积极性越高，选择这个项目的机会就越大。因此，连接“组织主动”和“用户主动”这两个变量的对于“项目选择”的因果关系也是积极的。“项目的需求/价值”和“用户主动”两个变量间积极相互的因果关系，则形成一个积极的因果反馈循环。

如果初步的项目估计成本更高，项目开发组织和用户可能会对这个项目失去信心。因此，的“项目预计成本”与“组织主动性”和“用户主动性”之间的因果关系是消极的。项目财务分析报告确认收益、利润，以及计划项目中除去开发成本的其他预期效益。如果预计成本更高，则会对项目的项目财务分析报告有负面影响，选择项目的可能性就会降低。因此，“项目预计成本”与“项目财务分析报告”的因果关系是负面的。如果有更详细和乐观的项目财务分析报告，将会吸引开发组织的关注和提升选择该项目的机会。因此，“项目财务分析报告”与“组织主动性”和“选择项目”两个变量是积极的因果关系。

项目选择的SD模型已经建立了上述各种因果关系以及因果反馈回路，模型的整体结构显示在图2。

5.结论

项目管理的成功始于对一个项目的正确选择，因此项目选择是项目管理中一个重要的基本步骤。本文通过对有助于选择正确项目的重大问题收集信息，共识别六个主要因素——项目的需求和价值，用户主动性，组织主动性，项目财务分析报告，财务有力和项目预计成本。并运用SD方法来描述这些问题中两两相互影响的类型，绘制出SD影响图。影响图的框架清楚展示了循序渐进的项目选择过程，以及因素之间的相互作用。

未来的研究方向是面向某一特定的IT组织的实际项目选择过程开发SD存量-流量模型，并在一定时间范围内进行模型的验证。

参考文献：

[1]Boyer C （2003）， “Make Profit Your Priority”， PM Network， Vol. 15， No. 10，pp. 37-42

[2]Gray C F， Larson E W and Desai G V （2010）， Project Management： The Managerial Process， 4th Edition， Tata McGraw Hill， New Delhi

[3]Meredith J R and Mantel S J Jr. （2003）， Project Management： A Managerial Approach， 5th Edition， John Wiley & Sons， USA

[4]张波、虞朝晖等.系统动力学简介及其相关软件综述[J]环境与可持续发展 ， 2010，（02）

[5]宁晓倩. 基于系统动力学的软件开发项目管理[D].复旦大学 2004

[6]王宇静. 系统动力学在项目管理中的应用研究综述与展望[J].科技与管理，2013，（01）

作者简介：

汪俊华（1986-），男，湖北省孝感市，硕士。研究方向：信息管理与信息系统，工程数字化。

高尚建（1984-），男，山东省菏泽市，学士。研究方向：工程数字化信息系统管理。

it项目管理范文第5篇

[关键词] 挣值法；IT项目管理；人工时

doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2015 . 17. 022

[中图分类号] F272.7 [文献标识码] A [文章编号] 1673 - 0194（2015）17- 0045- 06

1 概 述

随着第三次工业革命的到来，信息技术时代，特别是计算机网络的发展，信息技术已经越来越多地进入了我们日常的工作和生活。基于计算机网络技术，企业数据的共享和流程管理已逐渐成为可能。而因此，信息化技术（IT，Information Technology）的应用正越来越为企业所关注，并逐渐成为企业提高工作效率、促进管理水平的有效手段。

从简单的办公自动化（OA，Office Automatic）系统，到复杂的企业资源计划（ERP，Enterprise Resource Planning），供应链管理（SCM，Supply Chain Management），客户关系管理（CRM，Customer Relationship Management），产品生命周期管理（PLM，Product Lifecycle Management），制造执行系统（MES，Manufacture Execution System），各类不同的企业都在寻找适合自己的IT解决方案，或为了消除业务过程中的瓶颈，或为了将业务流程再造（BPR，Business Process Reengineering）的结果通过系统固化，抑或只是为了追赶潮流而不至于落后。

几年前，当ERP方兴未艾的时候，业内有一种说法流传甚广：“不上ERP是等死，上了ERP是找死”。这虽然只是句玩笑，但也折射出一个现象：IT项目实施难度大，成功率不高。对于一些复杂IT系统的实施，大家普遍比较认同的一种观点是：三分软件，七分实施。如何将一个成熟的软件系统，根据客户的需求和业务现状，以客户可以接受的方法和程度进行实施，并发挥效用，是每个IT项目经理面临的难题。这里面也包含很多方面和方法，PMBOK将项目管理的知识领域和过程组分析得非常清晰，项目经理也常常将沟通交流、范围控制、成本管理、变更控制放在案头与心中，但考虑得多了又往往千头万绪，不知从何下手。

近几年，挣值分析法正逐渐进入国内各个项目管理公司和IT项目经理的视线，为行业发展指出了方向。挣值法作为一种综合的偏差管理方法，可以综合地考虑项目的范围、时间、成本和质量的整体状况，量化地分析计划各指标与实际指标之间的差异，以便项目经理来确认是否可控可接受。挣值法起源于大型的国防、能源、建设项目，所以根据项目的规模和类型，其适用性也不尽相同。由于IT项目普遍规模和周期较小，往往并不具备独立的项目管理办公室来进行大量数据的收集和分析，主要的分析工作都集中在项目经理个人手中进行，因此使用和评价都各有千秋。在本文中，我们将就实际的项目为例，使用挣值法进行相关的尝试性分析。通常，IT项目有诸多种类，例如纯软件开发项目、系统实施项目、纯咨询项目等。在文中，我们所涉及的项目将主要针对于系统实施项目展开。

2 挣值法在IT项目管理中的应用

挣值分析法是一种能全面衡量项目进度状态、成本趋势的科学方法，其基本要素是用货币量代替实物量来测量项目的进度，它不以项目投入资金的多少来反映项目的进展，而是以投入资金已经转化为项目成果的量来衡量，是一种完整和有效的项目监控方法。挣值分析通过将时间与成本综合考虑的方法来确定项目执行的健康程度，将多维度的考核标准统一到一个维度，从而进行综合的评价。这种方法可以帮助我们直观地了解项目的状态，并预计其未来的走势。

然而，对于一般的系统实施项目经理，由于项目规模相对较小，并行开展项目较多，包括工资、差旅、设备折旧等成本并不会特别计入项目成本，而是作为日常成本摊入多个项目。而对于成本的直接考核往往借助于人天数。人天数是一个成本指数，当给一个人天数赋予单价，就可以方便地核算出人员投入方面的成本，而如果这个成本占项目成本比例非常高的话，这种核算方法就非常合理了。值得一提的是，人天数也是成本直接相关的一项指标，其直接关系到工资、差旅等成本，因此此考核方式是比较科学的。

系统实施项目就是这个情况，项目下达时通常会给项目经理一个人天数的指标，并规定项目的进行需要在人天数的指标之内完成；通常，项目超出10%的指标需要部门经理批准，超出20%就需要公司高管批准，而超出30%则即可视为项目责任事故。因此，项目经理往往对于人天数给予了高度的重视。

在一些情况下，由于项目开始阶段客户的准备不到位，部分项目组成员不需要到现场工作，从项目人天数的统计会发现人天数小于计划的情况，但往往在这种情况下，由于项目此时的进度严重延后，项目的健康度很低。通常，由于部分成员从其他项目中能够空闲出来，而大量投入本项目的实施，人天数统计有时会超出计划，而在这种情况下，由于团队集中工作，提高了沟通效率，反而可以事半功倍，将项目的进度提前。在这两种情况下，普通的时间进度计划和人天数统计表体现的数据可能无法直观地体现项目的健康度，项目经理必须具备全面的经验才能发现其中的奥妙，而挣值分析法则可以很好地弥补这两个参数的不足，更直观且准确地分析项目的执行情况和健康度。同时，通过人天数这一指标来反映成本，也简化了分类统计成本的复杂度，对项目经理来说也非常易于统计和操作。

2.1 挣值法基本知识

挣值（EV，Earned Value）是为项目管理而发明的一个中间指标，表示实际完成的工作所对应的预算成本，从而在计划和实际之间建立了一个衡量的桥梁。通过用成本指标来表示每个项目任务的价值，综合反映时间、资源、成本等多方面因素的影响。

挣值管理中用到的主要指标包括：

・BCWS（Budget Cost for Work Scheduled）表示计划的任务对应的预算成本，也叫PV（Plan Value）。

・ACWP（Actual Cost for Work Performed）表示实际完成的任务对应的实际成本，也叫AC（Actuel Cost）。

・BCWP（Bugedt Cost for Work Performed）表示实际完成的任务对应的预算成本，就是挣值，EV（Earned Value）。

・成本偏差：CV=BCWP-ACWP，就是实际完成的任务，比较预算成本和实际成本之差。

・进度偏差：SV=BCWP-BCWS，就是预算成本，比较实际完成的任务和计划中应完成的任务。

・成本绩效指数：CPI=BCWP/ACWP，就是已完成工作预算成本/已完成工作实际成本。

・进度绩效指数：SPI=BCWP/BCWS，就是已完工程预算成本/计划完成工作预算成本。

关于两个偏差（CV，SV）和两个指数（CPI，SPI）的值所代表的含义，可以简单地用表1说明。

2.2 项目背景

某电子研究所是国家一类研究所。随着业务的快速发展，原有的管理机制无法满足所管理层对企业的管理要求，在项目研发阶段管理、电子资料管理、研发过程规范化管理等方面都提出了更高的要求。因此，研究所在2006年，引进Teamcenter Enterprise 2.0 构建产品数据管理信息环境，并引进Teamcenter Project 3.2构建项目管理平台，为产品研发过程的管控提供3个方面的解决方案：

（1）为产品电子数据提供管控和利用手段，改变沿用人工纸质化管理电子化产品数据的不对称现状。

（2）为产品设计过程搭建可视化协同和管理平台，消除专业系统所形成的信息孤岛，为产品实现过程的数据流提供透明的集成环境。

（3）为质量管理体系运行提供基于流程控制的支持环境，实现技术状态演变过程的实时簿记和可追溯性。

PDM一期的实施让企业看到了PDM强大的功能，及其在企业研发过程中的重要作用，管理层认为推进PDM实施是企业实现研发过程电子化管理的可行道路，也期望看到更多的成果和更好的推广。因此研究所产生了PDM进一步实施的要求，要求在深度和广度上都有所提高。

在系统实施深度方面，希望通过进一步完善功能，利用先进的IT技术，解决易用性的问题，无论从界面和操作上都能够简化，提高用户对系统的接受程度；同时，通过引入新的模块，实现更高层次的电子化管理。在实施广度方面，研究所希望将PDM系统从原来的试点项目推广到全所级的运用，将所有的研发过程均纳入系统管理，真正意义上实现电子化管理。

2.3 项目计划

根据项目前期调研了解的用户期望，和对现状的把握，明确了二期项目的实施范围。基于工作内容和工作范围制定了项目的时间进度和人力资源投入计划。

本计划依据实施方法学的原则，详细规定了在实施过程中应当完成的每一项任务及其分解，并规定了这些任务所对应的交付内容。在项目计划中还规定了用于控制PDM系统实施品质的质量检验点，项目实施中的决策人员将在每个里程碑检验质量检验点的关键交付内容，以决定项目是继续进行还是应当延期以等待条件的成熟与完善。

2.4 挣值法进度分析

在项目的实际执行过程中，项目组通过周计划、周报告的方式详细记录了每周项目的执行情况，包括任务执行进度、人力资源投入、项目问题及处理以及项目风险记录。通过这些原始信息的积累，我们可以对项目的进度情况进行挣值分析。其中，以人天数为项目成本统计量。

2.4.1 项目第二个质量检验点：系统设计结束

根据项目计划，系统设计完成日期为2010年4月14日，计划的人天数是90。

根据项目组记录，系统设计完成日期是在2010年4月28日，统计的项目人天数是132。

因此，在2010年4月28日当天，

计划工作的预算费用：BCWS=PV= 100人天

已完成工作实际成本：ACWP=AC= 132人天

已完成工作的预算成本：BCWP=EV= 90人天

可以导出：

费用偏差：CV=EV-AC= 90-132= -42人天

CV

进度偏差：SV=EV-PV= 90-100= -10人天

SV

费用绩效指数：CPI=EV/AC=90/132=0.68

CPI

进度绩效指数：SPI=EV/PV=90/100=0.9

SPI

进一步分析：

假定完工预算：BAC=281人天

剩余成本：ETC=（BAC-EV）/CPI=（281-90）/0.68=280人天

总成本：EAC=ETC+AC=280+132=412人天

成本偏差：VAC=EAC-BAC=412-281=131人天

结果分析：

该项目进行到这一里程碑时，进度略有滞后，而投入人天超支较严重，如果继续执行下去，人天数将超额131/281=47%>30%，将会成为严重项目责任事故，因此项目组必须予以高度关注。

而分析原因，由于项目执行初期在需求确认过程中，用户部分之间发生分歧，导致评审周期变长，项目组整体待工。而由于多次评审会的需要，项目组调动了各个相关领域的资深顾问参与，导致项目人天投入也严重超支。

后续计划将加紧开发过程的进度，争取在计划上能有所超前。同时，由于需求确认较充分，因此期望后期在用户接受测试和用户评审阶段可以加快周期。

2.4.2 项目第三个质量检验点：开发结束

根据项目计划，开发结束完成日期为2010年6月16日，计划的人天数是225。

根据项目组记录，开发结束完成日期是在2010年6月23日，统计的项目人天是268人天。

因此，在2010年6月23日当天，

计划工作的预算费用：BCWS=PV= 230人天

已完成工作实际成本：ACWP=AC= 268人天

已完成工作的预算成本：BCWP=EV= 225人天

可以导出：

费用偏差：CV=EV-AC=225-268= -43人天

CV

进度偏差：SV=EV-PV= 225-230= -5人天

SV

费用绩效指数：CPI=EV/AC=225/268=0.84

CPI

进度绩效指数：SPI=EV/PV=225/230=0.98

SPI

进一步分析：

假定完工预算：BAC=281人天

剩余成本：ETC=（BAC-EV）/CPI=（281-225）/0.84=67人天

总成本：EAC=ETC+AC=67+268=335人天

成本偏差：VAC=EAC-BAC=335-281=54人天

结果分析：

该项目进行到第三个里程碑时，进度略有滞后只有5个工作日，而投入人天超支情况有所改善。如果照此趋势，人天数将超额54/281=19%>10%，仍然需要上报公司高管批准，因此项目组仍然需要关注项目执行情况。

而分析原因，由于开发过程基本由乙方完成，在需求和规格定义明确的情况下，执行基本受控，同时考虑到前期的滞后，还有所赶工，因此时间进度得以部分赶前。

后续计划仍将尽快赶上进度，特别是在人天投入方面，将考虑多利用用户方项目组团队成员参与最终用户培训，以减少乙方人员的投入。

2.4.3 项目第四个质量检验点：用户认可

根据项目计划，用户认可完成日期为2010年6月30日，计划的人天数是255。

根据项目组记录，用户认可完成日期是在2010年7月7日，统计的项目人天是288人天。

因此，在2010年7月7日当天，

计划工作的预算费用：BCWS=PV= 275人天

已完成工作实际成本：ACWP=AC= 288人天

已完成工作的预算成本：BCWP=EV= 255人天

可以导出：

费用偏差：CV=EV-AC=255-288= -33人天

CV

进度偏差：SV=EV-PV= 255-275= -20人天

SV

费用绩效指数：CPI=EV/AC=255/288=0.86

CPI

进度绩效指数：SPI=EV/PV=255/275=0.93

SPI

进一步分析：

假定完工预算：BAC=281人天

剩余成本：ETC=（BAC-EV）/CPI=（281-255）/0.86=30人天

总成本：EAC=ETC+AC=30+288=318人天

成本偏差：VAC=EAC-BAC=318-281=37人天

结果分析：

该项目进行到第四个里程碑时，进度略有滞后只有20个人天，投入人天超支情况又有所改善。照此趋势，人天数将超额37/281=13%

而分析原因，在文档编写和最终用户培训中，尽量调用了甲方项目团队的工作能力，因此节省了部分的人天，使项目健康度又有所改善。后续计划则将考虑系统配置工作能做好充分准备，尽量减少现场问题和现场人天。同时将数据迁移工作同步进行，并调动甲方团队的积极性，以期能赶上项目计划人天和资源投入。

2.4.4 趋势分析

整理以上的数据可以得到关于PV、AC、EV的数据表，见表3。

绘制曲线如图1所示。

从图中我们可以直观地看到成本偏差与进度偏差，也能看到偏差变化的趋势，特别是AC将接近于PV的趋势。如果我们能在项目执行过程中增加一些监控点的话，该趋势的表现将更加细致和直观，对项目进度和成本（人天）的监控也是非常有益的。

3 结 语

本文尝试以挣值分析法监控和分析IT项目实施过程中的项目执行情况和健康度，并以某项目实施案例为例予以分析说明。文中将项目成本中的费用替换成了人天数，对于部分以人天投入为主的项目实施，此类尝试已被证明是具有实用价值的。在文中，我们指出了挣值分析法在IT项目管理中分析项目进展情况并预计今后发展趋势的有效性，该方法可以指导项目经理人在项目过程中采取相应的策略、预见风险、以及减少项目的超期和超支。

最后，我们将挣值分析法在IT项目管理中的作用总结如下：

（1）帮助项目经理及早地发现项目可能出现的风险和问题，以采取应对措施规避风险。

（2）通过简单的数据积累和分析，提供量化的项目实时诊断信息，使诊断更准确。

（3）便于向管理层和项目监督小组做汇报，通过数据和图表的方式，更具说服力。

挣值分析法目前在国内IT项目管理中的应用尚不普遍。然而，我们相信经过一些改良，该方法可以在占用项目经理相对较小的工作量的前提下，利用项目组原先积累的数据就能够对项目进程作出相对准确和可靠的分析，其应用前景是非常值得肯定与期待的。

主要参考文献

[1][美]项目管理协会.项目管理知识体系指南[M].第4版.王勇，张斌，译.北京：电子工业出版社，2009.

[2]毛婧颖.挣值法研究现状及展望[J] .项目管理技术，2010，8（2）：19-23.

[3]蒋国瑞，等.IT项目管理[M].北京：电子工业出版社，2006.

[4]Fleming Quentin.Joel Koppelman. Earned Value Project Management[M].Third Edition. USA：Project Management Institute，2005.

[5]Barry W Boehm.软件工程经济学[M].李师贤，译.北京：机械工业出版社，2004.

[6]Capers Jones.Determining Software Schedules[J].Computer， 1995，28（2）：73-75.