十大管理领域可能的问题与解决举措

熟读吧，根据案例中出现的情况，使用不同的话术

可研过程中可能出现的问题

• 项目经理的技术经验不足
• 没有正式、书面的新产品研发项目建议书就开展可行性研究工作
• 新产品研发的可行性研究工作不充分，尤其缺少技术可行性分析和论证
• 研发过程中对人才缺乏、竟争对手等带来的风险缺乏充分的分析，没有合理有效的应对方案
• 没有新产品的初步设计方案就开始研发工作
• 新产品的需求和技术指标不应由领导把关，应进行外部评审
• 在项目启动前缺少对项目成本的估算或成本估算工作未到位
• 可行性研究报告缺少必要的内部论证或外部评估环节
• 没有制订综合、全面的项目管理计划，进度计划不能代替项目管理计划，领导的指示不能代替项目管理计划
• 项目发生进度延误的可能性时未及时调整或更新进度计划并与领导及相关各方沟通
• 前期立项工作中人员参与不充分，缺少关键技术人员和财务人员

整体管理可能的问题

• 项目管理计划不应由一人制定，应有项目组参与。
• 项目计划缺少相关分计划，如质量计划、沟通计划等
• 制定进度计划的方法不合理，没有预留一定的缓冲时间。
• 项目计划缺少评审和审批环节。
• 没有处理好外部因素（天气）和内部因素（团队）带来的风险，缺乏有效的应对措施。
• 项目发生变更时没有及时更新项目计划。
• 应识别受设备到场所影响的活动，对于不受影响的活动不应推迟进行。

软件项目失控的可能问题

• 需求不明确，即需求过多、需求不稳定、需模棱两可或需求不完整等。
• 不充分的计划和过于乐观的评估
  • 工作责任范不明确，WBS 与项目组织结构不明确或者不对应，各成员之间的接ロ不明确，导致一些工作根本无人负责；
  • 每个开发阶段的提交结果定义不明确，中间结果是否已经完成、完成了多少模不清，以致项目后期堆积了大量工作；
  • 开发计划没有指定里程碑或检查点，也没有规定设计评期：
  • 开发计划没有规定进度管理方法和职责，导致无法正常进行进度管理：
  • 对工作量的重要性认识不足：软件开发经常会出现一些平时不可见的工作量，如人员的培训时间、各个开发阶段的评审时间等，经验不足的项目经理经常会遺：
  • 出于容户或公司上层的压カ在工作量估算上予以妥协，例如客户威胁要用工数更少的开发商，公司因经营困难必须削减费用、缩短工期，最后只能妥协，寄布望于员工加班；
  • 设计者过于自信或出于自尊心问题，对一些技术问题不够重视；
  • 过分相信经验，没有具体分析就认为此次项目差不多，却没有想到此次项目有可能规模更大、项目成员更多且素质差异很大，或者项目出自于一个新的行业。
• 采用新技术，或关心创新而不关心费用和风险
  • 技术无法扩展
  • 技术是错误的解决方案
  • 技术不具有要求的功能性等。
• 管理方法缺乏或不恰当。
• 性能问题。
• 团队组织不当
  • 项目团队过小，所分配的技术人员水平达不到特定项目的要求；
  • 项目团队缺少资源人员，从而设计能カ不足：
  • 没有对分包商的设计能力仔细评价。
• 人际因素
  • 开发商与客户的关系
  • 销售人员与技术人员的关系
  • 项目管理者与开发人员的关系等。

范围管理可能问题

• 没有挖掘到全部隐性需求,缺乏精确的范围定义
• 没有有效的范围管理,造成二次变更
• 对范围控制不足
• 没有和客容户进行需求确认
• 没有制定范围管理计划或项目管理计划
• 变更结果没有得到容户的确认。
• 项目范围说明书内容不全面(或者项目范围定义不充分)
• 没有及时评估容户提出的变更要求对项目带来的影响并与容户及时沟通
• 变更不应由项目经理审批,应有CCB审批
• 项目变更实施前没有及时变更合同
• 缺少范围确认环节(或项目需求、设计等没有得到用户的正式评审)
• 范围控制存在问题

范围管理应对措施

• 项目范围进行清晣定义，并根据定义对工作进行分解，制定WBS
• 对项目进行合理估算，对工作量有量化的把握
• 对项目范围进行有效控制
• 重新定义项目范围必须得到高层和容户的确认
• 进行沟通管理，协调多个项日干系人之间的矛盾

需求变更的可能问题

• 没有按照严谨的变更控制流对整个需求变更做完整的记录和跟踪(对于需求变更请求没有记录、没有对变更进行正式的评审批准、对于变更的结果没有验证)
• 对需求变更可能造成的影响进行全面的评估和分析(只分析了需求变更对于工期的影响)
• 需求变更后没有修改项目管理计划并重新评审(项目经理不应口头布置任务，同时里程碑的调整没有通知相应的管理层)
• 配置管理工作没有做好(没有对需求文件和设计文件进行修改，并升级相应版本，相应的模块編码的修改也没有进行版本控制)
• 变更结果没有跟容户沟通(需求变更实施完成后,没有让客户对最终结果进行确认)

进度管理可能问题

• 团队成员没有及早参与，需求分析耗时长，要早期参与进项目
• 经验不足，进度计划制定不准，没有采取有效的历时估算方法和网络计划技术，制定进度计划
• 没有考虑项目期间特定时期会对进度产生影响
• 増加资源有时可能压缩工期有限，1项任务10个人做，和10个人做一个项目的效果不一样

解决方案

• 増加人手，聘请更有经验的人员，或找兼职人员

• 加班

• 并行

• 重新估算后面的工期

• 加强沟通,减少变更

• 加强控制，避免返工

• 外包

• 加强沟通，先完成关键需求

• 关注关鍵路径，在关键路径上加资源

• 关注里程碑

• 加强进度与成本、风险、质量等知识点的协调

• 向公司中请増加资源，或使用经验丰富的员エ

• 优化网络图，重排活动之间的顺序，压缩关键路径

• 临时加班(赶工)，尽可能补救耽误的时间或提高资源利用率

• 将部分阶段的工作改为并行，并进行内部流程的优化

• 变更原来的进度计划。根据上一阶段的绩效，对后续工作重新评估，修订计划，并征得项目干系人的同意

• 加强同项目千系人的沟通

• 加强对交付物、项目阶段工作的及时检查和控制，避免后期出现返工

• 尽可能调配非关键路径上的资源用于关键路径上的任务

• 优化外包，采购等环节，并全程监控。

成本管理可能问题

• 没写成本管理计划
• 估算不准确
• 预算不准确
• 没做好成本控制
• 成本观念淡薄
• 指标没有量化

项目质量管理可能问题

• 没有制定可行的质量管理计划并枳极实施
• 没有全面的质量管理进展情况报告
• 沟通方式单一或不全面，容易误导用户，导致用户不必要的担心
• 质量保证过程中缺乏QA的参与
• 质量控制环节缺失，例如评审和测试
• 测试方法不当或不充分
• 测试控制的流程不对,或测试安排的紧张，或末进行质量控制就进行了范围确认
• 没有进行质量保证
• 检查频率的设定有问题。
• 应加强项目过程中的质量控制或检査，不能等到工作产品完成后オ检查
• QA发现问题应与当事人协商，如果无法达成一致要向项目经理或更高级别的领导汇报，而不能自作主张。
• 在质量管理中，没有与合适的技术手段相结合
• 对程序员在质量意识和质量管理的培训不足
• 职责分配不清楚
• 项目经理在项目质量管理方面的经验欠缺
• 进度计划制定的不合理(或进度计划安排过于紧张)
• 需求分析、系统设计阶段的质量控制可能不到位、缺少评审环节
• 测试过程中配置管理工作未到位
• 项目缺乏质量标准和质量规范
• 没有建立项目的质量保证体系
• 在质量管理中，没有采用合适的工具、技术和方法

应该怎么解决或提高项目质量

• 严格执行公司的质量管理体系规范工作流程
• 制定质量管理计划
• 执行质量保证计划
• 调配相关资源(如:人、财、物等)加强后续质量保证工作
• 加强后期的质量控制和测试，应安排相对独立的测试人员
• 提前加强产品交付后的客户服务和维护工作;
• 加强沟通
• 建议必要时修改质量基准争取以最小的代价获得用户认可。
• 参与开发项目的软件过程描述。评审过程描述用于保证该过程与组织政策、内部软件标准、 外界标准及项目计划的其他部分相符:
• 按质量管理计划实施质量检查，检查是否按标准过程实施项目工作。及时完成项目过程中的质量检查，在毎次进行检查之前应检查清单，并将质量管理相关情况予以记录:
• 依据检查的情况和记录，识别与相应软件开发过程的偏差，分析问题原因，发现尚可能存在的问题，并与当事人协商，争取解決问题。问题解決后要进行验证，如果无法与当事人达成一致，应按问题上报流程报告项目经理(或更高级别的领导)，直至问题解决
• 定期给项目干系人分发质量报告:
• 协调变更控制和变更管理,并帮助收集和分析软件度量信息等;
• 为项目组成员提供质量管理要求方而的培训或指导等。
• 强有力的领导
• 建立组织级项目管理体系
• 建立组织级质量管理体系,包括制定可行的过程规范和质量目标、质量标准
• 建立项目级激励制度
• 理解质量成本
• 提高项目文档质量
• 发展和遵从成熟度模型
• 应安排独立于项目组的有经验的质量保证人员负责质量保证工作
• 对软件开发的过程实施质量軍计
• 注重对需求和设计等开发过程文件的技术评审工作
• 应加强需求和设计方案评审和质量控制工作
• 应加强项目实施过程中的配置管理工作
• 提出合理有效的质量整改措施(如建议的纠正措施、对项目计划可能的更新等)

人力资源可能问题:

• 缺乏足够的项目管理能カ和经验:
• 兼职过多，精力和时间不够用，顾此失彼:
• 没有进入管理角色，定位错误，疏于对项目的管理
• 新人缺乏培训和全程的跟踪和监控
• 没有进行良好 的冲突管理

应对措施

• 事先制定岗位的要求、职责和选人的标准,并选择合适的人选:
• 对工作进行全面估算，如果有人负荷过重，需要找人代替，解决负载平衡问题
• 事前沟通并对相应人员明确要求，明确角色的轻重缓急，促使尽快转换角色
• 上级应该注意平时对人员的培养和监控
• 对项目团队进行有效的冲突管理
• 采用合适的团队建设手段，消除团队成员间隔
• 明确项目团队的目标及项目组各成员的分工
• 建立清晰的工作流程和沟通机制
• 建立明确的考核评价标准。
• 鼓励团队成员之间建立参与和分享的氛围。
• 制定有效的激励措施

团队组建常见问题

• 招募不到合适的项目成员:
• 团队的组成人员尽管富有オ千，但却很难合作
• 团队气氛不积极，造成项目团队成员的士气低落
• 项目团队的任务和职责分配不清楚
• 人员流动过于频繁
• 没有能够建立人カ资源获取和培养的稳定机制
• 没有完整识别项目所需的人力资源种类、数量和相关任职条件
• 没有建立一个能充分、有效发挥能力的团队
• 没有清楚地分配工作职责到个人或人力单元

应对措施

• 建立稳定的人力资源获取和培养机制
• 在项目早期，进行项目的整体人力资源规划，明确岗位设置、工作职责和协作关系
• 进行项目团队建设，加强团队沟通，建立合作氖围
• 根据项目团队成员的工作职责和目标，跟踪工作绩效，及时予以调整和改进，提升项目整体绩效

沟通管理和干系人管理可能问题

• 缺乏沟通，合作氛围不够
• 没有对团队成员的测通需求和沟通风格进行分析
• 没有开一个高效的会
• 沟通方式单一
• 没有冲突管理
• 内部管理有问题，监管不力
• 没有或极少与容户进行直接沟通
• 现场管理制度执行不力
• 总包与分包责任不清
• 容户获取的信息失真，总包推卸责任
• 客户自己本身的问题，包括资金、管理水平等
• 可能监理工作没到位

应对措施

• 及时信息分发，加强沟通，让客户了解项目具体情况
• 注重沟通技巧，建立融治的合作气氛
• 分析成员的沟通风格,从而采用相应的沟通方式
• 多种沟通方式
• 采用一些沟通模板
• 加强冲突管理
• 采用一些沟通模板
• 加强冲突管理
• 多供应商的沟通
• 解決冲突，包括千系人对项目期望之间的冲突、资源冲突等
• 做好干系人分析，调研各集成商的沟通需求
• 周期性的沟通
• 突发事件的协调
• 发挥总包的牵头和监理的协调作用
• 对共用资源可用性进行分析，引入资源日历
• 建立健全项目管理制度并监管其执行
• 采用项目管理信息系统

风险管理可能问题

• 没有正确理解业务问题
• 用户不能恰当的使用系统
• 拒绝需求变更
• 对工作的分析和评估不足
• 人员流动
• 缺乏合适的开发工具
• 缺乏合适的开发与实施人员
• 缺乏适合的开发平台
• 使用了过时的技术

原因:

• 项目干系人对业务问题的认识不足、计算起来过于复杂、不合理的业务压力、不现实的期限
• 信息系统没有与组合战略相结合、对用户没有做足够的解释、帮助手册编写的不好、用户培训工作做的不够
• 固定的预算、固定的期限、决策者对市场和技术缺乏正确的理解
• 缺乏项目管理经验、工作压力过大、对项目工作不满意
• 不现实的工作条件、较差的工作关系、缺乏对职员的长远期望、行业发展不规范、企业规模较小
• 技术经验不足、缺乏技术管理准则、技术人员的市场调研或对市场理解有误、研究预算不足、组织实力不够
• 对组织架构缺乏认识、缺乏中长期的人カ资源计划、组织不重视技术人オ的技术工作、行业 人才紧缺
• 缺乏远见、没有市场和技术研究、团队庞大陈旧难以转型、缺乏预算
• 缺乏技末前瞻人オ、轻视技术、缺乏预算

解决措施

• 用户培训、系统所有者和用户的承诺与参与、使用高水平的系统分析师
• 用户的定期参与、项目的阶段交付、加强用户培训、完善信息系统文档
• 变更管理、应急措施
• 采用标准技术、使用具有丰富经验的项目管理师
• 保持好的职员条件、确保人与工作匹配、保持候补、外聘、行业规范
• 预先测试、教育培训、选择替代工具、増强组织实力
• 外聘、招募、培训
• 全面评估、推迟决策
• 延迟项目、标准检测、前期研究、培训

配置管理问题

• 没有项目管理经验,不适合项目经理的职位。
• 项目经理兼任配置管理员，精力不够，无法完成配置管理工作
• 范围管理有问题
• 版本管理没有做好，没有统一的版本管理机制，各版本不可追溯，导致重要版本丢失
• 项目中没有建立基线，导致需求、设计、编码无法对应:
• 没有做好变更管理，项目中的变更不可控
• 配置管理计划不应由CCB制定
• 基线变更流程缺少变更验证(或确认)环节
• CCB成员的要求不应以人数作为规定，而是以能否代表项目干系人利益为原则
• 该公司可能没有版本管理規定或甲乙没有统一执行版本規定
• 变更审查应该提交CCB軍核
• 变更发布应交由CMO完成
• 甲乙两人不能同时修改错误
• 没有做配置管理规划，缺少完整的配置管理方案
• 缺少配置管理及变更管理流程，没有配置管理委员会
• 试运行的系统版本没有及时建立基线并让各业务部门正式确认:
• 配置权限管理存在问题:
• 人员职责不清晰，没有CMO(配置管理员)的参与并控制配置权限
• 开发人员没有按照变更流程的要求修改系统及代码
• 开发人员修改代码后没有及时修改文档，导致两者不一致
• 代码被修改后没有及时进行回归测试并请干系人确认
• 文档管理存在问题，没有做好文档的交接、更新、变更管理工作
• 配置管理过程中没有做好相应的记录;
• 新人的培训工作没有跟进到位。

改进措施

• 从项目整体出发,做好配置管理规划
• 定义合理的配置管理流程,规定项目中出现变更的处理办法
• 与各方干系人达成共识，组建配置管理委员会
• 识别配置项，并为配置项建立惟一标识，保证其可追溯
• 建立配置基线,使重要配置项处于受控状态
• 定期提效配置状态报告,改进配置管理方法
• 组建配置管理方案设计小组
• 仔细了解单位的情况、历史、人员、组织形式等
• 对配置管理工具进行有效评估
• 制定全面有效的配置管理计划，包括建立配置管理环境、组织机构、成本、进度等，在配置管理计划中详描述，建立示例配置库、配置标识管理、配置库控制、配置的检查和评审、配置库的备份、配置管理计划附属文档
• 梳理变更脉络，确定统一的最终需求和设计:
• 梳理配置项及其历史版本
• 对照最终需求和设计逐项分析现有配置项及历史版本的符合情况
• 根据分析结果由干系人确定整体变更计划并实施
• 加强整体版本管理。

变更中常见的问题

• 没有遵循变更控制流程
• 没有书面的记录
• 应该有CCB进行审批
• 没有及时更新项目管计划。

合同管理里可能会出现的问题

• 合同没定好，没有就具体完成的工作形成明确清晰的条款
• 甲方没有对需求及其变更进行统一的组织和管理
• 缺乏变更的接收/拒绝准则
• 项目干系人及其关界分析不到位，范围定义不全面、不准确
• 甲乙双方对项目范围没有达成一致认可或承诺
• 缺乏项目全生命周期的范围控制
• 缺乏客户/用户参与
• 甲方无法进行跨部门协调
• 实施范围不清楚、验收标准不清楚
• 项目沟通有问题
• 客户不验收或拖延验收、签字、容户有情绪、不付款
• 客户对项目质量信心不足、售后没有承诺等
• 缺少违约责任相关条款
• 缺少变更处理及索赔相关条款

可能的收尾的问题

• 没有充分做好验收前的准备，或软件系统没有达到验收前的标准，或软件还存在计划修复的缺陷，这些缺陷未经修复和确认便进入正式验妆环节。
• 在验收过程中末根据变更控制流程对软件进行修改，导致文档与软件不一致
• 软件更新后没有对文档进行变更便交付给客户
• 项目验收未正式完成，未签署验收报告变更进行了项目总结
• 项目收尾过程不完整，缺少正式的项目总结环节，不能只编写总结报告
• 项目总结报告末能反映项目的实际情况
• 缺少项目评估或审计环节验收中存在的主要问题
• 没有进行有效的系统测试
• 没有准备好相应的文档
• 没有按照规范的流程进行验收
• 与客户的沟通不良

外包(采购)的害处

• 无法达到预期的成本降低目标
• 以前内部自行管理领域的整体品质降低
• 未和服务供应商达成真正的合作关系
• 企业雇主和服务提供商在服务品质和酬劳议题上有争议
• 无法借机开拓出满足客户新层次需求和符合弹性运作需求的机会。

如何做好外包(采购)

• 慎重的选择合格的外包商
• 互相同意对方的承诺
• 需要经常保持交流
• 根据合同的承诺跟踪承包商实际完成的情况和成果，也就是说要多沟通，多监控。