进度计划风险的完整列表
日期:2008-07-18 | 作者: Allen-
计划编制风险
- 计划、资源和产品定义全凭客户或上层领导口头指令,并且不完全一致。
- 计划是优化的,是“最佳状态”(但不现实,只能算是“期望状态”)。
- 计划忽略了必要的任务。
- 计划基于使用特定的小组成员,而那个小组成员其实指望不上。
- 在限定的时间内无法建成已定规模大小的产品。
- 产品规模比估计的要大(代码行数、功能点、与前一产品规模的百分比)。
- 工作量大与估算数(按代码行数、功能点、模块等)。
- 进度已经拖延的项目在重新估计时过于优化或忽视项目历史。
- 过度的进度压力造成生产率下降。
- 目标日期提前,但没有相应地调整产品范围或可用资源。
- 一个任务的延迟导致相关任务的连锁反应。
- 涉足不熟悉的产品领域,花费在设计和实现上的时间比预期的要多。
-
组织和管理
- 项目缺乏一个有凝聚力的最高领导人。
- 由于前期乏力,项目长时间被搁置。
- 解雇和削减开支导致项目小组能力下降。
- 仅有管理层或市场人员进行技术决策,导致计划进度延长。
- 低效的项目组织结构降低生产率。
- 管理层审查、决策的周期比预期时间长。
- 预算削减打乱项目计划。
- 管理层做出了打击项目组织积极性的决定。
- 非技术的第三方的工作比预期延长(预算批准,设备采购批准、法律方面的审查、安全保证等)。
- 计划性太差,无法适应期望的开发速度。
- 项目计划由于压力而放弃,导致开发混乱,低效。
- 管理层强调英雄主义,而忽视客观确切的状态报告,这会降低发现和改正问题的能力。
-
开发环境
- 设施没有及时到位。
- 设施到位,但不配套(如没有电话、网线、家具、办公用品等)。
- 设施拥挤、杂乱或者破损。
- 开发工具未能及时到位。
- 开发工具不能期望地那样有效,开发人员需要时间创建工作环境或者切换新的工具。
- 开发工具的选择不是基于技术需求,不能提供计划要求的性能。
- 新开发工具的学习期比预期的长,内容繁多。
-
最终用户
- 最终用户坚持新的需求。
- 最终用户对于最后交付的产品不满意,要求重新设计和重做。
- 最终用户不买进项目产品,无法提供后续支持。
- 最终用户的意见未被采纳,造成产品最终无法满足用户期望,而必须重做。
-
客户
- 客户坚持新的需求。
- 客户对规划、原型和规格的审核/决策周期要比预期的要厂。
- 客户没有或不能参与规划、原型和规格阶段的审核,导致需求不稳定和耗时的变更。
- 客户答复的时间比预期长(如回答或澄清需求相关问题的时间)。
- 客户坚持技术决策而导致进度计划延长。
- 客户对开发进度管理过细,导致实际进展变慢。
- 客户提供的组件无法与开发的产品匹配,导致额外的设计和集成工作。
- 客户提供的组件质量欠佳,导致额外的测试、设计和集成工作,以及额外的客户关系管理工作。
- 客户要求的支持工具和环境不兼容、性能差或者功能不完善,导致生产率降低。
-
承包商
- 承包商没有按承诺交付组件。
- 承包商递交的组件质量低下无法接收,必须花时间改进质量。
- 承包商没有买进项目开发需要的工具,进而无法提供需要的性能水平。
-
需求
- 需求已经成为项目基准,但变化还在继续。
- 需求定义欠佳,而进一步的定义会扩展项目范畴。
- 添加额外的需求。
- 产品定义含混的部分比预期需要更多的时间。
-
产品
- 错误发生率高的木偶快需要比预期更多的测试、设计和实现工作。
- 校正质量低下不可接受的产品,需要比预期更多的测试、设计和实现工作。
- 在一个或多个新兴领域推广计算机技术使得计划进度的延长不可预期。
- 由于软件功能的错误,需要重新设计和实现。
- 开发额外不需要的功能(镀金)延长了计划进度。
- 要满足产品规模与速度要求,需要比预期更多的时间,包括重新设计和实现的时间。
- 严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作。
- 要求与其他系统、其他复杂系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作。
- 要求在不同操作系统下运行将花费比预期更长的时间。
- 在不熟悉或未经检验的软件、硬件环境中运行产生未预料到的问题。
- 开发一种对组织全新的模块将比预期花费更长时间。
- 依赖正在开发中的技术将延长计划进度。
-
外部环境
- 产品依赖政府规章,而规章的改变将是不可预期的。
- 产品依赖草拟中的技术标准,而最后的标准将是不可预期的。
-
人员
- 招聘人员所花时间比预期的长。
- 最为先决条件的任务不能按时完成(如培训、其他项目的完成、工作许可证)。
- 开发人员和管理层之间关系不佳导致决策缓慢,影响全局。
- 项目组成员没有全身心投入项目,进而无法达到需要的产品性能水平。
- 缺乏激励措施,士气低下,降低了生产能力。
- 缺乏必要的规范,增加了工作失误与重复工作。
- 某些人需要更多时间适应不熟悉的软件工具和环境、硬件环境、编程语言。
- 项目结束前,人员离开团队。
- 项目后期加入新的开发人员,额外的培训和沟通降低现有成员的效率
- 项目组成员不能有效地一起工作。
- 由于项目组成员间的冲突,导致沟通不畅、设计不佳、接口错误和额外的重复工作。
- 有问题的成员没有调离项目组,损害了项目组其他成员的积极性。
- 项目的最佳人选未能加入项目组。
- 项目的最佳人员已加入项目组,但因政治或其他原因未能合理使用。
- 没有找到项目急需的具有特定技能的人。
- 关键任务只能兼职参与。
- 项目人员不足。
- 任务的分配与人员技能不匹配。
- 人员工作的进展比预期的慢。
- 项目管理人员怠工导致计划和进度失效。
- 技术人员怠工导致工作遗漏或质量低下,工作需要重做。
-
设计和实现
- 设计过于简单,无法确定主要事件,并导致重新设计和实现。
- 设计过于复杂,导致一些不必要工作,影响实现效率。
- 设计质量低下,导致重复设计和实现。
- 使用不熟悉的方法,导致额外的培训时间,并重犯前期使用这种方法时导致的错误。
- 产品采用低级语言来实施(如汇编),导致生产率比预期的低。
- 一些必要的功能无法使用现有的代码和库实现,开发人员必须使用新的库或者自行开发所要的功能。
- 代码和库质量低下,导致需要额外的测试、错误修正或重做。
- 过高估计了增强型工具对计划进度的节省量。
- 分别开发的模块无法有效集成,需要重新设计或重做。
-
过程
- 大量的纸面给偶工作导致进程比预期的慢。
- 进程跟踪不准确,导致无法预知项目是否已落后于计划进度。
- 前期的质量保证行为不真实,导致后期的重复工作。
- 质量跟踪不准确,导致无法得知影响进度的质量问题。
- 太不正规(缺乏对软件开发策略的标准的遵循),导致沟通不足,质量问题和工作重做。
- 过于正规(教条地坚持软件开发策略和标准),导致过多耗时无用的工作。
- 向管理层撰写进程报告占用开发人员的时间比预期的多。
- 风险管理粗心,导致没有发现重大的项目风险。
- 软件项目风险管理花费的时间比预期的多。