IT项目管理

IT项目管理（精选十篇）

IT项目管理 篇1

过渡期服务最早在官方文档上出现应该是ITILV3里面,据说最早是由惠普提出这个概念,据笔者所知,至少在12年前,惠普的IT外包部门里面就有专业的过渡期服务的团队,他们专门负责处理各类过渡期服务项目,结束后交接给运维团队,然后去做另外一个新项目的过渡期项目。这里需要再谈一谈什么叫做过渡期服务,一般情况下来讲,狭义的过渡期指的是从合同签订那天开始,到正式提供服务开始的那段时间叫做过渡期,过渡期一般情况下为3-6个月(取决于项目的规模和复杂程度);广义上来说,过渡期服务经理可能早在销售明确了客户的真实业务需求后就参与了,也就是开始了过渡期服务了。那么过渡期服务究竟做些什么事情呢?按照业内的说法,过渡期服务团队提供一个从“As-is”到“To-be”的转换服务。也就是说将客户现有的服务模式,彻底转换为未来应该实现的模式,这里要做的事情很多,包括流程的制定、人员的转移、资产的转移、供应商的转移、合同的细化、工具的准备等等。这个过渡期服务是完全符合项目的定义的:首先看临时性,过渡期服务的起止时间一般明确规定在外包合同里面,时长一般不超过半年(极个别全球大项目可能是一年)。其次看独特性:没有哪家公司的现有IT服务模式是一样的,也没有哪家公司的未来的IT服务模式是一样的,所以这个转换的过程就是更不可能一样的了,流程、工具、人员是完全迥异的。最后看渐进明细性,在合同签署的时候,可以说未来服务模式是完全一片空白的,而随着时间的进行,各种流程逐渐成型(可以分批次),到了末期的时候无论客户的甲方经理还是供应商的乙方运维经理都有相当的了解了,而且会根据他们的想法进行一定的调整。

好了,了解了过渡期服务的情况,我们就可以来和传统的IT项目进行比较了,我们这里就以传统的IT项目以信息系统集成为例。下文也将主要围绕着十大知识领域进行展开。其中,对于相同的部分,因为读者们已经接触过太多普通项目的管理术语和实例,笔者就不一一展开了,将会就不同点着重展开。

首先看重中之重的质量管理。过渡期服务的质量管理一般来说比普通项目重要,因为有些项目可能没有后续的运维,质量略差损失不大。而过渡期服务里面所有的成型文档是将来运维团队的北极星、指路明灯。未来的运维是要完全以过渡期服务这个项目的交付物为指导方针的。在过渡期服务里面,除了项目管理常用的质量控制、质量保证等流程以及检查表、鱼骨图、趋势图、直方图、控制图等常见工具之外,一般情况下大型组织里面还会加入两项内容,第一个是针对过渡期服务的特殊外部或内部审计(不同于我们常说的质量控制或者质量审计);第二个是让未来的项目运维经理提前介入,因为未来的运维是由运维经理负责,他就会尽可能对过渡期服务的质量提出高标准严要求,同传统IT信息系统集成项目相比,等于多了一方来自内部的监测—有时候内部监测比外部(客户或者监理)更加严格,因为他们深知公司内部的种种问题,这位运维经理如果对质量审计不上心,唯一的结果就是他将会痛苦3-5年(取决于合同时长)。

其次在成本、进度、范围这三要素的角度来看,本质上并无区别。这三者是项目成败的致命因素:成本超支直接导致后续的运维服务无法进行(因为两者虽然内部可能独立结算,但是合同本身大部分情况下是在一起);范围要在这个阶段通过WBS等手段进行细化,将合同中一些可能不是特别清晰的东西通过谈判、妥协等手段与甲方的信息技术经理达成共识;而进度管理则是和项目管理一样,要求非常高,完全不等同于未来的运维管理,很简单,如果甲方原有支持人员6月30日遣散,新的呼叫中心7月1日开始服务,如果到了7月1日这天凌晨,呼叫中心的网络、人员都还没有准备好,这怎么办?在这三要素的管理上,无论输入输出还是具体工具和PMP书籍里面讲的没有本质区别。

在其他六大知识领域里面,我们一分为二。相同的或者类似的基本忽略掉。在风险管理、采购管理、整体管理里面,没有大的区别。而在人力资源管理、沟通管理和最新的干系人管理里面区别较大。

先说人力资源管理,和普通信息系统集成项目不同,IT外包项目基本就是人,里面其他的内容比如软件、硬件占的比例非常低非常低。在人力资源管理里面首先要做的就是要设置现有过渡期团队的组织架构和未来运维时期的团队的组织架构,哪些人将来会从过渡期团队里面转移到运维时期,哪些人不转这个非常重要。其次对于未来的运维团队来说,必须设立科学、高效的组织架构。所谓科学,这个组织架构不能很机械地照搬其他项目,要根据现有客户的具体情况,结合本公司内部情况,设置出一套管理模式,如果照搬,未来就会给运维平添无数麻烦,比如甲方从IT经理到CEO有四层,乙方是三层,那么注定有一层无法覆盖到,就会为将来的沟通管理和干系人管理平添障碍。其次是要高效,前文说过,不同于大部分系统集成项目,外包项目的成本绝大部分都是人员构成的,一个冗余的架构不仅仅会导致效率低下,而且会直接导致运维成本超支。另外,在一般情况下,IT外包项目都会有多多少少人员转移的情况(即部分人员会从原来甲方的内部IT部门转移到乙方的组织里面来),这里面涉及到两个公司不同的薪酬支付体系以及文化上的交互,一般情况下,既要求要转移一定数量的人员(否则知识转移无法顺利完成),又要在成本上做相当的控制(大部分人在换工作的时候总是要求加工资,而作为乙方来说,一定是提供了比原来甲方更加低廉的价格才能拿到合同,那么转移哪些人,怎么转移就成为了一个技术活,笔者在超过十年的外包生涯中,领导的人员转移的合同就有好几个,涉及到的人员有几百个(也就说前前后后有几百人从客户处转移到了笔者之前从事的公司或者公司的第三方处),如果有时间,可以单独写一篇外包合同中人员转移的注意事项。

再看沟通管理,IT外包项目不同于其他典型IT项目(比如机房搬家、开发新程序、系统集成等),IT服务是涉及到几乎所有人的,因为所有人都会用到IT服务,服务模式的变化直接影响到他们,那么就需要和所有人进行沟通,这在别的项目(不管是IT还是其他项目)是难以想象,沟通内容之复杂,沟通对象之多是别的信息系统项目无法相比的。就沟通对象来说,至少有甲方的IT部门对口子部门、其他子部门、用户的战略管理层、用户的中层管理层、普通用户、甲方的其他供应商等几个级别,另外,对于用户来说,还要根据他们的IT的需求不同,去制定不同的沟通渠道和沟通内容。就拿零售业来看,目标客户至少是客户的高层(CXO)、客户的IT直接对口部门(大部分情况下是基础架构部门)、IT其他子部门(比如应用软件部门,比如网络、服务器小组等没有外包的内部部门,他们未来会成为外包方一线支持的后台团队,负责对复杂问题进行二线支持,必须要明确将来的合作模式)、总部办公人员、商店店员(商店支持模式和办公室是不同的)、商店店总、甲方的其他供应商(比如其他硬件提供商,比如POS机的提供者,将来用户报修到这个乙方的呼叫中心怎么办)。所以在规模较大的IT外包项目里面,会有一个专门的沟通经理(未必是彻底专职,但是正常情况下在这个项目里面不会再兼任其他职位,否则带宽不够),会制定各种沟通计划并可能亲自负责部分沟通工作。在某些技术含量极高的传统IT项目里面,沟通可能还没有达到和三要素(范围时间和成本)同等重要的地步,但是在IT外包项目里面,沟通的好坏直接涉及到项目的成败,如果过渡期内不能有效完成沟通管理计划的既定目标,项目极有可能失败,甲方会无限期推迟运维服务的正式开始(在全球范围内,因为过渡期项目管理的失败导致甲方暂停外包也就是乙方无法准时收到钱的例子举不胜举,而沟通失败在里面占了相当大的比重)。那么给乙方带来最惨痛的后果很可能是甲方单方面无赔偿取消这份合同。

最后再看看火热新鲜出炉的干系人管理,干系人管理是最新一个版本的PMI BOOK里面的概念,PMI变更这个知识领域后,我相信很多项目(不管是不是IT项目)一定会在列计划的时候加重干系人管理的比重或者干脆增加一页叫干系人管理。而在传统的IT外包项目,干系人管理则很早就占据了极其重要的位置,IT外包项目和那些技术含量高的项目不太相同,因为只要不是出了天大的漏子,IT服务并非是非外包不可,对干系人的分析稍有失误,一个上千万人民币的单子非常可能就消失了,售前的干系人分析不是本文的重点,本文只谈过渡期的干系人管理,前文说过,理论上说进入了过渡期之后,合同已经基本敲定甚至已经签署,但是和传统项目不同,传统项目比如机房搬家,这时候已经选定甲公司作为供应商,那么以前甲公司的反对者这时候无力回天,甲公司要做的基本就是将搬家项目的计划进行细化,风险管理好,就不会有太多问题。而外包项目则不同,因为外包项目影响范围太广,且是最直接的,一般情况下合同都会有退出条款,如果这时候不做好干系人的管理,那么整个大项目很可能功败垂成,特别是有些时候某些公司会做所谓的试运行,比如零售业中选出5家店试运行,好了再去签署后面的大合同,这时候过渡期项目经理应该要对着5家店的每一个干系人做出精准分析,比如为什么是这5家店被选出,店总愿意还是不愿意被作白老鼠,对外包的态度如何。下面员工是否了解外包对他们的影响,他们的期望值又是什么等等。笔者曾经见过某大型零售业更换外包服务商之后,不到半年,因为商店相关干系人的期望值管理不善,虽然各项服务级别都达标了,但是直接导致该公司首席信息官(CIO)被迫辞职。

IT项目沟通管理 篇2

在IT项目中，要做到一个项目迅速成功的完成，并能达到或者超过预先设计好的效果，是很不容易的，在完成所下达的任务当中，设计好的蓝图跟具体的实诸于实践，既要有规定统一的制定计划，还要有一套适时的监控执行方法，但同时又不能扼杀了整个项目开发中的创造性和自主性，这样，就必须有一个灵活而且容易使用的沟通方法的过程，从而使一些的重要的项目信息时时最新，做到实时同步。

在IT项目中，许多专家都认为：对于成功，威胁最大的就是沟通的失败。与IT项目成功的三个主要因素分别为：用户的积极参与，明确的需求表达，管理层的大力支持。而这三要素全部依赖于良好的沟通技巧，特别是非信息技术人员。沟通管理的目标是及时并适当地创建、收集、发送、储存和处理项目的信息，标准的项目沟通包含沟通计划、信息传递、实施情况报告、管理收尾共四个过程。本文将谈谈一些本人在沟通管理实践中的一些经验。制定沟通计划

在项目立项后，第一步就要制定《沟通计划》，《沟通计划》应包括以下内容：

? 文件保存方式：在沟通计划中首先明确信息保存方式、信息读写的权限，明确用户信件、会议记录、工作报告、项目文档（需求、设计、编码、发布程序等）、辅助文档等的存放位置，及相应的读写权力。这样用于收集和保存不同类型的信息，有必要制定和遵循一个规定好了的统一规章制度，将与项目有关的重要工作建档。

? 联系方式：应该有一个专用于项目管理中所有的相关的人员的联系方式的小册子，其中如项目组成员、项目组上级领导、行政部人员、技术支持人员、出差定房订票等系统中相关的人员，座机、手机、职能等等，应相应的一一列上，做到简洁又要明了，最好能有特殊人员的一些细小的标注，能够做到在一打开小册子的同时就能将所有的相关人员的资料了然于胸，正所谓知已知彼，这样一来，很多在平时大费周章的事，就能在养成的良好的习惯中，轻松做到。

? 工作汇报方式：明确表达项目组成员对项目经理或项目经理对上级和相干人员的工作汇报方式，明确什么时间，什么形式。比如项目组成员对项目经理通过EMAIL发送周报；项目经理对直接客户和上级按月通过EMAIL发月报的方式；紧急汇报通过电话及时沟通；每两周项目组进行一次当前工作沟通会议；每周同客户和上级进行一次口头汇报等等。

? 统一项目文件格式：对于一个项目本身统一的文件模板，是正规管理的一部分，所以必须统一各种文件模板，并提供编写指南。

? 《沟通计划》维护人：明确本计划在发行变化时，由谁进行修订，并对相关人员发送。

由于《沟通计划》是同很多人员有相关的，必须保证计划是有相关干系人参于制订，并且保证《沟通计划》是相当人员已经正解接收及理解。计划是用来执行的，而不是为计划而计划束之高阁。信息发送

对于项目管理的信息正确传达到相应的人员，是相当重要并有一定的困难的，经常发生的事情是信息发送人感到自己把信息正确传达了，但实际的结果却是信息没有传达到或是被错误的理解了。太多的人还是不太习惯成堆的文件或者通篇的E-MAIL传送的邮件，如果能利用非正式的方式或者是双方会谈的方式来听取重要的信息，就来得又快又准确更能让人接受，就象传统里的一纸书信在某些场合还是比任一现代化的联系方式来得好一样，价值取向不同，沟通的方式也就在使用效果上全然不一样了。

我们在沟通中应遵循彼得.德鲁克提出的四个基本法则：

? 沟通是一种感知

? 沟通是一种期望

? 沟通产生要求

? 信息不是沟通

本人在通过学习及结合实践的过程中得到以下的感受。

3.1 沟通是一种感知

沟通一定是双向，必须保证信息被接收者接到了。所有的沟通方式，必须有回馈机制，保证接收者接收到。比如：电子邮件进行沟通，无论是接收者简单回复“已收到、OK”等，还是电话回答收到，但必须保证接收者收到信息，并回应信息已经接收到。

信息收到必须保证理解是正确的，很多事情信息收到了，但被错误的理解了，很多信息是传达到了，但却被错误理解了。

比如：A项目经理对B项目经理说“今天我要去投标，不过我这边的现在人手少，你那边可否抽些人过来帮我壮壮声势”。

B项目经理手中有一些程序员和系统分析员，而当前程序员有些空闲人手，系统分析员今天正好有些紧急工作，但B项目经理错误理解为A项目经理需要的人是系统分析员，到时协助答辩，所以回答“不行，今天正好有紧急工作，没有办法帮忙”。

A项目经理只好另想办法。

以上就是典型的理解错误，发送方的正确表达、接收者的正确理解是非常重要的。比较简单的方式是发送者进行信息发送，接收者进行理解后进行细化并进行二次表达，但这种表达却是在确认自己理解了的同时去转叙或者执行的结果，而不是复述。

3.2 沟通是一种期望

在项目管理中，项目不同干系人是有不同的沟通需要的。

项目组成员在具体的工作安排中他想明白那个职位是否符合他的意愿等等，上级

要了解接收者的期望，向下属传达工作安排的同时还要了解他的意愿取向的问题，再采取相应的方法，调起其在工作上的热情，从而促使其在工作的高效付出，在项目管理中如让下属有反抗情绪的产生或者低效的工作，则是一个项目经理在沟通上不得法的一个失败实例。因此制定一个协调的沟通计划就更为重要了。而项目经理的上级和客户更加关心是进度的问题：时间是否会延期、是否要添加成本、质量是否有保障等等。这对于项目经理来说，就应即时的反馈这些时间，特别是将会有延期、将添加项目成本、质量将会有问题的苗头等等，更加必须提早汇报，使项目经理的上级和客户能及时并适时调整工作计划。

3.3 沟通产生要求

沟通是双向的，沟通必须能够符合接收者的利益，那样才有说服力。这就要求双方都要有良好的沟通方式，特别是良好的沟通又能达到双赢的目的，一致的沟通有助于组织促进项目更新。

口头的沟通能力同时似乎又是职位提升的关键因素。于是，沟通又必然的产生要求，比如：职位上成功，项目的早日完成，对问题作出恰当的回应，小到假期薪金等等都要沟通来达到目的。

3.4 信息不是沟通

当前是信息时代，必须分清哪些是沟通哪些是信息，对于用于沟通的信息必须明确简练、醒目，避免沉没于信息之海中。

信息也可用于沟通，但信息过于的生搬硬套，一个文字性的文件是并不能起到沟通的作用的，在项目中，项目经理并不是想集中于信息中而是想了解项目里工作的人员，并与之建立起相互信任的关系。而有效的发送信息，只能是依赖于项目经理和项目组成员的良好的沟通技能。

我们现在就能通过上面的四个法则来进行有效的沟通，达到保证管理中信息有效传达的目的了。实施情况报告

实施情况报告一般有三种形式：定期报告，阶段审查，紧急报告。

? 定期报告：就是在某一特定的时间内将所完成的工作量向上级汇报。在实际的项目管理中项目人员对项目经理按周报告，对于客户和项目经理的直接上级是按阶段或月进行统一的进展报告，从项目管理上讲，项目定期报告的主要内容就包括：当前是什么状态？在什么阶段？进度完成情况？当前有什么问题请上级（用户）协助解决？下周（下阶段或下月）的计划是什么等等。

? 阶段评审：在项目进行到重要的阶段或里程碑似的项目发展阶段，就要进行阶段评审。阶段评审的意义就在于评审当前的项目情况，迫使人们对其工作负责；阶段评审可以提前发现问题，提前将问题解决在初期阶段。不过阶段评审也是最容易产生争执的地方，这主要是针对于问题严重性的定级，项目经理或项目管理委员会必须在全面了解项目发展进展的情况下及时找到问题的重点，从而就事论

事的解决问题的真正症结所在，并进行后面的项目。

? 紧急报告：在出现意外情况下，进行紧急报告。紧急报告包括以下内容：当前发现的问题，相关影响，需如何解决（动用什么资源），问题紧迫性（必须什么时间内进行反馈）。

在实际的项目管理过程中，质量管理的质量保证部门也将进行质量审计，按阶段提交质量审计报告。

项目干系人接到实施情况报告后也应即时的进行反馈，明确报告已经成功接收到。并让项目干系人一道解决执行中的问题。管理收尾

5.1 项目客户验收

项目收尾期间客户将根据合同对项目进行验收，一般是对最终成果《软件系统》，项目文档《操作手册》、《安装手册》、《软件光盘》、《维护计划》或《维护手册》进行验收，双方将产生双方《项目开发总结报告》及《项目总结会议备忘录》

不同的人都有不同的见解，这些报告都是极好的资源，对未来项目的平稳运行有很大的帮助。

5.2 过程文件归档

项目组内部将对项目过程中的计划、需求、设计、源代码、变更、会议纪要、客户信件等文档整理归档，为以后的查询及参考作为一定的依据。项目档案常常在结束多年以后还有用，良好的项目档案能为当前的项目节省时间和金钱，有时还能对组织进行审计等快速提供有价值的信息。

5.3 项目总结

很多项目没有能进行很好的总结，推脱的理由有项目总结时项目人员已经不足/不全、现在有新的项目要接没有时间、写了没人看等等。这些理由全不是正确的，无论如何也要进行总结，只能总结当前，才能提高以后。

IT项目管理风险管理研究 篇3

关键词：IT项目管理；风险管理；风险识别；风险评估

IT项目管理与其他类型的项目管理一样，其立项、设计与实施等都是基于正常的、理想的技术、管理和组织以及对将来情况的预测。但是在实际运行的过程中，这些因素都可能产生变化，而这些变化将可能使原定的目标受到干扰甚至无法实现，因此我们将这些事先不能确定的内部和外部的干扰因素称之为风险。简言之，IT项目的风险就是项目中的不可靠因素，如果不能有效地规避风险就极有可能造成项目的失败。因此，风险管理已成为IT项目管理中不可或缺的重要环节。

一、风险和风险管理

风险是损失的不确定性，是给定情况下一定时期可能发生的各种结果间的差异。它的两个基本特征是不确定性和损失。项目开发的方式很少能保证开发工作一定成功，都要冒一定的风险，也就需要进行项目风险分析。在进行项目风险分析时，重要的是要量化不确定的程度和每个风险相当的损失程度，为实现这一点就必须要考虑以下问题：考虑未来，什么样的风险会导致软件项目失败；考虑变化，在用户需求、开发技术、目标、机制及其它与项目有关的因素的改变将会对按时交付和系统成功产生什么影响；必须解决选择问题，应采用什么方法和工具，应配备多少人力，在质量上强调到什么程度才满足要求；考虑风险类型等等[1]。

这些潜在的问题可能会对项目的计划、成本、技术、产品的质量及团队的士气都有负面的影响。而风险管理就是在这些潜在的问题对项目造成破坏之前识别、处理和排除。

项目风险管理贯穿在项目开发过程中的一系列管理步骤，它能让风险管理者主动“攻击”风险，进行有效的风险管理。

二、IT项目管理风险管理的必要性和目标

（一）必要性

IT项目管理的主要对象就是与信息技术紧密相关的各类IT项目，诸如软件开发、组建计算机网络和信息系统集成等。随着建设环境的日趋复杂，IT项目的投资和建设规模急剧增加，然而IT项目固有的建设标准不统一、人员流动性强、技术发展迅猛等特点决定了它不但要考虑项目管理可能遭遇的一般风险，还面临着其他类型项目所不具备的特殊风险。这些风险的存在很有可能会造成数据丢失、进度延迟、成本增加等不良后果，更为严重的可能会导致整个项目的失败。因此，在IT项目管理中引入风险研究很有必要[2]。

（二）目标

IT项目管理中风险研究的目标主要在于：识别可能影响IT项目成功的任何风险，提供识别和评估风险的标准过程和方法；通过适当的行动将风险产生的概率或后果压至最低；实时监测和报告风险，为制定防范和应对风险的措施提供决策依据。

三、IT项目管理中存在的风险种类

很多学者早就在其著作中提出了项目管理的风险问题，在国内外学者研究的基础上，单就IT项目管理这一特殊领域将影响IT项目的风险定义为以下五个方面[3]：

（一）外部风险

外部风险主要是指那些超出IT项目经理乃至整个项目组织控制范围的影响项目成功的干扰因素，主要体现在：市场和政策的变化、IT行业的迅猛发展、威胁IT项目的安全因素、相关法律问题、自然灾害等。

（二）成本风险

成本风险指因项目或项目组织的变化或失误从而影响项目成本控制的隐患，主要包括：项目运营成本溢出、项目范围的改变导致成本上升、出现未估算的项目成本、项目预算超支。

（三）进度风险

进度风险指由于错失或延误IT项目产品或服务的市场机会而导致项目失败的可能性，其直接表现：项目进度估计不准确、过多的技术、运营和外部问题牵扯项目进程、资源短缺或变更导致项目进度拖延

（四）技术风险

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

（五）运营风险

运营风险指项目无法达到预期收益目标或期望的可能性。主要包括：对优势和冲突的理解不充分、沟通不善、多项目管理。

四、IT项目风险管理的策略

在项目管理中，建立风险管理策略和在项目的生命周期中不断控制风险是非常重要的，一般来说，一套完整的IT风险管理策略包括以下四个阶段[4]：确定业务需求、评估风险等级、设计与实施解决方案、监控、管理与发展。

通过以上四个阶段，完整考虑企业IT风险管理的需求及其实现方式，可以帮助企业更准确地估计项目保护的成本，从而确保企业的投资水平在成本最优的前提下满足风险管理的需要。

五、结论

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

风险在每个IT项目的建设和管理中都有可能发生，这与组织和项目规模大小、项目类型和项目工期都没有必然联系，因此每个IT项目都必须实施风险管理，尽可能地规避风险的影响或者将风险产生的影响减至最低限度。

参考文献：

[1]程婷婷，陈伟亚.IT项目管理中制约因素的分析和研究[J].甘肃农业，2006（2）.

[2]林建平.企业信息化建设的项目管理[J].中国民用航空，2006（2）.

[3]刘普.企业引入项目管理应把握的主要问题[J].铁路工程造价管理，2005（6）.

[4]Murch Richard. Project Management： Best Practices for IT Professionals， First Edition[M].Higher Education Press & Pearson Education，2002.

IT项目管理 篇4

中小企业是社会经济活动中的重要构成单元,也是社会技术创新的主体。与大型企业相比,中小企业通常具有如下方面的基本特征:

(1) 企业规模和IT资源相对受限

由于中小企业自身的规模相对较小,企业内部的IT架构相对较为简单,且企业内部的IT建设与维护力量相对较为薄弱,对于IT建设和IT服务的成本承受能力相对较低。因而从整体上看,中小企业的IT资源相对受限,会更加倾向于通过IT服务外包等方式来构建虚拟的企业IT能力。

(2) 对IT服务质量和安全性的需求较高

中小企业虽然IT系统较为简单,但由于企业业务相对单一,企业业务发展对于业务数据的安全性依赖性较强,是企业的生存之本。如何在既充分发挥IT技术的优势提升企业的业务能力,同时又能有效地保护企业的核心业务数据,是中小企业关注的问题。各个不同行业的中小企业根据自身业务的特点,也会有不同的个性化需求。

(3) 需求与资源条件间的落差显著

综合以上2个方面,不难看出,中小企业在IT服务质量和安全性方面的需求和其自身的IT资源状况存在明显的落差,在实际的情况中将表现为:企业的IT服务质量无法得到保障,甚至可能影响到企业的核心业务运行;企业的核心IT资产无法得到有效的保护,企业整体的IT态势面临较多的安全风险。

在网络化的社会中,IT能力水平决定了一个企业的业务拓展前景和面向最终客户的服务水平,因而上述方面的落差已经成为中小企业业务拓展的一个瓶颈因素。当然,中小企业管理层在意识和管理理念方面也存在一定的差距。

从另一个视角来看,这些落差也意味着一个潜在的市场机会,即面向中小企业的IT服务和安全管理的市场领域。

在这里,将重点针对中小企业IT架构的2种典型的应用模式,分别探讨对应的企业IT服务和安全管理的实现机制问题。

2基于ASP托管的应用模式

(1) 模式提出的背景

ASP应用托管服务是面向中小企业提供的企业核心业务系统的一站式托管服务解决方案,即由ASP运营商构建统一的系统后台,提供企业核心业务功能,中小企业客户可以通过简单的客户化业务配置和定制来快速建立起自己的核心业务系统。

在ASP应用模式下,数据安全性和服务质量已经日益成为该业务拓展的瓶颈因素。对中小企业而言,业务数据和业务资源是企业生存的根本,而要将这些重要的数据存放在一个公用的托管应用平台之上,的确需要相应的IT服务质量和安全保障,才能打消企业用户的疑虑。

(2) IT服务和安全管理的实现机制设计

在ASP应用托管服务模式下,企业实际上采用了整体的IT服务外包模式,因而可适用于较多的企业构建模式,包括SOHO方式。

IT服务和安全管理机制在ASP应用托管模式下的应用,主要是考虑由ASP运营商在后台针对整个服务系统构建统一的IT服务和IT安全保障体系,并作为整体面向前端的中小企业提供服务保障。ASP运营商的IT服务和IT安全保障体系构建方法可参考通常的IT服务管理体系和IT安全管理体系构建方法论,但需要在以下方面提供一些定制化的服务内容:

多服务级别提供 应根据ASP托管服务的业务分级特点,针对不同服务等级需求来定义相应的IT服务和安全保障的服务级别,满足不同用户群的需求。这就要求后台的IT保障系统支持多服务级别的设置。

虚拟服务提供 在后台统一服务系统的基础上,需要面向前端的中小企业用户提供一个虚拟的服务接口,以满足用户的个性化配置需求,并能和ASP应用托管主服务无缝地整合起来。

统一后台服务调度 ASP运营商需要建立统一的后台服务调度体系,以便面向前端所有的中小企业用户提供IT服务管理和IT安全管理的相应服务,完成相应的服务调度和资源调配。

基于上述的IT服务和安全管理架构,ASP运营商即可面向前端的中小企业用户提供带服务质量和安全保证的应用托管服务。对应的系统架构如图1所示:

(3) 服务接口和SLA

在ASP应用服务托管模式下,ASP运营商和中小企业用户之间的服务接口将包括业务配置、业务管理监控、业务故障处理、业务结算等方面。

相应的服务SLA包括IT服务质量接口(业务服务质量、业务数据可用性保证要求)和IT安全管理接口(业务数据安全性、业务连续性保证要求)2方面。

3基于分级网管的应用模式

(1) 模式提出的背景

相对于上面的ASP应用托管服务,中小企业的另一种IT架构模式是部分自建,即企业内网上部署一些基本的IT系统和资源,这主要是出于对核心业务资源安全保护的需求。在自建IT的模式下,中小企业需要承担一定的IT服务管理和安全管理职责,而通常中小企业自身并不具备相应的一支专业化的IT服务力量,造成事实上的很多中小企业内部IT管理不善,并导致企业核心IT资源遭受较大的风险。

因此需要提供一种能提供半外包服务模式的IT服务管理与IT安全管理模式,才能帮助中小企业以相对合理的成本实现对企业内部IT资产的合理运作管理与保护。

(2) IT服务和安全管理的实现机制设计

在中小企业自建IT的服务模式下,通常在企业内网上部署基本的IT网管(综合网管系统)和IT安全控制系统(企业防病毒系统、安全控制系统等),企业内部的IT团队主要借助于这些IT管控设施进行日常的IT服务管理。

在自建IT的模式下,要实现统一的IT服务和安全管理需要采取类似于分级网管的模式,即在企业内网上建立一个简化版的IT服务管控中心,在企业内部运行IT服务和IT安全管理的前端流程(日常操作及简单巡检流程等,可根据客户需求定制确定),同时在企业内网上部署相应的数据采集agent,将企业内网中与IT服务和安全管理相关的事件传送到后端的分析中心进行处理。

在系统后台,将由IT服务提供商构建1个统一的后台管理系统,该系统在提供常规的IT服务管理和IT安全管理功能的基础上,需要重点解决以下方面的问题:

与前端企业用户的接口 在前端的中小企业用户内网和后台服务管理系统之间建立一个统一的数据和业务接口,便于agent采集数据的上传,以及后台的服务信息、服务流程指令的下达,实现前后端管理数据和流程的贯通。

虚拟服务管理 考虑到每个中小企业用户的内网实际情况和需求各不相同,因此需要在服务后台提供用户的个性化服务管理功能,并提供对多服务级别的支持特性,以满足不同类型用户的特点。

跨边界的流程调度 由于在该模式下,IT服务管理和IT安全管理的流程将在后台和前端之间进行分布,需要提供跨工作边界的工作流程调度管理,提供一种异步模式的工作流支持,以便能将前后端的管理流程贯通起来。

在上述实现机制下,后端的服务系统提供的主要功能将包括:

根据agent传递过来的企业内网的IT事件信息,进行综合的事件归并分析,以分析用户端网络的IT状况,并生成相应的事件、故障处理工单。

根据系统生成的IT维护或维修工单,实现跨系统边界的流程调度,指导企业内部IT人员进行现场维修和处理,并在必要时提供上门技术服务。

根据系统后台知识库的更新情况,定期向用户端推送知识库的更新和参考数据,帮助前端管理员提升IT管理水平。定期向前端管理员提供IT服务报告,帮助其明确整网的IT态势,以及是否需要进行配套的IT工程的建议。

而企业内部IT人员所承担的前端运维工作将主要包括:

企业内网的日常IT运维服务,对本地无法处置的IT事件,直接通报后端系统处理;

根据后端系统发送的工单,对系统自动发现的故障、隐患等进行现场处置,在必要时需要请求后端工程师的现场支持;

根据后端定期发布的IT服务报告,对企业内网进行必要的IT整改与建设,以降低系统的IT风险。

对应的系统架构参见图2所示:

(3) 服务接口和SLA

在分级网管模式下,后端IT服务提供商和前端中小企业之间的服务接口将包括业务配置、业务管理监控、业务故障处理、业务结算、数据采集等方面。

相应的服务SLA将包括IT服务质量接口(业务服务质量,业务数据可用性保证要求)和IT安全管理接口(业务数据安全性,业务连续性保证要求)2个方面。

4应用模式的分析

这里对上面2种典型的中小企业IT服务和安全管理的应用模式的特点进行对比分析,结果如表1所示。

从上述分析可以看出,2种不同的服务模式具有各自的特点和适用的场景。在构建上述的IT服务和安全管理机制之后,中小企业也拥有了自己的IT服务管理和IT安全管理的能力,能充分利用IT技术来提升自身的业务能力,确保自身的核心竞争力。但考虑到中小企业在业务特点、企业结构等方面存在的显著差异性,还是需要每个企业根据自身的特点来灵活选用相应的服务模式,或者是两者的混合模式。

摘要：中小企业在IT资源与需求之间的落差形成了中小企业IT服务和安全管理独特的应用模式。通过分析中小企业IT架构的2种典型的应用模式:ASP托管和分级网管,分别探讨对应的企业IT服务和安全管理的实现机制,从而建立中小企业自己的IT服务管理和IT安全管理的能力。

关键词：IT服务管理,IT安全管理架构,IT企业,ASP托管

参考文献

[1]朱海林,方乐,梁晟,等.IT服务[M].北京:机械工业出版社,2006.

[2]马雪.超企业IT服务管理—神龙公司IT服务管理实践[D].武汉:武汉大学,2004.

[3]谭荣.一种服务器与客户端时间同步的有效方法[J].现代电子技术,2006,29(5):48-49.

[4]郭跃周,张颖.基于校园网的计算机考试系统的设计与实现[J].现代电子技术,2006,29(4):121-123.

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

而这个细节也揭示了2007年以来华为全球管控模式的转变。“华为原来的管控模式是以集团总部为中心运作。2007年以后，我们开始采用‘前端一线推动后端总部’的模式，这让信息流的方向完全倒转过来。”即将调入企业业务BG的华为流程与IT管理部首席信息官周良军表示，华为的IT部门不仅仅关注流程的效率，还关注全球的协同和全球员工的效率。

2011年，华为销售总收入已经高达2039亿元人民币，超过70%的销售收入来自海外业务，海外业务已经拓展到140多个国家，全球员工也达到了14万人。而2000年华为刚开始国际业务拓展时，当年海外市场销售额只有区区1亿美元，可谓今非昔比。全球业务的飞速发展，促使华为IT部门创新性地改变传统的IT资源供给模式，提升流程效率和员工的工作效率。

1998年是华为IT发展历程的一个重要分水岭。1998年以前，华为从建设零散的小系统开始走向集中化建设阶段，逐步开始建立统一规划、集中管控的模式，这一时期华为建立了统一的技术平台和统一规范的IT流程，这为2000年以后华为在全球的业务扩展打下了坚实的基础，IT部门通过信息技术将华为内部的管理延伸到全球各地，真正做到业务发展到哪里，流程和沟通就延伸到哪里，有效支撑了业务高速发展。

全球化IT管控

2000年后，随着华为在全球的业务扩展，华为IT部门便开始面临现实而复杂的IT资源部署和分配问题——员工的多国籍多语言，地域分布广泛，还要支持全球协同产品开发、销售服务以及供应交付等。华为IT部门面临的挑战是：如何通过信息技术将华为内部的管理延伸到全球各地？如何高效支撑业务拓展？

“国内很多企业的IT部门往往关注基础的技术工作，或者关注业务系统的一些工作，但是业务系统和人的效率往往不能很好地结合，致使公司的运作效率大打折扣。”周良军表示。对于华为这样一家立足全球、人员分散的企业而言，这个问题至关重要。因此，华为的IT部门的策略是：将关注点放在两个方面上——如何提升流程的效率以及员工的工作效率。

在随后进行的诸多的变革中，华为IT部门首先选择进行主干流程的变革。“就像人体大动脉，只有它打通了，其他的才会通。”周良军表示，“主干流程需要时间完善，它可以跑得慢一点，但是一定要非常简捷。”为了适应华为全球化的管控要求，华为采取集中控制分散资源的方式，建立全球垂直管理的IT组织，以统一的流程方式进行，在IT基础设施和应用平台上进行集中管理。在这种模式下，华为使用同一套研发协同的IT平台，实现对全球23个研发中心的一体化协同产品开发；并且使用一套业务处理IT平台，实现对全球140个国家业务的一体化业务运作。在这个过程中，华为的IT部门通过和外界顾问合作的方式，迅速吸取国际的先进做法；在主干流程的系统建设上，则采用成熟软件包的方式，迅速完成主干系统的构建。

“主干简捷、末端灵活”是当时华为确定的IT管理核心原则。主干系统基本构建完成后，华为的IT部门将更多的精力倾注在自主研发构建快速、灵活的末端应用上，这样做的深层价值是：对于华为这样一家全球化公司而言，全球的协同、前后方的沟通和协调工作繁多，尽量降低一线员工的学习成本，可以简单方便地处理业务。

因此，华为致力于构建全球的工作协同平台。目前它已经构建了基于桌面云技术的研发与办公协同平台。2011年，华为已经有3.5万名用户在这一平台上工作，2012年，这一数字将计划扩大到6.5万。与此同时，华为倾力打造它的全球移动办公平台eSpace，现在这个平台上已经有20万用户，其中移动用户超过8万，每天华为员工在这里召开的会议达到2万个，人均效率提升19分钟。

另一项典型应用是，华为内部的员工和管理者，包括销售、交付、研发等不同部门的员工都有基于自我角色的门户，在这里，他们可以使用基于统一通信服务、邮件服务等完成沟通和协作，可以获取基于角色的行业信息发布及订阅，也可以一目了然地处理个人待办事项，以及使用个人收藏功能更快地找到工作相关内容。

在这个过程中，华为IT部门不断接到来自业务部门和一线部门的多种IT需求。为了管理这些源源不断产生的需求，华为在内部成立了一套严格的IT需求管理架构。为了对业务部门提出的IT需求进行评估，华为的一线部门、业务部门和IT部门每个月都会坐在一起，对这些需求进行讨论，从整体架构的角度对这些项目进行评估。最终投票获得通过的需求，会被提交到更高层级的变革指导委员会进行审批。“IT是一项投资，这项资源要用在最需要的地方，最终达到全局优化，而非局部优化的效果。”周良军表示，“那些仅仅着眼于局部优化的项目在华为内部不会被通过。”

一线驱动

2005年以后，随着华为全球业务的发展，为了更迅速响应前端一线业务的需求，华为内部的管控模式开始逐步转变，原来自上而下的管控模式，逐步转向一线业务端推动管理总部、总部服务一线的方式。华为IT部门需要随之做出的调整是：逐步建立前端一线推动后端的模式，帮助前端员工迅速获取他们需要的信息。为了完成这一转变，周良军和团队成员不断深入一线，了解一线员工的需求。

周良军印象很深的一个事情是，华为承接的一个海外订单——印尼的全球网络建设，需要建设成千上万个站点。在这期间，华为总部不断接到抱怨，原来一线人员发现他们70%的时间都耗费在打电话上：了解供应链上的到货情况，以及其他信息协同的沟通事务，这让他们非常郁闷。

这个问题在2008年以后得到了很好的解决，订单信息的获取方式完全以前端一线员工的需求为主导，现在一线员工希望看到订单的所有状态信息时，IT部门已经设置了20多个信息点（包括到货情况、单点安装情况等），后端会在第一时间将这些信息主动提供给前端。与此同时，当前端的一线员工安装好站点之后，也会通过手机拍照将完成工作的信息传回后端。（传统的做法是，后端等待以及督促前端把这一信息上传到后端。）

与此同时，华为的员工都安装了具有统一通信功能的智能手机，当他们希望与后端总部的相关人员进行沟通时，随时可以将这个人拉入电话会议中，没有繁琐的会议号没有密码，只要对方回复“y”（yes）便可一键入会。在当初在传统的IT资源使用模式下，一线员工如果需要开会，需要和后端人员事先沟通，还需要提交线上申请或者沟通，之后才能通过电话设备或者视频会议设备进行；通过手机开会还需要输入会议号和密码。

现在，前端的一线人员需要后端提供服务时，所有的流程也发生了倒置。按照传统的做法，当一线提交一项申请时，后端的财务部门需要审批一次、供应链部门需要审批一次。现在的方式是，华为的IT部门会事先了解一线需要什么服务，此后在流程上进行设置，令后端可以迅速响应前端的需求。在传统的审批模式下，各级主管需要查看邮件进行审批，审批时间分散并且不及时，现在华为的IT部门将所有系统中需要审批的事项全部集中显示在一个界面上，便可以进行集中审批。

在这个过程中，华为的IT部门也在不断面临挑战。周良军介绍，在推动IT支持全球化战略的过程中，华为也有过一些经验教训。2005年，当华为IT部门开始在全球推动全球ERP项目时，按照惯常的IT思维，首先选择最难的巴西作为试点部署。然而，巴西的税收政策与大多数国家不同，通用的ERP软件需做大量的定制开发，影响了整体业务部署进展。最终他们决定改变策略，转而选择容易部署的国家和地区部署ERP，最后再推行到巴西等国家，同时IT部门在已有的通用系统版本上，再做本地化特殊处理也容易多了，这时候项目便很快得到推进。

现在回首过去10多年华为IT系统建设走过的路，周良军认为，架构管理很重要，企业需要搭建相应的业务流程架构、信息架构、技术架构，而不是零敲碎打，东一榔头西一棒子。“企业经常会进入一个误区——由于没有将IT和业务结合在一起加以衡量，导致无法真正看到IT的价值，最终导致企业的IT建设不连贯、不均衡。”周良军表示，这也是华为最初就极力避免的问题。

“IT项目管理”课程体系建设 篇7

1“IT项目管理”课程目标

哈尔滨理工大学信息管理与信息系统专业, 经过省级重点专业建设和国家级特色专业建设,目前已经建立了“全方位、全过程、立体交叉”的教学管理体系和“平台+ 模块+ 实训”的课程体系。 在这种专业培养体系下,将本专业学生培养目标分解为8个阶段的能力目标,每一个子目标需要“公共基础课程群”“人文素质课程群”“学科基础课程群”“专业基础课程群”和“专业平台课程群”5 个课程群,以及课程设计、生产实习、学科竞赛等实践环节的支撑,形成信息管理与信息系统专业的人才培养体系,如图1 所示。 其中,垂直方向表示学生在校学习的8 个学期能力逐级提升培养过程;“人文素质课程群”“公共基础课程群”和“专业平台课程群”集中在前4 学期循序渐进地开设,主要培养学生的自我管理、专业认知、问题分析和技术应用的能力,“专业平台课程群”“专业方向课程群”和实践教学环环相扣,培养系统开发、理论研究、综合应用以及社会适应能力。

根据本专业的培养体系,“IT项目管理” 设置在第七学期开设,课程目标是培养学生综合应用能力。

2“IT项目管理”课程体系设计

根据“IT项目管理” 课程的培养目标,将综合应用能力的培养分解在项目管理的知识维、能力维和实践维,旨在通过实践环节综合提高学生的信息化实战能力。

(1) “IT项目管理”课程体系框架设计。 “ IT项目管理”是信息管理与信息系统专业的专业方向课之一, 针对本专业的培养目标,以及本门课的专业知识集成度高的特点［2］,培养学生不仅掌握项目管理的基本原理、 基本理论知识和相关的技术方法［3］,把握IT项目管理的工具、过程和技巧,同时还要求学生跟踪国内外IT项目管理的理论与实践动态, 培养学生应用项目管理理论和方法分析、 解决信息系统开发项目以及信息化建设项目的管理能力。因此,课程内容设置为3 个模块:1 理论教学模块。旨在使学生掌握IT项目管理的基本理论、方法,如九大知识领域和5个管理过程。 2 课内实验及课程设计模块。 在理论教学的过程中,安排6 次课内实验课,使学生掌握使用项目信息系统管理IT项目的技能,同时,在学期末,开展IT项目管理课程设计,通过具体的项目实例,根据IT项目的特点,进行组织设计,实现范围、时间、质量、成本等多要素的平衡,使学生掌握在IT项目管理过程中的关键管理问题,以及使用恰当的方法予以解决,进而形成IT项目管理的实战能力。 3 扩展实践模块。 在正常的教学任务之外,设置“项目管理沙盘推演”开放实验,以及“项目管理沙盘推演辅助决策支持系统”大学生创新实验,使学生在课余时间根据自己的兴趣、特长自主地提升项目管理的能力。 IT项目管理课程体系结构如图2 所示。

(2) “IT项目管理”课程体系建设。 该课程体系建设主要包括教材建设、教学组织建设、实验环境建设3 项内容。 1 教材建设。由于IT项目管理这门课程开设得比较晚,在教学内容和知识体系方面很难找到适合本专业培养目标的教材, 本课程组在积极跟踪国际现代项目管理理论和方法最新发展动态的前提下,开展了本门课程教材的改革与研究, 教材改革的总体思路是按照教育部对本专业教学的基本要求和本专业培养的目标要求,本着理论与实践相结合、借鉴与创新互补的原则,编写了《IT项目管理》教材及辅助教材(包括实验指导书和案例教材),目前本教材已经被列入了“中国科学院规划教材”,教材内容在规范的理论体系中融入了最新的、典型的教学案例,在教学实践中,有与教材配套的课件、试题库、网络课程和资料库等辅助资料,突出立体化教材的特色。 目前,系列教材已经使用两年,教学效果良好,受到学生的普遍好评。 2教学组织建设。 根据本专业人才能力培养的需要,课程组成员在教学组织上采用了一系列符合本课程教学特点的多样化的教学手段。 如案例教学、问题教学、实验教学、研究教学等先进的教学方法,提高课程教学效果。 其中案例教学方面,课程组成员收集在实际的IT项目管理过程中的典型案例, 在关键节点和重点问题中,引入教学案例［4］,形成了“方法+实例”的教学辅助资料库;问题教学法,是在解决关键问题,采用“多方式辩论”的教学手段调动学生的积极性;实验教学法,是利用“知识讲授+实践亲历”的方式,通过课内实验,在掌握项目管理知识体系的基础上,通过项目管理软件来管理项目, 提高学生对IT项目的实践认知;研究性教学法,鼓励有兴趣的学生申请大学生开放试验和大学生创新试验,结合自己的知识和能力开展理论研究,鼓励学生发表论文。 3 实验环境建设。 哈尔滨理工大学设有“IT项目管理沙盘实验室”和“IT项目管理实验室”,为学生创造较好的实验教学环境,同时学院还积极与社会上的企事业单位联系,签署了多项合作协议,使学生能够有更多的机会参加社会实践活动。 目前学院已与哈尔滨电机厂、 长春第一汽车制造厂等单位建立了长期的协作关系,作为学生的实习基地,与用友软件公司签署了校企合作协议,成为长期的战略合作伙伴。

通过以上教学体系的建设, 我们定位于基础扎实、 知识面宽、能力强、素质高、勤奋、团队、敬业、实践与创新,教师在理论知识传授的同时,积极组织学生进行研讨,鼓励并指导学生参加相关学科竞赛, 加强了教师和学生之间的互动与交流, 形成了“ 以教师为主导, 师生互动, 以学生为主导” 的教学模式, 使学生专业有深度、知识有广度,理论有用处。

3结语

IT项目风险管理分析 篇8

项目风险管理是指对项目风险从识别到分析乃至采取应对措施等一系列过程, 它包括将积极因素所产生的影响最大化和使消极因素产生的影响最小化两方面内容。主要包括:风险识别、风险量化、风险对策。随着信息化社会的形成, 信息化项目便宜成为社会发展的重要推动力。信息化项目的开展是以信息技术为支撑, 以业务活动为主体, 以现代化管理为指导思想的一项全新的、复杂的系统化工程。全新在于信息技术这一新生事物的飞速变化与发展, 复杂在于信息技术、业务工作、项目管理思想的一体化融合与集成化应用, 这正是IT项目管理问世的缘由。

IT项目风险是指由于IT项目所处环境和条件的不确定性, 导致项目的最终结果与我们的期望产生背离, 并给相关人带来损失的可能性。IT项目风险管理是对项目中潜在的风险进行预测并实行有效的控制, 从而可靠地实现项目的总体目标的一种管理IT项目管理与其他类型的项目管理一样, 其立项、设计与实施等都是基于正常的、理想的技术、管理和组织以及对将来情况 (政治、经济、社会等方面) 的预测。

2 我国IT项目风险管理现状分析

风险管理产生于20世纪初的英国、德国, 之后逐渐形成一种系统的科学方法。但是, 风险管理真正在工商企业中引起足够重视而得到推广则始于20世纪50年代。对于新兴的IT产业, 国内外项目管理专家和学者都从20世纪80年代就开始做了一些前瞻性的尝试和探索。但是, 由于IT产业发展时间较短, 研究和实践的基础较薄弱, IT项目管理本身存在着缺乏项目管理意识、没有精确的项目成本基础、项目管理制度不到位、缺乏专业服务组织、项目计划性差、项目风险意识淡薄以及业务参与意识薄弱的现状。同时IT产业与生俱来的高风险性、高更新性 (生命周期短) 以及高复杂性等特点, 导致了传统行业的通用项目风险分析方法和经验在IT行业中无法得到充分应用和借鉴。近年来, 随着IT项目的广泛实施, 一方面为众多的企业带来了管理、经营方面的革新, 而另一方面, 夭折、中断、失败的项目也不在少数。

3 IT项目管理中的风险类型分析

3.1 IT项目管理中的系统风险

系统风险风险主要是指那些超出IT项目经理乃至整个项目组织控制范围的影响项目成功的干扰因素, 主要体现在:

第一, 市场和政策的变化。市场和政策风险主要表现在两方面, 首先是市场需求的多变以及新产品、新服务的不断更迭可能导致IT项目建设方向的急剧改变, 这对绝大多数的项目来说都是致命的;其次是与IT项目管理相关的政策从无到有不断涌现, 给实施项目的企业设置了越来越多的约束。

第二, IT行业发展迅速, 产品更新换代快。IT行业被称为朝阳行业的根本原因就在于这个领域出现的时间不长而发展又非常迅速, 所以, IT项目必然面临层出不穷的新标准和新趋势。与此同时, IT业内的竞争与合作也不断改变着IT企业或企业联盟的战略和竞争优势, 从而影响IT项目的发展进程。

第三, 自然灾害的出现。火灾、洪水、地震等自然灾害对IT项目的建设而言是不可忽视的客观存在, 其破坏力之大往往超出人们的想象, 而自然灾害的随机性使得项目组织一般很难做出预测。

3.2 IT项目管理中的技术风险

(1) 技术成熟度不够。

无论是IT项目的业主还是项目组织都倾向于追求最新的技术, 然而现实的情况是新技术往往不够成熟, 将不成熟的技术引入IT项目的建设是极易招致失败的。

(2) 开发与管理工具选择不当。

“工欲善其事, 必先利其器”凸现了IT项目管理中工具选择的重要性, 能否从众多的开发和管理工具中做出正确的选择与项目的成功也是息息相关的。

(3) 项目测试不严谨。

测试是IT项目实施的重要环节, 由于很多项目未经严格的测试就投入运行, 以致无法提早发现和修正错误导致巨大的损失。此外, 试运行环节作为连接测试阶段与正式运行阶段的重要手段也可能未得到重视。

(4) 软硬件的集成矛盾。

由于IT行业在很多方面缺乏统一的标准和尺度, 致使IT项目中所采用的不同产商的软件和硬件设备在集成到一起时可能产生无法预期的错误和冲突, 进而影响IT项目的实施效果。

3.3 IT项目管理中的成本风险

(1) IT项目运营成本存在溢出性。

项目运营成本主要是指由项目团队、项目业主和项目顾问等涉及项目运营的组织或人员在项目建设过程中所引发的成本。由于IT项目的人员组成复杂且流动性非常强, 加上项目运营牵涉的不可控因素较多, 因此运营成本溢出的可能性非常大。

(2) 项目范围的异改变, 导致成本上升。

业务主需求的变化和信息技术的发展导致IT项目范围的改变是项目经理经常遇到的现象, 随之而来的便是项目成本的不断上升甚至成倍增长。

(3) 出现未估算的项目成本。

虽然IT项目在进行规划时就应做出精确的成本估算, 但成本估算毕竟是一项预测性的工作, 在实际操作过程中难免会产生错算、漏算从而导致未估算的成本项目的出现, 因而影响整个项目管理的成本和绩效。虽然在IT项目管理中对于成本和费用有严格的控制, 但人力成本变动、设备价格上涨、项目工期延误等无法预期的特殊情况的出现仍然可能带来项目预算的超支。

4 加强IT项目风险管理的策略性思考

4.1 识别IT项目中的风险

对IT项目进行风险管理, 首先要对存在的风险进行识别, 以明确对项目构成威胁的因素, 便于制定规避风险和降低风险的计划和策略。风险识别就是采用系统化的方法, 识别出项目中已知的和可预测到的风险。风险识别是一项反复的过程, 应该在IT项目的生命周期自始至终定期进行。风险识别包括确定风险来源、分析风险产生的条件、描述风险特征和确定风险的影响范围。风险的识别可以分为三步进行:收集资料、估计项目面临的风险形势、根据直接或间接症状将潜在的风险识别出来。

4.2 分析风险

对IT项目的风险分析应从两方面进行, 即:定性分析和定量分析。定性分析是指对已识别风险的可能性和影响性的评估;定量分析是在定性分析后进一步量化每一个风险的概率及其对项目目标造成的后果, 也分析项目总体风险的程度。

对IT项目风险进行定性分析, 可以从宏观上对项目是否可行有一个初步的概括, 可以加深项目管理人员对项目风险的认识与了解。定量风险分析是在定性风险分析之后进行的。有时在风险应对规划之后, 对作为风险监督和控制过程的组成部分, 应重新进行定量分析, 以确定项目总体风险是否降低到满意的结果, 以及是否需要增加或减少风险管理措施。

4.3 制定IT风险应对规划

针对风险定性、定量分析的结果, 制定风险应对规划, 以降低IT项目的风险或减少项目风险的副作用。如果风险识别和分析的结果超出项目组织或项目用户能够接受的水平很多, 应根据超出情况选择停止项目或取消项目。当风险识别和分析的结果少量超出项目组织或项目用户能够接受的水平时, 应该制定各种项目风险应对措施, 并通过开展项目风险控制来落实这些措施, 从而避免或消减项目风险所带来的损失。

风险的应对规划必须与风险的严重程度、成功实现目标的费用有效性相适应, 必须与项目成功的时间性、现实性相适应。同时, 必须取得所有项目利益相关者的认可后, 由专人负责。

参考文献

[1]袁义才.项目管理手册[M].北京:中信出版社, 2007.

[2]程婷婷, 陈伟亚.IT项目管理中制约因素的分析和研究[J].甘肃农业, 2009, (2) .

IT项目管理的路径与思考 篇9

0 引言

IT项目主要是指计算机信息管理系统。据业界的调查, 成功完成的IT项目不到1/3, 而大多数项目都因为时间延期和超过预算成为问题项目或失败项目。原因很多, 但大多是需求变更、业务方项目经理的不稳定或双方对业务的理解不一致, 以及开发单位人力资源配置不足等原因造成的。

1 IT项目管理

1.1 确定需求基准

在项目正式启动前, 要制定项目章程, 确定需求基准。确定需求基准是项目成功的关键。

双方对项目基准理解的一致性, 是项目顺利进行的前提。首先, 要求客户方的项目经理与开发单位的项目经理充分沟通, 对需求、业务和实现方法进行充分沟通, 达成一致的理解, 形成项目的需求基准;其次, 双方对列出的需求进行分析, 并进行逐项分析, 实事求是地进行取舍, 保证信息系统与管理流程充分融合。

1.2 选用项目经理

需求基准确定后, 挑选一个优秀的项目经理并支持其组成一个项目团队, 选用一个好的项目经理是项目成功的一半。

(1) 项目经理应有很强的沟通能力:项目经理在团队中不一定是技术能力最高的, 但一定是沟通能力最强的, 要与所有的“干系人”沟通 (干系人是指与项目有关系的所有组织和个人) 。项目经理不仅要善于与项目团队成员沟通, 协调团队实现目标, 而且还要擅于与直接领导和资源管理部门沟通, 为项目组争取必要的资源。更重要的是, 项目经理应能够很好地与客户方的项目经理 (主管) 沟通, 在项目进度、功能需求、风险控制等方面, 项目经理与客户项目主管达成共识对项目的顺利完成是至关重要的。项目经理可能要用80%的时间用于与各类“干系人”进行沟通。

(2) 项目经理应有足够的权力:项目经理首先是个组织者, 应该有对等的责、权、利。首先, 应该对项目的进度、质量和客户满意度负责任;其次, 应赋予一定的权力, 比如阶段性目标的制定、项目团队人员的分工、绩效考核和绩效工资的分配等等;最后, 项目的完成情况应与项目经理的利益挂钩, 使项目团队的利益与公司的利益统一起来。

(3) 给项目经理提供必要的资源:项目一旦立项, 就要给项目经理提供和配备必要的资源, 即必要的人员、合理的经费和相关的支持, 并且持续保障。

1.3 项目经理的角色和职责

项目经理的责任就是项目管理, 作为项目的主要责任人, 其根本职责是确保项目的全部工作在项目预算范围内按时、优质地完成, 使客户满意。

(1) 项目经理的角色:项目经理的角色具有多重性。对于不同的“干系人”扮演着不同的角色, 项目经理的角色在不停地转换。项目经理对于客户、经理、财务部门、系统设计师、供应商、公司高层领导、项目组成员等不同的“干系人”, 其角色在合作者、组织者、控制者、计划者、分析师、协调人和决策人之间转换。

(2) 项目经理的素质要求:对于IT项目来说, 项目经理对项目成功与否, 起着非常重要的作用。项目经理对于不同的“干系人”, 转换不同的角色, 应该是一个复合型人才。因此, 项目经理至少应具备以下素质:

1) 勇于承担责任的精神;

2) 积极创新的精神;

3) 实事求是的作风;

4) 任劳任怨、积极肯干的作风;

5) 自信心;

6) 一定的表达能力和说服别人的能力;

7) 精于领导, 但是应灵活机动;

8) 较强的协调能力, 可以协调多方的利益关系;

9) 擅长完善计划、制定计划和执行计划。

1.4 项目的组织形式

项目的组织形式是决定项目开发效率的关键因素之一, 也是影响项目人力资源配备和项目成本的因素之一。常见的组织类型有职能型、矩阵型和项目型。

(1) 职能型:根据项目的不同阶段及部门职责而对应成立的项目组织。职能型组织类型比较稳定, 职责比较明确, 但对一个完整的项目, 在不同的阶段要有不同的职能部门组成的项目经理来完成, 协调工作量小、人力成本不高、效率低, 适合于行业内部的信息企业和业务比较稳定的信息企业, 如图1所示。

(2) 矩阵型:矩阵型组织是把不同的职能部门的职员, 为了一个明确的项目专门成立的项目组织。矩阵型结构可以做到人才共享性高、人力资源成本低, 但存在着管理交叉、内部冲突多、协调工作量大。如图2所示。

(3) 项目型:项目型组织是根据项目的业务性质而成立的一种组织形式。项目型结构专注于项目的开发、实施和后期服务。项目组织内从设计、开发、实施和后期服务的人员俱全。这种形式的特点是专注项目、效率高、内部矛盾小, 但总体来看, 人力资源需求大, 公司成本开支大。适用于规模大、服务期长、市场稳定的项目, 如图3所示。

这3种项目组织形式, 各有特点, 可以根据承接项目的性质、规模、难度和市场的成熟度来选择。

1.5 项目的规划和控制

项目启动、需求基准明确后, 在研发的过程中, 关键是规划和控制。

(1) 项目的规划一般包括计划制定、范围规划。计划的主要内容是项目估算进度计划、费用计划、资源计划、质量计划、风险计划和辅助管理计划。

范围规划是指产品的规定特征与功能以及服务或成果而需要完成的工作。范围规划依据需求基准、项目章程、项目范围制定。

(2) 项目的控制主要包括控制质量、控制过程、控制风险和控制变更。项目的控制由项目经理和项目管理部完成。

1.6 项目的收尾及验收

通过执行一系列的计划和控制, 履行完项目合同和规划书的所有功能后, 应有计划的进行项目的收尾。这里包括项目移交方案的制定、关闭所有问题、召开用户参加的上线准备会、布置并执行上线方案。

与此同时, 项目经理应召开项目团队内部的会议, 进行绩效总结, 系统上线的风险控制和应急对策。项目移交用户试用或系统上线稳定后, 应与客户的项目经理 (客户代表) 共同制定验收方案, 严格对照项目的需求基准、项目章程 (项目合同书) 等文件制定验收大纲, 并对项目后的变更达成约定。原则上, 对于项目章程 (合同书) 及需求基准以外的变更, 双方应视为此项目的升级任务或启动另一个新的项目。项目一旦通过验收交付使用, 应认为此项目已完成。

2 结语

此处提及的项目, 是指一个组织为实现自己既定的目标, 在一定时间、人员和资源约束的条件下, 所开展的一种具有一定独创性的一次性工作。对于IT企业来说, 在一定的内部资源和技术能力的支持下, 所承接项目的成功率, 关键在于项目管理的能力和路径的选择。项目管理的水平是IT企业能力的标志, 项目经理队伍的能力是IT企业能力的体现。

浅谈如何有效管理IT项目 篇10

统计数据表明, 大多数IT开发项目的失败, 并不是由于IT开发技术方面的原因, 它们的失败是由于不适当的管理造成的。通过有效的项目管理, 我们可在同样的时间内, 花更少的钱, 开发出成功的更优秀的软件产品。这不是特例, 越来越多成功的公司和越来越多成功的产品一次又一次证明了实施软件项目管理的有效性。对于以项目为基本运作单位的IT服务公司来说, 主要目标是让每个项目都能使客户满意和公司获利, 成熟有效的项目管理无疑将起着重要的作用。

2 IT项目管理知识体系

2.1 项目及IT项目。

讨论项目管理必须先对项目的概念有所了解。项目 (project) 是“为生产一个特定的产品、服务或者结果而采取的临时性的努力”。IT项目通过实用硬件、软州:或网络来创造一种产品, 服务或者成果。“项目”是一个可大可小的词, 它可能是一项相当简单的活动, 比如为办公楼所有的接待员配上新的个人电脑, 也可能是一项很复杂的冒险活动, 例如开发系统软件或进行系统升级, 或者是一项有意义的庞大任务, 如全公司采用ERP。一个项目可能只有一个员工或者由来自不同公司的几十人组成的团队。简单的项目可能不需要规划, 所有的关键信息都存在你的脑海里就可以;相反, 一个复杂的项目可能需要特殊的项目软件, 同时需要团队进程和时间表以便跟踪管理。

2.2 九个知识领域与三项约束。

项目管理是由九个知识领域组成的:综合、范围、时间、成本、质量、人力资源、沟通、风险和采购。所有项目有三个必须考虑的要素:时间, 成本和质量。三者的关系经常是三角关系, 密不可分。三个要素在一个项目进行中也经常发生冲突。一般来讲, 人们总希望在非常短的时间内, 以尽可能低的成本获得最好的质量结果。然而, 这三种要素中的任何一个都可能成为重中之重, 一旦确定其中一点, 那么另外两点就需要相应进行调整。大部分项目都被迫要服从至少一个要素, 所以你必须知道你的重点。

2.3 五个过程组。

项目管理是一个综合性的努力, 在一个知识领域内的决策和行为在某个特定时间内通常会影响到其他的知识领域。管理这些交互过程通常需要在项目的范围、时间和成本 (项目管理的三项约束) 之间做出平衡。项目经理也需要在其他的知识领域 (例如在风险和人力资源) 进行平衡。因此, 可以把项目管理视为一系列的相关过程。过程 (process) 是指向某一特定结果的一系列活动。一个项目管理五个过程组包括启动活动、计划活动、执行活动、监控活动以及收尾活动。

3 IT项目管理的误区

3.1 误区1:

没有充分规划。规划管理力不足, CIO、项目总监、开发经理对设计重视不够, 为了赶工期, 很多项目的设计过程过于简单, 产品开发技术路线的选择比较随意, 有的甚至根本没有设计过程。失败往往是由于缺乏周密的计划造成的, 草率决定难以完成目标, 并且成本很高。没有良好的开发计划和开发模式, 产品缺乏良好的结构设计, 规划管理力不足, 项目的成功就难于谈起。

3.2 误区2:

没有预计到项目中人的影响。所有项目都会产生变化。所有项目将同时碰到欢迎与抵触的声音, 尤其是在项目直接影响的人群中。项目经理需要阐明好处, 帮助成员认可项目, 认可执行项目的结果。存在竞争的项目将引发内部的政治斗争, 以及引发对有限资源的利益分配斗争。当项目获批, 你要准备开始战斗。

3.3 误区3:

太纠缠于项目细节。由于项目的繁琐, 很容易就会陷入细节当中。项目经理应该关注宏观, 确保所有行动都按部就班, 按时并在预算范围内进行。不要纠缠微观性的东西。

4 IT项目管理的有效方法

4.1 制定目标导向计划。

首先为了保证按期完成, 我们要制定项目的计划, 它应该来自启动项目的基本文件。没有计划, 你无从知道什么时候控制和变更。制定一个详尽的计划, 以详细到开发人员可以理解的程度为宜。计划能够告诉你什么时候应该做什么。没有计划, 你无从知道自己需要做什么。对于开发人员来说, “目标导向”是充分调动其工作积极性的最佳方法, 每一个任务阶段的成果能够将员工的工作效率维持在一个较高的水平。因为近期目标总是比远期目标来说更容易看到和达到。为此, 制定一个计划, 让它符合目标导向 (通过各个具体任务计划促使项目总计划的达成) 。

4.2 将工作细化为小的目标。

小目标就是大目标细化后的结果。主要的目标是一个阶段或一段增量的末尾。要达到那一点, 项目需要在整个进程中都设立细化的目标。小目标一到两天的工夫就可以达到, 以小时为单位。它有这样的好处:可以改善状态报告;因为可以知道一个小目标是否没有完成所以能够实现细粒度控制;因为大约每天都可以完成一个小目标所以会更好地激励员工;还有可以降低执行进度超时的风险。为了避免项目中的各种问题, 建议小目标的设定从项目一开始时就着手实施。最好的办法是用电子表格记录和跟踪小目标的执行进度。由工具 (如Micro Soft?Project) 生成的项目计划最好只用于更上层的任务。尽早地实施小目标计划的工作可以避免潜在的灾难性结果的发生。

4.3 做好风险储备, 应对不断出现的变化。

作为项目管理人员来说, 应该及早预测可能出现的风险, 做好风险储备。对于大多数项目, 每个月项目的需求变化不会大于5%。功能特性蠕变都会轻易使得成本和执行进度超出预先的估计。当执行到某个阶段时, 项目需求就必需确定下来并锁定其核心内容。一个变化的管理过程由变化委员会来执行, 变化委员会由项目所涉及的每个领域的代表组成。变化委员会负责将所要做的改变交由适当的人去完成、对改变作出说明并测定来自各方的估算值的大小。在获得足够的信息后, 变化委员会就可以决定接受还是拒绝这项变化。一旦接受一个变化, 它将被加入到计划当中并且执行进度也要做出改变。一个项目如果在启用变化委员会之后有超过5%的改变, 则表明项目制定得非常糟糕或者已失去了控制, 最终很可能会失败。

4.4 了解项目管理的三个主要领域。

项目经理主要专注三个领域:企业。项目必须给企业战略提供支持, 项目还必须由适当的管理层进行分配。参与项目的每个人必须明确这个项目究竟是什么, 目标是什么, 它对企业的好处是什么。项目经理的工作就是确保项目从一开始被正确定义, 规划。人员。项目经理要判别出项目主持人 (总揽项目的人) 以及向重要任务指派人员, 项目经理还要判别出项目“拥护者”, 这些人主要对项目的成功提供支持。控制。从一开始起, 项目经理必须规划项目, 评估涉及到的风险, 判断所需技能与资源, 然后不断对项目进展进行监督, 不断调整直到成功完成目标。

4.5 发展关键技能。

项目经理必须非常具有组织能力, 并且乐于从事规划, 预算, 人员, 交流等复杂的工作, 他还要保持时间, 成本和质量三要素的平衡。项目经理因此不但需要在自己的领域表现出色, 而且还要有影响高层决策者的能力。除了专业技能, 他们还需要两种技能:商业与人际交流能力。商业技能方面, 项目经理应该能够:规划整个项目;监督成本, 效率和质量;运用技术和管理技能控制项目;确保所有相关人员都参与决策;在合适的时间, 为合适的任务分配合适的人员;当复杂问题出现时解决它们;要一直关注结果。人际交往能力方面, 项目经理还应该能够:以身作则, 给其他人树立领导者的榜样示范;与高层决策者协调项目需求, 比如日程, 预算等;用正直, 敏感和想象去激励;在成员之间培养良好关系氛围;与每个人明确进行沟通。

结束语

本文结合项目管理知识列出了IT项目管理的常见误区, 概述了帮助提高IT项目开发成功率的有效管理方法。在IT项目开发过程中, 遵从这些指导原则, 您可以在预算和预定时间范围内更好地完成项目, 提高项目开发成功率。

参考文献

[1]Kathy Schwalbe.IT项目管理[M].北京:机械工业出版社, 2008.