【管理制度)文件IT项目管理办法

（管理制度）文件IT项目
管理办法
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项目立项流程》执行。

本管理办法的适用范围为股份公司总部。

中外运股份XX公司信息化组织（以下简称ITO）是中外运股份XX公司专门致力于信息化建设的组织，负责企业信息系统应用的支持、业务信息化的帮助以及基于信息技术的业务开拓。

这些责任将使得ITO逐渐成为企业核心竞争力的壹个组成部分，和此同时，也要求ITO持续地改善其IT项目管理和运行能力。

为了将这些项目管理过程得到有效的落实，特制订以下IT项目管理办法。

ITO组织内所有人员需严格执行，保证ITO内的项目管理和系统运行逐渐提高到业界较高水准，满足企业业务高速发展的需要。

壹、术语定义
1.项目：于规定的时间和预算内完成的某种具有特定质量性能要求的壹次性、
多任务的工作。

2.项目的特征：
●目标确定性
●时限性
●壹次性
●独特性
3.项目生存期：壹个项目从立项到项目执行结束的过程。

4.项目生存期模型：是对项目生存期的抽象，其中包括项目阶段的划分、各个
阶段的进入条件、输入和输出等生存期公共属性。

5.关键过程域：是项目管理和项目执行所要关注的重要过程域，包括项目管理、
项目实施、项目支持等多方面的过程。

这些过程域是根据业务需要和资源情况逐步开发定义的。

6.验证：是对系统的评价过程，以确定壹个项目执行阶段的产品是否满足于此
阶段开始时所给定的条件。

7.确认：是于项目执行过程中或项目结束时评价系统，以确定它是否满足特定
的需求。

8.审核：是用于验证或确认的手段。

审核是壹种正式的评审活动，即需要计划
且按计划执行。

9.客户需求（Customer’sneeds）：是客户的需要和期待，这些要求和期待直
接关联于用户的业务过程和业务任务需求。

10.系统需求（RequirementsforSystem）：通过对客户需求的分析，确定系统
应实现的规格。

这些规格描述了系统的行为、特性和属性。

系统需求也称为系统规格。

11.功能性需求（FunctionalRequirements）：支持业务功能的系统需求，如数
据检索、交易执行、方案打印等。

12.非功能性需求（Non-functionalRequirements）：系统执行的行为特征，如
可靠性、安全性、性能指标等。

13.IT（InformationTechnology）：信息技术。

14.ITO（InformationTechnologyOrganization）：信息技术组织。

15.SOW（StatementOfWork）：任务书。

16.PP（ProjectPlanning）：项目计划。

17.PR（PeerReview）：同行评审或对等评审。

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

应用开发项目生存期模型定义图示如下：
项目立项（略）
项目执行：
●项目立项结束，进入项目执行阶段。

●SOW是项目执行阶段启动的文件。

●用户需求获取阶段是析取用户对IT系统的需要（Needs），其中包括系统
目的、范围、目标、业务需求、限制条件等方面。

●系统概念确定阶段的目的是提出如何满足用户需要的总体策略，即确定
满足需求的系统基本实现模式，如体系、架构、获取（Acquisition）方
式等内容。

●系统定义阶段是对用户的需求进壹步进行开发以得到系统实现的规格定
义（Specification）。

●设计阶段包括了系统层面的设计（高层设计）和实现层面的设计（详细
设计）。

●实现阶段包括了具体开发、集成、工程测试。

●验证阶段是基于用户的角度对系统的功能进行接收/验证测试。

●项目结束。

2.2应用部署项目生存期
应用部署项目生存期的执行阶段是将经过验证的应用系统部署到关联业务部门中且投入使用的过程。

由于中外运规模较大，且地域分布很广，壹个大型IT应用的部署会涉及到多个部门、多个场所和不同的内部和外包资源，因此应用部署往往会作为壹个独立的项目进行。

应用部署项目生存期模型就是用于此目的而建立的，该模型图示如下：
项目立项（略）
项目执行：
SOW
●
●
●
●
●实施计划制定阶段是应用部署的详细计划阶段，目的是确定具体的应用
部署活动步骤。

如果应用部署涉及到多个部门，该阶段也包括每个部门的行动计划。

●特殊需求处理阶段包括识别和解决壹些部署点的特殊的要求，目的是保
证部署活动不会因为这些特殊要求而受到阻碍。

●切换准备阶段是资源落实和最后测试的阶段，目的是确认切换所有的条
件已就绪。

●切换阶段将应用投入实际运行的阶段，其中也包括切换结束的总结（无
论成功或失败）。

项目结束。

2.3生存期模型裁减
生存期模型且不意味着中外运公司的所有IT项目执行周期壹成不变地覆盖整个生存期。

不同类型的项目于生存期模型上的启动点和终止点不完全壹样，需要根据项目的特征选择项目生存期且根据具体情况对项目生存期进行剪裁。

2.3.1内部项目
内部项目的特征是项目的管理和资源的控制均于ITO内部，因此可由ITO的壹个项目经理负责整个项目生存期的过程和工作产品。

实际上，这就是基本项目生存期的应用，具体如下：
项目立项（略）
项目执行：
项目执行阶段由壹个SOW启动，项目经理根据该SOW制订项目初步计划，
计划可于各个阶段里程碑结束后进行调整。

2.3.2外包项目
外包项目的特征是项目的管理和资源的控制均于ITO 外部，ITO 代表中外运公司向外包公司发出需求且定义完成条件。

ITO 项目经理的责任是负责提供合理的公司业务对IT 系统的要求且负责确认项目输出的有效性，具体如下：
项目立项（略） 项目执行：
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设备（包括软件）的采购项目，具体如下：
项目立项（略）
项目执行：
ITO
2.3.5混合型项目
当壹个IT项目较复杂时可能包括了自行开发、合作部分、外包部分以及采购部分。

于这种情况下可将项目分解成若干子项目，每个项目参照上面适用的生存期分别进行管理。

三、IT 项目过程
下述模型是个简化的IT 项目执行过程模型，该模型包括了最基本的控制环节、分解原则和实施过程等要素。

项目执行过程模型图示如下：
项目立项（略） 项目执行：
3.1启动
IT 项目于执行阶段必须有壹个正式的启动文件SOW 。

正式的含义包括：
●
来自于可下达任务的授权机构 ●
具有明确的主管人（发起人） ●
指定了项目经理
●
清晰的任务陈述（SOW ）
SOW 定义了项目执行阶段的开始。

3.2项目分解和计划
当项目经理接到任务书后，假设对任务书没有任何疑义，那么项目经理需要执行的第壹个过程是进行项目计划，这样才能保证项目有序的执行。

由于直接面向任务书中SOW进行计划会很难，特别是其中描述的任务规模很大时更是如此。

壹个有效的方法是将项目执行分为若干阶段，然后按阶段进行规划。

例如将项目执行分为如下的三个阶段：
项目执行：
当然，如果上述阶段划分太粗，仍能够进壹步细化，例如将“设计”分为“系统设计”和“单元设计”，将实现分为“编码”、“测试”和“集成”。

如果有必要，仍能够增加壹些阶段，如于“需求定义”和“设计”之间增加壹个“技术选择”的阶段来专门分析采用什么技术对系统开发最有效。

3.3项目实施
项目实施是项目计划的执行。

为了能够知道项目进展是否符合项目计划，需要对实施过程进行监控。

监控的方法是每隔壹个固定的时间对项目状态进行壹次检查，然后和计划进行比较。

如发生了偏离，则进行纠正。

仅仅按固定的时间间隔检查项目状态有时也不能及时处理项目的问题，例如于间隔之间发生了重大影响项目计划的事件，如壹项关键技术无法应用。

因此要增加基于事件的检查。

偏离纠正包括俩个方面，壹个方面是对项目工程活动和工作产品发生的偏离进行纠正，另壹方面是对计划进行修订。

这些工作必须加以控制，按严格的规范执行，否则不仅仅偏离未能解决，仍会引起新的问题。

于项目实施过程中，虽然是按项目计划进行的，但项目计划仅仅是定义了于什么时间由谁完成什么任务，没有规定如何完成这些任务。

如何完成有俩种方式，壹种是凭执行者的经验决策，另壹种是定义好完成任务的过程和模板，然后按照过程和模板进行工作。

当然，这俩种方式会结合起来。

3.4项目结束
项目计划的所有任务完成了，项目就能够结束。

项目计划确定的生存期中定义了项目的结束阶段和结束应该进行的工作。

项目结束不仅仅将项目交付件交给客户就算完成了，仍有壹些其它总结性的工作，如项目数据汇集等。

项目数据可为其它项目执行提供依据和参照。

3.5项目过程总结
壹个基本的项目管理体系应管理项目的启动、项目划分和计划、项目的执行管理以及项目的结束。

壹个更完善的项目管理体系仍应包括如何完成工程任务以及其它任务的过程。

此外，仍应包括需求开发和需求管理。

四、IT项目计划
项目计划的目的是为项目的执行和管理提供壹个合理计划。

项目计划过程域中的过程包括估计项目规模、定义项目生存期、确定项目目标、制订人员、时间和投入计划。

项目计划过程域和IT项目生存期的壹个示例关系如下：
且于第壹个阶段完成后对计划进行调整，然后实施第二个阶段。

第二个阶段完成后，交给壹个ITO内的项目开发组织，开发组织于他们承接项目的第壹个阶段（生存期模型第三个阶段）制订项目计划，且于每个阶段完成后，调整或修改计划。

计划的调整或修订且不是必需的，只有当发现计划和实际不符时才进行。

项目计划过程的目的是为执行软件工程活动和管理软件项目建立壹个合理的项目计划。

项目计划过程涉及的主要方面包括软件项目规模评估、计划责任的协商和确立以及软件项目计划的制定。

项目计划的目标为：
●项目规模估算且文档化，以保证于项目规划和跟踪中可用。

●规划项目活动和责任且文档化。

●项目关联组和人员同意所分配的责任。

根据这些目标，于ITO项目计划过程域中定义了三个过程：
●项目规模估算过程
●项目规划过程
●项目责任分配过程
4.1项目规模估算过程
4.2项目规划过程
4.3项目责任分配过程
4.4项目采购计划
采购规划是确定哪些项目需求能够通过从项目组织之外采购产品、服务或成果，从而最好地满足某些项目需求，是项目团队于项目实施过程中能够自行满足的过程。

它涉及是否需要采购、如何采购、采购什么、采购多少，以及何时采购等。

当项目从实施组织之外取得项目履行所需的产品、服务和成果时，每项产品或者服务均必须经历从采购规划到合同收尾的各个过程。

采购规划过程包括对每项外购决策涉及的风险，及就风险缓解或风险转移进行审核。

中国外运信息化建设中的IT采购工作分成项目采购和日常采购，日常采购包括但不限于个人电脑及配件的采购。

日常采购于每年年底制订采购计划，且通过项目采购方式选定合格经销商和购买产品种类，有效期1年。

日常采购均从选定的合格经销商中选择。

日常采购由具体采购人于合格经销商中采取俩人（含）之上询价的方式进行，部门负责人负责监控是否按流程进行，且抽查报价。

主管（副）总经理能够确认部门负责人的签字，也能够再次抽查。

项目采购需成立采购项目组，项目组应根据情况，于符合法律关联规定的前提下，以公开招标、邀请招标或者内部议标的方式选择设备供应商。

五、IT 项目监控
项目执行监控的目的是关注项目进展情况且对发生的偏差及时进行纠正。

项目执行监控的依据是项目计划，凡是计划了的内容，均需要进行监控，例如投入和时间安排。

项目计划过程域和IT 项目生存期的关系如下图所示：
箭头所示是项目执行监控的壹个应用场景。

壹般项目监控采用定期评审，例如按周的定期评审。

于每次定期评审中，检查项目是否偏离了计划。

若发生了偏离，则立即采取纠正措施。

此外，项目执行监控也可能是事件驱动的，壹旦于定期评审之间发生了重要的项目管理事件，如发生了某种风险，则进行基于事件的
评审，且根据评审结果采取相应措施。

每次评审的内容和结果要向所有关联人员通报，关联人员包括项目人员、用户和企业关联主管。

通报通常采用定期项目简报的形式。

项目监控过程的目标为：
按照计划跟踪项目的实际结果和执行性能。

监控点 监控点 监控点 监控点 监控点 监控点 监控点 监控点 监控点 监控点 监
控点
监控点
●当实际结果和执行性能偏离计划时，要采取纠正措施且对其进行管理。

●保证关联人员和组织同意所改变的责任。

根据上述目标，项目监控过程域包括四个过程：
●项目定期评审过程
●基于事件的评审过程
●偏离纠正过程
●计划修订过程
项目评审过程分为定期评审和基于事件评审。

定期评审是正常的周期性评审，基于事件的评审是当发生了严重影响项目进展事件时进行的评审。

基于事件的评审由项目经理根据具体情况决定。

偏离纠正过程用于控制管理项目进程中发现的问题和问题的处理。

计划修改过程用于控制和实施计划的变更，保证变更后的计划仍然具有合理性。

5.1项目定期评审过程
5.2项目事件评审过程
5.3偏离纠正过程
5.4计划修订过程
5.5项目采购监控
于进行项目采购的决策过程中，应考虑项目预算等制约因素。

实施组织的长远战略也是于采购监控中应考虑的内容。

如果决定外购，则反映了实施组织的长远规划和项目的当前需要。

例如，决定购置某种开发平台或数据库，不是临时使
用，而是希望获得长期支持。

从项目经济效益上见可能合算，也可能不合算。

可是如果实施组织需要长期使用该开发平台或数据库，则分摊到项目上的那部分购置费用就有可能低于临时使用的费用。

于进行项目采购时，应成立采购项目组，且对项目采购的过程进行监控。

采购项目组包括业务部门和信息管理部的主管领导及关联负责人员和经办人员，必要时请企划部、财务部等部门参加。

根据《中国外运股份XX公司投资管理制度》，超过三百万的项目采购，仍要上报股份公司，经批准后方可执行。

项目采购流程如下：
1.起草立项方案
项目组根据项目需求描述决定何时采购何物，制定相应的采购计划且起草立项方案，通过内请流程上报公司审批。

审批通过后，成立IT采购项目组，且确定项目组成员。

2.确定采购方式
经IT采购项目组讨论通过后，决定采购方式，主要包括三种方式：公开招标、邀请招标、询价采购。

3.供应商的选择和询报价
IT采购项目组应根据备选供方的报价单进行评定，即进行供应商的选择。

4.确定供应商和价格
IT采购项目组经过讨论，最终确定供应商和采购产品的价格。

5.签订合同
IT采购项目组和产品供应商谈判后签署采购合同。

6.合同执行
产品供应商按合同规定履约，IT采购项目组成员负责产品验收。

7.价款结算
IT采购项目组负责办理和产品供应商的价款结算。

8.填写IT采购申请/处理单
IT采购项目组负责填写IT采购申请/处理单。

六、IT项目审核
IT项目审核过程是壹种正式的评审，需要较高的资源投入，因此且不意味着所有IT项目交付件均要进行正式的审核。

审核对象的确定由项目经理于项目计划时根据质量风险来确定。

IT项目审核包括三个部分：审核计划、审核执行、审核问题纠正，这三个部分描述如下：
审核计划
审核计划是基于项目计划确定的审核对象和标准的审核过程来定义审核目标、资源计划和时间计划。

于项目计划中，需要确定审核对象和相应的审核主持人，和此同时于计划中分配审核主持人审核计划和审核执行任务。

于壹个项目中不同阶段会对不同的交付件进行审核，这些审核的主持人能够是不同的。

壹个主要的原则是审核主持人不能是交付件的责任人。

审核执行
审核执行包括审核准备、召开审核会和建立审核记录。

审核准备包括审核对象资料准备、审核人员熟悉所负责的审核内容。

审核会壹般不超过俩个小时，否则效率会大大降低。

审核会的目的是审核交付件是否满足相应的准则，而不是审核人的能力和具体采用的开发方法、技术的正确和否。

审核记录要记录审核过程发现的缺陷，缺陷属性，例如严重程度、来源（本阶段产生的，仍是前面阶段遗
留下来的）等。

审核问题纠正
审核问题纠正是解决审核中发现的缺陷。

审核问题的纠正要加以跟踪，直到全面完成。

6.1审核计划过程
6.2审核执行过程
七、IT项目需求开发和管理
7.1需求开发的步骤
系统需求是通过壹系列步骤逐步转化得到的。

这些步骤可能执行壹次，就可得到开发人员所要的系统规格定义，但更多的是重复地执行多次来确定系统规格定义。

需求开发的基本步骤如下：
●确定项目范围
●获取客户需求
●分析客户需求
●制订系统规格
●验证系统规格
●系统规格受控
确定项目范围
项目范围本身往往于项目开始时也不是很容易确定。

客户是壹个群体，不同层面的人员因处于不同的地位会对项目含义有不同的认识。

有时于同壹范围概念下，也会有不同内容的理解。

这个阶段的目的是建立壹个统壹的项目视图且于这个视图的基础上对项目范围取得共同的认识。

项目视图需要采用客户容易理解的图示来表达，例如系统环境关联图，系统功能层次图、系统于业务价值链中的位置等。

利用这些图示来进壹步刻画和描述系统范围要素，如支持的用户类别、系统特征、基于的环境和支持目标等。

项目范围实质上是客户需求的壹个部分且且是壹个重要的部分。

项目范围为项目任务圈定了壹个问题考虑范围。

随着需求分析的进展，项目范围会发生变化，这些变化应及时反映到关联的文档中，且及时知会关联的人员。

获取客户需求
项目范围定义是项目宏观的需求析取，为了能够真正开发壹个应用系统，必须全面了解客户对系统的要求。

由于客户不是系统分析人员，因此这个阶段的目的是确定有效的方法，然后利用所确定的方法从相对分散的需求源，系统化地获取客户需求。

获取客户需求方法的基本原则是系统地定义需求类别、建立统壹的需求表达、识别和规划需求获取的渠道。

系统地建立需求类别能够将壹个大的问题分解为若干小的问题，同时可帮助客户需求获取人员完备地收集客户需求。

建立统壹的客户需求表达可壹致化和规范化得到的需求，为后面的工作提供壹个良好的基础。

识别和规划需求渠道可有效地配备资源。

需求获取渠道不仅仅是按确定用户类别的访谈，也包括业务资料的分析等其它方面。

分析客户需求
获取的客户需求难以直接转化为系统规格定义，因为这些需求往往是概要性的、壹般情况下不会完备、相互之间可能存于不壹致。

因此这个阶段的目的是对获取的需求系统地加以分析，建立壹个相对完整的系统概念模型，如系统交互模
型。

通过系统概念模型的建立来细化、补充需求、消除需求中的不壹致性。

这个阶段会继续执行上个阶段的工作，以解决已经获取需求中的问题且补充分析客户需求所需要的进壹步信息。

这个继续工作不是简单的重复需求获取的工作，而是针对客户需求分析中发现的问题。

客户需求分析技术包括许多类型，如非常形式化的建模计划和简单的业务场景分析技术。

具体技术的采用取决于客户需求的复杂程度、客户的背景以及分析人员对技术的掌握等诸多因素。

此外，分析技术的采用也取决于是否有有效的工具支持，特别是基于图形的分析技术。

制订系统规格
系统分析人员必须给系统设计人员提供完整、清晰、明确的系统设计要求。

因此这个阶段的目的是基于客户需求和对客户需求的分析结果建立书面的系统规格定义。

这个规格定义不仅仅作为设计人员的设计依据，也将作为系统验证的依据。

同客户需求分析壹样，系统规格定义也包括许多类型的方法和技术，如形式化的定义方法和自然语言的描述。

壹个理想的情况是分析模型和定义模型采用相同的技术。

这样不仅仅能够平滑地联结分析客户需求和制订系统规格这俩个阶段，同时也可大大提高工作效率，因为分析模型的结果可被重用到规格定义中。

同样，具体技术的采用也和客户需求阶段相同。

验证系统规格
系统规格定义壹旦确定，将作为开发依据贯穿于整个项目开发活动中。

因此如果规格定义存于缺陷，将会产生很高代价的质量成本。

此外，系统规格是通过。