《IT项目管理办法》.doc

1、精品文档IT 项目管理办法信息管理部2004.4.精品文档目录前言 . .4一、术语定义.5二、 IT 项目生存期 .72.1应用开发项目生存期 .72.2应用部署项目生存期 .82.3生存期模型裁减 .102.3.1内部项目 .102.3.2外包项目 .112.3.3合作项目 .122.3.4采购项目 .122.3.5混合型项目 .13三、 IT 项目过程 .143.1启动 .143.2项目分解与计划 .143.3项目实施 .153.4项目结束 .163.5项目过程总结 .16四、 IT 项目计划 .174.1项目规模估算过程 .184.2项目规划过程 .194.3项目责任分配过程 .194

2、.4项目采购计划 .20五、 IT 项目监控 .225.1项目定期评审过程 .235.2项目事件评审过程 .245.3偏离纠正过程 .245.4计划修订过程 .255.5项目采购监控 .26六、 IT 项目审核 .286.1审核计划过程 .296.2审核执行过程 .29七、 IT 项目需求开发与管理 .317.1需求开发的步骤 .317.2需求管理的步骤 .34八、 IT 项目工作产品及验收 .368.1交付件.368.2质量记录 .378.3工作产品模板 .37.精品文档8.3.1任务书模板 .388.3.2计划书模板 .388.3.3评审报告模板 .398.3.4需求归纳表模板 .398.

3、4项目验收 .408.4.1可交付物验收 .408.4.2技术验收 .408.4.3功能验收 .418.4.4验收计划 .41九、项目经理的职责和素质.429.1项目经理的职责 .429.2项目经理的素质 .459.3项目经理的技能 .47.精品文档前言中外运对 IT 的投资是通过各种类型的 IT 项目来实现的，通过实施 IT 项目体现对 IT 投资的效果，因此有必要对 IT 项目制定相关的流程和规范。 IT 项目分为两个阶段：立项阶段和项目执行阶段。 本文只涉及项目执行阶段的管理办法， 项目立项阶段的流程按照 IT 项目立项流程执行。本管理办法的适用范围为股份公司总部。中外运股份有限公司信息

4、化组织（以下简称ITO ）是中外运股份有限公司专门致力于信息化建设的组织， 负责企业信息系统应用的支持、业务信息化的帮助以及基于信息技术的业务开拓。这些责任将使得ITO 逐渐成为企业核心竞争力的一个组成部分， 与此同时，也要求 ITO 持续地改善其IT 项目管理和运行能力。为了将这些项目管理过程得到有效的落实，特制订以下IT 项目管理办法。 ITO组织内所有人员需严格执行，保证ITO 内的项目管理和系统运行逐渐提高到业界较高水准，满足企业业务高速发展的需要。.精品文档一、术语定义1. 项目：在规定的时间和预算内完成的某种具有特定质量性能要求的一次性、多任务的工作。2. 项目的特征：目标确定性时

5、限性一次性独特性3. 项目生存期：一个项目从立项到项目执行结束的过程。4. 项目生存期模型：是对项目生存期的抽象，其中包括项目阶段的划分、各个阶段的进入条件、输入和输出等生存期公共属性。5. 关键过程域：是项目管理和项目执行所要关注的重要过程域， 包括项目管理、项目实施、项目支持等多方面的过程。这些过程域是根据业务需要和资源情况逐步开发定义的。6. 验证：是对系统的评价过程，以确定一个项目执行阶段的产品是否满足在此阶段开始时所给定的条件。7. 确认：是在项目执行过程中或项目结束时评价系统，以确定它是否满足特定的需求。8. 审核：是用于验证或确认的手段。审核是一种正式的评审活动，即需要计划并按计

6、划执行。9. 客户需求（ Customers needs）：是客户的需要与期待，这些要求和期待直接.精品文档相关于用户的业务过程和业务任务需求。10. 系统需求（ Requirements for System）：通过对客户需求的分析，确定系统应实现的规格。这些规格描述了系统的行为、特性和属性。系统需求也称为系统规格。11. 功能性需求（ Functional Requirements）：支持业务功能的系统需求，如数据检索、交易执行、报告打印等。12. 非功能性需求（ Non-functional Requirements）：系统执行的行为特征，如可靠性、安全性、性能指标等。13. IT （I

7、nformation 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用户需求获取系统

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

9、证阶段是基于用户的角度对系统的功能进行接收/验证测试。项目结束。2.2 应用部署项目生存期应用部署项目生存期的执行阶段是将经过验证的应用系统部署到相关业务部门中并投入使用的过程。 由于中外运规模较大， 且地域分布很广， 一个大型 IT应用的部署会涉及到多个部门、多个场所和不同的内部和外包资源，因此应用部署往往会作为一个独立的项目进行。应用部署项目生存期模型就是用于此目的而建立的，该模型图示如下：.精品文档项目立项（略）项目执行：SOW应用部署规划试点发布实施计划制定特殊需求处理切换准备切换项目立项结束，进入项目执行阶段。SOW 是项目执行阶段启动的文件。应用部署阶段是一个准备阶段，主要目的是进

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

11、切换阶段将应用投入实际运行的阶段，其中也包括切换结束的总结（无论成功或失败）。项目结束。2.3 生存期模型裁减生存期模型并不意味着中外运公司的所有IT 项目执行周期一成不变地覆盖整个生存期。不同类型的项目在生存期模型上的启动点和终止点不完全一样，需要根据项目的特征选择项目生存期并根据具体情况对项目生存期进行剪裁。2.3.1 内部项目内部项目的特征是项目的管理和资源的控制均在ITO 内部，因此可由 ITO 的一个项目经理负责整个项目生存期的过程和工作产品。实际上，这就是基本项目生存期的应用，具体如下：项目立项（略）项目执行：SOW用户需求系统概念系统设计实现验证应用获取确定定义交付.精品文档项目

12、执行阶段由一个SOW 启动，项目经理根据该SOW 制订项目初步计划，计划可在各个阶段里程碑结束后进行调整。2.3.2 外包项目外包项目的特征是项目的管理和资源的控制均在ITO 外部，ITO 代表中外运公司向外包公司发出需求并定义完成条件。ITO 项目经理的责任是负责提供合理的公司业务对 IT 系统的要求并负责确认项目输出的有效性，具体如下：项目立项（略）项目执行：SOW用户需求系统概念验证获取确定ITO- 标书- 合同企业采购部门系统设计实现应用定义交付外包部门项目执行阶段由一个SOW 启动，待完成了初步需求分析并形成了系统概念后，将用户初步需求和系统概念设计反应到标书中来选择外包商，反应到合

13、同中来启动外包项目。此外，项目生存期中验证阶段回到ITO 来执行。一般的应用交付涉及到用户的参与， 但该阶段的管理仍以外包商负责，或双方协调后共同负.精品文档责。如果外包的范围与上述不同，可对上述剪裁模式进行调整，关键是合同和验证两个控制点。 例如仅将设计部分外包时， 标书和合同涉及的也将仅仅是设计阶段，验收也是对设计的验收。 需要注意的是验证部分参与的内部人员和企业内部用户与实现部分参与的人员不同。2.3.3 合作项目合作项目是 ITO 与合作方资源统一管理的工作模式。若是以 ITO 为主，可参照 2.3.1 节描述的剪裁模型； 如果是以外方为主， 则可参照 2.3.2 节描述的剪裁模型。2

14、.3.4 采购项目外包项目和合作项目本质上也是采购项目，是IT 服务的采购。因此IT 服务采购项目的生存期参照上面2.3.2 节和 2.3.3 节。本节描述的是IT 设备（包括软件）的采购项目，具体如下：.精品文档项目立项（略）项目执行：SOW用户需求系统概念获取确定验证应用交付ITO- 采购标书- 采购合同企业采购部门供货程序供应商同样，内部以SOW 启动来确定设备采购的需求以及采购原则与策略（系统概念确定）。这些内容确定后形成采购标书，进而形成采购合同。供应商按其自己的供货程序工作。如果必要，可在他们的供货程序中插入质量检验的审核点。2.3.5 混合型项目当一个 IT 项目较复杂时可能包括

15、了自行开发、合作部分、外包部分以及采购部分。在这种情况下可将项目分解成若干子项目，每个项目参照上面适用的生存期分别进行管理。.精品文档三、 IT 项目过程下述模型是个简化的IT 项目执行过程模型，该模型包括了最基本的控制环节、分解原则和实施过程等要素。项目执行过程模型图示如下：项目立项（略）项目执行：启动项目分解结束与计划项目执行3.1 启动IT 项目在执行阶段必须有一个正式的启动文件SOW。正式的含义包括：来自于可下达任务的授权机构具有明确的主管人（发起人）指定了项目经理清晰的任务陈述（ SOW）SOW 定义了项目执行阶段的开始。3.2 项目分解与计划当项目经理接到任务书后，假设对任务书没有

16、任何疑义，那么项目经理需要.精品文档执行的第一个过程是进行项目计划，这样才能保证项目有序的执行。由于直接面向任务书中 SOW 进行计划会很难，特别是其中描述的任务规模很大时更是如此。一个有效的方法是将项目执行分为若干阶段，然后按阶段进行规划。 例如将项目执行分为如下的三个阶段：项目执行：SOW需求定义设计实现当然，如果上述阶段划分太粗， 还可以进一步细化， 例如将“设计” 分为“系统设计” 和“单元设计”，将实现分为 “编码”、“测试” 和“集成”。如果有必要，还可以增加一些阶段，如在“需求定义”和“设计”之间增加一个“技术选择”的阶段来专门分析采用什么技术对系统开发最有效。3.3 项目实施项

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

18、义了在什么时间由谁完成什么任务， 没有规定如何完成这些任务。 如何完成有两种方式，一种是凭执行者的经验决策， 另一种是定义好完成任务的过程和模板， 然后按照.精品文档过程和模板进行工作。当然，这两种方式会结合起来。3.4 项目结束项目计划的所有任务完成了，项目就可以结束。项目计划确定的生存期中定义了项目的结束阶段和结束应该进行的工作。项目结束不仅仅将项目交付件交给客户就算完成了， 还有一些其它总结性的工作，如项目数据汇集等。 项目数据可为其它项目执行提供依据和参照。3.5 项目过程总结一个基本的项目管理体系应管理项目的启动、项目划分和计划、项目的执行管理以及项目的结束。 一个更完善的项目管理体

19、系还应包括如何完成工程任务以及其它任务的过程。此外，还应包括需求开发和需求管理。.精品文档四、 IT 项目计划项目计划的目的是为项目的执行和管理提供一个合理计划。项目计划过程域中的过程包括估计项目规模、定义项目生存期、确定项目目标、制订人员、时间和投入计划。项目计划过程域与IT 项目生存期的一个示例关系如下：用户需求系统概念系统设计实现验证应用获取确定定义交付计计计计计计计划划划划划划划点修点修修修修订订订订订点点点点点箭头所指示的是项目计划在生存期的一个应用场景。 前两个阶段是由 ITO 和业务部门共同进行初步需求分析和系统概念确定， ITO 在项目初始制订了计划，并在第一个阶段完成后对计划

20、进行调整， 然后实施第二个阶段。 第二个阶段完成后，交给一个 ITO 内的项目开发组织，开发组织在他们承接项目的第一个阶段（生存期模型第三个阶段） 制订项目计划， 并在每个阶段完成后， 调整或修改计划。计划的调整或修订并不是必需的，只有当发现计划与实际不符时才进行。项目计划过程的目的是为执行软件工程活动和管理软件项目建立一个合理的项目计划。项目计划过程涉及的主要方面包括软件项目规模评估、 计划责任的协商与确立以及软件项目计划的制定。项目计划的目标为：项目规模估算并文档化，以保证在项目规划和跟踪中可用。.精品文档规划项目活动和责任并文档化。项目相关组和人员同意所分配的责任。根据这些目标，在ITO

21、 项目计划过程域中定义了三个过程：项目规模估算过程项目规划过程项目责任分配过程4.1 项目规模估算过程过程名项目规模估算过程标识 PP-01目标软件规模估算并文档化，以保证在项目规划和跟踪中可用。进入条件SOW （任务书）下达，并详细描述了任务范围。参与角色1.项目经理 ( 由 SOW确定 )2.项目人员 ( 由 SOW或项目经理确定，包括项目经理)3.相关评审人员 ( 由项目经理确定 )4.项目主管 ( 高层项目主管经理，由SOW确定 )输入SOW过程步骤序号描述输出项目经理根据SOW确定项目工作分解(WBS: Work Breakdown- WBS策略Structure)的策略和估算准则，

22、其中包括估算单位、估算方法、估算- 估算准则争议处理等。项目经理向项目人员分配项目分解任务。( 如果项目规模不大，可由项目经理本人独立进行项目分解和任务规模估算工作。)项目人员根据WBS策略和估算准则对项目进行分解估算，分别建立各-项目任务分解自管辖任务的WBS和相应的任务规模估算。项目经理负责进行汇总。(WBS)项目经理组织有关人员对WBS进行评审并根据评审结果对WBS以及估- 修订的项目 WBS和算进行修订。评审的目地是保证分解没有遗漏、重叠等问题；规模估任务规模估算算有依据。项目主管对WBS和估算结果进行审核。审核的目的是保证项目范围理- 审核通过的项目解正确、分解策略正确、估算结果合理

23、。WBS和任务规模估算项目经理负责整理上述步骤的输出，形成项目规模估算文件。- 项目规模估算文件完成标志1.项目 WBS和任务规模估算通过项目主管审核。2.形成项目规模估算文件( 过程提交产品 ) 。.精品文档4.2 项目规划过程过程名目标进入条件参与角色输入序号项目规划过程过程标识PP-02规划项目活动和责任并文档化。项目规模估算完成。1. 项目经理 ( 由 SOW确定 )2. 相关评审人员 ( 由项目经理确定 )3. 项目主管 ( 高层项目主管经理，由 SOW确定 )1. SOW2. 项目规模估算文件过程步骤输出描述项目经理根据SOW确定项目具体目标和项目交付件。- 项目目标描述- 项目交

24、付件清单确定项目策略，其中包括项目组织结构。- 项目组织图等项目经理根据SOW确定项目生存期模型。- 选择的生存期模型项目经理根据SOW、项目生存期模型和规模估算文件确定投入的资- 项目资源投入表源，包括人力资源。项目经理根据SOW、项目生存期模型和规模估算文件确定项目时间- 项目时间计划表安排。项目经理根据SOW、项目生存期模型和规模估算文件确定投入的资- 项目资金计划表金。项目经理对项目可能的风险进行分析并对高风险给出控制策略。风- 项目风险控制表险分析是基于项目目标和项目计划的，即影响项目目标和计划可能发生的事件。项目经理基于上面的输出，产生项目计划草案。- 项目计划草案项目主管召集有关

25、人员对项目计划进行评审。项目经理根据评审意- 项目计划评审报告见对项目计划进行修订，形成正式项目计划文档，并由项目主管根- 项目正式计划文档据项目确认。完成标志1.项目计划经过评审。2.正式项目计划文档产生。4.3 项目责任分配过程过程名项目责任分配过程过程标识 PP-03目标项目相关组和人员同意所分配的责任。进入条件项目正式计划形成。参与角色1.项目经理 ( 由 SOW确定 )2.项目组成员 ( 由项目计划确定 )3.项目主管 ( 高层项目主管经理，由SOW确定 )输入项目计划.精品文档过程步骤序号描述输出项目经理根据项目成员和时间计划生成每个人的任务时间计划并发放- 个人项目任务时间给各个

26、项目成员。计划各个相关人员确认所分配的责任，其中包括：- 个人项目任务时间分配的任务和时间是合理的。计划确认结果可满足完成任务所需要的业务要求。可满足完成任务所需要的时间要求。若不能确认上述一项或若干项条件，则将情况反馈给项目经理。项目经理根据反馈情况对计划进行调整，并对变化的人员责任重复上- 调整的项目计划一步骤。若有影响较大的调整，如关键人员的调整需得到项目主管的批准。若无调整，则跳过此步骤。项目经理发布项目计划，发布对象包括：项目主管项目组成员其他项目相关组织或人员( 如文档管理部门 )完成标志1. 计划经过所有项目相关责任人员的确认。2. 对无法承担项目责任进行调整并反映到计划中。3.

27、 调整的计划向所有有关人员发布。4.4 项目采购计划采购规划是确定哪些项目需求可以通过从项目组织之外采购产品、 服务或成果，从而最好地满足某些项目需求， 是项目团队在项目实施过程中可以自行满足的过程。它涉及是否需要采购、如何采购、采购什么、采购多少，以及何时采购等。当项目从实施组织之外取得项目履行所需的产品、服务和成果时，每项产品或者服务都必须经历从采购规划到合同收尾的各个过程。采购规划过程包括对每项外购决策涉及的风险，及就风险缓解或风险转移进行审核。中国外运信息化建设中的 IT 采购工作分成项目采购和日常采购，日常采购包括但不限于个人电脑及配件的采购。 日常采购在每年年底制订采购计划， 并通

28、过项目采购方式选定合格经销商和购买产品种类， 有效期 1 年。日常采购均从选定的合格经销商中选择。日常采购由具体采购人在合格经销商中采取两人 （含）以上询价的方式进行，部门负责人负责监控是否按流程进行，并抽查报价。主管（副）总经理可以确认部门负责人的签字，也可以再次抽查。.精品文档项目采购需成立采购项目组，项目组应根据情况，在符合法律相关规定的前提下，以公开招标、邀请招标或者内部议标的方式选择设备供应商。.精品文档五、 IT 项目监控项目执行监控的目的是关注项目进展情况并对发生的偏差及时进行纠正。项目执行监控的依据是项目计划，凡是计划了的内容， 都需要进行监控， 例如投入和时间安排。项目计划过

29、程域与IT 项目生存期的关系如下图所示：用户需求系统概念系统设计实现验证应用获取确定定义交付监监监监监监监监监监监监控控控控控控控控控控控控点点点点点点点点点点点点项目计划箭头所示是项目执行监控的一个应用场景。一般项目监控采用定期评审，例如按周的定期评审。 在每次定期评审中， 检查项目是否偏离了计划。 若发生了偏离，则立即采取纠正措施。此外，项目执行监控也可能是事件驱动的，一旦在定期评审之间发生了重要的项目管理事件， 如发生了某种风险， 则进行基于事件的评审，并根据评审结果采取相应措施。 每次评审的内容和结果要向所有相关人员通报，相关人员包括项目人员、 用户和企业相关主管。 通报通常采用定期项

30、目简报的形式。项目监控过程的目标为：按照计划跟踪项目的实际结果和执行性能。.精品文档当实际结果和执行性能偏离计划时，要采取纠正措施并对其进行管理。保证相关人员和组织同意所改变的责任。根据上述目标，项目监控过程域包括四个过程：项目定期评审过程基于事件的评审过程偏离纠正过程计划修订过程项目评审过程分为定期评审和基于事件评审。定期评审是正常的周期性评审，基于事件的评审是当发生了严重影响项目进展事件时进行的评审。 基于事件的评审由项目经理根据具体情况决定。 偏离纠正过程用于控制管理项目进程中发现的问题和问题的处理。 计划修改过程用于控制和实施计划的变更， 保证变更后的计划仍然具有合理性。5.1 项目定

31、期评审过程过程名项目定期评审过程过程标识 OM-01目标按照计划跟踪项目的实际结果和执行性能。进入条件到达项目评审时间参与角色1.项目经理 ( 由 SOW确定 )2.项目组成员 ( 由项目计划确定 )输入项目计划过程步骤序号描述输出项目经理根据项目计划本阶段要求完成的内容，收集各个项目成员的- 项目进展状态任务完成状态。项目经理将各个项目成员任务完成的状态与计划进行比较。若项目经- 偏离纠正措施理认为出现与计划的重要偏离，则与相关项目人员分析偏离原因，提出纠正措施，纠正措施包括对偏离的纠正或对计划的修改。对不是重要的偏离，则不提出纠正措施，而是列入到下次评审关注对象。偏离程度的判断由项目经理负

32、责。.精品文档项目经理审查以前定期评审确定关注的偏离问题( 如存在的话 ) ，并确- 偏离纠正措施( 若定是否采取偏离纠正措施。存在需纠正的偏离 )项目经理审查目前阶段正在执行的偏离纠正措施，若发现问题则给出- 偏离纠正措施执行问题解决建议。建议项目经理将上述评审结果形成项目定期评审报告，并发布给相关人员，- 项目定期评审报告发放范围依据项目计划。完成标志1.项目计划本阶段内所有要求的完成内容与实际完成状态进行了比较。2. 对需要纠正的偏离，向相关项目人员发出了纠正措施或纠正措施执行建议。3. 项目定期评审报告完成并向相关人员发布。5.2 项目事件评审过程过程名项目事件评审过程过程标识 OM-

33、02目标按照计划跟踪项目的实际结果和执行性能。进入条件项目经理得到项目成员的事件报告并决定进行评审。参与角色1.项目经理 ( 由 SOW确定 )2.项目组相关成员 ( 事件报告者和其他相关人员)输入1.事件报告2.项目计划过程步骤序号描述输出项目经理与相关人员分析事件对计划的影响，其中包括：- 事件影响分析计划进度的影响计划成本的影响计划资源的影响质量的影响等项目经理与相关人员确定事件处理措施，处理措施包括事件的解决、- 事件处理措施计划的调整等方面。项目经理落实事件处理的资源保证，如人力的保证。项目经理将上述评审结果形成项目事件评审报告，并发布给相关人员，- 项目事件评审报告发放范围包括评审会人员、主管人员以及其他相关人员。完成标志1.确定了项目事件处理措施并落实了相关事件处理的资源。2.项目事件评审报告完成并向相关人员发布。5.3 偏离纠正过程过程名计划偏离纠正过程过程标识 OM-03目标当实际结果和执行性能偏离计划时，要采取纠