项目管理流程.docx
《项目管理流程.docx》由会员分享，可在线阅读，更多相关《项目管理流程.docx（30页珍藏版）》请在冰点文库上搜索。
项目管理流程
项目管理流程
文件编号：
编制：
审核：
批准：
受控状态：
各版本建立及修订履历
版本号
建立/修订履历
申请人/日期
审核人/日期
批准人/日期
A00
初次建立
项目管理流程
1.目的和范围
2.
确定开发立项、策划、监控、风险管理及结项流程，通过规范项目管理过程，保证开发项目顺利进行，以保证最终产品质量。
本文件适用于一般开发项目管理过程。
3.引用文件
4.
●评审规程
●
●变更管理规程
●
5.职责
角色
职责
技术经理
1、项目策划工作：
✧组织进行项目工作结构分解
✧
✧组织进行项目估算，编制《项目基准计划》、《项目总体计划》
✧
✧组织进行《项目总体计划》和《项目基准计划》评审
✧
✧依据《项目总体计划》和《项目基准计划》进行月度计划分解
✧
✧按照项目计划进行开发管理
✧
2、项目监控工作：
✧对照计划进行项目的监督和控制，进行偏差控制
✧
✧按照要求进行项目报告
✧
✧组织项目里程碑评审
✧
✧提交项目评估申请
✧
✧向产品经理进行工作汇报
✧
3、风险监控工作：
✧项目风险识别及评估，建立项目《风险管理报告》
✧
✧按要求进行风险监控和风险缓解
✧
4、项目结项工作：
✧完成结项总结报告，提出项目结项绩效评估申请
✧
✧配合进行结项评估工作
项目组成员
1、项目策划工作：
✧参与项目策划过程
✧
✧按计划开展项目工作
✧
2、项目监控工作：
✧参加项目会议，向项目经理汇报工作
✧
3、风险管理工作：
✧识别、提出风险
✧
✧协助项目经理处理风险。
✧
✧跟踪所负责的风险，及时采取缓解措施
✧
4、项目结项工作：
5、
✧参与结项评估会议
大项目经理
1、立项工作：
✧安排人员提交《立项申请表》
✧
✧立项申请审核
✧
2、项目策划工作：
✧审核《项目基准计划》并协调资源
✧
3、项目监控工作：
✧跟踪项目经理对项目的监督和控制活动，审阅项目经理提交的报告，及时了解项目进展情况，并在项目偏差控制时，提供支持并监督偏差控制的纠正措施实施情况
✧
4、项目风险监控工作：
✧及时了解项目中高级别的风险以及缓解措施
✧
✧提供风险管理所需的资源
✧
5、项目结项工作：
✧接受结项申请
✧
✧组织进行结项评估
✧
✧审批结项结论
✧
✧参与结项评估
产品评审委员会
1、立项工作：
2、
✧进行《立项申请表》的审批
✧
3、项目策划工作：
4、
✧进行《项目基准计划》和《项目总体计划》的审批
✧
5、项目结项工作：
6、
✧审批项目绩效奖金
PQA工程师
1、项目策划工作：
2、
✧依据《项目基准计划》和《项目总体计划》编制《项目质量保证计划》。
✧
✧根据项目计划不断维护或变更《项目质量保证计划》
✧
✧参与项目评审工作
✧
✧依据《项目基准计划》和《项目总体计划》编制《项目总体测试计划》
✧
✧维护或变更《项目总体测试计划》
✧
3、项目管理过程审计工作：
4、
✧依据《项目质量保证计划》进行项目管理过程QA审计和报告
✧
✧参与项目评审工作。
✧
3、项目风险监控工作：
根据各项目的风险管理报告，建立并定期完善组织的风险数据库
配置管理员
1、项目策划工作：
2、
✧依据《项目基准计划》和《项目总体计划》编制《项目配置管理计划》
✧
✧维护或变更《项目配置管理计划》
✧
✧参与项目评审工作
✧
3、项目管理工作：
4、
✧依据《项目配置管理计划》进行配置管理工作
✧
✧
✧
✧
✧
6.术语
术语或缩略语
解释
PDP
ProjectDefinedProcess,项目已定义过程
WBS
工作分解结构（WBSWorkBreakdownStructure），
7.工作程序
8.
项目管理过程流程图：
8.1.开发立项
8.2.
8.2.1.立项流程
8.2.2.
立项申请
依据公司立项的主项目，开发部门组织进行项目分解或细化，指定人员进行立项申请，编制《立项申请表》；
内部及现有产品改型需求，开发部门提出立项需求，指定人员进行立项申请，编制《立项申请表》；
立项评审
开发部门组织进行立项评审。
《立项申请表》主要由开发部门负责人审核，高级管理者批准。
立项公告
《立项申请表》审批后，由立项申请部门将此表及相关资料提交开发管理部，由其进行ERP开发项目建立及公告。
项目任务下达：
《立项申请表》批准后，项目实施前，部门根据实际情况，给对应项目组下达《项目任务书》。
8.2.3.项目标识
8.2.4.
一般开发项目编号规则详见公司合同管理规定。
8.3.项目策划
8.4.
8.4.1.流程图
8.4.2.
8.4.2.1.建立需求阶段计划
8.4.2.2.
立项公告后，项目经理策划需求阶段工作进行分解，记录在《WBS》中。
需求评审通过以后，项目经理组织进行下一阶段各策划工作。
8.4.2.3.建立《项目总体计划》
8.4.2.4.
确定项目范围
项目经理根据项目立项公告和项目需求，获得项目的范围与工作要求的信息，确定项目最终交付物，明确项目组织结构。
项目分解
根据所确定的工作范围，项目经理组织进行WBS工作结构分解，并用Project表示，可在ProjectWebAccess上实现。
在项目的策划过程中，应通过阶段完善的方式对WBS进行不断的细化与补充。
为保证管理的有效性。
《WBS》由产品经理负责审批。
项目估算
根据所确定的WBS，由项目经理组织估算活动。
项目估算包括进度、规模、工作量，成本以及由此产生的其它工作与资源的估算（不仅局限于此）。
估算要求详细请参考“估算规程”。
建立《项目总体计划》以及《项目基准计划》
主要包括以下几个方面的内容：
✧项目进度安排；
✧
✧项目评审计划安排；
✧
✧项目资源计划；
✧
✧项目采购计划；
✧
✧项目的沟通计划；
✧
✧识别项目风险；
✧
✧项目成本计划；
✧
✧测量计划；
✧
✧制定支持计划，可以体现在《项目总体计划》中，也可以根据《项目总体计划》以及《项目基准计划》内容单独列出。
✧
《项目总体计划》以及《项目基准计划》的评审
《项目总体计划》以及《项目基准计划》评审的内容包括（但不限于）：
●项目目标是否明确，范围是否清晰；
●
●项目估算（规模、工作量、成本等）是否可信；
●
●项目生命周期模型以及选择过程模型是否合理；
●
●项目阶段和里程碑划分、评审计划是否合理；
●
●资源配置是否合理；
●
●职责分工是否清晰、合理；
●
●进度安排、各阶段费用安排是否合理并符合要求；
●
●支持计划是否与总体计划保持一致；
●
●风险是否考虑全面，缓解措施是否合理；
●
●测试计划中的测量项是否合理可执行。
●
评审过程：
项目基准计划编写完成后，由项目经理组织进行项目内部讨论与评审，评审前要求参与评审人员按照“计划检查单”内容记录项目实际情况，对评审会确认为问题的内容记录至《项目问题跟踪表》内容中。
评审过程可以参考“评审规程”中“管理会议评审”的方式。
评审通过后，项目经理将《项目总体计划》和《项目基准计划》提交产品经理审核，高级管理者批准。
8.4.2.5.建立项目支持计划
8.4.2.6.
项目支持计划可包含在《项目总体计划》中，也可单独列出。
配置管理员、QA工程师、测试主管根据批准后的《项目总体计划》和《项目基准计划》建立对应项目支持计划。
项目支持计划审批要求如下：
支持计划名称
审核
批准
配置管理计划
项目经理
产品经理
质量保证计划
项目经理
QA组长
总体测试计划
项目经理
产品经理
评审通过的《项目总体计划》和《项目基准计划》由项目组纳入配置管理并受控；评审不通过的项目计划，由项目组根据审核意见重新修改项目计划后在三个工作日内再次提交评审。
项目组对计划的修改要保留更改记录。
项目计划批准后，项目经理需将批准后的项目计划发送给所有利益相关人（如：
客户、营销中心、项目组成员、QA工程师、测试组、采购部门、产品使用部门、生产部门、公司内部相关代表等）。
8.4.2.7.分解《项目基准计划》和《项目总体计划》
8.4.2.8.
每月初，项目经理根据项目实际的开发进度以及《项目基准计划》《项目总体计划》中对主要节点完成时间的要求，策划项目本月开发计划的内容，项目经理组织进行WBS工作结构分解，并用Project表示，可在ProjectWebAccess上实现。
WBS的目的是将项目分解为可管理的任务，作为项目计划与跟踪的基础。
WBS分解详细程度的准则：
●任务包是否有利于分配与跟踪
●
●任务完成的状态是否可验证
●
●任务所分配的时长是否利于管理与控制
●
●每项任务的大小不要超过五个工作日。
●
本月项目的各类型支持计划如：
质量保证计划、配置管理计划、测试计划最终也在WBS上体现和管理。
8.4.2.9.项目支持计划
8.4.2.10.
配置管理员、QA工程师、测试主管根据项目各月度分解计划，分解对应支持计划。
直接在原支持计划基础上更新即可。
8.4.3.计划执行和变更控制
8.4.4.
项目组按计划执行项目活动，项目执行过程中如果项目的实际情况与项目计划产生偏差，项目经理执行变更，变更必须留下记录；
具体变更要求执行“变更管理规程”。
8.5.项目监控
8.6.
8.6.1.对照项目计划进行跟踪
8.6.2.
项目立项后、项目计划审批通过前，项目经理通过《项目周报》汇报项目进展情况。
项目经理周期性地跟踪项目计划的各种参数如规模、工作量、进度、资源、风险等，了解项目的实际进展情况。
跟踪报告的方式有三种：
周报告、项目总结报告、不定期报告。
跟踪的输出结果纳入配置管理。
8.6.2.1.周跟踪及报告
8.6.2.2.
●跟踪内容
●
✧进度
✧
✧工作量
✧
✧成本
✧
✧规模
✧
✧问题及解决情况
✧
●跟踪步骤及汇报
角色
任务
输出
汇报对象
项目经理
进行周跟踪（工作量、成本、进度、规模、问题）
编写《项目周报》
参与周例会
《项目周报》
《项目问题跟踪表》
产品经理
开发管理部
技术中心
召开各项目周例会
《会议纪要》
相关人员
1）项目经理（或安排项目组员）汇总项目信息，形成《项目周报》，一周监控中发现的问题，纳入《项目问题跟踪表》；
2）
3）技术中心每周六组织各项目例会，总结工作，讨论存在的问题，进行资源及承诺等跟踪，让所有项目成员清楚地了解项目的实际进展情况，同时明确下周工作任务分解。
对于周例会上发现的问题纳入对应项目《项目问题跟踪表》进行跟踪和管理。
4）
5）项目经理将《项目周报》、《项目问题跟踪表》汇报给产品经理，通报所有项目成员。
6）
8.6.2.3.里程碑/绩效节点跟踪及报告
8.6.2.4.
项目经理进行里程碑跟踪。
●跟踪内容
●
✧项目进度
✧
✧工作量
✧
✧成本
✧
✧规模
✧
✧风险
✧
✧问题及解决情况
✧
●跟踪记录
●
✧跟踪结果形成《项目总结报告》。
✧
✧项目经理（或其指定的项目成员），每里程碑对风险进行重新评估，确保新的风险变化能被及时识别。
风险跟踪的数据保存在《项目风险管理报告》中。
风险管理过程参见5.4“风险管理”。
✧
✧对问题及解决等情况等进行跟踪，记录在《项目问题跟踪表》中。
✧
●里程碑审查：
责任人
任务
输出
汇报对象
项目经理
（1）编制本里程碑的《项目总结报告》
（2）策划下一阶段的工作
《项目总结报告》
《项目问题跟踪表》
产品经理
项目组
（1）提出里程碑评审申请
（2）参加里程碑评审
《项目总结报告》
《项目问题跟踪表》
《项目风险管理报告》
《项目测量记录》
《里程碑评审检查单》
《评审报告》
✧项目经理在里程碑点跟踪总结里程碑工作完成情况：
✧
（1）收集并分析测量数据，形成项目测量记录，具体过程参见“测量和分析程序”。
（2）进行阶段工作总结，包括任务完成情况、风险和问题管理状况等，并进行偏差分析，形成《项目总结报告》。
（3）细化下一阶段的工作任务，更新《项目基准计划》《项目总体计划》和《WBS》。
（4）重新评估风险，更新《项目风险管理报告》。
（5）统计评审问题的状态，更新《评审问题跟踪表》。
（6）识别新的问题，更新《项目问题跟踪表》。
✧项目经理在里程碑点提请开发管理部组织里程碑评审。
里程碑评审采用“会议”方式进行，具体参见“评审规程”。
✧
（1）评审组成员可包括但不限于：
项目管理人员、项目经理以及主要项目成员、QA工程师、测试人员、配置管理员、客户代表、关联项目组代表；
（2）输入：
《项目总结报告》；重新识别后的《项目风险管理报告》；更新后的《项目总体计划》以及《项目基准计划》、《WBS》；最新处理情况的《评审问题跟踪表》、《项目问题跟踪表》、《项目测量记录》（以上输入由产品经理审核后提交开发管理部）；
本阶段QA工作报告，《QA问题跟踪表》由QA工程师提交开发管理部。
（3）输出：
《评审报告》；
（4）检查单：
《里程碑评审检查单》
✧里程碑会议和周例会间隔时间小于3天的，只召开一次会议，但必须同时输入里程碑和周工作情况。
✧
8.6.2.5.不定期跟踪
8.6.2.6.
项目经理根据实际需要，通过召开不定期会议的方式进行，形成《会议纪要》，通报所有项目成员。
8.6.3.问题管理
8.6.4.
项目经理在跟踪过程中收集了引起项目偏差的问题，同时需要对问题进行管理：
进行原因分析，采取纠正措施，管理纠正措施，直到结束。
问题管理的相关信息记录在《项目问题跟踪表》中。
8.6.4.1.原因分析
8.6.4.2.
项目经理组织对问题发生的原因进行分析，对问题进行归类，划分优先级，并找出根本原因。
对于“高”优先级的问题，上报产品经理。
8.6.4.3.制定纠正措施
8.6.4.4.
原因分析基础上，制定适当的纠正措施，根据问题的优先级，计划解决时间，指派责任人。
偏差控制参照“变更管理规程”。
8.6.4.5.跟踪纠正措施
8.6.4.6.
●责任人负责实施纠正措施、解决问题，记录问题解决时间。
●
●项目经理跟踪纠正措施执行的过程，指定人员进行验证，直到该问题被消除为止。
●
●如果问题重复出现，则将问题升级，重新进行原因分析，找出根本原因，采取新的纠正措施，并持续对问题进行跟踪处理直至解决。
●
8.7.风险管理
8.8.
8.8.1.风险识别
8.8.2.
风险识别阶段的目标是指确定哪些可能影响项目目标实现（导致费用超支、进度推迟或性能降低）的潜在问题，为项目团队创建一个《项目风险管理报告》。
《项目风险管理报告》为项目一段时期内可能存在的风险及监控记录，应定期审查，以便重新检查可能的风险来源和调整条件，从而进一步发现以前没有注意到的或者是未知的风险。
常用风险识别方法包括以下几种：
类比法
该方法通过获取组织财富库中《风险库》和历史类似项目积累的风险数据进行项目的风险识别。
在《风险库》中，按类别列出了在组织范围内与项目有关的所有可能风险描述，使得项目经理集中来识别常见的、已知的和可预测的风险，如产品规模风险、需求风险、管理风险及技术风险等。
项目组根据本项目的特点以及《风险库》，进行本项目的风险识别。
类比法的优点是它使风险识别能按照系统化、规范化的要求去识别风险，且简单易行。
头脑风暴法
项目经理组织合适人员（可考虑项目组成员、外聘专家、客户等各方人员）组成小组，根据项目目标、项目的制约因素和假设条件、与本项目具有相关性的历史资料以及过去的经验教训等信息通过头脑风暴法分析得出项目的可能风险。
头脑风暴法流程：
[Step1]：
选择合适人员参加（项目组成员、外聘专家），明确讨论的问题和时间限制。
[Step2]：
会议准备（确定时间、地点，会议通知等）。
[Step3]：
会议开始时，宣布议题：
分析项目可能风险，指定记录人。
主持人鼓励与会人员自由发表见解，禁止评论并控制时间。
记录人记录所有风险。
[Step4]：
会议结束后，项目经理整理会议列出的风险（合并同类风险、排序），并进行评价。
项目组可以结合使用上述两种方法，进行项目风险识别。
首先项目经理通过类比法的将识别结果记录到《项目风险管理报告》中，再召开头脑风暴会议，将补充风险记录在《风险管理报告》中。
内容包含：
风险编号、风险描述、提出人、可能发生阶段等。
风险识别的结果将成为风险评估阶段的主要输入。
风险识别过程记录在《风险识别记录》中。
8.8.3.风险评估
8.8.4.
项目成员评定各风险的产生原因、发生概率和产生影响以及可以采取的补救措施
风险评估活动
风险评估步骤
（1）评价风险可能性和影响
●对每一个风险进行评价，方法是对其可能性和影响进行打分，风险值较大的几个风险记录在《风险管理报告》中，进行管理和监控。
●
●可能性是指风险发生的可能性。
其量化评价方法是按下列描述打分：
高可能性P>=70%；中可能性30%●
影响是指当风险说明中所预料的结果发生时可能会对项目产生的冲击。
其量化评价要考虑到其性质、范围和时间，并使用下列因子：
低度影响I=1；中度影响I=2；高度影响I=4。
项目风险管理报告：
项目名称：
风险编号
风险描述
风险概率
风险影响
风险值
风险等级
14
所分配的人员在面向对象设计中没有经验；
根据学习曲线工期可能延长25%
80%
4
3.2
1
3
测试环境不具备所有必要的组件；
可能无法执行所有的测试用例
60%
2
1.2
2
（2）计算风险值和风险等级
对每个风险计算风险值，风险值=可能值*影响值。
然后对每个风险确定其等级，风险等级分为两级，为1级和2级（风险值矩阵的阴影部分是1级，非阴影部分为2级）。
对1级风险要参照风险值矩阵并根据管理者的直觉和判断力进行严格的审查。
必要时可以修改风险级别。
如果一个风险影响很大，但其发生的可能性很小，那么也不应为之付出太多的管理时间。
而那些高影响并且中高可能性的风险以及中度影响且有高度可能性的风险，则应当引起更多管理层的注意。
风险值矩阵：
可能性
影响
高
中
低
P>=70%
4.0-2.8
2.0-1.4
1.0-0.7
70%>P>30%
2.8-1.2
1.4-0.6
0.7-0.3
P<=30
1.2-0
0.6-0
0.3-0
（3）确定风险优先级
定义一个高优先级列表，方法是从1级风险中选择一个子集（最高的3到5个风险）。
高优先级的风险纳入《风险管理报告》，作为风险处理和减缓计划的输入。
由于每个项目的资源都是有限的，所以风险管理（处理、减缓、跟踪）必须把精力集中在这种最重要的风险子集上。
当然，如果在项目进行中条件和优先级改变了，那么组成此子集的风险也要随之改变。
（4）对风险分类
适当的时候，可以把风险进行分类，即相关的风险分组到一起：
这些风险可能需要相似的风险处理或者可能会在同一领域发生反面影响。
这种分组有助于理解风险的本质，并且会导致更为有效的风险处理和减缓计划。
8.8.5.风险缓解
8.8.6.
●风险缓解是针对那些对项目来说最重要的风险，拟订风险缓解措施的过程。
●
a）缓解方式有：
风险规避、风险转移、风险接受、风险减弱。
b）缓解措施：
制订风险缓解措施的时候，建议参照组织的《风险库》。
优先级越高的风险，优先保证缓解措施所需资源。
对于优先级排名前三位的风险，项目经理应该判断风险发生时是否要制订应急措施。
c）高级别的风险可以考虑制定多个缓解措施，在进行多种缓解措施选择的时候，需要引用“决策分析和决定程序”。
●风险缓解措施直接记录到《项目风险管理报告》中，将成为风险监控阶段的主要输入。
●
●在项目计划中的成本计划要考虑风险管理的成本。
●
8.8.7.风险监控
8.8.8.
风险管理是一个连续的过程，因此在项目的实施过程中需要遵循预先制订的计划定期监督风险和风险缓解措施的状态和执行结果。
风险应从三个方面进行监控：
8.8.8.1.监控风险的状态
8.8.8.2.
监控风险的状态并对风险缓解措施的执行情况进行跟踪，将风险状态和缓解措施执行情况记录于《项目风险管理报告》。
风险状态：
1）风险被缓解，关闭。
2）风险已发生，转入问题，关闭。
3）监控中，缓解措施正在实施，
4）监控中
5）新识别风险
缓解措施执行情况：
1）正在执行
2）已执行
3）更新缓解措施
8.8.8.3.应急措施的执行
8.8.8.4.
当风险发生时，转为项目问题，遵循5.3“项目监控”进行问题跟踪。
对于高级别风险发生时，项目经理应及时上报产品经理，执行应急措施。
8.8.8.5.风险持续管理
8.8.8.6.
持续进行风险识别、评估、缓解和监控工作，输出结果更新到《项目风险管理报告》。
8.9.项目结项
8.10.
8.10.1.结项总结
8.10.2.
产品正式发布，项目结束时，项目经理组织进行项目总结，编写《项目总结报告》。
《项目总结报告》主要内容：
✧项目过程概述
✧
✧项目主要工作目标进展情况
✧
✧项目物资资源投入分析
✧
✧项目人力资源投入分析
✧
✧项目总体成本分析
✧
✧主要工作产品
✧
✧项目维护、使用建议
✧
✧审批信息
✧
8.10.3.结项申请
8.10.4.
项目经理向产品经理提交《项目总结报告》，由产品经理审核《项目总结报告》，不符合要求的退回该报告，要求项目经理重新完善后再次提交。
《项目总结报告》通过后，由产品经理安排结项评估。
8.10.5.结项评估
8.10.6.
《项目总结报告》通过后，产品经理安排准备结项评
升级会员 