【信息系统项目管理师】第二部分：十大知识领域问题对策汇总

【信息系统项目管理师】第二部分：十大知识领域问题对策汇总

第四章 整体管理的问题对策

领域	问题	原因	对策
制定项目管理计划	简单的将项目管理计划合并在一起做成项目管理计划	不能简单的合并，项目目标的特点是有约束的性质	合并之后进一步的协调，需要做好优化平衡
制定项目管理计划	初步了解需求后就制定项目管理计划	没有全员参与，也没有详细了解	项目管理计划的制定需要全员参与需要详细的了解之后再实施
指导与管理项目工作	项目经理表示团队中没有人可以帮上忙	目经理没有学会授权	授权并指导部下开展工作，必要时需要培训
指导与管理项目工作	项目经理将任务在会议上口头分配，大家根据会议的会议纪要文档来开展工作	会议纪要不是正式文件	分配工作时需要团队成员的确认
监控项目工作	直到什么时候才发现什么问题	缺乏对于项目的监控	增加监控项目的措施
实施整体变更控制	客户方提出的要求全盘接受	客户方提出的要求不能全盘接受	建立变更管理审核机制
实施整体变更控制	项目进行中当出现与计划不相符的问题	在所难免	对于小的偏差可以考虑改善现状，对于大的计划偏差，可以考虑修改计划
结束项目或阶段	项目可交付成果试运行之后，便开总结会	缺少文档的提交，项目的验收	增加文档提交项目验收，然后再开总结会

第五章 范围管理的问题对策

领域	问题	原因	对策
规划范围管理	范围管理计划过于简单，对于范围管理没有什么参考价值	没有做好范围管理计划或范围管理计划安排得不合理	重新制定合理的范围管理计划
收集需求	在范围定义之前，发现缺乏精确的范围定义	没有挖掘到全部隐性需求，所获取的用户需求信息记载不足	对用户再一次进行了访谈后，再对项目范围进行清晰的定义，并根据定义分解为WBS
范围定义	为了尽快开始项目，没有定义详细的范围说明	不要参照初步范围说明书就开始实施工作，因为它不是基准还不够详细	定义详细的范围说明书，并和团队成员一起分解WBS
定义范围	项目经理独自制作了项目范围说明书	没有和甲方确认，也没有评审	邀请团队成员一起做，和甲方确认，并增加评审
范围定义	对于范围定义团队成员之间理解出现了偏差	项目整体范围定义不充分不详细	项目全体人员做好范围定义，并进行评审
范围确认	客户对于项目的进展表示担心，害怕无法按时完成可交付成果	没有与客户进行需求的确认，缺少范围确认环节	范围必须得到高层和客户的确认；进行沟通管理，协调多个项目干系人之间的矛盾
范围确认	与干系人进行范围确认时，发现有一个变更遗漏了	对于需求变更时，只记录了需求，没有对需求进行跟踪和管理	重新确认变更控制流程，确保变更有效的被跟踪，在与客户干系人进行范围确认时之前，一定要先由项目经理确认是否有遗漏之后，签名确认
范围确认	在范围确认的时候，发现有些需求没有做彻底	没有进行需求跟踪，导致有些需求缺失	导入需求需求跟踪矩阵，来跟踪需求实现
范围控制	没有有效的范围管理，造成了二次变更	范围控制存在问题，对范围控制不够	对项目范围的变更进行有效的控制和评估
范围控制	出现范围蔓延的情况	没有定义需求变更控制过程	定义需求变更控制的过程，同时在组织中任命临时的CCB来承认需求的变更
范围控制	变更实施的不够彻底，一个需求少对应了一个模块	在实施变更之前没有对变更请求进行充分的分析和论证	对需求的影响进行全面的评估和论证
范围控制	变更请求的管理出现混乱状态	只记录了需求，没有对需求进行跟踪和管理，也没有走需求变更流程	对每一项需求严格按照需求变更控制流程执行，并跟踪需求的实现情况
控制范围	客户方重复提出需求，一些已经实现一些还没实现	没有对需求进行很好的管理，配置管理没有做好	完善配置管理，建立变更管理流程

第六章 进度管理的问题对策

领域	问题	原因	对策
控制进度	项目进度产生1周以上的偏差	不可预见的事情发生	根据合同的工期索赔事项，与甲方谈判是否可以调整里程碑日期
控制进度	项目进度产生1周以上的偏差	项目参与者的工作失误	进度压缩的六种方法
控制进度	项目进度产生1周以上的偏差	工期计划方面的不足，盲目确定工期目标	启动变更流程，重新估算工期及确定范围，与甲方谈判是否可以调整里程碑日期
控制进度	各个活动工作包的进度只有0%和100%	各个活动工作包的进度把握不够细致，团队成员进度意识不足	重新修订进度管理计划，确定进度数据记入的方式和频度
控制进度	为了挽回进度，省掉了一些原本必要的文档	必要的文档当然不能省略	补上必要的文档
控制进度	增加尽可能多的项目人员来挽回进度	不合理，增加人员不一定可以挽回进度	进度压缩的六种方法

第七章 成本管理问题对策

领域	问题	原因	对策
估算成本	活动的估算成本不够准确	自己对对业务理解不够充分	让成员成员一起参与成本的估算，同时增加了WBS词典的说明内容，以方便更好的估算
控制成本	成本出现超支，进度落后的情况	部分工作效率低下，出现返工	给团队成员培训质量成本的意识，以及成本质量进度之间的相互制约关系，提倡一次把事情做对做好就是最好的节约成本方式，采用自动化工具，自动Build工具

第八章 质量管理的问题对策

领域	问题	原因	对策
规划质量管理	质量管理计划过于简要，对日常的质量管理工作无指导性	没有制定和实施合理的，可操作的质量管理计划，或使用进度计划代替了整个项目管理计划	重新根据实际情况，科学制定了质量管理计划，并进行了评审
规划质量管理	将检查测试作为项目质量保证的唯一方法	质量管理经验不足，在质量管理中没有采用合适的工具技术和方法	与SQA及其他干系人充分检讨质量管理尤其是质量保证的方式方法，经过评审后写入到质量管理计划当中
规划质量管理	制定质量管理计划时，无法很好的设定质量测量指标	高层领导对质量重视不足，项目缺乏质量标准和质量规范，没有建立项目的质量保证体系	建立项目的质量管理体系，包括制定可行的过程规范和质量目标，质量标准，并争取到高层领导的支持
规划质量管理	仅向用户提交测试的报告，没有向客户提交全面的质量管理进展的报告	除了测试没有采用有效的工具与技术，制定质量管理计划	重新修订质量管理计划，避免将检查测试作为项目质量保证的唯一方法
质量保证	团队成员反映质量保证活动没啥效果，反而增加了他们的负担	质量保证人员经验不足	在无法确保有经验的人员轮换的前提下，对目前的人员进行了质量培训，同时联系SQA人员改进了过程改进计划
质量控制	在结合测试阶段，测试找到的Bug数量比预期低很多	测试过程阶段安排不合理，软件系统测试时间不足	重视软件项目的测试环节，采用合理的方法进行充分的测试
质量控制	可交付成果在用户验收时发现有质量问题	技术方案设计没有进行质量评审	实施质量评审环节，评审测试是否充分且有效
质量控制	团队成员经常出现返工	没有注意可交付成果的质量	确立质量标准，培训质量成本的意识
质量控制	客户反映验收时出现质量问题	测试不够充分	最好有专门的测试团队进行测试，如果没有专门的测试团队进行测试的话，开发团队也可以，但是不要开发人员自己测自己的模块，在测试过程中，既要测试正常的测试用例，你要设计异常的测试用例

第九章 人力资源管理的问题对策

领域	问题	原因	对策
规划人力资源管理	项目团队中某某说负荷过重	项目角色职责是否制定还不够合理	如果有人符合过重，需要找人代替，解决负载平衡的问题
规划人力资源管理	有项目团队反映自己的职责还不够清晰	没有进入角色，定位错误	事先沟通，并对相应人员进行明确要求，明确角色的轻重缓急，促使尽快转换角色
规划人力资源管理	团队职责定义模糊，给人力资源获取增加了困难	没有完整识别人力资源所需的数量，种类和任职条件	在项目早期进行项目人力资源的规划，明确岗位设置，工作职责和协作关系
组建项目团队	项目成员缺乏相应开发经验和能力	没有事先制定岗位的要求，职责和选人的标准	重新选出合适的人才，通过其他手段确保人才
组建项目团队	招募不到合适的团队成员	没有建立人力资源获取和培养的稳定机制	建立稳定的人力资源获取和培养的机制
建设项目团队	新人较多，开展项目困难	新人缺乏培训和全面的跟踪和监控	开展项目培训，同时注意平时对人员的培养
建设项目团队	团队成员富有才干，但很难合作，气氛不积极	没有建立一个充分能有效发挥能力的一个团队	进行项目团队的建设，加强团队沟通，建立合作氛围
管理项目团队	因为变更请求导致工作分配负荷不均匀，进而发生冲突	没有进行有效的冲突管理	做好项目的冲突管理
管理项目团队	某些成员的绩效发生大规模波动	XY理论的过度使用，出现资源超负荷，缺乏团队间沟通所致	与项目组成员保持良好的沟通，并通过团队建设活动，来激励团队
建设项目团队	项目例会人员没有到齐过，而且会议出现迟到现象	开会意识不强	建立奖励与惩罚机制
管理项目团队	核心人员离职	团队成员激励不够，人文关怀不足	需要设置AB角色来配置
管理项目团队	在例会上意见相左，团队成员出现吵嘴冲突	团队成员职责不明确	冲突管理的五种方法
管理项目团队	团队成员对发生的错误相互推诿	成员之间职责不清导致	重新定义大家的职责，使用RACI矩阵
管理项目团队	项目成员进度报告时，言过其实	沟通存在问题且没有一个考核的机制	建立一个公平公正的绩效考核机制
管理项目团队	项目经理遇到问题，无法找人倾述	组织架构有问题，或者没有PMO	增加人文关怀，增加沟通渠道

第十章 沟通管理问题对策

领域	问题	原因	对策
规划沟通管理	客户反映项目绩效的邮件没有价值	沟通管理计划做得不够详细，没有对团队成员的沟通需求和沟通风格进行分析	分析干系人的沟通风格，从而改善相应的沟通方式并更新沟通管理计划
管理沟通	客户反映获取的信息失真	信息传递滞后，不够及时	及时的信息分发，加强沟通，让客户了解项目的具体真实情况，并采用一些沟通模版等
控制沟通	发现团队成员对需求把握不够准确	没有或极少与客户进行直接沟通	加强沟通，注重沟通技巧，建立融洽的合作气氛
控制沟通	开会经常超过预定时间，对沟通成本大，影响整体项目成本	开会效率低下	导入开高效会议的做法
识别干系人	采购工作绩效信息不足，采购出现问题	干系人登记册没有包含采购外包的人员	重新识别项目干系人，并修订沟通管理计
规划沟通管理	沟通管理计划存在不合适与项目	沟通管理计划由项目经理一个人制定	重新修订项目沟通管理计划，并邀请团队成员一起制定和评审计划
规划沟通管理	针对不同的干系人没有提交不同的信息	缺乏对项目干系人沟通需求和沟通风格的分析	实施干系人沟通需求和沟通风格的分析，并重新修正沟通管理计划
管理沟通	没有对沟通情况进行记录	对消息的分发做好记录归档工作	对沟通信息进行归档统计
控制沟通	客户管理层对该项目也有些不满，他们认为每天浪费了大量时间看了一些无用的信息	控制工作做得不好，没有对存在的沟通问题及时进行解决	做好沟通控制工作，必要时提出变更申请
控制沟通	项目成员抱怨：例会目的不明，时间太长，效率太低	会议不够高效	开展高效会议

第十一章 风险管理问题对策

领域	问题	原因	对策
规划风险管理	没有在识别风险之前制订风险管理计划	对于风险管理的认识存在偏差	制定风险管理计划
识别风险	没有考虑推新产品可能的风险	没有对这个风险进行详细的识别	进行风险的在评估，基于风险的评估基础上再决定是否要导入新产品
识别风险	没有识别出能识别的所有风险	在风险识别过程中，缺少干系人参加	风险识别需要全员参与，对于团队成员进行培训以提高相应风险意识
定量风险分析	不清楚风险发生可能对项目目标所造成的影响	没有针对高风险进行定量的风险分析	对于高风险实施定量风险的分析
规划风险应对	来自团队外部的风险没有应对	对于风险管理的认识存在偏差	来自团队外部的风险制定应对计划
规划风险应对	风险未发生时没有实施应对	风险应对措施大多数情况是在风险发生之后才实施，风险未发生往往不实施	重新制定风险应对计划，制定了风险的应急应对计划
控制风险	没有考虑推新产品可能的风险	对其风险的定性和定量分析实施不够充分	基于风险的评估基础上再决定是否要导入新产品
控制风险	提前结束了风险管理过程	哪怕风险清单中的风险全部关闭，都不能提前结束风险管理过程	继续实施风险的监控及风险再评估

第十二章 采购管理问题对策

领域	问题	原因	对策
规划采购管理	没有编制采购计划便开始匆忙采购实施	没有编制采购管理计划，仅仅列出了采购清单，无法对采购过程进行全面的管理	对采购进行规划，制定采购管理计划
规划采购管理	对于采购什么供应商提出了较多的问题	采购工作说明书没有充分详细的编写	详细编写采购工作书，并在实施采购时召开投标人会议，让所有供应商都对采购什么取得一致的认识
规划采购管理	没有做自制外购分析就决定采购	没有自制外购分析	对于采购的东西最先开始就实施自制外购分析
规划采购管理	合同签订的价格高于市场价格	合同签订前没有进行充分的调查，尤其是没有调研采购产品的市场价格，以及潜在供应商的资信情况	规划采购的时候一定要对采购商品进行市场调查
实施采购	选择的供应商存在问题，以最低价选择了供应商	在实施采购过程中，没有对潜在供应商进行有效的选择	需要对潜在供应商进行筛选；对供应商进行认真调查
实施采购	实施采购存在问题，没有询价比较和谈判等过程就签订了备件采购合同	项目经理采购管理经验不足	对潜在供应商进行认真调查，活用卖方建议书
实施采购	采购合同存在问题，对相关违约责任没有定义清楚	在签订合同时没有就违约索赔进行很好的定义	签订合同时和供应商谈判合同索赔的事项，并写入到合同当中
实施采购	采购时预付了全部采购款项给供应商	签订合同的时候存在问题	在签订合同的时候就约定支付款项的规则；在控制采购过程中采用支付系统这个工具支付款项
实施采购	在采购实施合同时，发现供应商的货物存在质量问题	合同条款不严谨，没有就产品的型号、质量等进行严格的约定，合同中的付款条件没有产品质量验收的约束，缺少对合同交付物必要的质量检验和付款条件的把控	向供应商明确质量要求；并变更合同
实施采购	以最低价选择了供应商	缺乏完善的评标标准	建立供方选择标准
采购控制	备件采购存放不规范，对采购的备件没有进行不合格的控制，导致出现异常等质量问题	缺乏对采购的控制	定期确认库存情况，确认库存环境，入库前对质量进行监测，采购产品验证合格了以后，进货检验记录单作为入库的条件

第十六章 变更管理问题对策

过程	问题	原因	对策
变更申请	产品的变更历史无法追溯	对用户的变更要求未进行记录，对可交付成果物的变更情况无法掌控	实施变更流程
变更初审	在后期产生变更工作的失误，来源不明的需求	变更请求没有经过充足的分析，也没有获得批准	实施变更流程
变更实施	变更失败的时候无法准确地还原	在修改过程中，没有进行版本管理	实施变更流程
变更评审	没有保证变更是否已经顺利正确的实现	修改完成后，没有进行充分的验证和评估	实施变更流程
通知干系人	对于某个变更，项目干系人的工作之间出现不一致的情况	修改完成后，修改的内容没有和项目干系人进行沟通	实施变更流程

附录1：风险登记册的一个例子

风险No	风险项目	产生原因	应对措施
01	没有正确理解业务问题	项目干系人对业务问题认识不足，计算起来过于复杂，不合理的业务压力，不现实的期限	用户培训，系统所有者和用户的承诺与参与，使用高水平的系统分析师
02	用户不能恰当的使用系统	没有和组合战略相互结合，对用户没有做足够的解释，帮助手册编写的不好，用户培训工作做得不够	用户的定期参与，项目的阶段交付，加强用户的培训，完善信息系统的文档
03	决策者拒绝需求变更	固定的预算，固定的期限，决策者对市场和技术缺乏正确的理解	变更管理，应急措施
04	对工作的分析和评估不足	缺乏项目管理经验，压力过大，对项目工作不满意	采用标准技术，使用具有丰富经验的项目管理师
05	人员流动频繁	不现实的工作条件，较差的工作关系，缺乏对职员的长期期望，行业发展不规范，企业规模小	保持好的职员条件，确保人与工作匹配，保持候补，外聘，行业规范
06	缺乏合适的开发工具	技术经验不足，缺乏技术管理准则，技术人员市场调研或对市场的理解有错误，研究预算不足，组织实力不够	预先测试，教育培训，选择替代工具，增强组织实力
07	缺乏合适的开发与实施人员	对组织架构缺乏认识，缺乏中长期人力资源规划，组织不重视技术人员的技术，行业人才紧缺	外聘，招募，培训
08	使用了过时的技术	缺乏技术前瞻人才，轻视技术缺乏预算	延迟项目，标准监测，前期研究，培训
09	缺乏适合的开发平台	乏远见，没有市场和技术研究，团队庞大陈旧，难以转型	全面评估，推迟决策

附录2：案例万金油

1. 没有对于发生的问题进行充分的沟通
2. 没有对风险进行高效的管理
3. 合同条款太过于泛泛而，合同条款一般越细越好
4. 团队成员的工作需要进行统一的协调

附录3：其他的一些心得

1. WBS根据自己的情况进行分解不对，需要结合项目的实际情况来；
2. 需求文件是需要甲方签字确认的
3. 销售经理的过度承诺；销售经理没有事业道德；需要明确项目的验收标准
4. 需求评审会议一定要甲方参与
5. 要求项目组成员严格按照计划去实施项目；很难做到
6. 在开发阶段对质量进行严格把关；说明缺少对于质量的规划
7. 投标文件肯定优于招标文件。所以我们要根据投标合同来制定相应的开发计划。
8. 项目技术人员发现有更简单可行的方法可以完成项目，说明之前技术可行性做的不够。
9. 专人做专事，需求验证最好由需求管理人员来做；
10. 初步可研是可以省略的，详细可研必须实施；
11. 投标文件很好写，但也需要商务部门一起去写；
12. 绩效报告要切合实际，不要为了赢得项目而去瞎报告项目进展；
13. 分包合同签订之前需要甲方同意，还应该确定分包供应商是否具备相应的资质；
14. 项目的试运行由业主方进行；
15. CCB可以是兼职人员，因为它不是作业机构，其他职责不能兼职；
16. 制定开发计划时，一定要先有整体的里程碑计划；
17. 在采购管理中，如果需要预付大部分项目款项，那么就有就需要注意采购的风险；
18. 乙方公司被合并，公司被注销时，之前的合同依然有效；
19. 人员离职，调离岗位需要特别注意配置管理工作，比如人员的工作文档是否已经提交
20. 客户的变更请求不要记录在备忘录中，因为它不是正式文档；