1 概述
1.1 项目管理体系
1.1.1 体系基础
项目管理体系是建立在公司 ISO 9000 质量管理体系基础上,结合 PMI 项目管理框架与 CMMI 能力成熟度模型,针对项目实施状态,对一些重点环节进行细化,加强重点环节的监控,明确职责,提高过程效率,从而为项目成功交付提供保障。
1.1.2 体系结构
项目管理体系分为管理过程和工程过程两大类别,其中工程过程又按项目类型分为软件开发、运维服务、咨询服务、集成服务、整体分包 5 个部分。
管理过程主要依据 PMI 项目管理框架从项目阶段(启动和策划、执行与监控、结项与收尾)和项目管理领域(范围、进度、成本、质量、人员、沟通、风险、采购)两个维度进行定义。
工程过程主要依据项目生命周期中的关键过程及其关键产出物进行定义。
1.2 项目经理职责
1.2.1 目标
- 管理项目目标及项目过程,以取得客户对产品或服务以及过程最满意的评价
- 管理项目团队,使高效而愉快的工作,并获得最满意的工作体验
1.2.2 职责
- 确定项目目标和项目计划;
- 确定项目组织形式,确定项目人员配置;
- 遵循组织过程规范,按预期进行交付;
- 控制项目进度;
- 对项目进展中的各项过程进行监控和调整;
- 控制项目的费用和成本;
- 对项目组成员进行考核,并激励员工完成目标;
1.3 项目管理整体要求
为更好地服务于公司的战略,为客户提供值得信赖的服务和管理过程,公司要求项目交付过程的透明。项目经理应本着为公司负责,为客户创造价值的思想,实践对交付透明化的要求,通过沟通机制,向客户和公司展示项目执行的过程和能力。公司项目管理体系的建设以及管理流程的定义均围绕项目交付过程透明的核心目标,项目管理平台为透明化管理提供良好的支撑。
项目过程透明化的含义主要包括五个方面:
编号 | 内容 | 描述 |
---|---|---|
1 | 预期透明 | 1、 准确地对项目的工作量进行估算,填写范围与工作量估算;2、 通过对项目工作的理解,正确评估项目的风险和填写风险列表;3、 通过启动会议和参观,让客户了解我们的交付过程、实施方法、项目计划;4、 通过《项目经理手册》指导项目经理的日常行为。 |
2 | 控制透明 | 1、 建立项目详细进度计划,项目任务分解到每人周;2、 每天依据项目详细进度计划,对项目进行跟踪;3、 定期召开周例会;4、 及时维护项目计划基准,保证项目控制(偏差)数据的准确性,并按月进行数据报告。 |
3 | 状态透明 | 1、 每周提交《项目周报》,《项目客户周报》。2、 通过项目月度信息报告、里程碑报告及会议,充分展示项目的状态;3、 质量经理独立对项目进行过程审计,以红黄牌的形式报告项目过程状态和进展状态。 |
4 | 问题透明 | 1、 收集和跟踪项目的风险和问题,确保对问题解决措施的落实;2、 通过重大问题管理机制,使重大问题得到最及时报告和处理。 |
5 | 结果透明 | 1、 里程碑和管理结项过程,项目经理应向客户进行汇报;2、 推动事业部总经理与公司领导对客户高层的互动。 |
2 项目启动和策划
2.1 项目立项
2.1.1 指定候选项目经理
- 项目进入立项准备阶段,工程总监根据项项目情况需要指定候选项目经理人选。并采用邮件的方式通知相关管理部门,同时维护项目管理信息系统相关信息,明确候选项目经理人选。如果是销售分包项目,则客户经理需要维护项目管理信息系统相关信息,明确候选项目经理人选。
- 候选项目经理如果是初次担任项目经理则需要到相关管理部门接受岗前资格确认。
- 候选项目经理在通过岗前资格确认后方可申请项目管理信息系统相关权限。
- 候选项目经理只有在述职通过并获得任命后才转为正式的项目经理。在此之前候选项目经理暂代项目经理的权责。
输出:1) 指定候选项目经理邮件
2.1.2 编写工作说明书
- 候选项目经理可以通过使用项目投标时的项目估算文件,对招标文件、投标文件、合同谈判提出的需求进行识别与跟踪等活动来编制《工作说明书》。
- 候选项目经理在编制《工作说明书》过程中需要特别注意对于变更的处理。要严格符合本部的要求。
输出:1) 《工作说明书》
2.1.3 提交审核并发布
- 候选项目经理将编制好的《工作说明书》提交工程总监进行审核。
- 候选项目经理将最终版本的《工作说明书》发布给客户经理和质量经理。
输出:1) 发布邮件
2.1.4 审核工作说明书
- 工程总监审核候选项目经理提交的《工作说明书》并提出审核意见。
输出:1) 审核结论
2.1.5 填报项目背景及定位
- 不同的项目背景和目标,直接影响项目实施的策略,候选项目经理应与客户经理、工程总监进行沟通,从质量、进度、成本等方面,确认项目的侧重点,并确认客户满意度的要求程度,提出具体的项目目标和定位。
- 候选项目经理负责将项目基本信息录入项目管理信息系统。
输出:1) 基本信息-背景及定义
2.1.6 关键干系人分析
- 该过程目的是列出项目的关键干系人,并对干系人对项目的期望和影响力进行分析。
- 候选项目经理与客户经理、工程总监一起对客户方的干系人进行分析,确定应对的策略。
- 候选项目经理负责将关键干系人分析结果录入项目管理信息系统。
输出:1) 基本信息-干系人期待
2.1.7 确定项目假设和前提条件
- 候选项目经理与客户经理、工程总监一起对客户方的干系人进行分析,列出项目顺利执行的前提条件和假设。
- 对于可能不成立的假设,要作为风险在“识别、评估风险”过程当中列出。
- 候选项目经理负责将项目假设和前提条件录入项目管理信息系统。
输出:1) -基本信息-项目假设
2.1.8 识别、评估风险
- 候选项目经理需要与客户经理、工程总监以及技术专家沟通,对项目存在的风险进行识别,分析各个风险的发生可能性和影响力,对风险进行等级评估并制定风险应对计划
- 候选项目经理负责将识别并评估后的风险信息和应对计划录入项目管理信息系统。
输出:1) 风险和问题-风险
2.1.9 制定项目高层计划
- 候选项目经理依据项目所选定的生命周期模型,对项目的里程碑点进行标识。结合项目合同要求以及客户的需要,确定项目里程碑点的计划达成时间。过程当中工程总监以及客户经理需要参与。
- 高层计划的制定需要达到下述要求:
a) 明确各里程碑点达成的标准;
b) 对关键工作再进行阶段细分;
c) 明确里程碑的产出物和相关要求;
d) 明确关键产出物的评审计划;
e) 明确里程碑评审计划;
f) 候选项目经理负责将高层计划录入项目管理信息系统。
输出:1) 高层计划
2.1.10 范围及工作量估算
- 候选项目经理需要根据项目情况将项目范围分为功能性工作和项目管理工作,其中功能性工作可以按照项目阶段进行分解。对于范围分解需要符合下述要求:
a) 软件开发类项目:功能性工作的分解按照项目需求的分解层次进行,立项阶段要求分解到 3 级;
b) 非软件开发类项目,功能性工作按照工作说明书的项目范围进行分解,立项时要求分解到 2 级;
c) 项目管理工作立项时分解到 2 级。 - 候选项目经理还需要在范围分解的基础上进行工作量估算。具体要求如下:
a) 功能性工作:面向时间段进行分解。例如:软件开发服务类项目可以按照需求分析、设计、开发、测试、发布、维护等过程来分解;咨询服务类项目可以按照方案设计、方案评审、方案推广、验收等过程来分解;集成类项目可以按照准备、实施、验收等过程来分解;运维服务类项目可以按照计划、实施、验收等过程来分解。
b) 项目管理工作:针对每项工作做整个项目周期内的总工作量的估计,可以分别进行项目管理、配置管理、需求管理、质量管理的工作量。 - 工程总监在此过程当中需要给予指导。
- 候选项目经理负责将范围分解以及工作量估算结果录入项目管理信息系统。
输出:1) 范围-范围矩阵
2.1.11 资源估算
- 候选项目经理需要依据范围分解以及工作量的估算的结果,将各个阶段的工作量分配到不同级别、不同区域(现场、基地)、不同部门的人头上。而后需要进一步将不同级别、不同阶段的人员工作量分解到各个月份上,以便于按月进行工作量的汇总。
- 工程总监在此过程当中需要给予指导。
- 候选项目经理负责将范围分解以及工作量估算结果录入项目管理信息系统。
输出:1) 估算-资源费用估算
2.1.12 成本估算
- 候选项目经理需要依据资源估算的结果,制定项目的成本预算。
- 如果有项目分包情况,候选项目经理需要在成本估算时明确分包金额和种类(买人月分包还是其他分包)。
- 项目工程成本率要符合本部要求。工程总监在此过程当中需要给予指导。
- 候选项目经理负责将项目成本预算结果录入项目管理信息系统。
输出:1) -财务-成本
2.1.13 分包项管理
- 如果有项目分包情况,候选项目经理需要制定分包计划。其中包括:分包任务的计划开始时间、计划结束时间,分包预算等。
- 工程总监在此过程当中需要给予指导。客户经理需要参与此过程。
- 候选项目经理负责将分包计划结果录入项目管理信息系统。
输出:1) 财务-分包项管理
2.1.14 提交立项审批流程
- 客户经理在项目管理信息系统当中做审批流程提交前的准备工作,例如:调
整合同分析报告等。 - 客户经理在项目管理信息系统当中启动审批流程。
输出:1) 流程审批结果
2.2 项目启动
2.2.1 组建项目团队
- 项目经理负责组建项目团队(含外包、劳务人员等),说明项目的组织结构,使项目成员 明确在项目中的岗位职责。
- 项目经理负责在团队当中指派配置管理员来进行日常配置管理工作。对于在总部办公环境内集中办公的项目,配置管理员由资源管理部统一指派。
- 资源管理部总经理根据项目情况指派项目质量经理。
- 项目经理负责组织形成项目通讯录,列入客户、我方人员、分包及其他参与项目的各方人员及联系方式。
- 对于项目所需但是暂时不具备的资源,项目经理负责向工程总监提出申请。
- 工程总监负责在管理范围内提供协调资源的支持。如果在工程总监管理范围内资源无法满足项目需求,则由工程总监向资源管理部资源经理提出申请。
- 资源管理部资源经理根据工程总监提出的资源申请,在资源池范围内提供资源协调的支持。
输出:1) 项目组通讯录
2.2.2 制定项目制度
- 项目经理应根据项目特点编制内部项目管理制度,主要包括:作息制度、个人(小组)周报制度、财务制度等,使项目成员明确日常工作规范;
- 工程总监在此过程当中给予指导
输出:1) 项目组各项制度
2.2.3 搭建项目环境
- 项目经理应负责组织进行办公、配置、开发、测试和缺陷管理环境的部署,使其符合项目实施和公司管理的要求。
- 任何类型的项目都必须搭建配置库环境并使用其进行配置管理工作。
- 对于在总部办公环境内集中办公的项目,都必须使用资源管理部统一的缺陷管理平台。
- 在项目组搭建配置、测试和缺陷管理环境的过程当中,资源管理部相关负责人给予必要的指导。
输出:1. 项目组工作环境
2.2.4 组织召开内部启动会
- 项目经理负责组织召开公司内部的项目启动会议,会议应包括以下内容:
a) 进行项目介绍
b) 进行团队成员介绍
c) 明确项目团队组成结构和管理角色任命
d) 发布管理制度和要求
e) 确认项目实施工作正式开始 - 工程总监和资源管理部质量经理参加项目组内部启动会议。所有项目组成员都需要参加内部项目启动会议。
- 项目经理负责组织形成会议纪要并发给所有参会人员。
输出:1) 内部启动会会议纪要
2.2.5 组织内部培训
- 项目经理负责根据项目组成员的背景,有选择的组织项目组内部培训,并保留记录。培训可以包括但不局限于以下几种类型:
a) 专用工具培训
b) 业务基础知识培训
c) 项目规范培训
d) 技术规范培训 - 工程总监和质量经理在此过程当中提供必要的支持。
输出:1) 项目组内部培训记录
2.2.6 申请项目经理任命
- 工程总监需要在项目立项后 2 周内填写《项目经理任命申请表》提交管理部,申请对于候选项目经理的任命。
输出:1) 项目经理任命申请表
2.2.7 是否免述职
- 资源管理部和工程总监共同根据项目的情况判断该候选人是否可以获得免述职,并确定替代检查方式。
- 通常情况下免述职的条件和替代检查方式如下:
a) 项目签约额在 50 万以下,可以不进行会议述职,由项目工程总监和资源管理部经理进行项目计划的审核来代替;
b) 若项目经理有过类似项目的管理经验,经过工程总监和资源管理部共同确
认,可以不进行会议述职,由文档审核来代替。 - 资源管理部总经理在《项目经理任命申请表》上给出述职方式的批复并邮件发送给项目质量经理。
输出:1) 是否免述职的结果
2.2.8 通知候选项目经理准备材料
- 资源管理部质量经理负责邮件或者电话通知候选项目经理准备述职材料。
输出:1) 通知邮件
2.2.9 准备述职材料
- 候选项目经理必须仔细阅读和掌握公司的项目管理体系。
- 候选项目经理参考《项目经理述职提纲》准备《项目经理述职材料》并发给
资源管理部质量经理审核。审核通过后方可组织项目经理述职会议。 - 工程总监在此过程当中需要给予指导。
输出:1) 项目经理述职报告.PPT
2.2.10 项目经理述职
- 资源管理部质量经理负责组织项目经理述职会议。工程总监、资源管理部总经理、客户经理作为评委必须参加。
- 述职会议的过程如下:
a) 候选项目经理陈述项目基本情况,项目实施计划和措施;
b) 评委针对项目情况以及对项目经理的综合能力要求,进行提问;
c) 评委给出述职是否通过的正式结论 ,以及对候选项目经理的指导意见。
d) 由资源管理部质量经理给出书面述职反馈意见。 - 候选项目经理根据资源管理部质量经理给出的书面述职反馈意见给予答复。对于问题需要明确改正时间。资源管理部质量经理负责跟踪问题修正情况。
- 候选项目经理的述职必须在项目立项完成后一个月之内完成。
输出:1) 项目经理述职反馈
2.2.11 任命项目经理
- 资源管理部总经理根据述职会议或检查情况(免述职会),签发《项目经理任
命书》。
输出:1) 项目经理任命书
2.2.12 召开现场启动会
- 项目经理负责组织或协助组织召开项目现场启动会。现场启动会需要邀请客户方项目经理、接口人等相关干系人参加,同时应争取邀请到客户方重要干系人参加。工程总监、客户经理、项目团队核心成员必须参加。如果现场启动会有客户方高层参加,还需提前邀请公司内部同等级别领导出席。
- 现场启动会议的目标首先是获得客户方高层的支持,其次是管理客户的期望和提示项目风险,再者是增进客户对我方的信任程度。
- 项目经理负责组织对现场启动会做会议纪要,并把在会议上达成的共识和问题整理汇总,会后发送给与会人员。
输出:1) 现场启动会会议纪要
2.3 项目计划
1.1.1 制定高层计划
1.项目经理在项目立项过程中制定高层计划,详见“项目立项过程定义”。
输出:1) 项目视图-高层计划
2.3.1 项目过程定义
2.项目生命周期模型:项目经理根据项目特点选择项目的生命周期;纯运维、咨询和集成项目不用选择。
3.项目过程定义:项目经理按照自身特征对组织标准过程进行裁剪,得出项目定义过程,项目将按照项目定义的过程进行项目管理和工程活动。所有项目都需要进行定义。
输出:1) 项目补充计划-(项目管理过程定义+项目工程过程定义)
2.3.2 制定沟通计划
- 项目经理分析项目干系人的信息需求,制定项目的沟通计划。
- 项目经理与客户协商,确定与客户之间的沟通方式。
- 项目经理与相关领导达成一致,确定与项目领导的沟通方式。
- 项目经理需要制定与员工的沟通计划。
- 项目经理将沟通计划填写到项目管理信息系统中。
输出:1) 沟通-沟通计划
2.3.3 制定风险计划
1.项目经理对项目存在的风险进行识别,并制定相应的风险应对措施。
2.项目经理将风险识别和应对措施填写到项目管理信息系统中。
输出:1) 风险和问题-风险
2.3.4 制定评审计划
- 项目经理负责制定项目评审计划,确定项目中要进行哪些评审。
- 评审计划需要确定以下两类评审,评审方式参见同行评审过程定义。
(1) 管理评审,主要指里程碑总结会。项目管理过程中必须执行管理评审,根据高层计划中的里程碑点制定管理评审计划。
(2) 工作产品评审,主要针对各项产出物。根据项目工程过程定义确定的工作产品对应的未被裁剪的评审过程,制定此工作产品的评审计划。工作产品的评审还需要确定工作产品的检查单。
输出:1) 项目补充计划-评审计划
2.3.5 制定项目进度计划
项目经理负责制定项目进度计划。按照工作分解结构(WBS)的方式进行项目详细计划的分解。
- 对于软件开发项目,将项目功能需求的分解作为项目详细计划的分解结构是常用的方法,将每个功能的需求、设计、开发和测试作为工作任务进行时间估算和资源分配,从而构成项目的详细开发计划。
- 非开发类的项目任务,可将工作范围划分为任务。
WBS 分解原则是要分解到不能再细分为止,最底层的任务活动要直接分派到个人去完成,而且工作量应在一个人周之内。
输出:1) 项目进度计划(WBS)
2.3.6 制定培训计划
1.项目经理分析项目成员技能和项目所需要的技能,制定项目培训计划。包括对项
目组和对客户的培训。
2.项目组的培训分为组内培训和组外培训。
项目组内的培训,由项目经理组织,安排组内有相关经验的人员进行内部的培
训。
项目组外的培训,项目经理需要申请、协调外部培训资源进行。
3.客户的培训计划要参照合同要求制定。
输出:1) 项目补充计划-(培训计划)
2.3.7 制定配置管理计划
1.配置经理制定配置管理计划并得到项目经理确认。
2.项目经理负责将配置管理计划上传到项目管理信息系统中。
输出:1) 配置管理计划
2.3.8 制定质量保证计划
1.质量经理制定质量保证计划并得到项目经理确认。
2.项目经理负责将质量保证计划上传到项目管理信息系统中。
输出:1) 质量保证计划
2.3.9 制定系统测试计划
1.测试经理制定系统测试计划并得到项目经理确认。必要时项目经理组织评审测试
计划。
2.项目经理负责将系统测试计划上传到项目管理信息系统中。
输出:1) 系统测试计划
2.3.10 制定项目版本发布计划
- 项目经理负责制定项目版本发布的计划。项目版本发布计划中要确定需要发布的正式或试运行版本,包括每个版本的名称、发布时间、发布内容及对应的制作基线等。
- 项目版本计划要得到客户和工程总监批准。
- 项目经理要根据项目版本发布计划安排开发进度。
- 配置经理要根据项目版本发布计划准备配置环境。
- 测试经理要根据项目版本发布计划准备测试环境。
输出:1) 项目补充计划-(项目版本发布计划)
2.3.11 制定分包监控计划
1.项目经理与客户经理协商制定分包监控计划。
2.项目经理在项目管理信息系统中建立分包任务,填写分包监控计划。
输出:1) 分包监控计划
2.3.12 计划确认
以上各子计划必须经得到工程总监的确认。
输出:1) 计划的签字
3 项目执行与监控
3.1 项目跟踪与控制
3.1.1 日常跟踪
1.召开项目例会
项目经理定期组织召开项目例会,了解项目工作进展情况和存在的问题,对后续工作做出安排,并对存在问题明确解决方案和责任人。项目经理将会议纪要发送工程总监、客户经理和质量经理并提交到项目管理信息系统。项目例会召开时间和频度可以在项目沟通计划中确定。
2.更新项目进度计划
项目经理根据项目进度完成情况,每周将更新的项目进度计划发送工程总监、客户经理和质量经理,并将更新的项目进度计划提交到项目管理信息系统。
3.提交项目周报
项目经理每周填写将项目周报,汇报项目进展、后续计划、阶段里程碑和交付成果完成情况、变更记录及问题风险跟踪情况。发送客户、工程总监、客户经理和质量经理,并将项目周报提交到项目管理信息系统。如无特殊要求,项目周报可与客户周报合并,周报的模版可根据项目要求调整,提交频度和方式可在项目沟通计划中确定。
4.提交运维月报(运维服务类项目)
运维服务类项目的项目经理每月填写运维月报。汇报本月工作情况、本月重点工作分析及后续工作安排等,发送客户、工程总监、客户经理和质量经理,并将运维月报提交到项目管理信息系统。运维月报的模版可根据客户要求确定,提交频度和方式可在项目沟通计划中确定。
5.提交分包监控月报(整体外包类项目)
整体外包类项目的项目经理每月填写分包监控月报。汇报本月工作情况、本月重点工作分析及后续工作安排等,发送客户、工程总监、客户经理和质量经理,并将分包监控月报提交到项目管理信息系统。
输出:
- 会议纪要
- 项目周报
- 运维月报
- 分包监控月报
- 更新的项目进度计划
3.1.2 里程碑总结
- 召开里程碑评审会议
1) 项目经理根据项目评审计划中确定的里程碑评审点,编写《里程碑报告》,并准备里程碑交付成果。
2) 项目经理组织里程碑评审会议,工程总监和客户经理必须参加。质量经理可选
择参加。
3) 项目经理在里程碑评审会议上,对项目里程碑点到达时项目的完成情况、人员、成本、质量、问题和风险等方面进行汇报,并确定项目后续计划和实施策略。
4) 项目经理将评审记录及结论提交到项目管理信息系统。 - 更新基准
项目经理在里程碑评审会议完成后,根据需要更新以下基准:
1) 范围基准:如果项目范围发生变化,则在项目管理信息系统中,重新评估项目的工作量和范围,形成新的范围基准。
2) 进度基准:如果项目高层计划发生变化,则在项目管理信息系统中,更新高层计划。
3) 成本基准:如果项目成本发生变化,或成本偏差>30%,则需按照 2.5.3 变更管理中预算变更流程完成预算变更。 - 重新识别风险
项目经理在里程碑评审会议完成后,重新识别项目风险和制定应对策略,并更新项目管理信息系统。 - 项目经理将项目阶段完工证明(客户签字盖章),按公司要求提交相关部门。
输出:
(1) 里程碑报告
(2) 里程碑会议纪要
(3) 更新的范围、进度和成本基准
(4) 更新的风险
(5) 阶段完工证明
3.1.3 变更管理
- 客户提出需求变更
(1) 项目经理需按照“需求管理过程定义”中变更流程执行。 - 预算变更
1) 工程成本预算内变更:由项目经理启动预算内变更流程。工程成本预算内变更是指成本总额保持不变的情况下,进行的工程成本各科目预算间的调整;
2) 工程成本预算外变更:由客户经理启动预算外变更流程。工程成本预算外变更是指工程成本预算总额发生了变化。
3) 预算变更流程的审批要求按照财年公司规定。 - 高层计划发生变更
1) 如果是由客户提出需求变更引起的高层计划变更,项目经理需按照“需求管理过程定义”中变更流程执行,在变更被批准开始执行时,如变更涉及高层计划变更,则需在项目管理信息系统中更新高层计划。
2) 如果是其他原因引起的高层计划变更,项目经理需在完成变更后更新高层计
划。
3) 项目高层计划变更需在项目管理信息系统中,按照审批流程进行。
4) 高层计划变更,需更新范围矩阵中的工作量。 - 项目子计划发生变更:
1) 项目经理将更新的项目子计划提交到项目管理信息系统。
这里的项目子计划包括:沟通计划、评审计划、详细计划、培训计划、配置管理计划、质量保证计划、系统测试计划、项目版本发布计划和分包监控计划等。
2) 项目各子计划变更必须得到工程总监确认。 - 基线变更
项目基线发生变更,执行配置管理中关于基线变更的流程。 - 项目经理变更
- 项目实施过程中,发生项目经理变更时,原项目经理需填写《项目经理工作交
接清单》与新项目经理逐项工作进行交接,并在《项目经理工作交接清单》双
方签字确认。 - 新任项目经理需按照项目经理任命流程进行述职,述职通过后方可被任命。
- 项目经理变更时,工程总监负责与客户进行沟通。
输出:
(1) 变更申请表
(2) 变更记录
(3) 完成的变更流程
(4) 变更的计划
(5) 变更的基线
(6) 项目经理工作交接清单
3.1.4 范围管理
- 需求变化引起的范围变更
(1) 项目经理需按照变更管理流程执行变更。
(2) 项目经理需在项目管理信息系统中,更新变更记录,更新范围矩阵和工作量。 - 新里程碑开始的范围调整
(1) 在项目完成里程碑总结后,项目经理需根据确定的工作内容更新范围矩阵,重
新估计项目的工作量,并形成新的项目范围基准。
(2) 项目经理在项目管理信息系统中,更新范围基准和维护完成度矩阵。
输出:
(1) 变更申请表
(2) 变更记录
(3) 更新的范围矩阵、完成度矩阵和工作量
3.1.5 客户管理
- 关键干系人管理:项目经理对于客户方中对项目有重要影响的关键干系人,要保持良好沟通,及时准确地理解关键干系人对项目的期望和要求,并建立合理的应对策略。
- 定期的正式沟通:项目经理需按照项目的沟通计划,定期与客户召开项目例会,向客户报告项目进展情况,及时获得客户对项目相关工作的配合与支持;每周向客户提交客户周报;保留与客户会议的会议纪要。
- 客户满意度调查:项目经理需配合资源管理部的客户满意度调查,按时获取客户签字的满意度调查表。分析客户反馈意见,并以此进行客户管理的改进工作。
- 配合客户经理:项目经理需积极配合客户经理,管理客户期望、引导客户、挖掘新机会、维护良好的客户关系。
输出:
(1) 与客户的项目例会纪要
(2) 提交客户的项目周报
(3) 满意度调查问卷
3.1.6 资源管理
- 资源申请与释放:项目经理需根据资源估算,按照公司技术人员调配流程,提前向人才发展中心申请所需要的资源;提前通知人才发展中心项目要释放的人员。
- 项目人员变动:在项目成员尤其是与客户有直接工作配合的成员发生调整的时候,项目经理要提前与客户进行说明,当事人不得事前直接与客户沟通自己变动的问题。项目经理要对人员变动时的工作交接进行检查确认,以保证项目工作的延续进行。
- 员工沟通:项目经理需关注项目组人员状态,加强内部的沟通。通过日常沟通、项目例会、团队活动等形式增强士气,提高人员积极性、工作主动性。每个月保证至少与一名项目组成员进行面对面的正式沟通,记录沟通内容。
- 员工考核:项目经理需明确每个成员的工作职责与评价标准,并与员工沟通确认。按照政府 SBU 统一要求,对项目成员工作进行绩效考核。
- 员工培训:项目经理根据培训计划开展项目组内的培训活动;对新加入项目组的成员进行有效的指导。
输出:
(1) 员工沟通记录
(2) 员工考核结果
(3) 员工培训记录
3.1.7 风险管理
- 重新识别风险:项目经理需在项目的执行过程中,定期针对已识别风险,进行重新识别,并将新识别的风险登记;
- 分析和制定风险应对策略:项目经理需针对每个风险的可能性和后果,制定应对策略和行动步骤;
- 跟踪风险状态:项目经理通过周报,跟踪风险状态。
- 项目经理需在项目管理信息系统中,完成对风险的识别、描述、制定应对策略和跟踪完成状态。
输出:
(1) 更新的风险列表
3.1.8 问题与事故管理
- 项目经理需在项目管理信息系统中,完成对项目问题与事故的记录及处理过程状态的更新。
- 在项目管理信息系统中,问题与事故按以下类型分为“重大问题”和“一般问题”两类,对应的处理时间和严重等级也不同。项目经理在登记问题时,可参考选择问题分类。
重大问题分类:
(1) 重大变更:对项目范围、进度、成本产生重大变化的变更要求。在项目的《工作说明书》中要事先对重大变更作严格定义。
(2) 进度失控:进度已经滞后 20%以上
(3) 成本失控:成本已经超支 20%以上
(4) 生产事故:客户生产系统出现事故,给客户带来实际损失,或者引起客户严重不满。项目发生以上重大问题时,项目管理信息系统会按照下表要求进行消息通知和报告。
(2). 一般问题分类:非重大问题。
输出:1) 风险和问题-问题
3.1.9 分包过程监控
- 项目经理需在项目管理信息系统中,填写分包任务完成比例及分包完成情况。
- 项目经理需参照整体分包项目的“管理分包的执行”过程要求,根据分包监控计划来执行对分包商的监控。
输出:
(1) 财务-分包项管理
(2) 会议纪要
(3) 分包实施方案评审记录
(4) 分包变更申请表
(5) 分包过程问题报告
(6) 分包过程阶段或整体验收申请
(7) 分包过程重大问题或事故报告
(8) 分包阶段或整体验收后的交付物
3.2 配置管理
3.2.1 制定配置管理计划
- 项目配置管理员参照项目计划制定《配置管理计划》。
输出:1) 配置管理计划
3.2.2 审批配置管理计划
- 项目配置管理员将《配置管理计划》提交项目经理审批。
- 项目经理审批通过,进入下一环节,如未通过,需依据审批意见进行修改,直至通过。
输出:1) 审批通过的配置管理计划
3.2.3 创建配置库
- 项目配置管理员负责创建项目配置库。
输出:1) 按公司目录要求的配置库
3.2.4 配置管理基础培训
- 项目配置管理员对项目组成员提供配置管理方面的培训,包括配置管理概念、工具等基础培训。
输出:1) 培训记录
3.2.5 在工作库工作
- 项目组成员根据分配的工作任务,工作完毕检入到工作库中。
输出:1) 工作库中的工作产品
3.2.6 受控库创建内部基线
- 项目组成员将工作库待测试/评审的工作产品提交到受控库作为内部基线等待测试
/评审。 - 对于代码类工作产品,还需由项目配置管理员集成编译为可执行目标码作为内部基
线。
输出:1) 受控库中的内部基线
3.2.7 测试/评审基线
- 测试/评审人员针对待测试/评审内部基线进行测试/评审,测试/评审通过后,项目
配置管理员准备形成对外发布基线。否则通知相关责任人继续修正相应配置项。 - 针对软件开发类项目,项目配置管理员要依据《xx 版本发布计划.doc》来形成对外发布基线。
输出:1) 对外发布的基线
3.2.8 配置审计
- 项目配置管理员依据《配置管理计划》对基线进行物理审计:检查基线的完整性;
- 项目配置管理员依据《xx 版本发布计划.doc》,检查基线的内容是否与此版本的计划一致;
- 项目配置管理员进行审计完毕,在《对外版本发布签字说明》配置管理员栏签字。
输出:1) 《对外版本发布签字说明》配置管理员栏签字
3.2.9 对外发布审批
- 项目配置管理员填写《对外版本发布签字说明》中的版本信息,里面有关测试信息由测试经理填写,填写完毕,根据情况,需相关审批人都签字审批同意后,方可进入下一环节。
- 正常情况:对于正常情况送交项目组外的版本(例如包括用户测试、第三方测评、上线试运行、发布生产环境等情况),除了要有评审的测试报告或测试情况说明外,还必须具备组织级测试经理、测试经理、质量经理、项目经理的共同签字确认,方可进入下一环节。
- 异常情况:对于异常情况需要提供版本使用(例如没有达到公司内部测试标准、客户特殊要求等),测试经理要出具该版本的测试情况说明后,必须要有项目经理、工程总监的共同签字确认,方可进入下一环节。
输出:1) 完成签批的对外版本发布签字说明
3.2.10 在基线库发布基线
- 对外发布审批通过后,项目配置管理员从受控库中获取对应内部基线,将其纳入基线库中,并标识该基线。对于代码类工作产品,源码和对应可运行版本都要纳入基线库。
- 项目配置管理员发布基线通知,通知相关人员该基线已经发布,通知中会包含完成内容、获取位置等信息。
输出:
(1) 基线库已建立基线
(2) 基线发布通知
3.2.11 发布配置状态报告
- 项目配置管理员将配置状态报告发布给项目经理、项目组成员、测试人员、质量经理。
- 发布对外版本时,发布配置状态报告,其他状况不需要发布配置状态报告。
输出:1) 配置状态报告
3.2.12 提出变更申请
- 变更申请人提出对基线的变更请求,将相关内容记录到变更单中以 mail 方式发送给项目配置管理员。驱动因素为内部发现基线需要变更;非内部提出的变更,如客户需求变更等,见“项目跟踪与控制过程定义”。
- 项目配置管理员将变更相关信息记录到配置状态报告中。
输出:
(1) 变更申请的提出部分
(2) 新增的变更记录
3.2.13 评估变更
- 项目配置管理员将变更单以 mail 方式发送给 CCB 或技术负责人,针对提交的变更请求,CCB 或技术负责人评估是否实施该变更。
输出:
(1) 变更申请的评估部分
(2) 状态为已评估的变更记录
3.2.14 审批变更
- 项目配置管理员将变更单打印成纸质,由 CCB 在变更单签字审批。
- 项目配置管理员将变更状态记录到配置状态报告。
输出:
(1) 变更申请的审批部分
(2) 状态为已审批的变更记录
3.2.15 拒绝变更通知
- CCB 或技术负责人针对该变更做出的拒绝决定通知变更申请人。
- 项目配置管理员将变更状态记录到配置状态报告。
输出:1) 状态为已拒绝的变更记录
(2) 拒绝通知邮件
3.2.16 分配变更任务
- 项目经理根据变更单上的变更内容分配变更任务。
输出:1) 分配的变更执行任务
3.2.17 日常配置管理工作
- 项目配置管理员对于配置库进行日常管理,比如:疑难解答、抛错处理、日常备份等
输出:1) 备份的配置库
3.3 质量保证
3.3.1 协助召开内部启动会
1.质量经理根据公司项目管理体系的要求,协助项目经理制定项目的管理规范。
2.质量经理协助项目经理组织项目内部启动会,并参加会议。
输出:1) 内部启动会会议纪要
3.3.2 培训管理体系
1.质量经理在项目组对公司的项目管理体系不太熟悉影响到项目执行的情况下,可对项目经理和项目组开展公司项目管理体系的培训。
输出:1) 管理体系培训记录
3.3.3 协助项目经理任命
1.质量经理邮件或者电话通知候选项目经理准备述职材料。
2.质量经理向项目经理介绍项目经理述职会的目的和要求。
3.质量经理对项目经理准备述职材料提供支持,并审核述职材料,确保符合公司的规范和项目情况要求。
4.质量经理负责组织项目经理述职会议,会议形式可采用电话会议。工程总监、资源管理部、客户经理作为评委必须参加。
5.述职会议中,质量经理就项目经理对管理规范的理解进行提问,并对存在的问题提出改进意见。
6.质量经理就述职结果,邮件反馈述职意见给组织级质量经理,抄送项目经理、工程总监和资源管理部总经理。
7.如果述职会议中记录了问题,质量经理负责跟踪问题修正情况。
8.如果述职不通过或存在问题,质量经理负责后续跟踪,直到述职通过或问题解决。
9.组织级质量经理协助资源管理部总经理完成项目经理任命书签字发布。
10.质量经理按公司流程为新项目经理申请项目信息系统管理的操作权限。
输出:
- 准备述职材料的通知
- 述职材料的审核结果
- 组织召开的述职会
- 反馈的述职结果
- 项目经理任命书
3.3.4 协助制定项目计划
1.质量经理需协助项目经理和配置管理、测试经理等项目组成员制定项目各项子计划。
2.质量经理尤其需要协助项目经理完成项目过程的定义和评审计划,协助项目经理标识出所有应当生产和评审的工作产品,也应包括这些工作产品应当遵从的标准或指南。
输出:1) 项目计划
3.3.5 制定质量保证计划
1.质量经理根据项目计划,制定《质量保证计划》。
输出:1) 质量保证计划
3.3.6 审批质量保证计划
1.项目经理和高级质量经理对《质量保证计划》进行审批,如果审批通过,质量经理开始对项目执行情况进行监控,如果不通过,质量经理对《质量保证计划》进行修改,重新提交审批,直至通过。
输出:1) 质量保证计划的审批结果
3.3.7 评估过程质量
1.质量经理根据《质量保证计划》,参照《项目过程定义》和《过程检查单》对项目已定义过程的执行进行评估,完成后向高级质量经理、所负责项目的项目经理、工程总监提交《项目红黄牌检查报告》。
2.质量经理跟踪《项目红黄牌检查报告》中提到的不符合项的解决情况。
输出:1) 项目红黄牌检查报告
3.3.8 项目执行的支持
1.质量经理需推动项目经理在里程碑完成后组织召开里程碑评审会,如果该里程碑完成后五个工作日尚未召开,质量经理负责催办,如果仍得不到解决,质量经理上报给高级质量经理。
2.就监控过程中发现的项目问题和风险,如项目组自身难以解决,质量经理可协助
项目经理进行解决,必要时推动高级质量经理进行解决。
3.质量经理在项目执行过程中,需及时响应项目组对公司管理体系和管理工具的使用执行的疑问,以提高项目的过程质量。
输出:1) 里程碑会议纪要
3.3.9 收集过程改进意见
1.质量经理在日常与项目组的各种沟通过程中,收集项目组在执行过程中提出的对公司项目管理体系的改进意见,随时记录到《过程改进修改建议表》中,以作为下次体系改进的基础。
输出:1) 过程改进修改建议表
3.3.10 项目日常监控
1.质量经理需每月监控项目相关数据是否已更新,如进度数据、成本数据、风险计划、沟通计划等
2.质量经理需在版本发布之前,监控已基线化工作产品的任何更改都进行了变更申请控制,并得到 CCB 批准,然后签批版本的发布。
3.质量经理需随项目红黄牌检查对项目的阶段状态报告(例如,周例会纪要、项目周报、里程碑报告等)进行检查,检查如下内容:
检查是否报告了任务状态,是否已经明确了本周的详细的工作任务
检查是否报告了存在的问题和风险,并进行了跟踪
检查涉及支持部门的有关问题是否已经讨论并且记录在项目状态报告中
如果支持部门出现了影响项目质量和进度的延迟,质量经理要上报高级质量经理,再由高级质量经理通报相关支持部门
4.质量经理需根据项目进展情况,每月与项目基准进行比对,识别偏差 ,并对发现的问题和风险,推动解决
输出:
(1) 版本发布的签批
(2) 各种催办邮件
3) 识别的过程风险和问题
3.3.11 协助管理结项
- 质量经理在项目总结会议前,执行如下检查:
a) 所有的软件和工作产品均被客户接受
b) 检查项目结项会议报告是否已经准备就绪 - 质量经理参加项目总结会,确保《会议纪要》和《项目总结报告》提交给高级质量经理和其他部门主管。
- 质量经理对结项资料和《结项申请》进行审核,审核通过后,在《结项申请》上
签字;审核不通过,将审核意见反馈给项目经理,由项目经理负责及时修改/补
充结项资料。 - 质量经理确保审核通过的结项资料提交集团机要室以及 SBU 相关部门进行审核归档。
输出:
(1) 项目总结会会议纪要
(2) 结项申请的签字
3.4 需求管理
3.4.1 达成共识
- 项目需求负责人负责组织客户与开发方之间,针对已确认的需求达成共识。
输出:1) 客户对需求文档的签字
3.4.2 提出变更申请
- 变更提出人填写《变更申请表》的申请部分,描述变更的理由和变更的内容,并确认签字。提交申请表时需一并提供变更的原始文档或明确说明文档存放的具体路径。
- 变更提出人需将《变更申请表》提交给项目需求负责人。
输出:
(1) 变更申请表的申请部分
3.4.3 确认变更
- 项目需求负责人接收《变更申请表》,同时在项目信息管理系统中增加变更记录。
- 项目需求负责人对变更申请进行分析,若有疑问可以与客户进行沟通。
输出:1) 新增的变更记录
3.4.4 评估变更
- 项目需求负责人负责组织对变更影响的评估,在《变更申请表》上填写评估意见签字后提交 CCB。
- 项目需求负责人评估变更后,需在项目信息管理系统中更新变更状态。
输出:
(1) 变更申请表的评估部分
(2) 状态更新为已评估的变更记录
3.4.5 审批变更
- 需求变更内部审批要求,10 人天以内的变更项目经理确认,10 人天以上,20 人天以内需要工程总监确认,20 人天以上的变更需要事业部总经理确认。
- 项目需求负责人根据需求变更内部审批要求,提交需求变更单给 CCB 相关人。
- CCB 根据评估结果给出最终变更的结论,是否进行变更、变更的条件和约束等。并在《变更申请表》CCB 评审意见栏签字。
- 项目需求负责人更新项目管理信息系统变更记录的状态和审批结果。
输出:
(1) 变更申请表的审批部分
(2) 状态更新为已审批的变更记录
3.4.6 反馈客户
- 项目需求负责人将变更结论反馈给客户,由客户确认是否同意变更,如不同意,则变更流程结束。如客户同意变更则需在申请表用户确认处签字。
- 项目需求负责人在客户确认后,更新项目管理信息系统的变更记录。
- 客户确认变更后,如因变更引起项目范围变更,项目需求负责人需在项目管理信息系统中更新范围矩阵。
输出:
(1) 变更申请表的客户确认部分
(2) 状态更新为已确认的变更记录
3.4.7 执行变更
- 对于客户同意的变更申请,由项目需求负责人推动落实变更的执行工作。
- 变更执行人完成变更后,在《变更申请表》填写执行结果,修改后的配置项经过确认后提交配置库。
- 项目需求负责人在执行变更完成后,更新项目管理信息系统的变更记录。
输出:
(1) 变更申请表的执行部分
(2) 状态更新为已执行的变更记录
3.4.8 验证变更
- 项目需求负责人负责变更最终结果的验证,在《变更申请表》填写验证结果。
- 项目需求负责人负责将验证通过的配置项,通知配置管理员生成基线。
- 项目需求负责人在项目管理信息系统中,项目需求负责人更新项目管理信息系统的变更记录和完成度矩阵。
输出:
(1) 变更申请表的验证和基线部分
(2) 状态更新为关闭的变更记录
(3) 更新的完成度矩阵
3.4.9 需求跟踪
- 需求跟踪主要是通过需求各个属性的跟踪与维护,清晰、准确地报告项目需求的状态,进而为项目的各项管理决策和操作提供支持。根据需求跟踪的侧重点不同,可以分为状态跟踪和关联性跟踪:
(1) 其中状态跟踪主要是针对需求各个属性尤其是进展状态的跟踪,而关联性跟踪主要针对每项需求与其相关的设计、代码、测试案例之间的关系进行跟踪,主要是保证需求驱动设计、设计驱动编码, 在需求发生变化的时候,能很容易找到受影响的其它需求、设计及代码。
(2) 关联性跟踪又分为单项跟踪和双向跟踪,单项跟踪是指管理从客户需求到系统需求、 从系统需求到设计、从设计到编码的对应关系;双向的跟踪指不仅进行从客户需求到下游工作产品的跟踪,还要进行从下游工作产品到需求的跟踪。关联性跟踪还应该考虑业务需求对验证测试、软件需求对系统测试,架构设计对集成测试、详细设计对单元测试的横向跟踪。 - 需求的跟踪主要有两个方面,一是在每个阶段点完成时,如需求、设计、开发、测试,二是由事件触发,如需求、设计变更时进行。
- 项目需求负责人负责跟踪需求状态,在项目管理信息系统中,更新完成度矩阵。
输出:
(1) 更新的范围矩阵
(2) 更新的完成度矩阵
3.5 同行评审
3.5.1 制定评审计划
1.项目经理根据项目计划对某一工作产品制定评审计划,确定评审的对象、版本、评审方式、时间、参与人员、检查表等,并记录在《评审记录表》计划部分中。
输出:
(1) 评审记录表的计划部分
3.5.2 个人审查
- 评审人员对下面两个方面进行工作产品的审查:
检查文档的结构、时效性、可追溯性、格式规范等, 具体内容可依据《评审记录表》中的检查表 sheet 页。
与其领域相关部分内容进行阅读分析,并分别进行确认,将检查出来的问题记录在《评审记录表》“缺陷跟踪表”sheet 页中。
如果有 50%的评审人员认为该工作产品不具备召开评审会的条件,或者个人审查没有达到预期的效果(例如:大多半的评审人员都没有进行审核),评审会就需要延迟,项目经理要及时更新评审计划。
输出:
(1) 个审结论
(2) 评审记录表的缺陷记录
3.5.3 召开评审会议
- 个人审查通过后,可以召开评审会议。评审组织者可以由项目经理来指定,也可以由项目经理来担任。
- 介绍:为了保证评审会议工作的顺利进行,评审组织者在评审会上首先可以进行介绍,其工作活动主要包括向评审专家介绍评审过程和评审的形式,作者简要介绍评审对象等。
- 评审:具体评审内容可依据检查表进行。评审会议一般不要超过两个小时;评审会议中,评审组织者要控制会议进程,将参会人员的注意力放到发现问题上,而不是讨论解决方案。作者要对评审人员提出的疑问进行解答,评审结论应写在《评审记录表》“评审过程记录表”sheet 页中。
- 额外会议:如有需要可以召开额外会议。其主要是讨论评审中的一些未解决的问题,或评审过程中已经确定的问题的解决方案。项目经理将决定是否需要召开额外会议。额外会议召开的次数和时间长短由项目经理确定。
输出:
(1) 评审记录表的缺陷记录部分
3.5.4 修改问题
- 被评审对象的作者认真分析评审报告中提出的问题及改进建议,制定纠正措施并负责落实。
- 如果评审结论为“不通过”,先修改完现有的问题,再进行重新评审。重新评审本身是一次单独的评审活动,适用本过程的所有要求。
输出:1) 评审记录表的修订部分
3.5.5 跟踪验证问题
- 项目经理或质量经理跟踪问题的状态,所有修改的问题根据具体情况,需要得到项目经理或者评审人员的确认。
输出:
(1) 评审记录表的跟踪部分
3.6 项目验收
3.6.1 项目初验
- 提出初验申请
项目经理按照项目合同或者任务书的约定,当项目初验条件已经满足时,向客户提出初验的《验收申请》。申请内容至少包括:项目名称、交付物列表、建议初验时间安排等。 - 审批初验申请和成立验收组
客户接到初验申请后,审核申请内容,确认达到初验条件后审批同意,并成立项目验收组。验收组成员包括:甲方项目成员、乙方项目成员,如有必要还可以聘请外部专家。 - 提交项目验收交付物
初验申请审批并成立项目验收组后,项目经理负责按照申请中的交付物列表提交验收交付物。 - 审核项目交付物和制定验收计划
项目验收组根据申请的建议验收时间、交付物内容和项目合同要求,制定详细的初
验《验收计划》。 - 组织验收和形成结论
项目验收组根据《验收计划》开展验收工作,形成初验《验收报告》初稿及结论。在项目初验过程中,发现项目存在不符合验收标准的地方,项目经理或其指定人员应详细记录存在的问题。如果《验收报告》结论为通过,则直接转入“签发初验报告”章节。 - 修改初验项目问题
针对验收过程中记录的问题,项目经理在与客户充分沟通后,将问题分为需要解决的问题和可以遗留的问题两大类。对需要解决问题,项目经理应安排项目组进行修改和完善后提交项目验收组再次确认和验证;对于遗留问题,应与客户协调好处理的办法并在验收报告中详细记录。 - 验证问题修改
项目验收组依据初验报告提出的问题,在项目经理提出验证申请后,进行再次验证,直至关闭,并给出具体的验证结论。 - 出具初验报告
项目验收组确认所有交付物符合合同规定和项目交付物质量要求后,出具正式的初验《验收报告》。报告主要内容包括初验的结论、遗留问题、是否能进行试运行等内容。 - 签发初验报告
客户查看初验《验收报告》,确认无误后签字/盖章审批项目初验正式完成。
输出:
(1) 验收申请
(2) 验收计划
(3) 验收文档
(4) 验收报告
3.6.2 试运行
- 成立试运行组
项目初验完成后,项目进入试运行阶段。客户组织成立项目试运行组,成员至少包括:甲方项目成员、乙方项目成员。 - 制定试运行计划
项目试运行组根据项目合同/任务书要求以及初验结论,制定《试运行计划》,并按此开展试运行工作。 - 试运行实施和记录
项目经理组织项目组成员按照《试运行计划》,配合项目试运行组进行试运行准备和试运行工作。在试运行过程中发现的问题,项目试运行组必须进行记录,并协调项目组解决这些问题。 - 修改项目试运行问题
项目经理组织项目组成员针对试运行记录中提出的问题,尽快进行修改、调试和完善,并将最终修改结果反馈项目试运行组。 - 提交试运行报告
试运行期满后,项目经理根据试运行情况,编制《试运行报告》,描述试运行过程、试运行问题及修改情况。 - 审核试运行报告
《试运行报告》需要正式提交项目试运行组审核,确认无误后提交客户审批。 - 签发试运行报告
客户查看项目《试运行报告》,确认无误后签字/盖章审批项目试运行工作正式完成。
输出:
(1) 试运行计划
(2) 试运行报告
3.6.3 项目终验
- 准备终验交付物和提出终验申请
试运行完成后,项目经理需要根据项目合同/任务书要求,全面整理项目交付物最终版本,并向项目验收组提出终验《验收申请》。申请内容至少包括:项目名称、交付物列表、建议终验时间安排等。 - 组织验收和形成结论
项目验收组收到申请后组织终验工作,根据初验《验收报告》、《试运行报告》,开展终验工作,一般以召开终验会议为主,并形成终验验收结论。 - 出具终验报告
确认项目工作全部完成后,项目验收组编制出具项目终验《验收报告》,并提交客户审核。验收报告的内容应包括:项目概述、验收组织形式及验收范围、验收内容
(含验收目标及测试结果)、遗留问题、验收结论。 - 签发终验报告
客户负责最终审核《验收报告》,确认无误后签字/盖章审批项目终验工作正式完成。
输出:
(1) 验收申请
(2) 验收文档
(3) 验收报告
4 项目结项与收尾
4.1 管理结项
4.1.1 进行项目总结
1.项目验收完毕后,项目经理组织项目组成员进行个人总结,并进行项目整体总结,形成《个人工作总结》和《项目工作总结》。形成的总结提交给工程总监、质量经理等相关人员。
2.项目经理召集项目总结会议,在工程总监的指导下,进行项目总结和经验交流,形成项目总结会议纪要,并将会议纪要分发给与会人员。
输出:
(1) 个人工作总结
(2) 项目工作总结
(3) 项目总结会会议纪要
4.1.2 整理结项资料
1.项目验收完毕后一个月内,项目经理负责组织项目组成员按照 ISO9K 以及 SBU的相关规定进行结项资料的整理,形成《结项申请》、《结项资料清单》、《结项总结》、以及项目结项资料。结项资料的整理结构,应按照项目实际划分的阶段进行分类。
举例:
- 软件类项目:立项、需求、设计、实现、测试、试运行、验收、结项、其它。
- 运维和咨询类项目:立项、实施、验收、结项、其它。
- 集成类项目:立项、实施方案、到货验收、集成实施、验收、结项、其它。
2.项目配置管理员整理项目配置库,遵循配置管理过程的要求。
输出:
(1) 结项申请
(2) 结项资料清单
(3) 项目结项资料
4.1.3 审核结项资料
1.项目经理将《结项申请》、《结项资料清单》、《结项总结》、以及项目结项资料提交给质量经理。
2.质量经理对结项资料进行审核。审核通过,在《结项申请》上签字;审核不通过,将审核意见反馈给项目经理,由项目经理负责及时修改/补充结项资料。
3.资源管理部负责将审核通过的结项资料提交集团机要室以及 SBU 要求的相关部门进行审核归档。
输出:
(1) 《结项申请》上的签字
(2) 归档记录
4.1.4 提交结项审批
1.结项资料通过质量经理的审核后,由项目经理确认项目收入是否全部确认完毕、以及项目实施成本是否全部报销完毕(如果有分包,要确认分包款是否全部支付完毕)。
2.收入确认完毕且实施成本报销完毕后,项目经理应及时发起管理结项审批电子流程,并跟踪流程审批状态直至审批完毕。审批完毕后财务人员会在财务系统进行项目管理结项的操作。
输出:1) 完成的结项审批流程
4.1.5 释放项目资源
1.人力资源的释放,项目经理须在预计释放日期提前 2 周邮件通知资源管理部。
2.进行项目总结后,项目经理可开始释放不参与结项资料整理工作的人力资源,如有租赁设备资源,一并释放。
3.在结项资料审核完毕后,项目经理可释放剩余人力资源。
4.管理结项电子流程审批完毕后,项目经理释放。
输出:1) 人力资源得到释放
5 项目监控
通过对项目的过程和结果进行监控,对规范执行情况的检查以及项目数据的分析,报告项目进展状态和存在风险问题。
5.1 规范执行的推动和日常检查
质量管理的重点工作:
- 项目立项过程所要求的信息填报完整
- 项目的过程得到定义
- 开发项目制定项目版本发布计划和评审计划
- 开发项目具备配置管理计划和配置状态报告
- 所有新启动的非软件开发项目,都有指定的配置管理员,并按规范的目录要求建立配置库,且存放文件
- 项目的需求得到评审、签字、形成基线,需求变更单得到跟踪,尤其是验证和形成基线部分的跟踪
- 项目的高层计划、范围矩阵、完成度矩阵得到跟踪
- 项目按计划的频率提交周报
- 项目定期更新 WBS 进度计划
- 质量经理每月识别项目执行过程的风险和问题
- 配置库每月回收总部备份
- 建立重大工程项目和核心业务与综合业务相结合的项目配置管理规范并执行
- 原系统升级开发项目,完成配置库目录优化工作
- 重大和重点项目必须具备专职测试人员并完成性能测试,且必须实现 QC工具上从需求到缺陷的全过程管理,其余项目可由开发人员兼职测试,但必须包含逆向测试用例
5.2 项目红黄牌检查
- 质量经理根据《质量经理规范》和《季度红黄牌检查计划》对项目实施规范的执行情况进行检查,并出具检查报告。
- 资源管理部每季度对所有项目的红黄牌检查结果进行汇总和总结,编写《项目红黄牌检查季度汇总报告》。
使用模版
(1) 《项目红黄牌检查报告》
(2) 《项目红黄牌检查季度汇总报告》
5.3 项目进展月度报告
- 通过分析项目进度、成本数据,结合当月项目日常检查和红黄牌检查结果,编写《项目信息月度汇总报告》。
- 每月 10日前完成上月的《项目状态汇总表》,发送高层领导,部门负责人、事业部负责人、工程总监、客户经理、项目经理。
- 输出:
(1) 《项目信息月度汇总报告》