项目忙还想过软考，您需要简练！ 《简练APP》针对软考项目管理中级高级，梳理历年真题、大纲、教程、知识点四者的动态关系，建立一体化的“学习-检测”系统，大纲为主线，教程为源点，知识点逐个击破，用真题检测。

---

1、回答问题的文字要简练，千万不要长篇大论，答案长度适中为好。
2、过程要清晰，特别是一些公式的计算，过程要写出来，哪怕结果不对，过程也给分的。
3、文字清晰，书写工整，这样老师对您的印象也会特别的好的。
4、可能您考试的时候记的不是很清晰，脑子里面有好几个答案的，我建议您都写上，因为多写不扣分的。
5、答题要有次序，阅卷老师要批改成千上万的试卷，如果您答得没有次序，老师也不会认真看的，也许就随便给几分了，因此我建议大家答题一定要有次序，最好分列说明， 12345 点、abcd 类型等。
6、尽量使用专业化的术语、而非口语；避免使用绝对的语言；引用案例原文；紧密联系知识点。
7、当遇到自己不会做的，千万不要放弃，因为案例的评分标准是答到点子上就有分的！所以您不会写也得写点东西，尽量往相关知识点上靠拢，还有，案例分析是多写不扣分的，比如标准答案只有3 条，您答了5 条，只要多答的2 条，没有很明显的错误， 都是不影响您的得分的，因此，我建议大家在答题的时候，可以尽量的多写。尽量往理论知识上靠拢！（非常重要，就算不会写也得写，不写肯定没有分，写了肯定有分，只是分数的多少而已）。
8、考试经验也很重要，主要是案例分析，由于答错不扣分，答对就有分，每个问题必须答够6点，每一点至少10个字，这样总有几点是对的。

1、看到有技术人员出身做项目经理就要回答：在信息系统工程中，开发和管理是两条不同的主线，开发人员所需要的技能与管理人员所需要的技能很不一样。角色定位可能不好、没有站在项目经理的角度管理项目，所以需要给他培训。
2、看到身兼数职就要回答：可能没有多少时间去学习管理知识，去从事管理工作。一人承担两个角色的工作，导致工作负荷过载，身心疲惫，其后果可能给全局带来不利影响。
3、看到新技术，就要想到风险，接着就是应该对大家进行培训、学习，然后监控技术风险，或者找合适的人选从事这项工作，最后实在不行就外包。
4、看到有人对项目不满意就要回答：可能没有建立有效的沟通机制和方式、方法，缺乏有效的项目绩效管理机制，需要加强沟通。
5、看到变更的方面就一定是变更的三个要素：书面申请、审批和确认、跟踪变更过程。这三个方面缺一不可。
6、看到由客户验收不通过，往往需要说明验收标准没有得到认可或确认，没有验收测试规范和方法等。
7、只要是与人有关的问题均可以找到沟通方面的答案。也就是沟通不到位。
8、看到过了一段时间才发现问题就说：监控不力，不能及时发现问题。
9、看到里程碑或一些时间做的很紧促，就说没有冗余考虑风险的想法。
10、看到因为外部因素导致的项目的延工等等就要想到：没有考虑外在因素的影响，这个可以结合变更5 个理由来考虑。
11、看到有争执就要想到：是不是沟通有问题，或者计划做的不够周密。
12、看到多头汇报的问题，就要想到：项目章程或者考虑多头回到导致信息沟通不畅通或者冲突产生等等，这个可以结合冲突产生的根源来考虑。

（1）因人手比较紧张，M从正在从事编程工作的高手中选择了小张作为负责软件子项目的项目经理，小张同时兼任模块的编程工作
1)技术到管理，没有培训
2)项目经理不应该身兼多职

（2）该开发人员就直接对系统软件进行了修改
1)缺少变更控制流程

（3）在验收过程中，老刘提出了一些小问题。项目经理张斌带领团队很快妥善解决了这些问题。但是随着时间的推移，客户的问题似乎不断。时间已超过系统试用期，但是客户仍然提出一些小问题，而有些问题都是客户方曾经提出过，并实际上已经解决了的问题。
1)范围蔓延
2)配置管理未做好

（4）项目经理小丁做过5年的系统分析和设计工作，但这是他第一次担任项目经理。小丁兼任系统分析工作
1)技术到管理，没有培训
2)项目经理不应该身兼多职

（5）因此他要求项目组成员无论如何每周都必须按时参加例会并发言，但对例会具体应如何进行，老张却不知如何规定。很快项目组成员就开始抱怨例会目的不明，时间太长，效率太低，缺乏效果等等，而且由于在例会上意见相左，很多组员开始相互争吵，甚至影响到了人际关系的融洽
1)沟通管理计划不细致

（6）在该项目合同中，简单地列出了几条项目承建方应完成的工作，据此小李自己制订了项目的范围说明书。
1)合同条款应当齐全
2)范围说明书需要甲方确认

（7）合同的相应条款作为依据，而这些条款要么太粗、不够明确
1)合同条款应当齐全

（8）以往项目销售经理的过度承诺给后继的实施工作带来了很大困难
1)过度承诺

（9）期间项目经理田某因故离职，其工作由系统集成商B的另一位高级项目经理鲍某接替
1)核心人员离职，工作未交接

（10）项目承建单位的一名副总裁承揽了一个新项目，他把程序员、测试工程师从该项目上调走，去执行他新承揽的项目。
1)人员抽走

（11）尚存在一些问题，主要有：方案遗漏一项基本需求，有多项无效需求，没有书面的需求调研报告；在项目的工期、系统功能和售后服务等方面，存在过度承诺现象。
1)需求评审没做好
2)过度承诺
3)文档管理不到位

（12）章某建议从在公司工作2年以上业务骨干中选拔项目经理。结果李某被章某选中负责该项目的软件开发子项目。
1)业务人员当人项目经理没有经验，未进行培训

（13）他领导的团队因经常返工而效率低下、团队成员对发生的错误互相推诿、开会时人员从来没有到齐过，甚至李某因忙于自己负责的模块开会时都迟到过。大家向李某汇报项目的实际进度、成本时往往言过其实，直到李某对自己负责的模块进行接口调试时才发现这些问题。
1)经常返工，质量有问题
2)团队人员职责定义不清
3)项目经理身兼多职，不以身作则
4)绩效考核不到位
5)监控不利

（14）这次和以往不同的是强某还同时管理着另外两个项目，而这个人口管理系统项目的工期要求紧、他能调用的人手少。
1)身兼多职
2)人力资源不足

（15）张工认为此项目质量管理的关键在于系统地进行测试。
1)质量是计划出来的，不是检查出来的。

（16）新毕业的大学生小吕负责项目的质量保证
1)小吕没有质量保证相关经验，需要进行培训

（17）而WBS则由小刘自己依据以往的经验进行分解
1)WBS需要根据项目实际情况进行编制

（18）因为项目的验收日期是合同里规定的，人员是公司配备的，所以进度里程碑计划是从验收日期倒推到启动日期分阶段制定的。在该项目计划的评审会上，大家是第一次看到该计划，在改了若干错别字后，就匆忙通过了该计划。该项目计划交到负责质量保证的小吕那里，小吕看到计划的内容，该填的都填了，格式也符合要求，就签了字。
1)进度计划不能用那个倒推
2)进度计划应该有冗余
3)会议材料应当提前发给与会人员
4)质量保证不到位

（19）在需求分析时，他们制作的需求分析报告的内容比合同的技术规格要求更为具体和细致。小刘把需求文档提交给了甲方联系人审阅，该联系人也没提什么意见。
1)需求文档未经过甲方确认

（20）甚至有关技术指标不符合国家电表标准等等，而此时S公司因内部原因退出中国大陆市场
1)风险管理不到位

（21）由于此客户为A公司的重要客户，为维护客户关系，A公司同意了建设单位的要求。为了完成项目建设任务，A公司将应用软件分成了多个子系统，并分别组织开发团队突击开发，为提高效率，尽量采用并行的工作方式，在没有全面完成初步设计的情况下，有些开发组同时开始详细设计与部分编码工作；同时新招聘了6名应届毕业生加入开发团队。
1)快速跟进有返工风险
2)新人员需要培训

（22）然后参考项目管理教材和国外一些大型项目管理经验制定了一系列相关规定以及奖惩措施，针对正在开发的项目分别指定了技术骨干作为项目的项目经理。
1)技术人员转项目经理，技能不足需要进行培训
2)项目的规定和奖惩措施需要根据企业、项目的实际情况进行制定

（23）认为“公司规模小没有必要进行项目管理”，与其花费了大量时间开会、写文档，不如几个人碰碰头说说就可以了。实际开发工作中总是以开发任务重等原因不按照规定履行项目管理程序。
1)公司质量体系不健全
2)项目管理不到位

（24）因此决定从公司工作3年以上的业务骨干中选拔一批项目经理。张某原是公司的一名技术骨干，编程水平很高，在同事中有一定威信，因此被选中直接担当了某系统集成项目的项目经理。
1)技术人员转项目经理，技能不足需要进行培训

（25）他领导的小组有2个新招聘的高校毕业生，技术和经验十分欠缺，一遇到技术难题，就请张某进行技术指导。有时张某干脆亲自动手编码来解决问题，因为教这些新手如何解决问题反而更费时间。由于有些组员是张某之前的老同事，在他们没能按计划完成工作时，张某为了维护同事关系，不好意思当面指出，只好亲自将他们未做完的工作做完或将不合格的地方修改好。该项目的客户方是某政府行政管理部门，客户代表是该部门的主任，和公司老总的关系很好。因此对于客户方提出的各种要求，张某和组内的技术人员基本全盘接受，生怕得罪了客户，进而影响公司老总对自己能力的看法。张某在项目中遇到的各种问题和困惑，也感觉无处倾诉。项目的进度已经严重滞后，而客户的新需求不断增加，各种问题纷至沓来，张某觉得项目上的各种压力都集中在他一个人身上，而项目组的其他成员没有一个人能帮上忙。
1)团队人员技能不足，未进行培训
2)需求变更控制流程不到位
3)组织沟通不通畅
4)团队职责不清晰
5)团队管理不到位

（26）王某认为这是正常的项目团队磨合过程，没有过多干预。同时，批评新加入成员效率低下，认为项目团队原成员更有经验，要求新加入成员要多向原成员虚心请教。项目实施两个月后，王某发现大家汇报项目的进度言过其实，进度没有达到计划目标。
1)团队建设，冲突管理
2)绩效考核不到位
3)监控不到位

（27）小方根据在学校学习的项目管理知识，制定并发布了项目章程。因工期紧，小方仅确定了项目负责人、组织结构、概要的里程碑计划和大致的预算，便组织相关人员开始各个网站的开发工作。
1)没有根据项目实际情况制定项目章程

（28）项目经理召开项目组内部会议将任务口头布置给了小组成员。会后，主要由编码人员按照会议备忘录的要求对已完成的模块编码进行修改，而未完成的模块按照会议备忘录的要求进行编写。
1)沟通

（29）需求分析完成后，项目组编写了《需求分析报告》。项目经理小赵召集部分骨干人员召开评审会，对需求文件进行了评审。为了尽快进入下一阶段工作，评审会从早上9点一直开到晚上9点，终于把全部文件都审完了。评审组找到了几处小问题，并当场进行了修改，项目经理宣布可以进入设计阶段了。设计人员根据需求文件编写了《设计说明书》，并提交给小赵。小赵对设计文件仔细审阅后，便安排程序员开始编程。
1)未让甲方参加需求评审
2)会议效率低下
3)无甲方签字确认
4)设计说明书未经过评审,甲方必须参与？

（30）由于该高校是公司重要的客户，A公司领导口头答应了客户的要求。

（31）李某凭借自己项目管理的经验，认为这些变更在约定的工期内可以完成，因此直接答应了对方的变更要求，随后，李某找到负责变更模块的项目组成员，要求其完成对业务流程变更的修改。
1)未经过变更控制
2)风险

（32）临近外包交工时，对方提出人力资源紧张，要求延长合同期限，如果延长外包期限，将导致无线抄表系统项目进度无法完成，公司将承受很大的损失。
1)合同监控不到位

（33）小王在初步了解了这个项目的基本情况之后，就按照公司的模板与项目组的几个核心成员共同制订了项目管理计划。
1)不是基本情况后，是详细

（34）考虑到刘某第一次管理这种商业性项目，因此对很多管理细节都进行了细化，并将计划重点集中在项目执行计划的制订方面，配置管理计划做得比较简单
1)管理经验不足
2)对配置管理的认识不足

（35）项目经理经过与项目组及项目管理部协商，决定去掉详细设计这个环节，直接进入产品的编码阶段，安排开发工程师根据总体设计负责各自模块的开发工作。
1)详细设计环境不能去掉
2)开发不讷讷感各自为营

（36）5名开发工程师组成的开发小组进入非常忙碌的编码阶段后，经常加班加点。开发过程中，由于原来制定的计划已完全被打乱，SQA无法再根据原来的质量保证计划进行跟踪，项目组其他人员也已无法发挥作用。
1)计划未及时更新

（37）这时已有2名开发人员因为信心问题而离职，项目经理除了要考虑项目进度外，还要考虑项目资源，由于此时其他项目任务也很重，公司资源很紧张，他不得不重新招聘开发人员。
1)团队建设未到位

（38）小赵被任命为某软件开发项目的专职质量管理人员，他此前只有过三个月的软件开发经历。
1)没有QA经验

（39）项目经理李工决定调整计划，不划分测试阶段，将所有模块一次集成后统一开始测试。
1)全过程测试

（40）由于模块由不同人员开发，需要不同的人来修改，常常是已修复的BUG，在修复其他的BUG之后又再次出现，开发人员不停修改
1)配置没做好
2)沟通不到位

（41）质量部便借鉴了其它公司的体系文件，对其简单修改后形成了A公司的质量管理体系文件。
1)未根据单位自身实际情况

（42）鉴于项目已经完成了试运行，李工就组织大家召开了项目总结会。在总结会上李工表示了对大家的感谢，然后就宣布项目已经结束，项目团队成员可以各自按照原先的人力资源计划进入新的项目。
1)项目未验收
2)未进行项目总结，分析经验教训，更新组织过程资产

（43）项目小组在2009年1月20日前完成任务，1月21日至28日各模块联调，1月29日至31日机动。
1)未考虑节假日

（44）小李随后在原道路监控项目解决方案的基础上组织制定了智能交通管理系统项目的技术方案。
1)需要根据实际项目

（45）为了赶工期项目组省掉了一些环节和工作，虽然最后通过验收，但却给后续的售后服务带来很大的麻烦：为了解决项目网络出现的问题，售后服务部的技术人员要到现场逐个环节查遍网络，绘出网络的实际连接图才能找到问题的所在。售后服务部感到对系统进行支持有帮助的资料就只有政府网站的网页HTML文档及其内嵌代码。
1)文档缺失

（46）H公司同甲方关系比较密切，但也正因为如此，合同签的较为简单，项目执行较为随意。

（47）小赵是一位优秀的软件设计师，负责过多项系统集成项目的应用开发，现在公司因人手紧张，让他作为项目经理独自管理一个类似的项目

（48）李工按照4个月的工期重新制定了项目计划，向公司申请尽量多增派开发人员，并要求所有的开发人员加班加点工作以便向前赶进度。由于公司有多个项目并行实施，给李工增派的开发人员都是刚招进公司的新人。为节省时间，李工还决定项目组取消每日例会，改为每周例会。同时，李工还允许需求调研和方案设计部分重叠进行，允许需求未经确认即可进行方案设计。
1)加班不利于团队氛围。。。。
2)增加人员不一定有效
3)快速跟进风险
4)需求未确认

（49）张工在担任此新项目的项目经理同时，所负责的原项目尚处在收尾阶段。张工在进行了认真分析后，认为新项目刚刚开始，处于需求分析阶段，而原项目尚有某些重要工作需要完成，因此张工将新项目需求分析阶段的质量控制工作全权委托给了软件质量保证（SQA）人员李工。李工制定了本项目的质量计划，包括收集资料、编制分质量计划、并通过相应的工具和技术，形成了项目质量计划书，并按照质量计划书开展相关需求调研和分析阶段的质量控制工作。
1)身兼多职
2)质量控制给QA
3)质量计划各干系人参与
4)对需求分析不重视
5)质量是全过程的

（50）某网络建设项目在商务谈判阶段，建设方和承建方鉴于以前有过合作经历,并且在合同谈判阶段双方都认为理解了对方的意图，因此签订的合同只简单规定了项目建设内容、项目金额、付款方式和交工时间。

（51）王某是某管理平台开发项目的项目经理。王某在项目启动阶段确定了项目组的成员，并任命程序员李工兼任质量保证人员。李工认为项目工期较长，因此将项目的质量检查时间定为每月1次。
1)QA兼职
2)频度太低

（52）李工对这个开发人员开具了不符合项报告，但开发人员认为并不是自己的问题，而且修改代码会影响项目进度，双方一直未达成一致，因此代码也没有修改。
1)QA未按要求上报

（53）老陆是某系统集成公司资深项目经理，在项目建设初期带领项目团队确定了项目范围。后因工作安排太忙，无瑕顾及本项目，于是他要求：①本项目各小组组长分别制定组成项目管理计划的子计划；②本项目各小组组长各自监督其团队成员在整个项目建设过程中子计划的执行情况；③项目组成员坚决执行子计划，且原则上不允许修改。

（54）在编码阶段，赵工发现需求文件还在不断修改，形成了多个版本，设计文件不知道该与哪一版本的需求文件对应，而代码更不知道对应哪一版本的需求和设计文件。同时，客户仍在不断提出新的需求，有些很细微的修改，开发人员随手就改掉了。
1)需要蔓延
2)配置管理

（55）小刘经过详细的需求调研，开始着手制定项目计划，在此过程中，他仔细考虑了项目中可能遇到的风险，整理出一张风险列表。
1)计划各干系人参与
2)风险全员参与

（56）项目管理计划制定完成后，小刘通知了项目组成员，召开了第一次项目会议，将任务布置给大家。随后，大家按分配给自己的任务开展了工作。
1)工作需要确认
2)无启动会

（57）某公司的质量管理体系中的配置管理程序文件中有如下规定：①由变更控制委员会（CCB）制定项目的配置管理计划；②由配置管理员（CMO）创建配置管理环境；③由CCB审核变更计划；④项目中配置基线的变更经过变更申请、变更评估、变更实施后便可发布；⑤CCB组成人员不少于一人，主席由项目经理担任。
1)CMO制定配置管理计划
2)少验证
3)ccb一个人时为甲方领导

（58）为了节约时间，小陈根据自己在沟通会议上记录的结果，当晚组织相关人员撰写了软件需求规格说明。次日便要求设计人员开始进行系统设计，并指出项目组成员必须严格按照进度计划执行，以不辜负领导的期望与嘱托。
1)需求要确认
2)进度可能有变更

（59）项目进行到2月底时，校方主管此业务的新领导到任，并提出了新的信息化管理要求。小陈进行变更代价分析，认为成本超支严重，于是小陈准备不进行范围变更，并将结果通知客户，引起客户不满。
1)变更控制流程不对
2)沟通

（60）近期，该公司承担了某自然灾害预警系统项目，由于项目时间紧张，上线任务迫切，经过管理层

讨论，决定临时简化流程，在开发阶段集中对质量进行把关。由于以前做过类似的项目，为了节约时间，项目经理带领团队套用原有成功项目的需求和设计思路，对历史项目的相关文档进行修改后，立即进入编码阶段。编码完成后，为争取系统提前交付，匆忙进行测试，并上线试运行。
1)简化
2)质量是全过程把关,质量是计划出来的，不是检查出来的
3)文档需要结合本项目实际情况
4)需求需确认
5)测试要认真

（61）项目组准备了详尽的测试用例，会同业主共同进行系统测试，测试过程中为了节约时间，小张指派项目开发人员小李从测试用例中挑选了部分合理、有效的数据进行测试，保证系统正常运行。
1)小李最好为专门QC
2)测试用例要有正确的和错误的

（62）项目组将业主的数据和设置加载到系统中进行正常操作，完成了试运行工作。 1)试运行数据加载应该由甲方自己做
2)不是做正常操作，而是实际操作

（63）经初步调研，杨某发现该项目进度紧、任务重、用户需求模糊，可能存在较大风险。但B公司领导认为应该先签下该项目，其他问题在项目实施中再想办法结局。A、B双方很快签订了一份总价合同。在合同中，根据赵某提供的初步需求说明，简单列出了系统应完成的各项功能和性能指标。杨某根据合同制定了项目的范围说明书。
1)总价合同对B公司不利，应该为单价合同
2)初步需求简单列出不对

（64）杨某将上述情况汇报给了B公司主管领导，主管领导认为A单位为公司客户，非常重要，要求杨某利用合同条款的模糊性，简化部分模块的功能实现，以保持成本和进度不变。
1)模糊性无职业道德

（65）小李为项目制定了整体进度计划，将项目分为需求、设计、实施和上线试运行四个阶段，项目开始后，张工凭借其丰富的经验使开发过程得到了很好的质量保证，需求和设计顺利通过了张工的把关。
1)计划要各干系人参与
2)项目少测试阶段

（66）A公司同时进行的信息系统开发项目比较多，李工在完成生产过程管理信息系统的需求说明书后，转到了另外的项目开发组。在赵工带领开发小组进行设计与编码的过程中，客户经常提出一些小的改动，赵工认为满足客户的需求是很重要的，所以，能改的就改了，没有与A公司的其他人进行协商。
1)身兼多职
2)需求蔓延
3)变更控制不到位

（67）由于技术人员有限，为保证各个项目的进展，人员在项目间的兼职与交叉很严重。一个技术开发人员在M项目上工作2天后，很可能转入Y项目工作，过了3天，再转回M项目工作。项目的文档一

般采用各自的命名方式进行管理，客户提出的修改也各自负责，在技术开发人员的本地机上进行了开发。 1)人员复用
2)配置管理有问题

（68）接到任务后，项目经理小王开始着手编制项目管理计划，根据招标文件，小王列出了一个初步的进度计划，进度计划中的各里程碑点正好是甲方招标文件中规定的各时间节点。随后，小王估计了项目的各项开销，确定了项目预算。
1)计划要干系人参与
2)根据合同，投标文件而不是招标文件
3)初步计划应该是详细计划
4)实际应该有冗余
5)确定的应该是估算不是预算

（69）为了赶工，就对项目开发人员再发工，将试运行的系统版本作为原始版本，在些基础上开始并行为其他委办局定制开发各自的政务信息资源整合系统。试运行的版本在运行中根据用户的要求，产生了一些功能的变动，开发人员改动代码，这些改动后的代码有的适合其他委办局，有的不适合；而在为其他委办局开发中，也在根据用户的要求进行各自代码的修改。项目进展得很顺利，期间，主要开发人员小王和小李因故提出辞职，刘经理向公司申请补充开发人员接替小王和小李的工作，然而由于之前的变更没有相关文档的记录，开发版本与设计和需求的版本对应不上。
1)身兼多职
2)配置管理不到位
3)变更控制流程不到位
4)文档不全

（70）鉴于项目规模较小，而且已经获得了总经理的支持，因此项目经理李某觉得没有必要进行项目的可行性研究，只是组织业内的几个专家，根据他自己对项目的描述做了简单的评审，专家也没有对该项目提出太多的异议。但是在项目的实施阶段，问题却层出不穷。首先是，项目团队发现有新的、更简单易行的技术方案可以实现项目的目标；其次是与销售部门会议后，销售部门的人反映目前开发的产品不是他们需要的产品；更麻烦的是，相关政府部门出台政策，为了稳定市场秩序，限制了该类产品的市场销售。
1)可行性研究不能少
2)技术、市场、社会可行性都没有

（71）S公司是某市一家从事电子政务应用系统研发的系统集成公司，公司总经理原为该市市政府信息中心总工程师。S公司最近承接了该市政府X部门的一个软件项目，而X部门一直是S公司的老客户。因为当时公司总经量急于出差，所以在系统范围界定和验收标准并不十分明确的情况下，就和客户签订了合同，并任命李工为该项目的项目经理。
1)老客户
2)无项目经理经验

（72）随着项目的逐步开展，客户方不断提出一些变更要求，项目组起初严格按照变更管理流程进行处理，但是由于S公司与X部门比较熟悉，且胡某强调这些变更都是必需的业务要求，因此几乎所有变更都被批准和接受。

（73）李工要求项目组天天加班以保证进度，但需求变更似乎没完没了。为了节省时间，客户的业务人员不再正式提交变更申请，而是直接和程序员商量，程序员也往往直接修改代码而来不及做相关文档记录。对此李工也很无奈。

（74）此时有一个项目A的项目经理告知小张，发现基线库中有一个重要的功能缺陷要修改,项目经理组织配置控制委员会进行了分析讨论后，同意修改，并指派了程序员小王进行修改，于是小张按照项目经理的要求在受控库中增加了小王的修改权，以便小王可以在受控库中直接修改该功能。
1)变更控制未走CCB
2)配置管理未到位，开发人员不应该能修改受控库

（75）项目经理认为，公司的控制系统软件是比较成熟的产品，虽然需要按项目需要进行二次开发，但应该能够提前完成，但列车控制设备需要协调外包生产，比原计划提前2个月没有把握，公司领导认为，从铁路行业的项目特点来考虑，提前开始铁路是必须完成的任务，因此客户的要求不能拒绝。于是他要求项目经理无论如何也要想办法满足客户提出的提前交付的需求。
1)风险
2)变更

（76）该企业已按照ISO9001的要求建立了一套质量管理体系，对于项目管理、软件开发等的流程均有明确的书面规定。但公司中很多人认为这套管理体系的要求对于项目来说是多余的，条条框框的约束太多，大部分项目经理都是在项目结项前才把质量体系要求的文档补齐以便能通过结项审批。公司的质量管理员也习以为常，只要在项目结束前能把文档补齐，就不会干涉项目建设。
1)未按照公司质量方针，制定项目的质量管理计划
2)质量意思不行
3)文档补全不对
4)QA走过场

（77）老李组织了技术骨干对客户的需求进行了调研，通过对用户需求的分析和整理，项目组直接制定了一个总体的技术方案，然后老李制定了一个较粗略的项目计划：
1)计划应该是尽量准确的。
2)项目计划不是老李自己一个人做的，应该感谢人参与

（78）在软件与采集设备的联调过程中，老李请环保局的客户代表来检查工作。客户代表发现由于项目组不了解环保领域的一些参数指标，完成的系统达不到客户方的要求。由于项目从一开始就没有完整的项目文档，老张为了避免再出现重大问题，只好重新进行需求调研。客户方很不满意，既担心项目不能按时上线又担心项目质量无法保证。
1)文档配置不到位
2)沟通不畅
3)需求开发工作不到位
4)质量保证有问题

（79）张工按照项目内容，将项目分成子项目1、子项目2和子项目3，分别任命李工、王工和廖工负责。三个项目在张工的领导及协调下进展顺利。在整个项目进行到80%时，出资人提出子项目1由于政策原因需要终止，子项目2、子项目3继续按照原计划进行。因此张工通知李工将子项目1资料归档并提交给公司管理资产的人员。随后为了保证子项目2、子项目3的顺利进行，张工将子项目1的项目团队解散，有关员工加入到子项目2、子项目3中。子项目2、子项目3在张工引入新的资源后，进展顺利，因此张工觉得不需要再加强阶段审查，等项目全部完成后再统一进行验收。在项目结束后，张工组织客户对子项目2、子项目3分别进行验收，结果客户对子项目2的成果很不满意。因子项目3需要的一个关键部件是子项目2提供的，最后影响了二者的总体验收，项目因此没有按时交工。
1)政策原因中止可能是可研没做好
2)项目结束应该一起提交
3）统一验收有问题
4)项目应该统一验收

（80）项目启动时，乙公司领导安排王工担任此项目的项目经理，王工自己按照公司项目章程模板撰写项目章程，进入了下一个过程，新撰写的项目章程内容包括：质量控制人员、项目组织结构、项目基本需求、项目完工日期。同时为了保证项目质量，王工亲自撰写了初步的项目范围说明书。王工依照以前公司的经验撰写的初步的项目范围说明书内容包括：项目概述、产品要求、项目完工日期、项目约定条件、初始风险。初步的项目范围说明书撰写完成后，王工通知了项目组成员，按照初步的项目范围说明书开始工作，项目组成员有人认为初步范围说明书内容太过简单，跟以往项目范围说明书差别太大，但担心项目经理不高兴，也没有直接说。
1)项目章程不对
2)初步项目范围书王工写的。。。
3)沟通不畅

（81）刚进入项目规划阶段，发生的几个事件让王工觉得非常棘手：①项目组成员就系统是否包含数据库导出、备份功能产生了分歧，查看初步的项目范围说明书发现也没有相应描述。②有项目组成员认为初步的项目范围说明书中给出的系统安全等级过高，实现难度非常大，还可能导致项目成本大幅度增加③项目组成员不确定项目验收时是否要给客户交付《产品使用手册》，有成员建议既然不确定就不要做了，这样可以节约成本。④在初步的项目范围说明书中没有涉及到项目的质量管理要求，乙公司内部的质量技术部因此没有安排专门的人员配合王工工作。⑤一些项目组成员经常抱怨王工大包大揽，项目启动阶段的工作不严格遵照公司管理流程执行，也未征求其他项目组成员的意见和建议。
1)文档编写有问题--目范围说明书发现也没有相应描述
2)安全等级未和客户交流，未进行详细技术可研
3)文档不到位
4)变更控制流程
5)团队管理

（82）甲公司是一家通信技术运营公司。经公司战略规划部开会讨论，决定开发新一代通信管理支持系统，以提升现有系统综合性能，满足未来几年通信业务高速发展需要。战略规划部按照以下步骤启动该项目：①起草立项申请，报公司总经理批准。②总经理批准后，战略规划部开展了初步的项目可行性研究工作，主要从国家政策导向、市场现状、成本估算等方面进行了粗略的调研。③战略规划部依据初步的项目可行性研究报告，认为该项目符合国家政策导向，肯定要上马。公司立即成立了建设方项目工作小组，计划以公开招标的方式选择承建方。
1)缺少详细可研
2)缺少论证立项流程

（83）乙公司成立时间不足两年，研发队伍能力较强，也有为其它通信技术公司开发过软件产品的经验。乙公司得知甲公司的招标信息后，马上组织人员开始投标工作。该项目的投标工作由软件研发部的郑工负责。郑工是公司的软件工程师，具有丰富的软件代码编写经验。郑工从技术角度分析认为项目可行，独立编制完成了投标文件。
1)乙方未可研
2)承建方论证的内容

（84）某信息系统开发公司承担了某企业的ERP系统开发项目，由项目经理老杨带领着一支6人的技术团队负责开发。由于工期短、任务重，老杨向公司申请增加人员，公司招聘了2名应届大学毕业生小陈和小王补充到该团队中。老杨安排编程能力强的小陈与技术骨干老张共同开发某些程序模块，而安排编程技术弱的小王负责版本控制工作。在项目开发初期，小陈由于不熟悉企业的业务需求，需要经常更改他和老张共同编写的源代码文件，但是他不知道哪个是最新版本，也不知道老张最近改动了哪些地方。一次由于小王的计算机中了病毒，造成部分程序和文档丢失，项目组不得不连续一周加班进行重新返工。此后，老杨吸取教训，要求小王每天下班前把所有最新版本程序和文档备份到2台不同的服务器上。一段时间后，项目组在模块联调时发现一个基础功能模块存在重大BUG，需要调取之前的备份进行重新开发。可是小王发现，这样一来，这个备份版本之后的所有备份版本要么失去意义，要么就必须全部进行相应的修改。项目工期过半，团队中的小李突然离职，老杨在他走后发现找不到小李所负责模块的最新版本源代码了．只好安排其他人员对该模块进行重新开发。
1)版本管理员无经验
2)未对团队成员进行培训
3)配置管理不到位
4)配置管理系统出问题了？
5)一段时间后----监控不利

(85) 项目进入编码阶段后，承办单位为了扩大影响力，要求在项目中增加全国服装模特海选的宣传、选拔、评奖与管理。因此，建设方代表直接找到小曹提出增加项目内容，并答应会支付相应的费用，但要确保项目工期不能拖延。（1）小曹见到其领导时转述了建设方的要求;（2）领导考虑了一会儿，对小曹说“答应客户要求”，（3）小曹通知商务人员与建设方签订补充协议，（4）因建设单位要求工期不能拖延，故小曹决定项目进度计划不变;（5）小曹找来设计工程师小廖，把新增部分全权委托给了他，让他加班加点确保进度。交付期至时，项目集成测试中发现的问题还未得到及时解决。
1)进度计划是否变更需要评估 2) 加班加点 3) 全权委托

(86) 信息系统集成公司A（以下简称A公司）于2012年5月承接了某市级银行的计费数据库系统开发项目，约定在该银行十三个本地网点计费系统建设中提供硬件平台及相应软件产品，并由A公司负责系统总集成，以及后期相关的运维工作。由于感觉技术比较单一，因此签订了总价合同，合同中只是简单规定了技术总体要求，并约定依据项目的大致进展进行付款。
1)不应当签订总结合同
2)合同条款不清晰

（87）1、张经理认为做好运维的核心是运维人员的维修水平。由于运维合同价格偏低，在招聘人员时主要考虑人员是否有相关设备维修经验，并指派本公司有系统集成实施经验的若干名人员加入运维团队，要求团队成员满负荷工作，项目组人员不能有冗余。2、在运维项目实施期间，遇到值班人员有事或生病，只能由项目经理代班，遇到客户报修的设备问题，维修人员常常以我不懂该专业，让客户第二天再报。运维人员遇到无法解决的技术问题向项目经理汇报时，项目经理回答“你们招进来就是解决设备问题的，我无法提供帮助，你们自己解决”相关运维人员经常超过规定时间，也未能使设备恢复运行。3、项目经理认为团队管理的核心是团队凝聚力强，不发生冲突。项目经理利用工作和业务时间进行了大量的沟通和协调工作。确保在运维实施期间，成员关系比较融治。但在季末法院信息中心进行的服务满意度调查时，综合满意度只有70%,设施综合可用性指标只达到98%。
1)团队管理不当
2)项目经理不应该兼职
3)沟通职责有问题
4)没有培训
5)应该有有冲突解决

（88）某石化行业的信息化项目是一个大型项目，前期投标竞争非常激烈，甲公司最终中标。合同谈判过程也比较紧张，客户提出的一些要求，如工期和某些增加的功能，虽然在公司内部讨论时，认为并没有把握按要求完成，但是为了赢得这个项目，甲公司在谈合同时未提出异议。由于项目工期紧张，甲公司选择了项目经理老李负责该项目。原因是老李在甲公司多年一直从事石化行业的项目咨询、设计、开发，对行业非常熟悉，技术水平高。而近一年来，他正努力转型做项目经理，管理并负责完成了2个较小规模的项目。老李带领项目组根据客户要求的工期制定了项目计划，但项目执行到第一阶段，就未按计划进度完成。由于项目刚开始，老李怕客户有意见终止合同，因此决定不把实际情况告知客户，打算在后面的工作中加班加点把进度追回来。接下来，项目组在解决客户谈判过程中增加的功能需求的时候，遇到了一个技术问题，老李带领项目组加班进行技术攻关，耗费了几周的时间，终于解决了技术问题。但此时项目进度延误得更多了。甲公司已建立项目管理体系，该项目的QA本应该执照甲公司要求对项目过程进行检查，但老李认为过程的检查会影响到项目组的工期，要求QA在项目阶段未再进行检查。时间已经超过工期的一半，客户到甲公司检查项目工作，发现项目进度严重滞后，并且已经完成的部分也未能达到质量要求。
1)风险---甲公司在谈合同时未提出异议
2)老李无大型项目经验
3)和甲方沟通不到位
4)老李过度参与技术
5)QA应该是全过程的

（89）项目前期，A公司请王副总经理负责此项目的启动工作。王副总经理简单了解项目的概要情况后制定并发布了项目章程，任命小丁为项目经理。项目团队根据分工制定了相应的项目管理子计划。据此，项目经理小丁把各个子计划归并为项目管理计划。
1)简单了解后不能发布项目章程

（90）为了保证项目按客户要求尽快完成，小丁基于自身的行业经验和对客户需求的初步了解，即安排项目团队开始进行项目实施，在系统开发过程中，建设方提出的建设需求不断变化，小丁本着客户至上的原则，总是安排项目组进行修改，从而导致开发工作多次反复。而因为项目计划的多次变化，导致项目团队的成员也经历过多次调整，实际进度与里程碑计划存在严重偏离，实际进度与里程碑计划存在严重偏离，并且项目的质量指标也经常也暴露出问题。
1)初步了解不对
2)需求未确认
3)变更控制不到位
4)团队建设不到位

一、合同管理的常见问题：
1、未签订合同，或缺少必要的合同条款；
2、合同条款约定不明（时间、地点、质量要求、费用等）；
3、合同执行过程中没有留下相应的记录；
4、项目变更中没有相应的进行合同变更
5、未做好合同签订前的调研工作，合同签订过于草率；
6、缺少变更处理相关条款；
7、缺少违约责任相关条款；
8、缺少项目索赔及纠纷处理相关条款；
9、项目变更中，未对相应的合同进行变更；
10、项目合同执行过程中，未留下相应的文档记录；
11、未采取措施，确保合同双方对合同条款达成一致理解；
12、合同双方未对项目范围达成一致认可或承诺。
二、变更中常见的问题：
1、没有按照变更要求处理更过程；
2、变更要求没有留下书面记录；
3、是否接受或拒绝变更，不应由项目经理独自决定；
4、项目变更后有没有相应的变更合同
三、项目管理计划的常见问题：
1、计划的制定不应由一人进行，应全员参与；
2、项目计划制定考虑不周，缺少对某些风险的考虑和应对策略；
3、计划没有得到评审和批准便执行；
4、项目情况发生变化后没有相应的变更计划；
5、计划的变更没有按照变更流程的要求进行（详见变更中常见的问题）
四、范围管理中的常见问题：
1、没有制定范围管理计划或计划安排不合理；
2、范围定义不充分（或没有做好需求分析、调研等工作）
3、缺少范围确认环节（或项目需求、设计等没有得到用户的正式评审）；
4、范围控制存在问题（详见变更中常见的问题）
5、没有区分项目产品范围和项目工作范围
6、缺少项目范围管理计划（对范围管理出现问题时，对一些意外问题无所适从）
7、范围的定义不明确（项目结束遥遥无期，像个无底洞）
8、WBS不合理（层次级别错乱、冗余或缺失、太粗或太细）
9、没有进行范围核实；在核实之前没有进行质量控制工作（测试、评审等）
10、范围变更没有控制（需求不明确、项目实施时间过长、业务需求变更）
11、前期变更的预防、迭代开发
12、没有经验教训的总结
13、范围确认问题：
13.1、可交付成果是否确实、可验证
13.2、里程碑是否明确、可辨认；每个里程碑是否有可交付成果
13.3、是否明确了质量标准，是否按照标准要求
13.4、审核和承诺是否有清晰的表达
13.5、项目范围是否涵盖了要完成产品和服务进行的所有活动
13.6、项目范围的风险是否太高
14、未制定项目范围管理计划或内容不完善；
15、项目沟通存在问题；
16、项目经理缺乏必要的项目管理经验；
17、范围没有管好，造成二次变更；
18、项目范围控制存在问题；
19、项目变更中，没有对相应的合同进行变更；
20、缺少需求调研、分析等环节；
21、没有定义出项目范围说明书或范围定义不充分；
22、缺少范围确认环节；
23、变更没有规范地变更流程；
24、项目的需求、设计文件未得到客户的正式评审；
25、变更结果没有得到客户的确认；
26、没有及时评估项目范围变更给项目带来的方方面面的影响，并与项目干系人沟通。
五、进度管理中的常见问题：
1、没有制定进度讣划或计划考虑不周（主要是没有预留应急时间储备或储备不足）；
2、活动资源估算（或历时估算）不准确；
3、项目存在延期趋势时没有及时更新进度计划并与xx 沟通；
4、压缩进度的方式不合理（赶工、快速跟进）；
5、项目发生事实上的延期后没有按照变更流程的要求处理工程延期（详见变更中的常见问题）
6、进度计划估算不合理；
7、忽略损失的时间：
7.1、节假日的时间损失；
7.2、预留时间；
7.3、人员交接的损失；
8、没有明确项目工作实施顺序和时间（分期的项目）；
9、没有确定适当的工期（资源平衡）；
10、没有把握计划粗细的程度；
11、影响进度的因素（人：pm，团队，项目干系人、材料和设备、方法和工艺、资金和环境）：
11.1、低估了项目实现的条件（低估技术难度、协调的复杂程度）
11.2、项目参与者的错误
11.3、计划制定错误或没有考虑预留时间
11.4、高层或客户不支持
11.5、管理上的缺漏：外包的控制、人员离职、其它风险
12、项目团队成员没有尽早的参与项目，需求分析耗时过长；
13、开发团队没有尽早的参与项目，需求分析耗时过长；
14、未制定项目进度管理计划或内容不完善；
15、仅靠类似项目估算本项目历时不准确；
16、项目经理缺乏必要的项目管理经验，项目资源分配不足；
17、经验不足，进度计划估算不准确；
18、没有合理的使用分配到项目上的资源；
19、未考虑特定时期会对项目进度产生影响；
20、进行项目历时估算时，未充分考虑节假日的影响；
21、进度控制存在问题；
22、项目沟通存在问题，增加人员经验不足，经常加班，导致工作效率降低；
23、未对项目管理计划、技术方案进行详细评审，需求文件未经确认。
六、质量管理中的常见问题：
1、没有制定质量管理计划；
2、质量职责分配不合理，主要是没有QA，或QA 不独立于项目组，或QA 没有全程参与项目；
3、质量控制缺少必要的环节（评审、测试）
4、质量控制方法不合理，效果不佳（评审，测试）
5、没有按照变更流程的要求处理质量标准（验收标准）的变更（详见变更中的常见问题）
6、未制定项目质量管理计划或内容不完善；
7、为建立质量保证体系；
8、缺乏质量标准和质量规范；
9、质量管理没有使用有效地管理工具、技术、方法；
10、项目沟通存在问题；
11、质量职责分配不合理，没有QA人员，或QA人员未独立于项目组，或没有全程参与项目；
12、项目经理缺乏必要的项目管理经验或项目质量保证人员经验不足；
13、质量控制的方法存在问题，效果不佳；
14、仅向用户提交了测试报告，而未向用户提交全面质量管理进展报告；
15、项目质量控制缺少必要地环节（如：缺少评审、检查等）；
16、新进人员经验不足；
17、测试过程中，配置管理工作未到位；
18、没有按照正规的变更控制流程处理质量标准和验收标准的变更。
19、企业质量管理体系可能存在的问题：
19.1、体系的建立应全员参与；
19.2、体系的建立应充分结合本企业的特点，不能照搬照抄；
19.3、体系制定完成，应立即运行，不断改善，不能束之高阁；
19.4、体系运行过程中，应及时发现问题，进行改进；
19.5、企业质量管理部门应全程参与体系的制订（建立）及运行；
19.6、企业的项目应严格遵照体系的要求执行。
七、人力资源管理（或团队组建、建设和管理）中的常见问题：
1、组建团队存在问题（选人、挑人存在问题）
2、建设团队存在问题（或没有采取有效的团队建设措施）
3、没有对人员实行绩效考评或相应的激励机制
4、团队管理存在问题，主要是没有及时发现冲突并分析原因，采取有效的冲突管理措施。
5、招募不到合适的项目成员；没有能够建立人力资源获取/培养的稳定机制，应该建立稳定的人力资源获取和培养机制；
6、团队的组成人员尽管富有才干，但是却很难合作；没有能够完整地识别项目所需的人力资源的种类、数量和相关任职条件；应该在项目早期，进行项目的整体人力资源规划、 明确岗位设置、工作职责以及协作关系；
7、团队的气氛不积极，造成项目团队成员士气低落；没有建立一个能充分、有效地发挥能力的项目团队；应该进行项目团队建设，加强团队沟通，建立合作氛围；
8、项目团队的任务和职责分配不清楚；没有清楚地分配工作职责到组织个人或者人力单元；应该根据项目团队成员的工作职责和目标，跟踪工作绩效， 以及予以调整和改进，提升项目整体绩效。
9、人员流动过于频繁；
10、项目经理缺乏必要的项目管理经验；
11、项目沟通存在问题；
12、未进行良好的冲突管理；
13、兼职过多，没有足够地精力和时间，顾此失彼；
14、项目经理没有真正进入项目管理角色，定位错误，疏于对项目的管理；
15、新进成员缺乏培训和全程的跟踪监控；
16、没有共同制定并遵守的工作纪律。
八、可行性分析常见问题：
1、没有进行充分的项目可行性分析
2、技术路线不先进或不成熟，两者没有取得平衡
3、没有考虑信息安全的问题，或者安全措施不可靠
4、项目采用的做法不符合国家标准规范
5、项目负责人、技术核心人员或外聘专家不能保证到位，或没有合适的人选
6、投资估算不合理
7、资金来源不能保证
8、对市场需求和经济效益的预测没有依据
9、没有考虑项目的风险，没有预防措施和处置方案
10、不符合国家产业政策
九、项目整体管理常见问题：
1、项目各单项管理具有局限性，没有整体观
2、没有定义项目范围说明书，没有书面的范围界定文档，没有制定项目完成或阶段结束的标准
3、范围说明书中没有定义项目的目标，判断的标准要明确（要量化）
4、范围说明书没有经过相关方的确认和核实
5、没有进行变更的管理或管理不规范
6、项目管理计划内容残缺；附属计划没有与整体计划一致
7、项目计划制定的问题：
7.1、没有区分计划的层次性（高级计划、阶段计划、详细的计划）
7.2、制定的计划不现实，估算没有依据（没经验、没历史数据参考），没得到相关干系（包括客户）参与或承诺；不够明细以指导后续的实施
8、计划实施的执行力不够
9、没有对发现的项目的问题进行控制（各个目标的监督和控制）
10、不同的监控方式没有在项目中使用（控制方式单一、无效）
11、整体的变更的控制没有制定，即使制定了也不规范或没有遵循流程
12、项目管理计划的制定不应由项目经理单独完成；
13、制定完成的项目管理计划应经评审；
14、未制定项目管理计划或内容不完善；
15、未制定范围和需求管理子计划；
16、对用户需求获取不充分；
17、需求分析不到位；
18、缺少需求定义环节，未定义出需求规格说明书；
19、缺少需求验证环节，没有请客户一起对需求进行确认；
20、没有求得项目干系人对需求的一致理解；
21、没有求得项目干系人对需求的承诺；
22、没有制定整体变更流程和变更控制流程；
23、没有有效地管理需求变更控制；
24、范围没有管好，导致范围蔓延；
25、进度控制存在问题，没有充分及时评估范围变更而导致的方方面面的影响，造成进度延误；
26、项目经理缺乏必要的项目管理经验；
27、项目沟通存在问题。
十、项目风险管理常见问题：
1、需求风险；
2、市场风险；
3、关键人员风险；
4、进度、质量、成本等其他风险；
5、政策风险；
6、法律法规风险；
7、团队风险；
8、运行风险；
9、技术风险；
10、环境风险；
11、预算风险。
十一、项目需求管理常见问题：
1、未制定项目需求管理计划；
2、项目沟通存在问题；
3、项目经理缺乏必要的项目管理经验；
4、没有有效地管理需求变更控制；
5、没有有效地维护对需求进行跟踪管理；
6、没有按照规范的需求开发和需求管理的内容和流程开展需求工作；
7、没有及时识别项目工作与需求之间的不一致性；
8、没有建立有效地需求变更流程；
9、对用户的需求获取不充分；
10、缺少需求分析环节或分析不到位；
11、缺少需求定义环节，未定义出需求规格说明书；
12、缺少需求验证环节，没有请客户一起对需求进行评审；
13、没有求得项目干系人对需求的一致理解；
14、没有求得项目干系人对需求的承诺。
十二、项目配置管理常见问题：
1、项目沟通存在问题；
2、项目经理缺乏必要的项目管理经验；
3、未制定项目配置管理计划；
4、为建立配置管理系统或机制；
5、项目整体版本管理存在问题；
6、未使用有效地配置管理工具；
7、未对配置管理工具的有效性进行评估；
8、缺乏对配置管理人员的培训；
9、缺少配置管理流程；
10、未设置配置管理人员或经验不足；
11、没有建立基线；
12、没有做好变更管理；
13、缺少各种单元测试和集成测试；
14、缺少项目整体管理的权衡；
15、未对配置进行综合管理。
十三、项目收尾管理常见问题：
1、未制定规范的项目收尾规程；
2、项目沟通存在问题；
3、催收剩余款项，缺少正式且必要的依据；
4、项目在产品和工作上还不满足收尾条件；
5、项目收尾时，应提交的必要文件没有准备好，并经客户签收确认；
6、项目总结会未让全体项目团队成员参加；
7、项目总结报告未能反映项目的实际情况；
8、未经过正式规范的收尾，就提前报告项目结束，进行了人员转移，给项目带来诸多风险；
9、项目产品未经正式验收和确认，未签署验收报告，就进行了项目总结；
10、没有做好验收前的准备工作，软件还存在缺陷，缺陷未经修复和确认，就进入了正式验收环节。
11、在验收过程中，为根据规范的变更控制对软件进行修改，导致软件与文档不一致；
12、软件更新后，未对相应的文档进行变更，便交付给了客户。
十一、共性问题：
1、没有做好xx和yy的沟通
2、项目经理的经验不足
3、没有相关的管理流程或方针
4、没有进行良好的策划
5、资源不足（人、资金、设备和工具）
6、缺少培训，不具备相关的知识和技能要求
7、项目干系人识别不充分，干系人没有充分的介入
8、缺少配置管理、变更控制和版本控制
9、高层没有实时的监控项目
10、没有对以前的经验教训进行积累、总结和使用

项目章程的定义和作用
项目章程是正式批准一个项目的文档，或者是批准现行项目是否进入下一阶段的文档。项目章程应当由项目组织以外的项目发起人发布，若项目为本组织开发也可由投资人发布。发布人其在组织内的级别应能批准项目，并有栅应的为项目提供所需资金的权力。项目章程为项目经理使用组织资源进行项目活动提供了授权。尽可能在项目早期确定和任命项目经理。应该总是在开始项目计划前就任命项目经理，在项目启动时任命会更合适。
项目章程的内容
1.基于项目干系人的需求和期望提出的要求；
2.项目必须满足的业务要求或产品需求；
3.项目的目的或项目立项的理由；
4.委派的项目经理及项目经理的权限级别；
5.概要的里程碑进度计划；
6.项目干系人的影响；
7.职能组织及其参与；
8.组织的、环境的和外部的假设；
9.组织的、环境的和外部的约束；
10.论证项目的业务方案，包括投资回报率；
11.概要预算。
组织过程资产的内容
组织过程资产包含：项目实施组织的企业计划、政策方针、规程、指南和管理系统，实施项目组织的知识和经验教训。
初步项目范围说明书的内容
1.项目和范围的目标
2.产品或服务的需求和特性
3.项目的需求和可交付物
4.产品验收标准
5.项目的边界
6.项目约束条件
7.项目假设
8.最初的项目组织
9.最初定义的风险
10.进度里程碑
11.对项目工作的初步分解
12.初步的量级成本估算
13.项目配置管理的需求
14.审批要求
项目管理计划的内容
1.项目背景如项目名称、客户名称、项目的商业目的等；
2.项目经理、项目经理的主管领导、客户方联系人、客户方的主管领导，项目领导小组(即项目管理团队)和项目实施小组人员；
3.项目的总体技术解决方案；
4.对用于完成这些过程的工具和技术的描述；
5.选择的项目的生命周期和相关的项目阶段；
6.项目最终目标和阶段性目标；
7.进度计划；
8.项目预算；
9.变更流程和变更控制委员会；
10.沟通管理计划；
11.对于内容、范围和时间的关键管理评审，以便于确定悬留问题和未决决策。
项目计划的编制流程
1.明确目标；
2.成立初步的项目团队；
3.工作准备与信息收集；
4.依据标准、模板，编写初步的概要的项目计划；
5.编写范围管理、质量管理、进度、预算等分计划；
6.把上述分计划纳入项目计划，然后对项目计划进行综合平衡、优化；
7.项目经理负责组织编写项目计划；
8.评审与批准项目计划；
9.获得批准后的项目计划就成为了项目的基准计划。

WBS的表现形式
1.分级的树形结构
2.列表形式
分解WBS结构的方法
1.使用项目生命周期的阶段作为分解的第一层，而把项目可交付物安排在第二层
2.把项目的重要可交付物作为分解的第一层
3.把子项目安排在第一层，再分解子项目的WBS
工作分解结构应把握的原则
1.在各层次上保持项目的完整性，避免遗漏必要的组成部分
2.一个工作单元只能从属于某个上层单元，避免交叉从属
3.相同层次的工作单元应有相同性质
4.工作单元应能分开不同的责任者和不同工作内容
5.便于项目管理进行计划和控制的管理需要
6.最低层工作应该具有可比性，是可管理的，可定量检查的
7.应包括项目管理工作，包括分包出去的工作
8.WBS的最低层次的工作单元是工作包

活动资源估算的方法
1.专家判断
2.多方案分析
3.出版的估算数据
4.项目管理软件
5.自下而上估算
活动历时估算的方法
1.专家判断
2.类比估算
3.参数估算
4.三点估算
5.后备分析
制定进度计划的方法和工具
1.进度网络分析
2.关键路线法
3.进度压缩(赶进度、快速跟进)
4.假设情景分析
5.资源平衡
6.关键链法(缓冲)
7.项目管理软件
8.应用日历
9.调整时间提前与滞后量
10.进度模型
进度控制关注的内容
1.确定项目进度的当前状态
2.对引起进度变更的因素施加影响，以保证这种变化朝着有利的方向发展
3.确定项目进度已经变更
4.当变更发生时管理实际的变更
缩短工期的方法
1.投入更多的资源以加速活动进程
2.指派经验更丰富的人去完成或帮助完成项目工作
3.减小活动范围或降低活动要求
4.通过改进方法或技术提高生产效率

成本估算的工具和技术
1.类比估算
2.确定资源费率
3.自下而上估算
4.参数估算
5.项目管理软件
6.供货商投标分析
7.准备金分析
8.质量成本
成本预算的工具和方法
1.成本汇总
2.准备金分析
3.参数估算
4.资金限制平衡
项目成本控制的主要内容
1.对造成成本基准变更的因素施加影响;
2.确保变更请求获得同意;
3.当变更发生时，管理这些实际的变更;
4.保证潜在的成本超支不超过授权的项目阶段资金和总体资金;
5.监督成本执行(绩效)，找出与成本基准的偏差;
6.准确记录所有的与成本基准的偏差;
7.防止错误的、不恰当的或未批准的变更被纳入成本或资源使用报告中;
8.就审定的变更，通知项目干系人;
9.采取措施，将预期的成本超支控制在可接受的范围内;

质量管理过程的4个环节
1.确立质量标准体系
2.对项目实施进行质量监控
3.将实际与标准对照
4.纠偏纠错
制定项目质量的工具和技术
1.效益/成本分析
2.基准比较
3.流程图
4.实验设计
5.质量成本分析
6.质量功能展开
7.过程决策程序图法
质量保证活动的基本内容
1.制定质量标准
2.制定质量控制流程
3.提出质量保证所采用方法和技术
4.建立质量保证体系
质量控制的方法
1.新七：因果图、流程图、直方圈、检查表、散点图、排列图和控制图
2.老七：相互关系图、亲和圈、树状图、矩阵图、优先矩阵图、过程决策方法图和活动网络图
3.测试、检查、统计抽样、6西格玛
质量控制的步骤
1.选择控制对象
2.为控制对象确定标准或目标
3.制定实施计划，确定保证措施
4.按计划执行
5.对项目实施情况进行跟踪监测、检查，并将监测的结果与计划或标准相比较
6.发现并分析偏差
7.根据偏差采取相应对策

组建项目团队的工具和技术
1.事先分派：预先分配到项目中
2.谈判：人员分派多少在谈判中
3.采购：聘用和分包
4.虚拟团队：互联网
成功的项目团队的特点
1.团队的目标明确，成员清楚自己的工作对目标的贡献
2.团队的组织结构清晰，岗位明确
3.有成文或习惯的工作流程和方法，而且流程简明有效
4.项目经理对团队成员有明确的考核和评价标准，工作结果公正公开，赏罚分明
5.共同制定并遵守的组织纪律
6.协同工作，也就是一个成员工作需要依赖于另一个成员的结果，善于总结和学习

沟通管理计划的内容
1.项目干系人沟通要求
2.对要发布信息的描述，包括格式、内容和详尽程度
3.信息接收的个人或组织
4.传达信息所需的技术或方法如备忘录、电子邮件、新闻发布等
5.沟通频率如每周沟通
6.上报过程，对下层无法解决的问题，确定问题上报的时间要求和管理链(名称)
7.随项目的进展对沟通管理计划更新与细化的方法
8.通用词语表
项目总结会议的目的(意义)
1.了解项目全过程的工作情况及相关的团队或成员的绩效状况
2.了解出现的问题并进行改进措施总结
3.了解项目全过程中出现的值得吸取的经验并进行总结
4.对总结后的文档进行讨论，通过后存入公司的知识库，从而纳入企业的过程

风险管理计划的内容
方法论，角色与职责，预算，时间安排，风险类别，风险概率和影响的定义，概率影响矩阵，项目干系人的风险承受度，报告格式，跟踪。
风险识别的工具与技术
SWOT分析，专家判断，文档审查，假设分析，信息收集技术（头脑风暴，德尔菲，访谈，根本原因识别），核对表分析，图解技术（因果图，影响图，过程流程图）
定性风险分析工具与技术
风险概率与影响评估，概率影响矩阵，风险数据质量评估，风险分类，风险紧迫度评估，专家判断。
定量风险分析的工具与技术
敏感性分析，决策树分析，预期货币价值分析，龙卷风图，蒙特卡洛分析，专家判断，访谈，概率分布。
识别风险的主要内容
1、识别并确定项目有哪些潜在的风险
2、识别引起这些风险的主要因素
3、识别项目风险可能引起的后果

采购审计的定义
对所有采购过程进行结构化审查，其目的是找出合同准备或管理方面成功经验和失败教训，供本项目其他采购合同或执行组织内其他项目采购合同借鉴。
规划采购输入
项目管理计划，需求文件，风险登记册，活动资源需求，项目进度计划，活动成本估算，干系人登记册，事业环境因素，组织过程资产。
规划采购的输出
采购管理计划，采购文件，采购工作说明书，供方选择标准，自制或外购决策，变更请求。

维度	技术思维	管理思维
目标聚焦	集中在具体的技术和实现上	更多地关注组织和人员的协调，一级如何有效地实现目标和策略
问题解决方式	通过直接的分析和逻辑思维来解决问题，以寻求最优的技术解决方案	需要从多个角度和层面来解决问题，包括战略、政策、团队动态等
决策过程	通常会更依赖于数据和证据，喜欢在所有信息都明确的情况下做出决定	在决策时要权衡和平衡多种不确定的因素，包括人力、资源、时间和风险等
视野和范围	视野通常更狭窄，更专注于具体的技术领域或问题	需要有全局的视野，以理解和处理更广泛的问题和挑战
人际关系	更侧重于与事务的关系，如与设备、代码或数据的关系	更侧重于人与人之间的关系，包括团队协作、沟通、影响力等
风险态度	倾向于清除不确定性，避免风险，以求保证技术的稳定和可靠	更接受风险和不确定性，因为管理者需要在不确定中寻求机会，推动创新和变革
长期视角	往往专注于短期的任务和目标，如解决特定的技术问题	需要对未来长远的考虑，包括公司的长期战略和目标
交流方式	强调精准和明确，通常喜欢使用详细和具体的语言	更强调影响和说服，通常需要使用更抽象和策略性的语言
团队协作	更倾向于独立工作，或者与相似背景的技术人员合作	通常需要协调不同背景、不同技能的人员，需要激发团队合作精神
资源管理	通常关注具体的技术资源，如硬件、软件或代码	关注更广泛的资源，包括人力资源、财务资源、时间等
变化应对	更习惯于稳定和预见的环境，有时对突然的变化反应不佳	更能适应和管理变化，能在不确定的环境中做决策
风险接受度	倾向于最小化风险，因为技术错误可能导致严重的后果	更可能接收有一定风险的决策，因为管理者需要寻求机会并推动创新
学习方式	倾向于深度学习，专注于技术的深入研究和专业技能的提升	需要广泛的学习，包括策略、领导力、人力资源管理、沟通技巧等