-
立项管理-案例常见问题
- 立项申请应由(建设方)甲方(非承建方,即乙方)的上级主管单位,而非甲方总经理批准。
- 做完初步可以行研究就立马上马。
- 未做详细可行性研究就生成可行性研究报告
- 可行性研究报告未经评审
- 仅根据项目符合国家政策就判断项目肯定要上马,判断依据过于单一
- 可行性分析的申请金额比申请下来的金额超过了上下10%的浮动,还继续使用,没有重写
- 可行性分析的申请金额比申请下来的金额没超过了上下10%浮动,但没补充内容
- 投标由软件工程师负责不合适,缺少相关经验(专人专事)
- 仅从技术角度分析项目可行不全面,需要综合考虑经济、技术、社会等因素。
- 投标文件不能单独完成,需要比较有经验的各领域专家共同参与编写
- 未编写项目建议书
- 未进行项目评估,或项目评估自己做。
- 没有进行系统的可行性分析,没有进行多方案比较。
- 调研不充分,没有调研大规模应用的案例。
- 没有调研国家政策是否允许。
- 未进行项目论证
-
整体管理-案例常见问题
- 没编写、发布项目章程
- 没编写项目管理计划
- 执行过于随意,没按计划进行
- 没进行项目监控、没有管理好项目知识
- 没走变更控制程序
- 没做好收尾工作
- 项目章程是项目经理发布的
- 一个人编写项目管理计划
- 计划没经过评审
- 项目章程内容不全
- 计划内容不全
- 项目已经变更,计划未更新
- 没做好各子计划的统一协调,可能导致项目计划不符合项目实际情况
- 缺乏项目整体管理的思想
- 项目计划缺少相关分计划,如质量计划、沟通计划等
- 项目管理计划制定比较简单,不足以支持整个项目对所需过程的指导和管理
- 公司缺乏对项目的指导和监控
- 选择的软件开发生命周期模型不适合项目
- 缺乏阶段性的评审,从而未能及时发现问题
- 启动工作未按照公司管理流程执行
- 项目管理办公室对项目监督不力,没有及时发现项目中存在的问题并予以指导
- 项目章程
- 项目管理计划
- 执行与指导项目管理工作
- 执行过于随意,没按计划进行
- 公司缺乏对项目的指导和监控。
- 项目经理没人支持,感觉迷茫缺少PMO
- 管理项目知识
- 没有管理项目知识
- 没有形成经验教训登记册
- 没有合理运用相关的工具和技术
- 项目监控和整体变更控制
- 没进行项目监控。
- 没走变更控制程序。
- 变更控制程序缺少部分的步骤。
- 缺少CCB。
- 项目成员不走变更流程,直接修改项目工作内容。
- 变更发生之后,不做处理。(项目经理没尽责)
- 监控不力,(只到。才发现/。。时)
- 项目收尾
- 没做好收尾工作(项目一结束立即就解散团队)
- 没有甲方的同意,签字,项目经理就进行收尾工作。
- 没有验收报名,甲方没有在验收报名签名。
- 收尾的时候没有做经验总结
-
范围管理-案例常见问题
- 没做规划范围管理
- 没做需求收集工作
- 没进行范围定义
- 没进行创建WBS
- 没做范围确认
- 没做好范围控制
- 范围管理计划、需求管理计划是1个人编写的
- 没召开需求评审会,没确认需求
- 范围说明书内容不全
- 没有与各干系人对需求进行详细分析,只是在对客户需求的初步了解后就开始实施。
- 不能只参照类似项目的范围说明书,需要根据本项目情况进行编写
- 范围说明书没经过评审
- 不能单独一人对项目进行分解,而要让项目组成员也参与进来
- 范围管理没做好,导致范围出现蔓延
- 一个人编写了范围说明书不对
- WBS没有经过相关干系人的确认
- 范围确认存在问题,导致WBS中定义的功能没有开发
- 闭门造车式地开展需求调研与项目范围说明书的编写工作,没让相关干系人参与进来
- 没有编制WBS和WBS词典,以形成权威的范围基准。
- 没有进行范围管理计划的评审
- WBS最好可以分解到4-6层
- 存在镀金行为
- 对需求估计不准确,资源估算不足
- 需求评审没有客户参与,可能导致最终对需求不能达成一致,设计文件没有经过正式评审,可能导致设计文件有较多的错误
- 缺乏项目范围管理的思想
- 一个工作只能由1个人负责
- 工作包的大小应该介于8/80之间
- 没包含外包出去的模块
- 没包含项目管理工作
- 一个下层属于多个上层了,有交叉从属人力资源管理,选用没用管理经验但专业能力强的人做项目经理,没进行培训。
-
需求方面的问题:
- 对客户(或用户)的需求获取不充分
- 没有按照规范的需求开发与需求管理的流程及内容开展需求工作
- 缺乏需求定义环节,没有定义出需求规格说明书
- 缺乏需求验证环节,没有请客户代表一起进行需求评审
- 没有制定范围和需求管理计划
- 没有求得干系人对需求的一致理解
- 没有求得干系人对需求的承诺
- 没有有效地管理需求变更控制
- 没有有效维护对需求进行跟踪管理
- 没有及时识别项目工作与需求之间的不一致性
-
进度管理-案例常见问题
- 没进行规划进度管理
- 没进行活动定义
- 没进行活动排序
- 没进行历时估算
- 没制定进度计划
- 没做进度控制
- 加班会增加成本,影响质量
- 并行工作会增加风险
- 增加资源有时可能压缩工期有限
- 制定进度计划的方法不合理,没有预留一定的缓冲时间。
- 项目进度计划不合理
- 计划未经过评审就付诸实施
- 不能一人来制定进度计划,并且没有从项目实际出发来制定进度计划,而根据合同规定的时间来制定的进度计划可能不符合项目实际情况
- 控制进度的工作做得不好
- 缺乏进度管理的思想
- 制定工作计划时,没考虑资源日历,导致有冲突
- 在压缩工期的情况下,没有考虑新增加开发人员的可用性
- 未经过评估情况下随意将原来系统开发时间压缩
- 关键里程碑点没有获得相关干系人的签字确认
-
成本管理-案例常见问题
- 没进行成本规划
- 没进行成本估算
- 没进行成本预算
- 没进行成本控制
- 1个人编写了成本管理计划
- 成本管理计划没经过评审
- 成本估算不准确
- 成本预算不准确
- 没采用相关工具进行成本控制
- 赶工导致成本超支了
-
质量管理-案例常见问题
- 没有制定可行的质量管理计划并积极实施
- 没做管理质量,管理质量没有考虑设计环节
- 没做质量控制
- 没有全面的质量管理进展情况报告
- 质量保证过程中缺乏QA的参与
- 质量控制环节缺失,例如评审和测试
- 测试方法不当或不充分
- 测试控制的流程不对,或未进行质量控制就进行了范围确认
- 项目经理用人错误,小李没有质量保证经验
- 应加强项目过程中的质量控制或检查,不能等到工作产品完成后才检查
- QA发现问题应与当事人协商,如果无法达成一致要向项目经理或更高级别的领导汇报,而不能自作主张
- 在质量管理中,没有与合适的技术手段相结合
- 对程序员在质量意识和质量管理的培训不足
- 没有严格执行公司完善的质量管理体系;
- 质量职责分配不合理
- 质量管理计划内容不全
- 在规划质量管理的时候应该同步制订过程改进计划,质量测量指标、质量核对单,并同步更新项目文件
- 项目经理认为质量管理中他是配合的角色,认识错误公司高层对质量管理认识不足,不重视质量管理
- 没有指定专门的质量管理人员
- 缺少质量标准和质量规范
- 没有建立质量保证体系
- 质量控制做得不到位。
- 未审计质量要求和质量控制测量结果
- 质量管理计划不应由小张一个人制定
- 质量管理计划应经过评审
- 质量管理计划的制定没有考虑项目实际情况
- 质量管理的工具利用比较单一
- 存在走过场问题,没有深入地评审
- 测试工作中在测试用例、测试方法、测试人员及测试环境等方面存在问题
- 项目经理在项目质量管理方面的经验欠缺
- 测试过程的阶段安排不合理,软件系统的测试时间不足
- 体系建设应全员参与,不应由质量部门单独负责体系文件编制
- 体系应结合企业自身特点设计,不能照搬其它公司的文件或经验
- 质量部门应全程参与项目的质量管理和体系运行,不能只检查结果
- 代码被修改后没有及时进行回归测试并请干系人确认
- 没有按公司的质量管理体系要求来进行项目的质量管理,团队成员没有质量意识;
- 没有安排专职的项目质量管理人员;
- 没有建立质量保证体系,没有QA或QA不独立于项目组织或经验不足
- 只是凭经验进行检查工作,而没有按质量的标准进行检查
- 在质量检查中发现问题后没有及时解决,没有达到质量检查的效果
- 质量控制做的不到位,检查工作颗粒度不一
- 缺少对项目质量管理工作和监督指导
- 对团队成员质量意识和质量管理方面的培训不足
- 测试人员应该纳入项目团队管理,不应该请办公室职员代劳
-
资源管理-案例常见问题
- 规划资源管理
- 没有规划资源管理
- 资源管理计划项目经理一人制定,没有全员参与
- 资源管理计划内容不全面,有遗漏
- 质量工程师编写资源管理计划是不对的
- 资源管理计划应该各干系人参与,而且还需要经过评审
- 估算活动资源
- 没有做估算活动资源
- 资源估算过于简单,没有准确估算出项目中的团队资源和实物资源
- 资源估算内容不全
- 由项目经理一人进行资源估算,没有全员参与
- 没有采用合适的工具和技术
- 获取资源
- 招聘人员时的考核指标不应该仅仅是设备维修经验,还应该注重能力的考查
- 团队成员应该有冗余,防止因事假、病假造成其它成员的超负荷工作
- 人员任命方面存在问题,任命的项目经理虽然研发能力强,但项目管理经验不足
- 成员水平参差不齐,项目团队组建的人员是从各个组别中找出空闲的人员,需要根据实际情况组建团队
- 用人不当,不应选新毕业生做质量保证
- 缺乏团队领导经验,事必躬亲的做法不对
- 实物资源采购价格过高,没有多方询价对比
- 实物资源获取方式不合理,没有全部获取到
- 获得到的资源种类和数量不全
- 建设团队
- 没做团队建设
- 团队的组成人员尽管富有才干,但是却很难合作
- 项目团队的职责分配不清楚,没有建立RAM责任矩阵
- 团队的气氛不积极,造成项目团队成员的士气低落
- 人员流动过于频繁
- 兼职过多,精力和时间不够用,顾此失彼
- 没有进入管理角色,定位错误,疏于对项目的管理
- 新人缺乏培训和全程的跟踪和监控
- 项目团队成员能力不足
- 项目经理应该给予必要的帮助和辅导,加快团队成员的成长
- 绩效管理方面存在问题,没有及时对加班成员进行激励
- 团队成员没有明确的考核和评价标准,考核规则不明确,需要明确标准
- 建设团队可能不合理,考虑不充分,导致需要远程办公
- Y型的管理风格没有与切实可行的规章制度相结合
- 钱某的管理风格没有与直接领导的管理风格相协调。
- 管理团队
- 控制资源
- 没做控制资源
- 没有对资源使用情况进行监控或监控周期过长
- 资源在不再需要时候没有做释放,导致成本超支
- 资源分配不合理
- 出现资源相关问题时没有通知相应干系人
- 没有分析出影响可以导致资源使用变更的因素
- 在变更实际发生时没有对其进行管理或没有走变更流程
- 规划资源管理
-
沟通/干系人管理-案例常见问题
- 没进行规划沟通管理
- 没做管理沟通
- 没做监督沟通
- 没进行干系人识别
- 没进行规划干系人参与
- 没做管理干系人参与
- 没做监督干系人参与
- 没有或极少与客户进行直接沟通,合作氛围不够
- 没有对团队成员的沟通需求和沟通风格进行分析
- 沟通方式单一
- 项目执行过程中未能进行及时有效的沟通(或建立有效的沟通机制)
- 沟通管理计划不能一人制订
- 干系人识别不全,遗漏了重要干系人
- 没有对沟通情况进行记录
- 监督沟通工作做得不好,没有对存在的沟通问题及时进行解决
- 沟通管理存在问题,导致客户对项目很不满并投诉,并且没有将相关项目绩效数据发送给项目管理办公室
- 与客户发生了争执,沟通管理有问题
- 独自编制干系人清单不妥
- 干系人沟通方式单一,只采用电子邮件方式
- 管理沟通不力,对于员工的诉求,应私下解决问题,不应在大会上公开说
- 监督沟通不力,采取强迫手段中止员工的诉求,导致后续的冲突升级
- 与高层沟通不力,未得到高层领导的认同。
- 周报内容不全
- 月度例会粒度太粗
- 甲方没有对各部门的需求进行统一的组织和管理
- 缺乏与客户清晰的、统一的接口,与客户沟通不是很有效
- 公司其他职能部门支持或协作不够
- 缺乏良好的沟通能力和沟通技巧
- 对项目干系人的需求了解不细致。
- 项目缺乏阶段沟通与阶段评审
- 每周例会应该采取会议的形式进行沟通。
- 每周例会还包括项目潜在风险的评估、项目团队人力资源协调等内容。
- 方案评审会议没有通知相关领导与客户等重要干系人
- 开发技能培训应该要明确培训时间
- 项目交流会应该采用会议形式。
- 项目启动应召开项目启动会议,而不是项目交流会。
- 方案评审应该包括客户、外包、领导等干系人。
- 项目结束的时候还应召开项目总结会议。
- 沟通管理计划中缺少干系人的沟通需求
- 沟通管理计划缺少针对沟通信息的描述,包括格式、内容、详尽程度
- 沟通管理计划中缺少负责沟通的具体人员
- 沟通管理计划表中缺少沟通频率
- 每周工作例会应使用会议方式,而不是谈话
- 项目阶段性总结是重要的阶段审查,应通过正式会议方式更合适,而不是电子邮件
- 方案评审会应包括客户等需要对方案确认的干系人
- 软件开发技能培训应明确时间安排和负责培训的人员、培训内容
- 项目启动应召开正式的项目启动会,而不是交流会
- 项目结束时应召开项目总结会
- 规划沟通
- 不应该由负责研发的小陈制定沟通管理计划,工作安排不合理,用人不当。
- 制定沟通管理计划没有结合项目实际情况,只参考了以往的文件制定。
- 沟通管理计划不够详细,不够完善。
- 制定沟通管理计划后没有经过评审。
- 项目经理对沟通管理经验不足
- 管理沟通
- 项目沟通会不应该由客户召集。
- 会议应该要定时召开,案例中没有明确开会时间。
- 每次开会,不应该临时安排参会人员,应提前通知安排。
- 召开会议前,应提前准备会议议题,
- 开会应当注重效率,不要延伸无关内容
- 未能及时与客户沟通,引起客户不满
- 监督沟通
- 沟通结果未能形成相关记录文件
- 控制沟通过程没有邀请专家参与
- 没有提出变更申请,没有组建CCB变更控制委员会对变更进行确认
- 变更没有书面记录,只是电话通知了变更实施者
- 变更过程中没有监控
-
风险管理-案例常见问题
- 没进行规划风险管理
- 没做风险识别
- 没做定性风险分析
- 没做定量风险分析
- 没做风险应对、没有做实施风险应对
- 没做监督风险
- 对项目的风险认识不足
- 自己负责各项应对措施不妥,各风险应对措施的实施应责任分配到人
- 没有处理好外部因素(天气)和内部因素(团队)带来的风险,缺乏有效的应对措施。
- 风险管理计划编制存在问题,独自一人完成而没有邀请项目组其他成员参与。
- 不能仅凭个人的经验进行风险识别,而要与项目组成员一起参与。
- 风险识别不够详细,只识别出了主要风险,没有识别出所有风险。
- 监督风险做的不好,导致风险没有及时发现。
- 风险应对措施制订不合理
- 没有进行风险再识别
- 识别不全面,风险识别过程应该是反复的过程
- 仅仅参照以前的项目模板编制风险管理计划
- 不能仅凭个人的经验进行风险的识别
- 风险管理计划没有经过项目组讨论直接签字下发实施,缺乏沟通,也导致项目中的实际问题与计划的偏差较大。
- 实施风险应对不理想,监控不到位
- 监督风险和应对措施都是各成员按各自理解进行安排。应该在充分沟通的前提下统一进行风险应对和管控。
- 员工缺乏风险意识
- 依据自己经验制定应对计划不妥,应依据定性风险分析的风险值开展定量风险分析排序后,制定风险应对计划
-
采购管理-案例常见问题
- 没做规划采购
- 没做实施采购
- 没做控制采购
- 没做结束采购
- 在项目采购过程中,项目经理片面相信甲方的推荐,没有真正发挥自身在合同管理中的职责,而在被检查出问题后,又没有能够积极主动地采取措施,而是推卸责任
- 未进行充分的自制或外购分析
- 未审核投标代理机构的资质
- 未审核投标方的资质
- 招标过程中修改了招标文件,却只进行了电话沟通
- 选择最低价的并不一定是最好的,可能缺乏完善的评分办法
- 开标时间不符要求。开标应在招标文件确定的截止时间的同一时间公开进行
- 评标专家委员会成员缺少经济、技术类专家,要求是5人以上单数,技术、经济类专家占2/3
- 投标文件的密封应有投标人或代表检查,不应由代理机构检查
- 供应商的获取方式存在问题
- 设备到货验收存在问题
- 监督合同的执行过程存在问题
- 控制采购过程中相关文档和往来凭证管理存在问题
- 库房管理(环境等)存在问题
- 招标未公示
- 中标候选人超过3个
- 中标公示结果少于3天
- 投标截止时间存在问题,依法必须进行招标的项目,自招标文件开始发出之日起至投标人提交投标文件截止之日止,最短不得少于二十日
- 招标代理机构拒绝投标人投标文件修改存在问题,投标人在招标文件要求提交投标文件的截至时间前,可以补充、修改或者撤回已提交的投标文件,并书面通知招标人
- 接受迟到的C公司投标文件存在问题,在招标文件要求提交投标文件的截止时间后送达的投标文件,招标人应当拒收
- 没有对中标候选人进行排名
- A公司直接决定D公司中标存在问题,招标人应当确定排名第一的中标候选人为中标人
- A公司公布中标结果,并向D公司发出了中标通知书存在问题,中标人确定后,招标人应当向中标人发出中标通知书,并同时将中标结果通知所有未中标的投标人。
- B公司向招标代理机构询问中标结果,招标代理机构以保密为由拒绝告知,需要将中标结果通知所有未中标的投标人
- A公司与D公司签署了商务合同存在问题,招标人和中标人应当自中标通知书发出之日起三十日内,按照招标文件和中标人的投标文件订立书面合同
- D公司将项目的某重要工作分包给了另一家公司存在问题,只能将非关键、非主体工作进行分包
- D公司直接分包项目存在问题,中标人需按照合同约定或者经招标人同意。
-
合同管理-案例常见问题
- 没有做好签订合同之前的调查工作,合同签订过于草率
- 合同没有制定好,缺乏明确清晰的工作说明或更细化的合同条款
- 没有采取措施,确保合同签约双方对合同条款的一致理解
- 合同中缺乏相应的纠纷处理条款
- 对于签订总价合同的风险认识不足
- 合同中可能未对工期、质量和项目目标等关键问题进行约束
- 合同中缺少必要的项目需求描述及违约责任约定
- 合同执行过程中没有做好记录保存工作(或合同档案管理不规范)
- 缺少事先约定的合同变更流程。
- 合同中对项目的维护和保养责任约定不明确,应当明确约定项目的维护责任、期限及相关费用的支付方式
- 合同中对合同履行地没有详细的约定,应当明确约定合同履行地
- 合同条款不严谨,没有就产品的型号、质量等进行严格的约定,合同中的付款条件没有产品质量验收的约束,缺少对合同交付物必要的质量检验和付款条件的把控
- 在项目执行过程中,项目经理发现了问题,没有及时采取措施,对合同进行变更,将可能的影响降到最低
- 合同条款中的验收标准存在问题
- 缺乏合同管理的意识
-
配置管理-案例常见问题
- 没编写配置管理计划
- 没进行配置识别
- 没进行配置控制
- 没进行配置状态报告
- 没进行配置审计
- 没进行发布管理与交付
- 修改完成后未进行验证
- 对用户的要求未进行记录
- 对变更的请求未进行足够的分析,也没有获得批准
- 在修改的过程中没有注意进行版本管理
- 项目经理兼任配置管理员,精力不够,无法完成配置管理工作;
- 变更控制委员会组成成员不合理
- 项目中没有建立基线,导致需求、设计、编码无法对应;
- 配置管理计划不应由CCB制定
- 基线变更流程缺少变更验证(或确认)环节
- 对配置管理工具没有进行有效评估
- 没有将变更可能造成的影响告诉变更提出方。应该对变更提出方施加影响,确认变更的必要性,确保变更是有价值的
- 没有对变更实施进行监控,没有对变更作记录并形成文档,造成变更内容无法追溯
- 直接在受控库中增加修改权限
- 没有统一的版本管理机制,各版本不可追溯,导致重要版本丟失
- 没有对配置库进行很好的分类管理
- 变更管理没有走流程或没有规范的变更流程。
- 项目发生变更时没有及时更新项目计划
- 没有很好的配置管理系统
- 变更结束后要通知相关影响人员,而不仅仅只项目经理确认
- 甲乙两人不能同时修改错误
- 变更没有记录文件
- 开发库与产品库的内容均不完整,且文档更新很不及时
- 项目经理严重缺乏配置管理的意识与经验
- 不能删除配置项
- 配置管理意识不足
- 没编写可行的配置管理方案
- 变更发布应交由CMO完成
-
变更管理-案例常见问题
- 未提交书面变更申请,项目经理没有按照变更管理的流程要求制定变更规则。
- 变更控制委员会组成成员不合理,应该包括客户代表,最好是高级管理人员,并明确分工
- 几乎所有变更都被批准和接受,说明CCB没有严格控制项目变更申请的提交,没有认真审核;
- 应该对变更因素施加影响,积极沟通,确认变更的必要性
- 没有进行变更后的评审,对变更造成的影响没有进行分析。
- 没有将变更可能造成的影响告诉变更提出方(或对应的干系人)。
- 没有严格按照变更控制流程进行变更管理。
- 没有对变更作记录并形成文档,造成变更内容无法追溯。
- 变更批准后,没有及时更新相应的项目计划和文件,导致内容不一致
- 变更结果没有进行正式验证,未得到客户的确认
- 是否接受或拒绝变更,不应该全部由项目经理(或某个人)决定;
- 项目变更后没有相应的变更合同。
- 客户需求发生变化时,应该由项目经理进行变更影响评估,而不是由其他人进行。
- 对于变更请求,任何人不能直接进行修改,应该由CCB(变更控制委员会)决策,同意修改后,由项目经理安排相关人员进行修改。
- 没有对变更影响作评估以及对变更方案的论证。
- 没有成立CCB(变更控制委员会)。
- 缺乏对变更过程的监控措施。
- 没有对变更的效果作评估。
- 没有变更文件
- 变更问题与措施:
- 未制定标准的变更管理流程
- 未书面记录变更;
- 未充分评估变更影响;
- 未成立CCB(CCB未包括客户)
- 未及时更新项目管理计划及文件;
- 未及时与干系人沟通;
- 未验证和监控变更;
- 应对措施:
- 建立规范的变更控制流程;
- 书面申请和记录变更;
- 应充分评估变更影响;
- 应建立CCB,包含客户等干系人;
- 及时更新项目计划和文件;
- 及时与干系人沟通变更影响和结果;
- 变更后要验证和监控变更;