文件2《IT项目管理办法》.doc

IT项目管理办法

信息管理部
2004.4

目录

前言 4
一、术语定义 5
二、IT项目生存期 7
2.1应用开发项目生存期 7
2.2应用部署项目生存期 8
2.3生存期模型裁减 10
2.3.1内部项目 10
2.3.2外包项目 11
2.3.3合作项目 12
2.3.4采购项目 12
2.3.5混合型项目 13
三、IT项目过程 14
3.1启动 14
3.2项目分解与计划 14
3.3项目实施 15
3.4项目结束 16
3.5项目过程总结 16
四、IT项目计划 17
4.1项目规模估算过程 18
4.2项目规划过程 19
4.3项目责任分配过程 19
4.4项目采购计划 20
五、IT项目监控 22
5.1项目定期评审过程 23
5.2项目事件评审过程 24
5.3偏离纠正过程 24
5.4计划修订过程 25
5.5项目采购监控 26
六、IT项目审核 28
6.1审核计划过程 29
6.2审核执行过程 29
七、IT项目需求开发与管理 31
7.1需求开发的步骤 31
7.2需求管理的步骤 34
八、IT项目工作产品及验收 36
8.1交付件 36
8.2质量记录 37
8.3工作产品模板 37
8.3.1任务书模板 38
8.3.2计划书模板 38
8.3.3评审报告模板 39
8.3.4需求归纳表模板 39
8.4项目验收 40
8.4.1可交付物验收 40
8.4.2技术验收 40
8.4.3功能验收 41
8.4.4验收计划 41
九、项目经理的职责和素质 42
9.1项目经理的职责 42
9.2项目经理的素质 45
9.3项目经理的技能 47

前言
中外运对IT的投资是通过各种类型的IT项目来实现的，通过实施IT项目体现对IT投资的效果，因此有必要对IT项目制定相关的流程和规范。IT项目分为两个阶段：立项阶段和项目执行阶段。本文只涉及项目执行阶段的管理办法，项目立项阶段的流程按照《IT项目立项流程》执行。
本管理办法的适用范围为股份公司总部。
中外运股份有限公司信息化组织（以下简称ITO）是中外运股份有限公司专门致力于信息化建设的组织，负责企业信息系统应用的支持、业务信息化的帮助以及基于信息技术的业务开拓。这些责任将使得ITO逐渐成为企业核心竞争力的一个组成部分，与此同时，也要求ITO持续地改善其IT项目管理和运行能力。为了将这些项目管理过程得到有效的落实，特制订以下IT项目管理办法。ITO组织内所有人员需严格执行，保证ITO内的项目管理和系统运行逐渐提高到业界较高水准，满足企业业务高速发展的需要。
一、术语定义
1. 项目：在规定的时间和预算内完成的某种具有特定质量性能要求的一次性、多任务的工作。
2. 项目的特征：
l 目标确定性
l 时限性
l 一次性
l 独特性
3. 项目生存期：一个项目从立项到项目执行结束的过程。
4. 项目生存期模型：是对项目生存期的抽象，其中包括项目阶段的划分、各个阶段的进入条件、输入和输出等生存期公共属性。
5. 关键过程域：是项目管理和项目执行所要关注的重要过程域，包括项目管理、项目实施、项目支持等多方面的过程。这些过程域是根据业务需要和资源情况逐步开发定义的。
6. 验证：是对系统的评价过程，以确定一个项目执行阶段的产品是否满足在此阶段开始时所给定的条件。
7. 确认：是在项目执行过程中或项目结束时评价系统，以确定它是否满足特定的需求。
8. 审核：是用于验证或确认的手段。审核是一种正式的评审活动，即需要计划并按计划执行。
9. 客户需求（Customer’s needs）：是客户的需要与期待，这些要求和期待直接相关于用户的业务过程和业务任务需求。
10. 系统需求（Requirements for System）：通过对客户需求的分析，确定系统应实现的规格。这些规格描述了系统的行为、特性和属性。系统需求也称为系统规格。
11. 功能性需求（Functional Requirements）：支持业务功能的系统需求，如数据检索、交易执行、报告打印等。
12. 非功能性需求（Non-functional Requirements）：系统执行的行为特征，如可靠性、安全性、性能指标等。
13. IT（Information Technology）：信息技术。
14. ITO（Information Technology Organization）：信息技术组织。
15. SOW（Statement Of Work）：任务书。
16. PP（Project Planning）：项目计划。
17. PR（Peer Review）：同行评审或对等评审。

二、IT项目生存期
2.1应用开发项目生存期
应用开发项目生存期是中外运ITO管辖的所有IT开发项目的生存期模型，该模型可通过剪裁应用到不同类型的开发中。应用开发项目生存期模型定义图示如下：

项目立项（略）
项目执行：
用户需求获取
SOW
系统概念确定
系统定义
设计
实现
验证
定义过程
实施过程

l 项目立项结束，进入项目执行阶段。
l SOW是项目执行阶段启动的文件。
l 用户需求获取阶段是析取用户对IT系统的需要（Needs），其中包括系统目的、范围、目标、业务需求、限制条件等方面。
l 系统概念确定阶段的目的是提出如何满足用户需要的总体策略，即确定满足需求的系统基本实现模式，如体系、架构、获取（Acquisition）方式等内容。
l 系统定义阶段是对用户的需求进一步进行开发以得到系统实现的规格定义（Specification）。
l 设计阶段包括了系统层面的设计（高层设计）和实现层面的设计（详细设计）。
l 实现阶段包括了具体开发、集成、工程测试。
l 验证阶段是基于用户的角度对系统的功能进行接收/验证测试。
l 项目结束。

2.2应用部署项目生存期
应用部署项目生存期的执行阶段是将经过验证的应用系统部署到相关业务部门中并投入使用的过程。由于中外运规模较大，且地域分布很广，一个大型IT应用的部署会涉及到多个部门、多个场所和不同的内部和外包资源，因此应用部署往往会作为一个独立的项目进行。应用部署项目生存期模型就是用于此目的而建立的，该模型图示如下：

项目立项（略）
项目执行：
应用部署规划
SOW
试点发布
实施计划制定
特殊需求处理
切换准备
切换

l 项目立项结束，进入项目执行阶段。
l SOW是项目执行阶段启动的文件。
l 应用部署阶段是一个准备阶段，主要目的是进行实施策略、实施方法、相关人员、时间以及试点等方面的总体规划和所需资源的准备。
l 试点发布阶段是实施策略和实施方法的测试阶段，主要目的是确认实施策略和实施方法的可行性并获取用于全面部署的经验。在应用部署规划时，如果确认试点发布无必要（例如，曾有过类似产品的发布），则可忽略此阶段。
l 实施计划制定阶段是应用部署的详细计划阶段，目的是确定具体的应用部署活动步骤。如果应用部署涉及到多个部门，该阶段也包括每个部门的行动计划。
l 特殊需求处理阶段包括识别和解决一些部署点的特殊的要求，目的是保证部署活动不会因为这些特殊要求而受到阻碍。
l 切换准备阶段是资源落实和最后测试的阶段，目的是确认切换所有的条件已就绪。
l 切换阶段将应用投入实际运行的阶段，其中也包括切换结束的总结（无论成功或失败）。
l 项目结束。

2.3生存期模型裁减
生存期模型并不意味着中外运公司的所有IT项目执行周期一成不变地覆盖整个生存期。不同类型的项目在生存期模型上的启动点和终止点不完全一样，需要根据项目的特征选择项目生存期并根据具体情况对项目生存期进行剪裁。

2.3.1内部项目
内部项目的特征是项目的管理和资源的控制均在ITO内部，因此可由ITO的一个项目经理负责整个项目生存期的过程和工作产品。实际上，这就是基本项目生存期的应用，具体如下：

项目立项（略）
项目执行：
SOW

用户需求获取

系统概念确定

系统
定义

设计

实现

验证

应用
交付

项目执行阶段由一个SOW启动，项目经理根据该SOW制订项目初步计划，计划可在各个阶段里程碑结束后进行调整。

2.3.2外包项目
外包项目的特征是项目的管理和资源的控制均在ITO外部，ITO代表中外运公司向外包公司发出需求并定义完成条件。ITO项目经理的责任是负责提供合理的公司业务对IT系统的要求并负责确认项目输出的有效性，具体如下：

验证

项目立项（略）
项目执行：

SOW

用户需求获取

系统概念确定

ITO
- 标书
- 合同

企业采购部门

系统
定义

设计

实现

应用
交付

外包部门

项目执行阶段由一个SOW启动，待完成了初步需求分析并形成了系统概念后，将用户初步需求和系统概念设计反应到标书中来选择外包商，反应到合同中来启动外包项目。此外，项目生存期中验证阶段回到ITO来执行。一般的应用交付涉及到用户的参与，但该阶段的管理仍以外包商负责，或双方协调后共同负责。
如果外包的范围与上述不同，可对上述剪裁模式进行调整，关键是合同和验证两个控制点。例如仅将设计部分外包时，标书和合同涉及的也将仅仅是设计阶段，验收也是对设计的验收。需要注意的是验证部分参与的内部人员和企业内部用户与实现部分参与的人员不同。

2.3.3合作项目
合作项目是ITO与合作方资源统一管理的工作模式。若是以ITO为主，可参照2.3.1节描述的剪裁模型；如果是以外方为主，则可参照2.3.2节描述的剪裁模型。

2.3.4采购项目
外包项目和合作项目本质上也是采购项目，是IT服务的采购。因此IT服务采购项目的生存期参照上面2.3.2节和2.3.3节。本节描述的是IT设备（包括软件）的采购项目，具体如下：

项目立项（略）
项目执行：

验证

应用
交付
SOW

用户需求获取

系统概念确定
ITO

供货程序
- 采购标书
- 采购合同

企业采购部门

供应商

同样，内部以SOW启动来确定设备采购的需求以及采购原则与策略（系统概念确定）。这些内容确定后形成采购标书，进而形成采购合同。供应商按其自己的供货程序工作。如果必要，可在他们的供货程序中插入质量检验的审核点。

2.3.5混合型项目
当一个IT项目较复杂时可能包括了自行开发、合作部分、外包部分以及采购部分。在这种情况下可将项目分解成若干子项目，每个项目参照上面适用的生存期分别进行管理。
三、IT项目过程
下述模型是个简化的IT项目执行过程模型，该模型包括了最基本的控制环节、分解原则和实施过程等要素。
项目执行过程模型图示如下：

项目立项（略）
项目执行：
项目分解
与计划
启动
结束
项目执行

3.1启动
IT项目在执行阶段必须有一个正式的启动文件SOW。正式的含义包括：
l 来自于可下达任务的授权机构
l 具有明确的主管人（发起人）
l 指定了项目经理
l 清晰的任务陈述（SOW）
SOW定义了项目执行阶段的开始。

3.2项目分解与计划
当项目经理接到任务书后，假设对任务书没有任何疑义，那么项目经理需要执行的第一个过程是进行项目计划，这样才能保证项目有序的执行。由于直接面向任务书中SOW进行计划会很难，特别是其中描述的任务规模很大时更是如此。一个有效的方法是将项目执行分为若干阶段，然后按阶段进行规划。例如将项目执行分为如下的三个阶段：

项目执行：
SOW
实现
设计
需求定义

当然，如果上述阶段划分太粗，还可以进一步细化，例如将“设计”分为“系统设计”和“单元设计”，将实现分为“编码”、“测试”和“集成”。如果有必要，还可以增加一些阶段，如在“需求定义”和“设计”之间增加一个“技术选择”的阶段来专门分析采用什么技术对系统开发最有效。

3.3项目实施
项目实施是项目计划的执行。为了能够知道项目进展是否符合项目计划，需要对实施过程进行监控。监控的方法是每隔一个固定的时间对项目状态进行一次检查，然后与计划进行比较。如发生了偏离，则进行纠正。
仅仅按固定的时间间隔检查项目状态有时也不能及时处理项目的问题，例如在间隔之间发生了重大影响项目计划的事件，如一项关键技术无法应用。因此要增加基于事件的检查。
偏离纠正包括两个方面，一个方面是对项目工程活动和工作产品发生的偏离进行纠正，另一方面是对计划进行修订。这些工作必须加以控制，按严格的规范执行，否则不仅仅偏离未能解决，还会引起新的问题。
在项目实施过程中，虽然是按项目计划进行的，但项目计划仅仅是定义了在什么时间由谁完成什么任务，没有规定如何完成这些任务。如何完成有两种方式，一种是凭执行者的经验决策，另一种是定义好完成任务的过程和模板，然后按照过程和模板进行工作。当然，这两种方式会结合起来。

3.4项目结束
项目计划的所有任务完成了，项目就可以结束。项目计划确定的生存期中定义了项目的结束阶段和结束应该进行的工作。项目结束不仅仅将项目交付件交给客户就算完成了，还有一些其它总结性的工作，如项目数据汇集等。项目数据可为其它项目执行提供依据和参照。

3.5项目过程总结
一个基本的项目管理体系应管理项目的启动、项目划分和计划、项目的执行管理以及项目的结束。一个更完善的项目管理体系还应包括如何完成工程任务以及其它任务的过程。此外，还应包括需求开发和需求管理。

四、IT项目计划
项目计划的目的是为项目的执行和管理提供一个合理计划。项目计划过程域中的过程包括估计项目规模、定义项目生存期、确定项目目标、制订人员、时间和投入计划。项目计划过程域与IT项目生存期的一个示例关系如下：

用户需求获取

系统概念确定

系统
定义

设计

实现

验证

应用
交付

计
划
修
订
点
计
划
修订点
计
划
修
订
点
计
划
修
订
点
计
划
修
订
点
计
划
点
计
划
点

箭头所指示的是项目计划在生存期的一个应用场景。前两个阶段是由ITO和业务部门共同进行初步需求分析和系统概念确定，ITO在项目初始制订了计划，并在第一个阶段完成后对计划进行调整，然后实施第二个阶段。第二个阶段完成后，交给一个ITO内的项目开发组织，开发组织在他们承接项目的第一个阶段（生存期模型第三个阶段）制订项目计划，并在每个阶段完成后，调整或修改计划。计划的调整或修订并不是必需的，只有当发现计划与实际不符时才进行。
项目计划过程的目的是为执行软件工程活动和管理软件项目建立一个合理的项目计划。项目计划过程涉及的主要方面包括软件项目规模评估、计划责任的协商与确立以及软件项目计划的制定。
项目计划的目标为：
l 项目规模估算并文档化，以保证在项目规划和跟踪中可用。
l 规划项目活动和责任并文档化。
l 项目相关组和人员同意所分配的责任。
根据这些目标，在ITO项目计划过程域中定义了三个过程：
l 项目规模估算过程
l 项目规划过程
l 项目责任分配过程

4.1项目规模估算过程

过程名
项目规模估算
过程标识
PP-01
目标
软件规模估算并文档化，以保证在项目规划和跟踪中可用。
进入条件
SOW（任务书）下达，并详细描述了任务范围。
参与角色
1. 项目经理(由SOW确定)
2. 项目人员(由SOW或项目经理确定，包括项目经理)
3. 相关评审人员(由项目经理确定)
4. 项目主管(高层项目主管经理，由SOW确定)
输入
SOW
过程步骤

输出
序号
描述

项目经理根据SOW确定项目工作分解 (WBS: Work Breakdown Structure) 的策略和估算准则，其中包括估算单位、估算方法、估算争议处理等。
- WBS策略
- 估算准则

项目经理向项目人员分配项目分解任务。(如果项目规模不大，可由项目经理本人独立进行项目分解和任务规模估算工作。)

项目人员根据WBS策略和估算准则对项目进行分解估算，分别建立各自管辖任务的WBS和相应的任务规模估算。项目经理负责进行汇总。
- 项目任务分解(WBS)

项目经理组织有关人员对WBS进行评审并根据评审结果对WBS以及估算进行修订。评审的目地是保证分解没有遗漏、重叠等问题；规模估算有依据。
- 修订的项目WBS和任务规模估算

项目主管对WBS和估算结果进行审核。审核的目的是保证项目范围理解正确、分解策略正确、估算结果合理。
- 审核通过的项目WBS和任务规模估算

项目经理负责整理上述步骤的输出，形成项目规模估算文件。
- 项目规模估算文件
完成标志
1. 项目WBS和任务规模估算通过项目主管审核。
2. 形成项目规模估算文件(过程提交产品)。

4.2项目规划过程

过程名
项目规划过程
过程标识
PP-02
目标
规划项目活动和责任并文档化。
进入条件
项目规模估算完成。
参与角色
1. 项目经理(由SOW确定)
2. 相关评审人员(由项目经理确定)
3. 项目主管(高层项目主管经理，由SOW确定)
输入
1. SOW
2. 项目规模估算文件
过程步骤

输出
序号
描述

项目经理根据SOW确定项目具体目标和项目交付件。
- 项目目标描述
- 项目交付件清单

确定项目策略，其中包括项目组织结构。
- 项目组织图等

项目经理根据SOW确定项目生存期模型。
- 选择的生存期模型

项目经理根据SOW、项目生存期模型和规模估算文件确定投入的资源，包括人力资源。
- 项目资源投入表

项目经理根据SOW、项目生存期模型和规模估算文件确定项目时间安排。
- 项目时间计划表

项目经理根据SOW、项目生存期模型和规模估算文件确定投入的资金。
- 项目资金计划表

项目经理对项目可能的风险进行分析并对高风险给出控制策略。风险分析是基于项目目标和项目计划的，即影响项目目标和计划可能发生的事件。
- 项目风险控制表

项目经理基于上面的输出，产生项目计划草案。
- 项目计划草案

项目主管召集有关人员对项目计划进行评审。项目经理根据评审意见对项目计划进行修订，形成正式项目计划文档，并由项目主管根据项目确认。
- 项目计划评审报告
- 项目正式计划文档
完成标志
1. 项目计划经过评审。
2. 正式项目计划文档产生。

4.3项目责任分配过程

过程名
项目责任分配过程
过程标识
PP-03
目标
项目相关组和人员同意所分配的责任。
进入条件
项目正式计划形成。
参与角色
1. 项目经理(由SOW确定)
2. 项目组成员(由项目计划确定)
3. 项目主管(高层项目主管经理，由SOW确定)
输入
项目计划
过程步骤

输出
序号
描述

项目经理根据项目成员和时间计划生成每个人的任务时间计划并发放给各个项目成员。
- 个人项目任务时间计划

各个相关人员确认所分配的责任，其中包括：
l 分配的任务和时间是合理的。
l 可满足完成任务所需要的业务要求。
l 可满足完成任务所需要的时间要求。
若不能确认上述一项或若干项条件，则将情况反馈给项目经理。
- 个人项目任务时间计划确认结果

项目经理根据反馈情况对计划进行调整，并对变化的人员责任重复上一步骤。若有影响较大的调整，如关键人员的调整需得到项目主管的批准。若无调整，则跳过此步骤。
- 调整的项目计划

项目经理发布项目计划，发布对象包括：
l 项目主管
l 项目组成员
其他项目相关组织或人员(如文档管理部门)

完成标志
1. 计划经过所有项目相关责任人员的确认。
2. 对无法承担项目责任进行调整并反映到计划中。
3. 调整的计划向所有有关人员发布。

4.4项目采购计划
采购规划是确定哪些项目需求可以通过从项目组织之外采购产品、服务或成果，从而最好地满足某些项目需求，是项目团队在项目实施过程中可以自行满足的过程。它涉及是否需要采购、如何采购、采购什么、采购多少，以及何时采购等。
当项目从实施组织之外取得项目履行所需的产品、服务和成果时，每项产品或者服务都必须经历从采购规划到合同收尾的各个过程。采购规划过程包括对每项外购决策涉及的风险，及就风险缓解或风险转移进行审核。
中国外运信息化建设中的IT采购工作分成项目采购和日常采购，日常采购包括但不限于个人电脑及配件的采购。日常采购在每年年底制订采购计划，并通过项目采购方式选定合格经销商和购买产品种类，有效期1年。日常采购均从选定的合格经销商中选择。
日常采购由具体采购人在合格经销商中采取两人（含）以上询价的方式进行，部门负责人负责监控是否按流程进行，并抽查报价。主管（副）总经理可以确认部门负责人的签字，也可以再次抽查。
项目采购需成立采购项目组，项目组应根据情况，在符合法律相关规定的前提下，以公开招标、邀请招标或者内部议标的方式选择设备供应商。

五、IT项目监控
项目执行监控的目的是关注项目进展情况并对发生的偏差及时进行纠正。项目执行监控的依据是项目计划，凡是计划了的内容，都需要进行监控，例如投入和时间安排。项目计划过程域与IT项目生存期的关系如下图所示：

用户需求获取

系统概念确定

系统
定义

设计

实现

验证

应用
交付
监控点
监控点
监控点
监控点
监控点
监控点
监控点
监控点
监控点
监控点
监控点
监控点

项目计划

箭头所示是项目执行监控的一个应用场景。一般项目监控采用定期评审，例如按周的定期评审。在每次定期评审中，检查项目是否偏离了计划。若发生了偏离，则立即采取纠正措施。此外，项目执行监控也可能是事件驱动的，一旦在定期评审之间发生了重要的项目管理事件，如发生了某种风险，则进行基于事件的评审，并根据评审结果采取相应措施。每次评审的内容和结果要向所有相关人员通报，相关人员包括项目人员、用户和企业相关主管。通报通常采用定期项目简报的形式。
项目监控过程的目标为：
l 按照计划跟踪项目的实际结果和执行性能。
l 当实际结果和执行性能偏离计划时，要采取纠正措施并对其进行管理。
l 保证相关人员和组织同意所改变的责任。
根据上述目标，项目监控过程域包括四个过程：
l 项目定期评审过程
l 基于事件的评审过程
l 偏离纠正过程
l 计划修订过程
项目评审过程分为定期评审和基于事件评审。定期评审是正常的周期性评审，基于事件的评审是当发生了严重影响项目进展事件时进行的评审。基于事件的评审由项目经理根据具体情况决定。偏离纠正过程用于控制管理项目进程中发现的问题和问题的处理。计划修改过程用于控制和实施计划的变更，保证变更后的计划仍然具有合理性。

5.1项目定期评审过程

过程名
项目定期评审过程
过程标识
OM-01
目标
按照计划跟踪项目的实际结果和执行性能。
进入条件
到达项目评审时间
参与角色
1. 项目经理(由SOW确定)
2. 项目组成员(由项目计划确定)
输入
项目计划
过程步骤

输出
序号
描述

项目经理根据项目计划本阶段要求完成的内容，收集各个项目成员的任务完成状态。
- 项目进展状态

项目经理将各个项目成员任务完成的状态与计划进行比较。若项目经理认为出现与计划的重要偏离，则与相关项目人员分析偏离原因，提出纠正措施，纠正措施包括对偏离的纠正或对计划的修改。对不是重要的偏离，则不提出纠正措施，而是列入到下次评审关注对象。偏离程度的判断由项目经理负责。
- 偏离纠正措施

项目经理审查以前定期评审确定关注的偏离问题(如存在的话)，并确定是否采取偏离纠正措施。
- 偏离纠正措施(若存在需纠正的偏离)

项目经理审查目前阶段正在执行的偏离纠正措施，若发现问题则给出问题解决建议。
- 偏离纠正措施执行建议

项目经理将上述评审结果形成项目定期评审报告，并发布给相关人员，发放范围依据项目计划。
- 项目定期评审报告
完成标志
1. 项目计划本阶段内所有要求的完成内容与实际完成状态进行了比较。
2. 对需要纠正的偏离，向相关项目人员发出了纠正措施或纠正措施执行建议。
3. 项目定期评审报告完成并向相关人员发布。

5.2项目事件评审过程

过程名
项目事件评审过程
过程标识
OM-02
目标
按照计划跟踪项目的实际结果和执行性能。
进入条件
项目经理得到项目成员的事件报告并决定进行评审。
参与角色
1. 项目经理(由SOW确定)
2. 项目组相关成员(事件报告者和其他相关人员)
输入
1. 事件报告
2. 项目计划
过程步骤

输出
序号
描述

项目经理与相关人员分析事件对计划的影响，其中包括：
l 计划进度的影响
l 计划成本的影响
l 计划资源的影响
l 质量的影响等
- 事件影响分析

项目经理与相关人员确定事件处理措施，处理措施包括事件的解决、计划的调整等方面。
- 事件处理措施

项目经理落实事件处理的资源保证，如人力的保证。

项目经理将上述评审结果形成项目事件评审报告，并发布给相关人员，发放范围包括评审会人员、主管人员以及其他相关人员。
- 项目事件评审报告
完成标志
1. 确定了项目事件处理措施并落实了相关事件处理的资源。
2. 项目事件评审报告完成并向相关人员发布。

5.3偏离纠正过程

过程名
计划偏离纠正过程
过程标识
OM-03
目标
当实际结果和执行性能偏离计划时，要采取纠正措施并对其进行管理。
进入条件
1. 项目定期评审会发出偏离纠正措施，或
2. 项目事件评审会发出事件处理措施
参与角色
1. 偏离纠正人员，或
2. 事件处理人员、
3. 项目经理
输入
1. 偏离纠正措施，或
2. 事件处理措施
过程步骤

输出
序号
描述

偏离纠正人员/事件处理人员根据偏离纠正措施/事件处理措施制订纠正/处理步骤。
- 偏离纠正/事件处理步骤

偏离纠正人员/事件处理人员执行制订的偏离纠正/事件处理步骤，直至结束。
- 偏离纠正/事件处理结果

项目经理审核偏离纠正/事件处理结果，若存在问题，则确定相应措施，再重复1-2两个步骤。

偏离纠正人员/事件处理人员将偏离纠正/事件处理结果形成报告。
- 偏离纠正/事件处理结果报告

项目经理审核偏离纠正/事件处理结果报告，并发布给有关人员。

完成标志
1. 项目经理审核通过偏离纠正/事件处理结果。
2. 偏离纠正/事件处理结果报告完成并向相关人员发布。

5.4计划修订过程

过程名
计划修订过程
过程标识
OM-04
目标
1. 当实际结果和执行性能偏离计划时，要采取纠正措施并对其进行管理。
2. 保证相关人员和组织同意所改变的责任。
进入条件
1. 项目定期评审会发出偏离纠正措施，该措施包括计划的修订，或
2. 项目事件评审会发出事件处理措施，该措施包括计划的修订。
参与角色
1. 项目经理
2. 项目主管
输入
1. 偏离纠正措施，或
2. 事件处理措施
过程步骤

输出
序号
描述

项目经理根据偏离纠正措施/事件处理措施确定计划修订的范围和内容。
- 计划修订范围和内容

项目经理根据确定的修订范围和内容修订计划。
- 修订的计划

若修订的计划涉及到人员责任的变化，则项目经理与相关人员确认变化的责任是否可接受。若不可接受，则需进一步调整。
- 修订的计划

项目主管审核修订的计划，若存在问题确定重新修订的范围和内容，再次执行步骤2-3。
- 重新修订的范围和内容，或
- 审核通过的计划

项目经理发布经项目主管的审核计划，发布范围同原计划发布的范围。

完成标志
1. 项目主管审核通过修订的计划。
2. 审核通过的修订计划向相关人员发布。

5.5项目采购监控
在进行项目采购的决策过程中，应考虑项目预算等制约因素。实施组织的长远战略也是在采购监控中应考虑的内容。如果决定外购，则反映了实施组织的长远规划和项目的当前需要。例如，决定购置某种开发平台或数据库，不是临时使用，而是希望获得长期支持。从项目经济效益上看可能合算，也可能不合算。但是如果实施组织需要长期使用该开发平台或数据库，则分摊到项目上的那部分购置费用就有可能低于临时使用的费用。
在进行项目采购时，应成立采购项目组，并对项目采购的过程进行监控。采购项目组包括业务部门和信息管理部的主管领导及相关负责人员和经办人员，必要时请企划部、财务部等部门参加。根据《中国外运股份有限公司投资管理规定》，超过三百万的项目采购，还要上报股份公司，经批准后方可执行。
项目采购流程如下：
1. 起草立项报告
项目组根据项目需求描述决定何时采购何物，制定相应的采购计划并起草立项报告，通过内请流程上报公司审批。审批通过后，成立IT采购项目组，并确定项目组成员。
2. 确定采购方式
经IT采购项目组讨论通过后，决定采购方式，主要包括三种方式：公开招标、邀请招标、询价采购。
3. 供应商的选择和询报价
IT采购项目组应根据备选供方的报价单进行评定，即进行供应商的选择。
4. 确定供应商和价格
IT采购项目组经过讨论，最终确定供应商和采购产品的价格。
5. 签订合同
IT采购项目组和产品供应商谈判后签署采购合同。
6. 合同执行
产品供应商按合同规定履约，IT采购项目组成员负责产品验收。
7. 价款结算
IT采购项目组负责办理和产品供应商的价款结算。
8. 填写IT采购申请/处理单
IT采购项目组负责填写IT采购申请/处理单。

六、IT项目审核
IT项目审核过程是一种正式的评审，需要较高的资源投入，因此并不意味着所有IT项目交付件都要进行正式的审核。审核对象的确定由项目经理在项目计划时根据质量风险来确定。
IT项目审核包括三个部分：审核计划、审核执行、审核问题纠正，这三个部分描述如下：
审核计划
审核计划是基于项目计划确定的审核对象和标准的审核过程来定义审核目标、资源计划和时间计划。在项目计划中，需要确定审核对象和相应的审核主持人，与此同时在计划中分配审核主持人审核计划和审核执行任务。在一个项目中不同阶段会对不同的交付件进行审核，这些审核的主持人可以是不同的。一个主要的原则是审核主持人不能是交付件的责任人。
审核执行
审核执行包括审核准备、召开审核会和建立审核记录。审核准备包括审核对象资料准备、审核人员熟悉所负责的审核内容。审核会一般不超过两个小时，否则效率会大大降低。审核会的目的是审核交付件是否满足相应的准则，而不是审核人的能力和具体采用的开发方法、技术的正确与否。审核记录要记录审核过程发现的缺陷，缺陷属性，例如严重程度、来源（本阶段产生的，还是前面阶段遗留下来的）等。
审核问题纠正
审核问题纠正是解决审核中发现的缺陷。审核问题的纠正要加以跟踪，直到全面完成。

6.1审核计划过程

过程名
审核计划过程
过程标识
PR-01
目标
对审核活动进行计划。
进入条件
到达项目计划的审核计划时间。
参与角色
1. 审核主持人(由项目经理在计划中指定)
2. 审核人
3. 交付件开发责任人
输入
1. 审核对象定义(根据项目计划)
2. 审核过程
过程步骤

输出
序号
描述
1
审核主持人根据审核对象定义确定审核目标。
- 审核目标
2
审核人与交付件开发责任人讨论确认审核目标。
- 交付件开发责任人确认的审核目标
3
审核主持人根据审核对象和审核目标确定主审人和审核人以及它们的责任，并得到这些人员参加审核的确认和对审核目标的确认。
- 审核人名单
- 确认的审核目标
4
审核主持人与交付件开发责任人确认审核材料提交的时间和发放的对象。
- 审核材料提交时间、清单和发放对象
5
审核主持人确定审核时间和地点并得到审核人员和交付件开发责任人的确认。
- 审核时间
6
审核主持人形成书面审核计划并送达交付件开发责任人、所有审核人员和项目经理。
- 审核计划
完成标志
审核计划送达所有相关人员。

6.2审核执行过程

过程名
审核过程执行过程
过程标识
PR-02
目标
按照计划执行审核。
进入条件
1. 到达审核计划确定的审核任务时间
2. 审核对象材料发放
参与角色
1. 审核主持人(由项目计划确定)
2. 审核人员(由审核计划确定，包括主审人)
3. 交付件开发责任人
输入
1. 审核计划
2. 审核对象材料
过程步骤

输出
序号
描述
1
所有审核人通过审核对象材料了解与其责任相关的审核内容。审核主持人对此进行确认。
无
2
审核主持人按计划召集审核会。
无
3
主审人报告全面审核的结果。
- 主审人审核结果
4
各个审核人报告各自责任范围内的审核的结果。
- 审核人审核结果
5
审核人讨论交付件可能的缺陷。
- 候选缺陷
6
交付件开发责任人对审核人提出的问题应答。
无
7
审核人确认交付件的缺陷和缺陷属性，其中包括严重程度(高、中、低)和来源(本阶段产生，前面阶段遗留)。
- 缺陷清单
8
审核主持人形成审核报告，并得到与会人员的认可。
- 审核报告确认的缺陷清单作为该报告的附件。
10
审核主持人向项目经理、质量保证经理、配置管理经理和与会人员提交审核报告。
- 无
完成标志
审核报告完成并向相关人员发布。

七、IT项目需求开发与管理
7.1需求开发的步骤
系统需求是通过一系列步骤逐步转化得到的。这些步骤可能执行一次，就可得到开发人员所要的系统规格定义，但更多的是重复地执行多次来确定系统规格定义。需求开发的基本步骤如下：
l 确定项目范围
l 获取客户需求
l 分析客户需求
l 制订系统规格
l 验证系统规格
l 系统规格受控
确定项目范围
项目范围本身往往在项目开始时也不是很容易确定。客户是一个群体，不同层面的人员因处于不同的地位会对项目含义有不同的认识。有时在同一范围概念下，也会有不同内容的理解。这个阶段的目的是建立一个统一的项目视图并在这个视图的基础上对项目范围取得共同的认识。
项目视图需要采用客户容易理解的图示来表达，例如系统环境关联图，系统功能层次图、系统在业务价值链中的位置等。利用这些图示来进一步刻画和描述系统范围要素，如支持的用户类别、系统特征、基于的环境和支持目标等。
项目范围实质上是客户需求的一个部分