如何进行有效的IT项目管理

IT项目管理的风险有哪些

项目风险是一种不确定事件或状况，一旦发生，会对至少一个项目目标，如进度、成本、范围或质量目标产生积极或消极影响。那么IT项目管理的风险有哪些呢？一起来了解下吧：

(1)技术风险。

核心系统升级引入了外包厂商的最新产品，使用了很多新技术，行内研发人员熟悉这些技术需要一定的时间，而在项目过程中却不可避免地会遇到一些技术问题。如何能快速解决这些棘手的技术问题我们的做法是：第一，指定行内外包厂商接头人，由接头人负责和外包厂商的技术人员进行沟通，同时该接头人也是行内对厂商产品最熟悉的人，一般性的小问题基本上此人就可以解决，比较复杂的问题才提交给厂商解决，这样比起全部问题都去找厂商解决，节省了时间。第二，购买厂商的人力进行技术支持，请厂商的研发人员来到开发现场和我们一块研发。第三，预约厂商在系统上线期间到现场待命，以应对紧急问题发生，对可能出现的问题进行第一时间的响应。

(2)沟通风险。

参与项目的外包厂商有多个，沟通渠道多，沟通成本大，而且容易出现理解不一致的情况。所以，项目组成立了专门的PMO，负责制定相应的沟通计划，为每个厂商指定行内的接头人，对内部人员实行分级管理，组织定期例会解决项目过程中出现的问题，防范由于对需求理解不一致造成的项目延误，充分利用已有的邮件、会议、电话和短信等沟通工具，并推广使用某即时通讯工具以作为主要的工作沟通工具。

(3)需求变更风险。

针对IT软件项目中不可避免的需求变更活动，在项目开始后，我部就停止了除政策性需求以外的所有规模超过20人/天的新业务需求，同时制定了需求变更流程：所有业务需求的变更必须由业务方的代表统一提出，变更必须有书面记录，开发人员仔细评估是否接受，最后由总管变更的领导(CCB)复审，总管领导具有一票否决权，从而精简了一些不合理的需求变更。在项目中期引入了IBM的配置管理工具CCCQ来管理代码和缺陷，所有Bug都进行了分类，并录入CQ系统，防止重复修改和修改后无记录等情况的发生。迁移演练之后的缺陷都由各个系统的负责人统一对缺陷进行分析评审，消除Bug修复可能导致的系统关联问题。

(4)进度风险。

项目进行核心升级，引起了客户面数据结构和一些外部接口的变化，同时前端业务平台也做了很大的调整，如开发了新的权限系统、迁移主机老权限系统上的权限数据到微机、替换传输协议XML为JSON、改造微机调用主机框架等。主机平台和开放平台开发工作量巨大，需要留有足够的ST、UAT测试时间，项目开发时间有限，为了应对可能造成的进度延误，我们采用了以下应对方法：一是制定详细的进度计划，明确每个人的任务，各项目组每周定期检视项目进度，如出现偏差及时纠正;二是与外包公司合作，引入外包人力，为项目临时增派了多名生力军;三是强制加班;四是并行化详细设计和编码同时加强代码评审，在加快进度的同时减少返工。

(5)数据迁移风险。

项目涉及的系统多达上百个，系统集成环境复杂，需要迁移的数据量庞大，而且数据迁移对数据的准确性和完整性有着很高的要求。项目制定了分阶段集成和多次迁移演练的策略：将迁移工作进行提前预演，模拟真实上线迁移场景。经过多次演练以后，问题大大减少，减轻了系统上线的数据迁移风险。

(6)人力资源风险。

项目建设周期长，历时两年，大范围人员流动可能会造成项目延误。针对这一风险，应对的方法是：做两手准备，尽力挽留要走的人员，晓之以理，动之以情，请求公司人力资源部提升员工待遇;同时加紧社会招聘，在重要的岗位上安排备份，防止由于成员生病、离职等意外造成的减员。最终这个风险没有成为问题。

在项目升级项目中，我负责两个子系统的开放部分，由于高层对风险管理的重视，我在执行的时候也特别重视对风险的控制。项目组有四个人，沟通成本比较低，所以我们每隔一周进行一次代码评审，解决遇到的一些技术难题和编码规范问题，在实际开发中使用Checkstyle进行代码规范检视，及早扼杀了可能出现的Bug和不规范的代码;制定组员每周报告进度制度，防范进度偏差;面对前端最可能出现的需求变更——UI变更，我尝试在设计初期使用原型方法和业务进行有效沟通，大大减少了后期UAT阶段UI变更需求。回想刚进公司时我做过的某个项目，由于没有考虑到UI类需求变更风险，前期没有进行UI设计的交流，导致UAT阶段大量返工，使项目延误了一个多月，并且浪费了不少人力资源。设想如果当时识别了这类风险，在早期就把风险发生的概率降低，那么项目可能会顺利得多。

由于前期风险控制得当，一直到迁移演练前我负责的项目都很顺利，但是在迁移演练过程中出现了一些问题，其中一个问题是导库程序不能正常执行，并多次发生。我和同事花了很多时间研究问题，最后找到的原因是某个配置参数的问题，研发人员使用了错误的配置参数，ST、UAT期间导库的数据量比真实演练期间的数据量小太多，所以没有被发现，修改配置后再演练环境导库成功。还有一些问题是没有有效沟通导致的。例如，在演练的时候用户反映某个查询交易很慢，经排查，后台人员说前台调错了交易，前台人员提出异议：为什么ST环境查询很快原来后台人员写了多个查询交易，新交易确实能提升查询速度，但是没有在正式的文档上注明前台应使用新交易替换老交易，也没有通过别的途径告知前台，这样前台调用的还是老交易，导致了查询性能问题。由于ST、UAT环境和生产环境的差异性，上述两类问题很难暴露，试想如果没有进行迁移演练，这个问题恐怕要在生产上出现了。迁移演练提前暴露了ST、UAT所不能测出的系统缺陷，使得研发人员能有充分的时间去排查问题和修复缺陷，有效降低了系统上线风险。

经过这次核心升级项目的洗礼，我深深认识到风险管理在IT项目中的重要性，正因为对风险管理足够重视，提前制定了风险应对计划，我们才得以如庖丁解牛般化解项目中遇到的各种风险，并最终取得了上线的胜利。任何项目都不能回避风险问题，风险的存在导致几乎每个项目都不可能顺风顺水地完成项目目标，良好的风险管理技能将帮助项目经理处理好项目中的不确定因素，保证项目的顺利进行。

;

当IT项目经理应该做哪些事情？

项目经理是具体项目工作的管理者，他们在工作中不断提升自己的领导才华，同时该职业又是一个权利与责任并存的职业， 他们主要对项目进行背景调查，收集整理项目相关资料，进行需求策划，撰写项目调查报告和信息综述，对项目组成部分或模块进行完整系统设计，联系项目相关单位和相关技术专家，制定项目可行性研究报告，协同配合制定和申报立项报告材料，组织项目团队完成项目任务，保证项目的完成时间和完成质量。下面是我为大家整理的IT项目经理应该做什么，欢迎阅读!

IT项目经理应该做什么

经常看到这样的项目经理，一副整天忙得团团转的样子，电话不停地作响，一个小时之内要发出几十个指令，好像他所领导的团队离开了他就一天也活不下去。然后他还会说："我很忙"或"我很累"，"我需要增加人手"。这样的项目经理经常事无巨细都要亲自过问，即使旗下有人，你说他能不累吗

甚至还有这样的事列发生，研发部门经理亲自参与项目软件的编码工作，如果只有一、两个项目，也许这样还可以，试想，如果有十几个项目你能都参与具体的技术工作，另外是否考虑过部门经理参与具体项目后所带来的其他问题，部门日常事物务无处理，部门人员无人关注，部门的其他项目得不到项目经理的协助，更是无人为部门的未来作打算。类似的项目经理的行为很多：譬如善于销售的经理就对自己的销售人员总是不放心，觉得下面的人出马总是不那么牢靠;文笔较好的项目经理总是要亲自起草文件，因为秘书起草的东西总是叫他看不上眼，如此等等。

由此造成的结果是经理整天搞得手忙脚乱，管理效率很低。做经理者没有时间考虑部门发展的问题，做下属者觉得自己得不到信任，做事小心翼翼，不敢越雷池半步，没有积极性。

由此想到刘备，文不如诸葛亮，武不如关张赵马黄，但是他会用人，会笼络人。做项目经理人的恐怕都需要学习一下刘备的做法，即便你是在某些方面非常地出色。你可以把你的经验传授给你的下属，不要怕他们犯错误。"用人不疑，疑人不用"，虽然很难做到而且有时也不一定非要做到，但是你既然给了一个人那个位置，那份薪水，就应该让他们充分地发挥，你不能替他们做事，你不能"抢"你付给他们的权力。记得有次记者采访CA公司总裁汪嘉廉先生时，汪先生说他到目前还没有个人email地址，记者很惊诧的问他为什么时，他说“没有必要，我有很好的业务总监们，他们会处理好公司的日常事务，我要有充足的时间考虑公司的发展战略，我不希望被一些琐事打扰”。汪嘉廉是一位好的管理者，所以CA才有今天的地位。

做得好的项目经理可能看起来每天的工作并不是那么紧张。所以有些下属就可能提出这样的问题："我们忙，你在干什么"

项目经理，对于一个团队履行它的使命和发展负责的人。因此创造出一个大于其各组成部分的总和的真正的整体，创造出一个富有活力的整体，应该是其第一使命。即人们经常谈论的管理，通过管理则可以把在自然界1+1〉2的不可能转变为可能。为履行这一使命，项目经理应该做什么呢

一、一个项目经理首先要制定目标，即确定团队的目标，只有知道往哪走，才能到达那里。确定目标是什么，而且目标要能够有效的支撑团队的责任，有助于团队的发展。而且要将目标传达给团队的每一位人员，让他们认识到他们在实现目标过程中的责任和重要性。

二、一个项目经理要进行组织工作，即如何安排工作，需要分析所需的各项活动、决定和关系，他需要对工作分类，确定作业任务的主次和轻重缓急，并为作业分配适当的执行的人员。

三、一个项目经理要进行激励和信息交流工作。他把担任各项职能的人组合成为一个团队，它需要通过对下属的激励，以及同上、下、同级间的相互信息交流，协调完成工作。

四、一个项目经理需要进行衡量考核,衡量团队的绩效和个人的绩效。首先需要确立衡量的标准，这个标准不但要专注于团队的绩效，而且还要求专注于个人的工作并帮助他做好工作。一个项目经理把衡量的意义和结果通报给他的下级、上级和同级。

五、一个项目经理要培养人，也包括他自己。项目经理比其他人更了解其下属的长处和短处、更清楚下属的培训需求，也常常拥有帮助其下属改进工作绩效所必需的技能，只有下属的技能提高了，整个团队的效率才可能提升，只有团队的成员有发展，他们才会在执行工作时投入热情和责任。 经理需要制定培训计划并部署。

在我们这个行业，好多项目经理是在业务或者说技术方面有过硬的能力后才被赋予经理这一责任的，他们可能没有受过管理学的教育，希望此文能够给与他们思考与认识自己责任。

项目经理该做什么，不该做什么

1以目标导向来做事情

首先要明白该做什么，其次才是如何做。目标是项目管理的重要特征，项目经理做事原则都是围绕项目目标展开，对于有利于项目目标达成而又不违背项目经理职业道德和行为准则的事情都是该做的事情。

目标有短期目标和常用目标，把当前项目按目标完成可能是短期目标，通过一年时间带出一个高效的团队可能是一个长期目标。对于非临时项目的项目经理，更加应 该着眼于项目长期目标，而不是太在意于当前项目的短期利益。只有意识到这点，才能够认识到培训，教练，团队，自发，团队语言和规则等在整个项目中的重要 性。

2对自己定义的目标进行分解

对于软件项目，项目经理根据商业或用户需求会定义软件产品发布后的故障率小于05个/KLOC代码。要达到这个目标就需要结合项目的时间过程分析影响该 目标的要素，各个阶段交付物的质量，缺陷的泄露，测试的水平，需求的变更和稳定性，前期的需求设计和开发规范，团队规则，开发人员的责任心多方面因素都可 能影响到该目标的实现。

一个总体目标的达成绝对不是简单的改善一项影响要素就可以达成的，而且各个要素间还存在这正反作用，必须要综合性的系统思考。确定出期望的各个要素的区间 水平，然后将这些期望值列入到计划中进行跟踪和控制。这一系列的过程要表明的都是你做的每一件事情都是有目的的，都是为了实现当初定义的目标而服务，绝不 是无中生有。

3具体实际 *** 作的关注点

首先对于风险和危机的重视度远大于对问题的重视度。不是说问题解决不重要，而是项目经理应该更多的管理风险和消除隐患，不让风险转换为真正的问题。项目经 理必须有足够的问题前瞻性和敏锐的洞察力，发现各种征兆和危机，危机发生前应对往往仅仅是项目经理找成员谈谈心，或者说组织一次关于规程的培训，但危机如 果发生造成的损失会远远大于风险应对的成本。

项目经理应该更多的取做教练，而不是去做领导。管理者要懂得授权，但项目经理更关注的是授权不会影响到进度和质量，因此项目经理绝对不是越俎代庖啥事情都 自己做，也不是盲目授权后啥都不管，而是充当好教练的角色。让项目成员有能力的全完成事情，而且是有责任心的去完成事情。如果自己做只花1个小时，而教会 团队成员做需要一天，从团队常用的角度必须花费这一天时间教会成员如何正确的做事情。

PMBOK九大知识体系内容都是项目需要考虑做的内容。里面有个关键词是项目管理组，项目管理组是由项目核心成员共同组成的。必须要分清楚哪些是项目经理 做，哪些是项目管理组做。另外一个关注点是做事情的粒度，项目任务的跟踪是项目经理要做的，但项目经理应该根据项目目标确定自己跟踪任务的粒度，粒度太细 的可以由项目成员或小组负责人跟踪。项目经理该做什么不能简单项目经理人与项目成员的实战指南

在一个团队中，作为一名团队领导，将：

1) 避免团队目标向政治问题妥协

2) 向团队目标显示个人承诺

3) 不用太多优先级的事物冲淡团队的工作

4) 公正、公平的对待团队成员

5) 愿意面对和解决与团队成员不良表现有关的问题

6) 对来自员工的新思维和新信息采取开放的态度

作为团队成员，要将：

1) 展示对个人角色和责任的真正理解

2) 展示目标和以事实为基础的判断

3) 和其他团队成员有效地合作

4) 使团队目标优先个人目标

5) 展示投身于任何项目成功所需的努力的愿望

6) 愿意分享信息、感受和产生适当的反馈

7) 当其他成员需要时给予适当的帮助

8) 展示对自己的高标准要求

9) 支持团队决策

10) 以为团队的成功而奋斗的方式体现带头作用

11) 对别人的反馈做出积极的反应的理解为二元问题，更多的是跟项目目标和管理粒度相关的做事情的粒度问题。

IT项目经理的经验总结

本人做项目经理工作多年，感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导，只有最合适的，没有什么叫对的，什么叫错的，项目经理最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。以下是本人一些做项目的个人体会，写出来供大家指点，在讨论过程中共同提高水平。

项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：

1这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统系统。前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。

2这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经理是一定要记住的;

3基本了解了客户的情况后，下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视，这个决定了你在需要资源的时候，公司是否会根据你的要求提供最有力的支持。领导口头肯定是说支持的，你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对你做项目计划产生直接的影响;

4在做整体项目计划前，还要大致计算一下你手上的资源。首先是时间，现在市场竞争激烈，往往很多项目要求在几乎不可能的时间范围里完成。对于这一点，你在做项目的风险控制计划的时候要充分考虑。其次是人员，根据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动。最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间;

5现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得很清楚(主要是讲做什么，而不是说怎么做)，而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做哪些事情，也让客户的业务人员(一般不懂技术)知道项目做成什么样就算完成了。简单地说，项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。

6 是到做总体计划的'时间了吗不，你现在已经知道了客户的目标和你手上的资源，那么做计划以前，你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话，将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，如果项目经理不能尽早发现风险，那么就只能去当烈士了。

7明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项目小组的时候了。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家(Industry expert)，这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧。

8现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则，如果你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。下面的东西看起来无聊，其实还是很管用的：第一个是规定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。这种情况适合小项目，人少;拉的意思就是项目经理就是一个类似web服务器，你自己需要什么信息就去问他。当然，没有项目经理把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。第二个问题就是文档问题，很多人怕写文档，但是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外所有达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。记住：说了的就和没说一样，只有写下来大家签字后才算真正发生了的。还有一些问题，比如你提交的报告，给领导(包括本方领导和客户领导)做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，但是注意要留记录，标明是谁的责任;另外，如果你在开始阶段就和领导商定：如果批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。再比如不同事件的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到，以后的工作就越主动。

9 好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。这一节，任意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会就是了。首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这里要强调一点：完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：你选我做这个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确，比如用微软的Project软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。所有的结果最后用一个叫做甘特图的形式表现出来。你做完这个表以后会惊奇地发现，甘特图上项目的结束时间会远远落后于你的计划结束时间(签合同的人永远不会先征求你的意见的)。当然，学过项目管理的人会大谈什么WBS、优化路径之类的东西，但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否罗列了所有要做的事情和正确评估了他们所需要的时间。这时候，你就要考虑牺牲一些任务的时间(也意味着质量)了。按照什么标准牺牲这个项目的战略!我们在第三节提到过的战略。我的经验是如果你什么都赶进度，其结果可能就是十件事情你一件也没做好，想想多么失败啊。所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件做成了精品，三件完成，还有四件因为某些原因延误，成绩单是否靓丽了很多呢战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。

好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的时候，不像前期的时候项目经理要象记者一样到处和不同的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。当然，小项目的项目经理往往自己也是一个资源，要做很多事情，这时候反而比谁都苦。项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，比如：“王局长，最近项目进度还算正常，就是JVM经常发生一些内存泄漏的情况…”王局长：“(&$@@”。和自己的领导汇报也要注意这个问题，除非他是一个技术高手，你需要他的技术经验，否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了，有些需要他支持的地方，比如资源调用需要说详细一点。

和组员开会，除了一些项目进度跟踪会议以外，还有很多讨论会，需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强(如果总结得不对，欢迎大家拍砖)，所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。一个问题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的。你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的(而不是正确的)方案。所以，在会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论(你要让大家知道事情不是非黑即白的，而是多元的，唉，我们的教育惹的祸…)。会后，你自己写文档，做决定。会议上大家的面子都被照顾了，自然实施起来的阻力就小，如果还有意见的，你就私下找他聊，如果还不能说服他，你就要让他明白，因为你负责这个项目、你担当风险，所以，这个优先级应该你来判断。组织中的高层，并不见得水平会比一般的成员高，但是，他要承担组织的风险，加之信息的不对称性，所以，对事情的优先级的判断肯定比下属强。

在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，界面要求：美观大方、简洁明快，这个要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务开发人员熟悉EJB编程，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。另外我插一句：我是极其不主张到客户现场开发的。尤其是一大群技术人员直接和客户交流，很容易引起冲突和矛盾(技术人员的本性决定的)。我的做法是项目经理和项目实施人员到现场，软件开发人员还是在公司做项目。项目实施人员就是初级项目经理，他们了解自己的产品，懂得一些客户的业务，关键是在于他们具有良好的沟通能力，俗称“皮厚”。他们是客户和研发人员的桥梁，其职业方向也是很机动灵活，以后可以有很多方向可以转，比开发人员的路要宽得多。

接着，我们再谈谈最让人头痛的需求变更问题。变更通常分为两种：一种是部分更改了原先的目标，即需求变更;另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。这时候，如果需要改并且你的战略是容许这种情况的，那么注意下面几点：

1确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后说话没有凭据;

2和客户坐下来，自己探讨他修改的根本目的是什么，是不是有同样能达到相同目的，但是对你来说有代价更小的选择

3(项目初期的工作)明确更改流程，一般是客户指定一人签字(否则客户每个领导都有权力来插一杠子，你就废了)，以正式项目文件的方式提交给你，然后，你做评估分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由此带来的不确定后果(这个东西先写出来，后面如果真的发生了，至少不是你的错)。然后再让客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗对，就学习那个，让大家都意识到任何的更改都有成本和代价。

;

从普遍角度上说，一个有效的项目管理要从几方面入手。

1 项目范围

明确定义好项目管理范围，才能有效配置相应资源。

2 项目计划

根据项目要求，制定切实可行的项目计划。国内大部分项目经理都是根据上级指示做事，没有仔细做过项目评估，这就导致在项目执行过程中，经常出现不可控因素，影响了项目的执行结果。

3 项目资源

包括设备，材料，资金，人力资源等。关键是资金和人力资源，一个是保持适当的现金流，一个是保证有足够的人去做该做的事。

4 风险预估

包括对用户及对自身评估两部分。对用户主要涉及其信用度，财务状况，技术能力/经验等方面；对自身主要包括足够的项目管理人员，技术人员配置是否足够，经验是否丰富，有否做过同类项目，用户的付款条件对项目管理造成的风险是否可控？

以上是针对工程类项目，针对软件开发项目，在项目范围/风险中，还需要特别关注用户对项目的具体及特殊要求。

内容来源于ITSS符合性评估落地工具-云雀运维！！！

书　名　IT项目管理(工业和信息化普通高等教育“十二五”规划教材立项项目)

丛 书 名　21世纪高等院校经济管理类规划教材

标准书号　ISBN 978-7-115-27882-1

作　者　郭宁 编著

责任编辑　李海涛

开　本　16 开

印　张　22

字　数　523 千字

页　数　342 页

装　帧　平装

版　次　第1版第1次

初版时间　2012年6月

定　价　4200 元

内容提要

本书针对IT项目管理的特点，以IT项目为研究对象，对IT项目管理的主要内容进行了较为系统的研究，对项目的9个知识域和过程管理等环节进行了系统全面的介绍。全书共分12章，主要内容包括IT项目管理的概念与内涵、IT项目的管理环境、IT项目全生命周期及其各阶段的主要工作、范围管理、时间管理、成本管理、风险管理、质量管理、人力资源管理、沟通管理、冲突管理、采购管理及项目管理工具Project应用指南等。在各章都配有实际的案例，突出了IT项目管理的特色，有利于扩展读者的思路，提高IT项目管理的能力，这些启发性的案例本身就是对IT项目管理的最好注解。同时，在各章后面还配有习题与实践环节的参考题目，可供读者复习巩固和拓展知识之用。

理论与实践相结合、实用性与可读性相结合是本书的最大特点。本书可作为大学本科生及研究生IT项目管理课程的教材，也可作为项目管理人员的培训教材。有兴趣了解IT项目管理的人士也可利用本书进行自学。

目录

第1章　IT项目管理概述　1

11　项目的概念　1

111　项目的价值　1

112　项目定义　2

113　IT项目的特点　2

12　项目管理概述　4

121　项目管理的含义与价值　4

122　项目管理的特征　5

123　项目管理的发展　6

124　项目管理的知识体系　7

13　软件项目管理　9

131　软件项目管理的特点　9

132　项目管理的本质　10

133　IT项目中的常见问题分析　11

案例研究　12

习题　13

实践环节　14

第2章　组织环境与项目管理过程　15

21　IT项目管理的环境　16

211　项目环境　16

212　项目与组织战略　17

213　项目相关利益者分析　18

214　组织结构　19

22　IT项目生命周期　24

221　IT项目生命周期　24

222　IT项目各阶段内容　25

23　IT项目的管理过程　27

231　项目管理过程　27

232　IT项目的管理过程　30

24　项目经理的责任和权力　33

241　项目经理的地位和作用　33

242　项目经理的职责　34

243　项目经理的权力　34

244　项目经理的能力　35

案例研究　37

习题　39

实践环节　40

第3章　IT项目整体管理　41

31　项目启动和可行性分析　41

311　项目准备和启动过程　42

312　可行性研究　44

32　项目管理计划　47

321　项目计划　47

322　制订项目管理计划　51

33　IT项目目标管理　52

331　IT项目目标体系　52

332　IT项目目标控制　53

34　项目计划执行与变更控制　56

341　指导与管理项目执行　56

342　项目整体变更控制　57

35　项目收尾与验收　58

351　结束项目或阶段　59

352　项目验收　61

353　项目移交与清算　63

案例研究　64

习题　67

实践环节　68

第4章　IT项目范围管理　69

41　项目范围管理概述　69

411　项目范围与范围管理　69

412　IT项目范围管理的重要性　70

42　项目范围规划与范围定义　70

421　项目范围规划的编制　71

422　收集项目需求　71

423 项目范围定义　73

424　软件项目的需求管理　74

43　项目工作分解结构技术　77

431　工作分解结构　77

432　工作分解的过程　78

44　项目范围核实与控制　81

441　项目范围核实　81

442　项目范围控制　81

案例研究　84

习题　84

实践环节　85

第5章　IT项目时间管理　86

51　项目时间管理概述　87

511　项目进度管理的重要性　87

512　项目进度及项目进度管理　87

513　项目进度管理过程　87

514　IT项目时间管理的特点　88

52　活动定义　88

521　活动的定义　88

522　项目活动的特征　89

523　项目活动定义过程　89

53　活动排序　90

531　活动排序的依据　90

532　网络图　90

54　活动资源估计　92

541　IT项目资源分类　93

542　资源估算的主要依据　94

543　资源估算的过程　94

544　编制资源计划的方法与工具　95

55　活动持续时间估计　98

551　历时估计的依据　98

552　历时估计的方法　98

553　软件项目的工作量估算　99

56　编制项目进度计划　100

561　项目进度计划　101

562　进度计划编制的依据　102

563　计划编制技术　103

564　进度计划编制结果　109

57　IT项目进度控制　109

571　IT项目进度控制　110

572　进度控制的工具和方法　112

573　项目进度优化与控制　113

案例研究　117

习题　118

实践环节　119

第6章　IT项目成本管理　120

61　成本管理概述　120

611　项目成本与成本特点　120

612　项目成本管理过程　124

62　项目成本估算　125

621　项目成本估算过程　125

622　软件项目成本估算方法　127

623　项目成本估算的结果　133

63　项目成本预算　135

631　成本预算概述　135

632 项目成本预算的步骤　136

633　成本预算的结果　138

634　项目费用与资源的优化　138

64　成本控制　139

641　项目成本控制的原则和内容　140

642　项目成本控制方法　141

65　项目成本效益分析　148

651　成本效益分析的必要性　148

652　成本效益分析方法　148

案例研究　149

习题　153

实践环节　154

第7章　IT项目质量管理　155

71　项目质量管理概述　155

711　项目质量管理的概念　155

712　质量管理的过程　158

713　软件质量　158

714　IT企业质量管理体系　161

72　IT项目质量计划　163

721　质量计划的依据　163

722　编制质量计划的方法　164

723　质量计划的输出　165

73　IT项目质量保证　167

731　IT项目质量保证的思想　167

732　质量保证体系　168

74　IT项目质量控制　171

741　常见的IT项目质量问题　171

742　实施质量控制　172

743　IT项目质量控制工具与技术　173

744　质量控制成果　176

案例研究　177

习题　179

实践环节　180

第8章　项目人力资源管理　181

81 项目人力资源管理概述　181

811　项目人力资源　181

812　IT项目的人力资源管理　182

813　IT项目人力资源管理的特性　183

82 项目人力资源规划　184

821　IT项目组织的确定　184

822　IT项目工作设计　185

823　项目组织计划的编制　186

83　项目团队建设　189

831　项目团队的特殊性　189

832　项目团队的发展阶段　190

833　团队成员的选择　192

834　项目团队建设　194

835　人员培训与开发　199

836　项目绩效评估　201

84　项目人力资源的激励　203

841　动机理论　203

842　激励理论　205

843　激励因素　207

844　团队激励与组织凝聚实例　208

案例研究　209

习题　210

实践环节　211

第9章　项目沟通管理　212

91　项目沟通管理概述　212

911　项目沟通管理概述　212

912　沟通的作用与影响　214

92　项目沟通规划　216

921　项目信息传递的方式与渠道　217

922　编制项目沟通计划　220

93　信息发布　222

931　项目信息分发　222

932　召开有效的工作会议　222

94　绩效报告　223

941　绩效报告的工具与技术　223

942　绩效报告的结果　224

95　利益相关者管理　224

951　利益相关者管理　224

952　有效沟通的原则　226

953　项目沟通障碍分析　227

954　有效沟通的方法和技巧　228

96　项目冲突管理　230

961　冲突管理的概念　231

962　冲突来源　232

963　冲突处理策略　233

964　冲突管理的技巧　235

案例研究　236

习题　238

实践环节　238

第10章　IT项目风险管理　239

101　项目风险管理概述　239

1011　风险概述　240

1012　项目风险管理概述　243

1013　项目风险管理过程与作用　245

102　风险管理规划　246

1021　风险管理规划的内容与依据　247

1022　风险管理规划的程序　248

1023　风险管理规划的成果　248

103　IT项目风险识别　251

1031　风险识别过程　251

1032　风险识别方法　252

1033　风险识别的结果　256

104　项目风险定性与定量分析　257

1041　风险评估基础　257

1042　定性风险分析　259

1043　定量风险分析　261

1044　项目风险评估　263

105　项目风险应对规划　264

1051　项目风险应对原则　265

1052　项目风险的应对措施　265

1053　制定风险应对措施的依据　268

1054　风险应对规划的结果　268

106　项目风险监控　269

1061　项目风险监控概述　269

1062　风险监控程序　270

1063　风险监控的方法　271

1064　风险监控的成果　272

案例研究　273

习题　275

实践环节　276

第11章　项目采购管理　277

111　项目采购管理概述　277

1111　项目采购　277

1112　项目采购管理　280

112　采购规划　280

1121　编制采购规划的依据　281

1122　编制采购规划的方法和技术　281

1123　采购规划的输出　282

113　项目的招投标　283

1131　招投标的基本程序　283

1132　编写项目标书　285

1133　投标决策　287

1134　编写投标书　288

1135　产品选择与商务谈判　289

114　项目合同管理　290

1141　签订合同时应注重的问题　290

1142　软件项目合同条款分析　291

1143　合同管理　297

1144　合同收尾　298

案例研究　299

习题　302

实践环节　303

第12章　Microsoft Project 2007应用指南　304

121　Microsoft Project 2007概述　304

1211　导言　304

1212　Microsoft Office Project 2007简介　305

1213　启动Project 2007　305

1214　Project视图　307

122　创建项目计划　311

1221　创建新的项目计划　311

1222　设置非工作日　312

1223　输入项目属性　313

123　创建任务列表　314

1231　输入任务　314

1232　估计工期　315

1233　输入里程碑　317

1234　分阶段组织任务　317

1235　链接任务　318

1236　记录任务　320

1237　检查任务工期　321

124　设置与分配资源　322

1241　设置人员与设备资源　323

1242　设置材料资源　324

1243　设置成本资源及资源费率　325

1244　为单个资源调整工作时间　326

1245　为任务分配工时资源　328

1246　为任务分配额外资源　330

1247　为任务分配成本资源　333

125　跟踪任务进度　334

1251　保存项目的基准　334

1252　根据日程跟踪项目　336

1253　输入任务完成比例　336

1254　输入任务的实际值　338

习题　340

实践环节　341

参考文献　342 作者：孙雨生著

出版社：清华大学出版社

开本：185260

版次：2011年12月第1版

印次：2011年12月第一次印刷

定价4200元

《基于Project的IT项目管理》系统全面，《基于Project的IT项目管理》通过丰富的IT项目管理实例和完整的项目分析与设计过程，由浅入深、图文并茂地介绍了Project2010的 *** 作方法与使用技巧，涵盖了Project2010基础知识、IT项目计划制定、IT项目实施控制、IT项目信息沟通与协作等内容，构筑了一个面向实际应用的知识体系。全程图解本书采用全程图解的方式进行 *** 作演示，语言通俗，步骤详细。书中的图像做了大量的裁切、拼合和加工，信息丰富，效果精美，轻松易学。案例一致本书始终以同一个软件开发项目为例，进行基于Project2010的IT项目管理介绍，便于读者构建完整的lT项目管理知识体系。资源丰富本书免费提供多媒体课件及书中实例的完整素材文件，便于读者自学和进行实践练习。

《基于project的it项目管理》既是一本project最新版本的教材，又是一本project实际应用的参考书。《基于project的it项目管理》共分为4篇12章，主要讲解了it项目管理的具体内容及基于microsoft project 2010的it项目管理 *** 作技能，内容包括it项目管理与project 2010的基础知识，基于project 2010的it项目进度计划、资源计划、成本计划的制作、优化及发布，基于project 2010的it项目资源、进度、成本跟踪与控制，以及基于project 2010的it项目信息提取、沟通与协作管理。《基于project的it项目管理》体系完整、内容翔实、结构清晰、循序渐进，既可作为高等院校管理科学与工程、信息管理与信息系统、计算机科学与技术、电子商务、电子政务、软件工程等专业高年级本科生和研究生教材以及项目管理工程硕士、mba相关课程的教材，又可供it项目管理人员和it咨询服务人员参考使用，还可作为各种电脑培训机构的培训教材。 作　者： （美）斯奇沃泊（Schwalbe，K）　著；邢春晓　等译

出 版 社： 机械工业出版社

出版时间： 2008-8-1

字　数：

版　次： 1

页　数： 365

印刷时间： 2008/08/01

开　本： 16开

印　次： 1

纸　张： 胶版纸

I S B N ： 9787111240235

包　装： 平装

编辑推荐

自2002年第1版在中国引进出版以来，这本教材为项目管理知识体系在中国的普及和发展作出了卓有成效的贡献，产生了很大的影响。本书不但很好地阐述了项目管理的知识体系，而且结合IT项目特别是软件工程项目的特点，讲述了IT项目管理的方法和过程。全书通过许多现实中的成功和失败的项目实例，讲述了项目管理的基本内容，包括项目集成、范围、时间安排、成本、质量、人力资源、沟通、风险以及采购。

随书光盘包括：

●MicrosoftProjectProfessional2003软件的120天试用版。

●FissureProjectSimulation软件，利用该软件学生可以在模拟的业务环境中亲身体验如何进行项目管理。

有关本书的附加资源（例如，各章课堂笔记的幻灯片、FissureProjectSimulation软件的详细说明、模板文件等）请访问华章网站。

内容简介

本书是关于IT项目管理方面的教材，全面阐释了与IT项目相关的概念、技巧、工具和技术。书中介绍了运用项目管理的9大知识领域（项目综合、范围、时间、成本、质量、人力资源、沟通、风险和采购管理）以及启动、计划、实话、控制和收尾等过程组。增加了运行案例、模板以及一些项目管理模拟软件，帮助读者掌握并运用在本书中学到的知识和技能。

本书适合作为高等院校计算机相关专业高年级本科生或研究生的教材，也可供相关技术人员参考。

作者简介

Kathy Schwalbe美国明尼达大学博士，现为奥古斯堡学院企业计、信息系统项目和电子商务等课程。在1991年进入学术界以前，她做过系统分析师、项目经理、高级工程师以及信息技术咨询顾问等。她还是美国项目管理协会（PMI）的活跃成员。

目录

出版者的话

译者序

前言

第1章 项目管理概述

11 简介

12 什么是项目

121 IT项目的例子

122 项目属性

123 三项约束

13 什么是项目管理

131 项目干系人

132 项目管理知识领域

133 项目管理工具和技术

134 项目成功要素

14 项目经理的作用

141 项目经理的工作描述

142 项目经理应具备的技能

143 IT项目经理的重要技能

144 领导才能的重要性

145 IT项目经理职业

15 项目管理专业

151 项目管理的历史

152 项目管理学会

153 项目管理认证

154 项目管理的职业道德规范

155 项目管理软件

第2章 项目管理和IT背景

21 项目管理的系统观点

211 什么是系统方法

212 系统管理的三球模型

22 了解组织

221 组织的四个框架

222 组织结构

223 组织文化

23 干系人管理

231 高层管理承诺的重要性

232 组织对信息技术承诺的需要

233 组织标准的需要

24 项目阶段和项目生命周期

241 产品生命周期

242 项目阶段和管理评审的重要性

25 IT项目的环境

251 IT项目的本质

252 IT项目团队成员的特征

253 多样的技术

第3章 项目管理过程组：案例研究

31 项目管理过程组

32 把过程组映射到知识领域

33 开发IT项目管理方法

34 案例研究：JWD咨询公司的

项目管理内网项目

341 项目启动

342 项目计划

343 项目执行

344 项目监控

345 项目收尾

第4章 项目综合管理

41 什么是项目综合管理

42 战略规划与项目选择

421 识别潜在项目

422 IT与业务战略相结合

423 选择项目的方法

424 项目章程

43 初步的范围说明书

44 项目管理计划

441 项目管理计划的内容

442 项目管理计划编制的指导原则

443 干系人的分析和高层管理的支持

45 项目执行

451 协调计划和执行

452 提供强大的领导力和支持性文化

453 为产品、业务和应用领域的知识投资

454 项目执行工具和技术

46 监控项目工作

47 综合变更控制

471 IT项目中的变更控制

472 变更控制系统

48 项目收尾

49 使用软件辅助项目综合管理

第5章 项目范围管理

第6章 项目时间管理

第7章 项目成本管理

第8章 项目质量管理

第9章 项目人力资源管理

第10章 项目沟通管理

第11章 项目风险管理

第12章 项目采购管理

附录A 微软Project 2003使用指南

附录B 对PMP考试及相关认证的建议

附录C 运行案例339

附录D 模板344

附录E Fissure公司项目管理模拟

术语表

最新的第五版《IT项目管理》做了较大的修改，由杨坤翻译，2009年1月第一版已经出版，还是机械工业出版社出版的。

主要修改是全书的结构主要按照项目管理的九大手法来编排，内容作了精简，使得学习和阅读更为简单；同时还加入了对PMP考试的指导。 书 名: IT项目管理

作　者：凯西施瓦尔贝(KathySchwalbe)

出版社：机械工业出版社

出版时间： 2010年10月1日

ISBN: 9787111318132

开本： 16开

定价: 6900元

内容简介

《IT项目管理(英文原书第6版)》是运用九大项目管理知识领域(包括项目集成管理以及范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理和采购管理)以及全部五个过程组(包括启动、计划、实施、监控和收尾)的唯一一本教科书，为管理项目提供了坚实的框架和内容。《IT项目管理(英文原书第6版)》适合高等院校管理相关专业的本科生、研究生使用，也可作为it从业人员、高新技术企业管理者的参考书。

作者简介

作者：（美国）凯西施瓦尔贝（Kathy Schwalbe） 译者：杨坤

凯西·施瓦尔贝（Kathy Schwalbe），凯西·施瓦尔贝教授任教于明尼苏达奥格斯堡学院商务管理系，主讲项目管理、商业问题处理、系统分析与设计、信息系统项目和电子商务等课程。作为明尼苏达大学的兼职教师，她为工程系的研究生讲授项目管理课程。同时，她还为一些组织提供培训和咨询服务，并在一些会议上发表演讲。在1991年进入学术界之前，她在工业界工作过10年。她曾是一名空军军官、系统分析师、项目经理、高级工程师和IT顾问。凯西女士还是PMI（美国项目管理协会）的活跃分子，负责PMI明尼苏达分会学生会的联络工作，担任明尼苏达分会分管教育的副主席，以及《ISSIG评论》联络和编辑部主管，她还是PMI考题编写组成员。

凯西女士毕业于圣母玛丽亚大学，获得数学学士学位；在美国东北大学的高科技MBA项目完成了MBA的学习，最终在明尼苏达大学的高等教育学院获得博士学位。

图书目录

前言

致谢

作者简介

术语表

第1章 项目管理概述 1

第2章 项目管理与信息技术环境 29

第3章 项目管理过程组：案例研究 63

第4章 项目集成管理 115

第5章 项目范围管理 161

第6章 项目时间管理 195

第7章 项目成本管理 237

第8章 项目质量管理 275

第9章 项目人力资源管理 321

第10章 项目沟通管理 365

第11章 项目风险管理 405

第12章 项目采购管理 445 基本信息

书号：7-113-07991

作者：谭武梁等

定价：2400元

版次：1版1次

开本：16开

出版日期：200708

配套教材：IT项目管理习题与指导

出版单位：中国铁道出版社

内容简介

本书循序渐进地介绍了IT项目从启动到收尾管理过程中的各个环节，并通过校园网项目的实例，让大家了解IT项目管理的规范，掌握IT项目管理的原理、方法和技巧。全书共分为13章，主要包括：IT项目管理概述、项目启动与立项、项目计划、项目进度管理、资源管理、成本管理、质量管理、风险管理、采购管理、沟通管理、范围管理、整合管理、项目收尾。本书层次分明，实例丰富，图文并茂，理论联系实际，可作为高校计算机类的教材，也可供从事IT项目管理的人员参考和使用。

图书目录

第1章 概述

第2章 项目启动与立项

第3章 项目计划

第4章 进度管理

第5章 资源管理

第6章 成本管理 第7章 质量管理

第8章 项目风险管理

第9章 项目采购管理

第10章 项目沟通管理

第11章 项目范围管理

第12章 项目整合管理

第13章 项目收尾

附录A

附录B

参考文献

建立管理机构，明确外包范围，严格审查制度，加强风险监控和激励机制建设，这些措施是商业银行IT外包风险防范的重要保障。 对外包风险的把握，直接决定着 信息技术外包的成功与否。从根本上来说，对信息技术外包风险的防范过程就是对外包活动实施全面有效的管理过程。

建立外包事务管理机构 要对外包实施全面有效的管理，必须首先建立外包事务管理机构。目前，商业银行外包过程中，仅在外包决策、外包商选择、或发生了法律纠纷时，才成立临时性机构，处理相应外包事务。管理组织的不稳定造成管理人员的频繁调动和流失，削弱对外包项目的充分理解，影响了合作双方感情的建立。人员的不稳定必将造成管理策略的不连续，削弱双方合作和信任基础，给外包项目的管理和监督带来不必要的麻烦，影响外包的服务质量和进度。

外包事务管理机构应该由银行战略规划专家、外包咨询专家、各部门熟悉本行业务信息流关系的代表、信息技术专业人员、费用预算人员、法律顾问、实施管理和协调人员组成。主要负责外包前对国内、外行业、竞争对手以及自身的信息化需求进行调查研究；识别信息技术的核心竞争能力；在收益、成本和风险之间进行平衡并进行外包决策；制定外包的建设技术标准；设计外包方案，避免重复投资与信息孤岛；评价外包商的技术等级、发展能力，选择承包商；签署外包合同；对外包服务过程进行全面监督、协调和控制；处理与现有外包商的外包关系；监督并审议通过外包商的技术决策；积累外包经验并帮助制定未来的外包决策；谈判并推行未来的外包合同；使IT整体战略与不断变化的银行的整体战略保持一致。

明确IT外包范围 哪些是构成核心竞争力的信息技术，哪些是可以外包的非核心技术，外包范围的确定是商业银行信息技术外包中面临的首要问题。 JP摩根公司通过对美国商业银行的电子化发展研究，提出M1-M2-M3层信息技术构架理论（如图1所示），M1是指计算机系统的硬件、系统软件、工具软件、网络设施和其他银行使用的专用机具；M2层主要由应用软件和人机接口组成；M3层的内容主要包括业务流程重组、策略规划、应用系统集成和现有应用系统的管理和维护。M1层的技术属于技术提供商而非银行，对于商业银行来说，M1层的竞争主要表现在合并分散的数据处理中心以追求更好的规模效益；在M2层的信息化建设上，美国商业银行走了一段曲折的道路，开始采取完全自主开发的方式，在支付巨额开发成本的同时，还要承担开发失败的风险，开发完成后发现各家银行基本雷同，是一种低水平的重复建。因此进入上世纪80年代，美国商业银行不仅共同投资建设网络，实现资源共享，而且逐渐与IT公司合作开发软件或直接使用商品化的软件。经过研究发现，美国商业银行在M1和M2层的开发投入，实际收获的只是M1和M2层的技术培训，在M1和M2层领先所产生的效益不如M3层快。 借鉴美国商业银行的电子化发展经验和摩根公司M框架理论，我国商业银行在进行信息技术外包的过程中，应将M1、M2层外包，利用外包商的规模效益，降低成本，集中力量建设M3层，才能培养核心竞争力，实现特色化经营。 建立对外包商资格审查制度 外包成功的关键因素之一是选择具有良好社会形象和信誉、相关金融行业系统实施经验丰富、能够引领或紧跟信息技术发展的外包商作为战略合作伙伴。因此，对外包商的资格审查应从技术能力、经营管理能力、发展能力这三个方面着手。 技术能力：外包商提供的信息技术产品是否具备创新性、开放性、安全性、兼容性，是否拥有较高的市场占有率，能否实现信息数据的共享；外包商是否具有信息技术方面的资格认证，如信息产业部颁发的系统集成商证书、认定的软件厂商证书等；外包商是否了解金融行业特点，能够拿出真正适合商业银行业务的解决方案；信息系统的设计方案中是否应用了稳定、成熟的信息技术，是否符合银行发展的要求，是否充分体现了银行以客户为中心的服务理念；是否具备对大型设备的运行、维护、管理经验，和多系统整合能力；是否拥有对高新技术深入理解的技术专家和项目管理人员。 经营管理能力：了解外包商的领导层结构、员工素质、客户数量、社会评价；项目管理水平，如软件工程工具、质量保证体系、成本控制、配置管理方法、管理和技术人员的老化率或流动率；是否具备能够证明其良好运营管理能力的成功案例；员工间是否具备团队合作精神，外包商客户的满意程度。 发展能力：分析外包服务商已审计的财务报告、年度报告和其他各项财务指标，了解其盈利能力；考察外包企业从事外包业务的时间、市场份额以及波动因素；考察银行的外包合同对外包服务商财务状况的重要性如何；评估外包服务商的技术费用支出以及在信息技术领域内的产品创新，确定他们在技术方面的投资水平是否能够支持银行的外包项目。 对外包实施进行风险监控 信息技术外包的目的在于通过整合信息技术合作伙伴的企业资源，快速实现服务手段和服务方式的信息化，满足客户的需要。信息技术外包中产生的任何风险都会严重影响银行的形象。因此，在信息外包的全过程中要实施风险管理。 风险管理应分为四个步骤：第一步是识别外包实施中各阶段的宏观、微观层面风险，设置监控点。宏观上密切关注信息技术、外包市场的发展，以及银行自身经营环境、竞争对手外包策略、外包商经营状况的变化，防范技术、市场风险。微观层面上，听取外包商在项目实施不同阶段的报告，评估外包商运行的信息系统和相应的控制措施（如资源安全性、完整性、保密性），定期审查外包商相关的内部控制、系统开发和维护、以及应急计划措施，以保证它们符合合同要求，并且与当前的市场和技术环境相一致；了解外包服务是否及时，服务质量、服务水平是否得到提高，防范交易和信誉风险。第二步是分析造成工作偏离预定标准的问题的实质，对产生问题的原因进行调查并做出结论；第三步是拟订解决问题的可行方案，并从中选择出最好的；实施选定的方案，使外包工作回到原定的、期望的标准上。 建立对外包商激励机制 外包商的经营目标是实现利润最大化，而银行希望以公平价格获得良好的服务，因此，商业银行应制订激励机制，将其经营绩效与外包服务要求挂钩，使合作双方目标一致。可采取以下激励措施： 优质优价：根据信息技术外包的范围，按照系统正常运转的时间、效率，制定合格、满意、优质三层标准，达到不同标准给予不同价格。标准的制定应该随着技术的发展而不断提高，如果外包商在技术方面的创新能够使银行实现某些业务盈利，应给予外包商一定的奖励。这样可以鼓励外包商使用新技术、持续改进服务。

级别管理：根据对外包商的资格审查、合作时间长短、合作过程中满意程度，制订相应的评级制度，将外包商划分为准入级、合作级、伙伴级。级别评定是能上能下的，如果外包商的服务水平下降、服务质量降低，就会被降级。级别管理是希望通过一系列连续的合同来加强银行与外包商的合作关系，提醒外包商通过优质服务建立良好声誉、获得收益的重要性。

IT项目管理中开发项目时都分四大类的角色：管理、前端UI、后台开发、测试这几类角色。

管理

部门经理

协调部门内和企业内的资源分配，协调各部门的沟通，并承上启下地为部门的整体业绩负责

项目经理

协调项目内的资源分配，如日常沟通，进度管理等，为项目负责

产品经理

调研客户需求，进行需求分析，形成MRD文档，对产品规划，根据市场需求和分享规划产品发展路线，设计产品商业和服务模式，并定义相关功能模块

技术经理

协调项目内的技术活动，推动主要技术决策，技术的可行性研究，评价、确认并文档化软件架构等

前端UI

UI设计师

旨在设计项目开发中的具体界面，与人进行交互的UI界面

绘画制作

根据需要来绘制设计各种不同的静态资源

后台开发

项目组长

协调小组成员分工，指导、分配、落实小组成员工作，发挥团队职能优势，不断提高小组成员工作效率，优化工作流程，推进项目研发进度

系统架构师

主要负责大系统项目的架构设计

软件工程师  

编写代码，同时编写项目文档，如需求，详细设计，架构设计，用户手册，开发计划等；

程序员

编写代码，实现功能；

测试

软件测试工程师 

主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象

扩展资料

软件质量保证

创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。

IT项目管理

IT项目管理是项目管理在IT领域的应用，结合IT行业特点运用项目管理技术、理念和方法，包括9大知识领域（项目综合、范围、时间、成本、质量、人力资源、沟通、风险和采购管理）以及启动、计划、实施、控制和收尾等过程组成。

特点

1、任务的明确性

2、管理工具的先进性

3、信息沟通的及时性

4、资源提供的必要性

5、测试完善的严谨性

6、度量的准确性

7、项目管理的贯穿性

参考资料：百度百科—IT项目管理

IT项目管理：问题、体系、方法

摘要：无论是在国内还是国外，项目管理的学科、技术和应用的普及与发展已经进入了一个飞速发展的时代，信息技术（Information Technology，简称IT）的发展又将IT项目管理推向了全新的应用高度。本文分析了IT项目管理技术及其应用与发展的关键问题，提出了基于系统集成理念构建的IT项目管理的体系结构和技术框架，肯定了IT项目管理的总体指导思想和实施策略是“需求牵引、效益驱动、总体规划、分步实施”。

关键词：信息技术 项目管理 体系结构

引言

人类进入21世纪，信息化成为我国全面构建和谐社会、快速发展国民经济的着眼点。党的十五届五中全会就明确指出：“大力推进国民经济和社会信息化，是覆盖现代化建设全局的战略举措。以信息化带动工业化，发挥后发优势，实现社会生产力的跨越式发展。”党的十六大再次明确：“信息化是我国加快实现工业化和现代化的必然选择。坚持以信息化带动工业化，以工业化促进信息化，走出一条科技含量高、经济效益好、资源消耗低、环境污染少、人力资源优势得到充分发挥的新型工业化路子。”目前全国上下各行各业、各个领域、各个层面的信息化建设正在如火如荼地进行着。

信息化项目的开展是以信息技术为支撑，以业务活动为主体，以现代化管理为指导思想的一项全新的、复杂的系统化工程。全新在于信息技术这一新生事物的飞速变化与发展，复杂在于信息技术、业务工作、项目管理思想的一体化融合与集成化应用，这正是IT项目管理问世的缘由。信息化建设的成功经验告诉我们，结合信息化应用特点，采用项目管理技术而开发的专用方法对IT项目在计划落实、质量跟踪、成本管理和风险控制等方面进行管理，是保证IT项目达到预期目标的有效手段。

本文在项目管理知识体系的基础上，介绍了IT项目管理的特殊性，回顾了学术界和工业界在不同方向上为解决这些问题所做的努力、获得的成果。在系统集成理念的指导下，探讨IT项目管理的体系结构和模型驱动的集成技术与方法。

1 IT项目管理的特殊性

信息技术发展快、渗透广等特点，使得IT项目与一般工程项目存在着明显的差别，这种差异性造成了基于工程项目管理理论与经验基础上发展起来的项目管理知识体系在处理IT项目时面临诸多的难题。

第一，IT项目的需求来源广泛，涉及国民经济的各个领域，几乎所有领域都能够和信息技术相结合而构成信息化项目。信息技术可以支持多种业务需求的发展：

（1）市场要求，如商业银行提供网上支付业务，以支持越来越频繁的电子商务活动。

（2）环境需求，如企业为了应对各国越来越严格的环境标准中对产品回收再利用的要求，启动一个构建产品全生命周期管理系统的项目。

（3）经营需要，如一个传统的大型商业企业开展网上销售业务，以扩大其销售收入。

（4）技术发展，如飞机制造企业为了提高设计水平而开展虚拟制造系统的项目。

（5）用户要求，如快递公司要构建一个物流管理系统，以满足顾客对跟踪其委托的快递物件过程状态的查询需求。

（6）法律需求，如一个城市为了减少合同犯罪的数量，而启动企业印鉴信息系统；为了杜绝文凭的泛滥而建立文凭查询信息系统。

正是由于信息化项目涉及到了几乎所有的经济领域，因此很难形成有针对性的规范和标准，这无疑增加了项目管理的难度。

第二，与一般工程项目所涉及的领域经过了长时期的发展、技术相对成熟不同，IT领域是目前发展最快、最活跃的领域，新的技术层出不穷，技术更新也非常迅速，因此IT项目开展过程中会具有更多的风险因素。有统计表明，每18个月，CPU的速度就会翻一番，与之关联的计算机体系结构、软件架构等也发展非常迅速。例如早期的集成信息系统采用大型主机带终端的结构，随着网络技术和分布式计算技术的发展，出现了Client/Server结构的信息系统，而目前流行的架构则是在互联网上基于Browser/Server结构的信息系统，C、C++、Java等各种开发工具更是一代代迅速更迭，各类 *** 作系统、协议、标准等都是IT项目必须面对的，这些都会增加项目过程中的风险。

为了处理好技术发展迅速所带来的问题，IT项目团队必须在先进性、实用性、经济性、成熟性等诸多方面进行权衡，片面追求技术的先进性往往会事与愿违。在保证项目所采取的技术具有相当的前瞻性、先进性和可扩展性、可集成性的同时，从需求出发，注意技术的可靠性、成熟性和经济性。

第三，信息技术的应用主体在管理领域，管理信息系统包含了特定的管理理念，将这些管理理念同企业的发展战略与业务逻辑进行整合是信息系统实施的关键任务。IT项目的阻力75%以上是来自人和管理的因素，因此，IT项目特别强调技术、管理与人的集成。如何处理好信息系统所涉及的人的问题是成功管理IT项目的关键。

从更深层的角度而言，经典项目管理理论是构建在土建工程项目的研究和实践基础上的，基本的项目管理方法并不能解决IT项目的特殊问题，例如：

（1）如何衡量项目进度的问题，土建工程使用完成土石方的量来标识工程进度，但是完成软件90%的代码编写工作并不意味着还有10%的时间就可以完成软件开发项目了。业界普遍认为在工程项目中广泛使用的挣值法在IT项目中缺乏适应性。

（2）在计划的调整方法上，土建工程在计划拖期时，可以通过增加资源的方式来加快进度，但是对于一个软件开发项目，如果出现同样的问题，寄希望于增加编程人员的数量来追赶工期，只能造成更大的麻烦。

另外，除了信息技术之外，IT项目还涉及信息系统应用单位的组织、管理的调整与经营过程/业务流程的重构，单靠信息技术是无能为力的。因此，要成功管理IT项目，要成为IT项目的合格从业人员，需要一套全面的IT项目的知识体系与方法的支撑，它的内容将覆盖项目管理、信息技术、现代管理技术、系统集成技术、软件工程技术等多学科领域，这正是IT项目管理技术研究和实践的目标与方向。

2 IT项目管理技术的发展脉络

目前在信息化领域的不同方向，许多学者开发了针对不同方面的项目管理方法，其中比较有代表性的是软件项目管理和广义的IT项目管理。

软件项目管理是软件工程和项目管理的有效结合，将项目管理中重视过程、重视计划控制的观点引入软件工程领域，目的是控制软件开发项目的成本、进度、质量、风险等问题。近几年IT领域进一步引进全面质量管理理念，认为软件开发企业自身质量控制体系和控制能力的优劣，将会极大地影响软件产品的质量，这就要求软件企业从修炼内功入手，也就是确认质量是控制出来的而不是检测出来的，从根本上保证软件产品的质量，由此提出了软件过程改进和软件能力成熟度模型(CMM)的概念。CMM基于经典的产品质量原理，建立了定量控制软件过程的项目管理和项目工程的基本原则，与此同时，CMM有关能力成熟度的 *** 作方法也被引入经典项目管理领域，用以测评承担项目的组织的项目管理能力。

广义IT项目管理是目前业界讨论比较多的，也出了不少这方面的专著，其基本思路是将IT项目当做一般工程项目，使用PMBOK的方法体系，结合一些信息技术项目的案例，研究如何在信息技术项目中应用项目管理方法。

广义IT项目管理是将所有与IT有关的项目不加区分地通盘考虑，包括IT产品开发项目的管理和IT应用项目的管理。实际上广义IT项目可以细分出多个类别，各个类别之间的差距是非常巨大的。计算机硬件开发项目与一般家用电器产品的开发设计具有非常高的相似度，而软件设计开发则完全不同，信息技术应用项目与上述两个分支领域更是存在巨大的差异，因此广义的IT项目管理实际上是在经典项目管理知识体系的基础上，尝试解决IT项目的具体问题。目前来看这种处理方式比软件项目管理体系的针对性差很多，对其进行细分研究具有非常重要的意义。为了提高IT项目管理的针对性，提高解决方案的系统性，学术界和企业界在企业信息化、数字化城市与电子政务、数字化军工、供应链与物流、电子商务等不同领域分别开展了体系结构、实施指南、参考模型等的研究和实践，取得了一定的成果。

3 IT项目管理的体系结构与方法论

系统参考体系结构是“一组用以描述所研究系统的不同方面和不同开发阶段的、结构化的、多层次多视图的模型和方法的集合，体现了对系统的整体描述和认识，为对系统的理解、设计、开发和构建提供工具和方法论的指导”。

系统参考体系结构为IT项目的管理提供了体系参考和方法论，经过各国专家的努力，已经形成了一批相当有代表性和广泛影响力的体系结构及其建模方法，并进行了大量的工业实践，如CIM开放系统体系结构(CIM-OSA)、GRAI集成方法论(GIM)、IMPACS、普度参考体系结构(PERA)、集成的信息系统体系结构(ARIS)、通用企业参考体系结构与方法论(GERAM)，以及在我国提出的阶梯形CIM系统参考体系结构(SLA)等。

在信息化项目管理过程中，系统的认识和构建是阶梯上升的，在概念定义阶段需要明确企业的战略目标，并据此形成集成系统的目标，然后围绕系统目标，从组织、资源、信息、产品、功能和经营过程等角度描述企业的现状，形成对企业基本框架和运行机制的完整描述。在这些描述的约束下，采用合适的模型分析手段进行分析，找出现有系统中的问题进行改进，然后构建目标系统，形成多视图的目标系统的描述。在形成目标系统描述时，除了使用各个视图的描述方法外，还可以应用其他建模方法，以便提供对系统更为完整的描述。完成基于模型的设计后，就是在构建工具集的帮助下，将设计转化为实际系统构建的技术说明，并构建实际系统。系统描述对于系统的运行仍然能够发挥作用，可以作为实际系统运行的参考，并据此进行系统的优化与调整。

一方面由于信息化项目的多专业性，为了解决沟通和分析设计的问题，需要借助建模的手段实现对被处理对象系统的描述；另一方面由于信息化处理对象的复杂性，依据“化繁为简、分而治之”的原则，使用多层次多视图的模型来描述目标系统。视图的划分包括反映结构信息的信息视图、资源视图、组织视图、产品视图，反映系统时间和逻辑特征的过程视图，结合反映系统功能结构和功能关系的功能视图，以及反映企业经济性和目的性的经济视图。静态结构反映了系统的存在，行为结构给出了系统的属性和运行方式，而评价结构则将系统和它的目的性关联在一起。透过多视图，为IDEF、ARIS等其他建模方法和工具的集成，对于制造企业原模型和企业本体的开发提供了技术框架。利用模型技术解决IT项目的交流、设计、技术转移、系统构建乃至运行维护的问题是目前学术界和业界的普遍看法，模型驱动的体系结构是目前的一个研究和实践的热点。

4 结论

随着信息技术的发展和应用范围的不断扩大，IT项目管理越来越具有普遍性。分析IT项目的内在特征和特有问题，在项目管理知识体系的架构下，有针对性地开发适应性的理念和方法，将是IT项目管理领域的发展方向。

需要强调的是，信息技术本身的发展并不是IT项目的目的，满足应用对象的需求和战略目标才是其出发点，因此需要切实做好项目的需求分析，一切从业务工作的实际需求出发，在集成理念的指导下，充分考虑整个系统的集成要求，并在此基础上选择相关的成熟技术、应用系统和产品，同时做好项目的技术经济分析，才能保证信息化项目发挥实效。国家863计划CIMS主题专家组在大量信息化工程实践的基础上提出的“需求牵引、效益驱动、总体规划、分步实施”的策略是IT信息化项目管理的总体指导思想。

质量管理的实质通俗地讲就是“把要做的写下来”，“把写的做出来”，“把做的过程记下来”，大家可能注意到一点：其中主要说的就是两个字“做”和“写”，与我们一般做事方法不同之处在于多了个“写”的动作，因此用“文档”管理“过程”成为质量管理的一个重要特点。我们举一个简单例子说明如何通过各种文档控制一个过程，一般这需要三种文档：

1)记录：记录活动的过程和结果，最常见的记录就是表格。 一个过程可能涉及A、B、C和D四个活动，并由不同的人员执行。每个人完成各自活动后就记录处理过程和结果，并签字确认。因此这个表格留下了所有人相关人员处理的“痕迹”，一旦出了问题就可以回溯，确定是哪一步出了什么问题。

2)规程：光有一个表格还不行，还需要一个文件规定活动的执行顺序和要求，这样的文件就是规程 。规程表示按A-B-C-D顺序执行，复杂的规程还可能包括条件分支，每一步骤的具体 *** 作和要求也应该在规程中描述。

3)状态：有了记录和规程还会发生问题 。比如，记录丢失了而不知道谁负责(甚至根本不知道丢失了)。这是因为不知道记录的状态当前在谁手里，处理的结果如何。因此还需要状态文档。

这确实多了一些“额外”的工作，不光需要员工额外的“文字”工作，还可能增加专职的管理人员，所以质量管理需要一定的“代价”。IT企业中，几乎所有开发人员都知道“质量”的重要性，但却不能正确看待质量的“代价”。一旦需要他们填写表格或者严格遵照流程工作时，多数都会说“太麻烦了”“效率太低了”。的确，如果没有文档工作一定程度上可以提高效率、节约成本，但长期看因管理混乱和质量低劣带来的损失可能远远大于短期的利益。还有一种常见的错误看法是“质量就是凑齐文档”，表现为在进度压力下违规 *** 作，待完成项目后匆匆补文档。坦率地说，如果补的是中间文档(例如部分详细设计)还情有可原，如果补“过程记录”则实在不甘恭维。例如，笔者就见过在项目完成后补《测试错误记录》的情况，其实这时补这些文档对测试过程的管理已经根本没有意义，花时间精力仅仅是让项目看起来规范一些，可以算是一种“粉饰太平”的行为。个人认为，如果你真的认为一个过程不需要文档也可以控制，则可以进行适当的裁剪。其实项目并非越规范越好，应该根据具体的质量要求平衡质量和进度、成本三者的关系。

质量管理活动基本包括质量保证和质量控制两类。质量保证是在项目过程中实施的有计划、有系统的'活动，确保项目满足相关的标准，典型的例子是评审和审计。质量控制指采取适当的方法监控项目结果，确保结果符合质量标准，还包括跟踪缺陷的排除情况，典型的例子就是测试。对于软件开发来说，重要的质量活动包括：

1)评审：检查项目中间产品，早期发现缺陷以减少后期修改和返工的工作量。

2)测试：直接检查软件产品中的缺陷，确保产品符合要求。一般通过单元测试、功能测试、集成测试、压力测试实现。

3)缺陷追踪：记录和追踪缺陷从发现到解决的整个过程，确保所有的问题都有结论(注意，并非一定都能解决，解决不了的要进行评价)。

这是与评审和测试配合使用的一个重要管理过程。

4)审计：对项目的工作过程进行检查，确保所有活动遵循规程进行。

5)变更控制：在前面的章节中谈过，这也是一个重要的质量活动。

6)配置管理：记录这些中间和最终产品(配置项)变化的历史，确保他们的正确性和一致性。

质量管理不是一堆文档就可以解决问题的，要想确实作好有三点很重要：一是培训，要确保员工知道为什么要这样做能解决什么问题具体如何做没有这种培训，员工很容易把质量管理理解为填写各种表格的繁文缛节。二是与客户交流，笔者发现很多时候因厂商没有与客户进行必要的交流，客户总觉得“什么事都要填表”是在故意刁难;通过解释客户往往非常理解，觉得这正是厂商做事规范的表现，因此会变得很配合。三是慎重选用SQA。SQA在软件质量管理中责任重大，最好有一定的开发经验，并愿意从事质量管理活动。SQA典型职责如下：

1)根据项目特点对过程进行裁剪，并审定最终的质量标准;

2)帮助项目经理制定计划并最终审批，过程中对变更进行审批;

3)进行日常的项目审计，确保项目按规程工作;

4)在阶段点对项目的基线进行审计，配置管理情况;

5)收集和分析各种度量数据，并向高层报告项目情况;

6)对项目组成员进行培训。

总之，质量管理主要通过“文档”控制“过程”。质量管理需要一定代价，要平衡与进度和成本的关系。质量保证是确保最终产品质量的一系列活动;质量控制是确保最终产品满足要求一系列活动。软件项目中的质量管理的重要角色是SQA。

以上就是关于IT项目管理的风险有哪些全部的内容，包括:IT项目管理的风险有哪些、当IT项目经理应该做哪些事情、如何进行有效的IT项目管理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！