文件《IT项目管理办法》Word格式.docx
《文件《IT项目管理办法》Word格式.docx》由会员分享，可在线阅读，更多相关《文件《IT项目管理办法》Word格式.docx（42页珍藏版）》请在冰豆网上搜索。
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.项目的特征：
●目标确定性
●时限性
●一次性
●独特性
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应用的部署会涉及到多个部门、多个场所和不同的内部和外包资源，因此应用部署往往会作为一个独立的项目进行。
应用部署项目生存期模型就是用于此目的而建立的，该模型图示如下：
●应用部署阶段是一个准备阶段，主要目的是进行实施策略、实施方法、相关人员、时间以及试点等方面的总体规划和所需资源的准备。
●试点发布阶段是实施策略和实施方法的测试阶段，主要目的是确认实施策略和实施方法的可行性并获取用于全面部署的经验。
在应用部署规划时，如果确认试点发布无必要（例如，曾有过类似产品的发布），则可忽略此阶段。
●实施计划制定阶段是应用部署的详细计划阶段，目的是确定具体的应用部署活动步骤。
如果应用部署涉及到多个部门，该阶段也包括每个部门的行动计划。
●特殊需求处理阶段包括识别和解决一些部署点的特殊的要求，目的是保证部署活动不会因为这些特殊要求而受到阻碍。
●切换准备阶段是资源落实和最后测试的阶段，目的是确认切换所有的条件已就绪。
●切换阶段将应用投入实际运行的阶段，其中也包括切换结束的总结（无论成功或失败）。
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.4采购项目
外包项目和合作项目本质上也是采购项目，是IT服务的采购。
因此IT服务采购项目的生存期参照上面2.3.2节和2.3.3节。
本节描述的是IT设备（包括软件）的采购项目，具体如下：
供货程序
供应商
同样，内部以SOW启动来确定设备采购的需求以及采购原则与策略（系统概念确定）。
这些内容确定后形成采购标书，进而形成采购合同。
供应商按其自己的供货程序工作。
如果必要，可在他们的供货程序中插入质量检验的审核点。
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在项目初始制订了计划，并在第一个阶段完成后对计划进行调整，然后实施第二个阶段。
第二个阶段完成后，交给一个ITO内的项目开发组织，开发组织在他们承接项目的第一个阶段（生存期模型第三个阶段）制订项目计划，并在每个阶段完成后，调整或修改计划。
计划的调整或修订并不是必需的，只有当发现计划与实际不符时才进行。
项目计划过程的目的是为执行软件工程活动和管理软件项目建立一个合理的项目计划。
项目计划过程涉及的主要方面包括软件项目规模评估、计划责任的协商与确立以及软件项目计划的制定。
项目计划的目标为：
●项目规模估算并文档化，以保证在项目规划和跟踪中可用。
●规划项目活动和责任并文档化。
●项目相关组和人员同意所分配的责任。
根据这些目标，在ITO项目计划过程域中定义了三个过程：
●项目规模估算过程
●项目规划过程
●项目责任分配过程
4.1项目规模估算过程
过程名
项目规模估算
过程标识
PP-01
目标
软件规模估算并文档化，以保证在项目规划和跟踪中可用。
进入条件
SOW（任务书）下达，并详细描述了任务范围。
参与角色
1.项目经理（由SOW确定）
2.项目人员（由SOW或项目经理确定，包括项目经理）
3.相关评审人员（由项目经理确定）
4.项目主管（高层项目主管经理，由SOW确定）
输入
SOW
过程步骤
输出
序号
描述
项目经理根据SOW确定项目工作分解（WBS:
WorkBreakdownStructure）的策略和估算准则，其中包括估算单位、估算方法、估算争议处理等。
-WBS策略
-估算准则
项目经理向项目人员分配项目分解任务。
（如果项目规模不大，可由项目经理本人独立进行项目分解和任务规模估算工作。
）
项目人员根据WBS策略和估算准则对项目进行分解估算，分别建立各自管辖任务的WBS和相应的任务规模估算。
项目经理负责进行汇总。
-项目任务分解（WBS）
项目经理组织有关人员对WBS进行评审并根据评审结果对WBS以及估算进行修订。
评审的目地是保证分解没有遗漏、重叠等问题；
规模估算有依据。
-修订的项目WBS和任务规模估算
项目主管对WBS和估算结果进行审核。
审核的目的是保证项目范围理解正确、分解策略正确、估算结果合理。
-审核通过的项目WBS和任务规模估算
项目经理负责整理上述步骤的输出，形成项目规模估算文件。
-项目规模估算文件
完成标志
1.项目WBS和任务规模估算通过项目主管审核。
2.形成项目规模估算文件（过程提交产品）。
4.2项目规划过程
项目规划过程
PP-02
规划项目活动和责任并文档化。
项目规模估算完成。
2.相关评审人员（由项目经理确定）
3.项目主管（高层项目主管经理，由SOW确定）
1.SOW
2.项目规模估算文件
项目经理根据SOW确定项目具体目标和项目交付件。
-项目目标描述
-项目交付件清单
确定项目策略，其中包括项目组织结构。
-项目组织图等
项目经理根据SOW确定项目生存期模型。
-选择的生存期模型
项目经理根据SOW、项目生存期模型和规模估算文件确定投入的资源，包括人力资源。
-项目资源投入表
项目经理根据SOW、项目生存期模型和规模估算文件确定项目时间安排。
-项目时间计划表
项目经理根据SOW、项目生存期模型和规模估算文件确定投入的资金。
-项目资金计划表
项目经理对项目可能的风险进行分析并对高风险给出控制策略。
风险分析是基于项目目标和项目计划的，即影响项目目标和计划可能发生的事件。
-项目风险控制表
项目经理基于上面的输出，产生项目计划草案。
-项目计划草案
项目主管召集有关人员对项目计划进行评审。
项目经理根据评审意见对项目计划进行修订，形成正式项目计划文档，并由项目主管根据项目确认。
-项目计划评审报告
-项目正式计划文档
1.项目计划经过评审。
2.正式项目计划文档产生。
4.3项目责任分配过程
项目责任分配过程
PP-03
项目相关组和人员同意所分配的责任。
项目正式计划形成。
2.项目组成员（由项目计划确定）
项目计划
项目经理根据项目成员和时间计划生成每个人的任务时间计划并发放给各个项目成员。
-个人项目任务时间计划
各个相关人员确认所分配的责任，其中包括：
●分配的任务和时间是合理的。
●可满足完成任务所需要的业务要求。
●可满足完成任务所需要的时间要求。
若不能确认上述一项或若干项条件，则将情况反馈给项目经理。
-个人项目任务时间计划确认结果
项目经理根据反馈情况对计划进行调整，并对变化的人员责任重复上一步骤。
若有影响较大的调整，如关键人员的调整需得到项目主管的批准。
若无调整，则跳过此步骤。
-调整的项目计划
项目经理发布项目计划，发布对象包括：
●项目主管
●项目组成员
其他项目相关组织或人员（如文档管理部门）
1.计划经过所有项目相关责任人员的确认。
2.对无法承担项目责任进行调整并反映到计划中。
3.调整的计划向所有有关人员发布。
4.4项目采购计划
采购规划是确定哪些项目需求可以通过从项目组织之外采购产品、服务或成果，从而最好地满足某些项目需求，是项目团队在项目实施过程中可以自行满足的过程。
它涉及是否需要采购、如何采购、采购什么、采购多少，以及何时采购等。
当项目从实施组织之外取得项目履行所需的产品、服务和成果时，每项产品或者服务都必须经历从采购规划到合同收尾的各个过程。
采购规划过程包括对每项外购决策涉及的风险，及就风险缓解或风险转移进行审核。
中国外运信息化建设中的IT采购工作分成项目采购和日常采购，日常采购包括但不限于个人电脑及配件的采购。
日常采购在每年年底制订采购计划，并通过项目采购方式选定合格经销商和购买产品种类，有效期1年。
日常采购均从选定的合格经销商中选择。
日常采购由具体采购人在合格经销商中采取两人（含）以上询价的方式进行，部门负责人负责监控是否按流程进行，并抽查报价。
主管（副）总经理可以确认部门负责人的签字，也可以再次抽查。
项目采购需成立采购项目组，项目组应根据情况，在符合法律相关规定的前提下，以公开招标、邀请招标或者内部议标的方式选择设备供应商。
五、IT项目监控
项目执行监控的目的是关注项目进展情况并对发生的偏差及时进行纠正。
项目执行监控的依据是项目计划，凡是计划了的内容，都需要进行监控，例如投入和时间安排。
项目计划过程域与IT项目生存期的关系如下图所示：
箭头所示是项目执行监控的一个应用场景。
一般项目监控采用定期评审，例如按周的定期评审。
在每次定期评审中，检查项目是否偏离了计划。
若发生了偏离，则立即采取纠正措施。
此外，项目执行监控也可能是事件驱动的，一旦在定期评审之间发生了重要的项目管理事件，如发生了某种风险，则进行基于事件的评审，并根据评审结果采取相应措施。
每次评审的内容和结果要向所有相关人员通报，相关人员包括项目人员、用户和企业相关主管。
通报通常采用定期项目简报的形式。
项目监控过程的目标为：
●按照计划跟踪项目的实际结果和执行性能。
●当实际结果和执行性能偏离计划时，要采取纠正措施并对其进行管理。
●保证相关人员和组织同意所改变的责任。
根据上述目标，项目监控过程域包括四个过程：
●项目定期评审过程
●基于事件的评审过程
●偏离纠正过程
●计划修订过程
项目评审过程分为定期评审和基于事件评审。
定期评审是正常的周期性评审，基于事件的评审是当发生了严重影响项目进展事件时进行的评审。
基于事件的评审由项目经理根据具体情况决定。
偏离纠正过程用于控制管理项目进程中发现的问题和问题的处理。
计划修改过程用于控制和实施计划的变更，保证变更后的计划仍然具有合理性。
5.1项目定期评审过程
项目定期评审过程
OM-01
按照计划跟踪项目的实际结果和执行性能。
到达项目评审时间
项目经理根据项目计划本阶段要求完成的内容，收集各个项目成员的任务完成状态。
-项目进展状态
项目经理将各个项目成员任务完成的状态与计划进行比较。
若项目经理认为出现与计划的重要偏离，则与相关项目人员分析偏离原因，提出纠正措施，纠正措施包括对偏离的纠正或对计划的修改。
对不是重要的偏离，则不提出纠正措施，而是列入到下次评审关注对象。
偏离程度的判断由项目经理负责。
-偏离纠正措施
项目经理审查以前定期评审确定关注的偏离问题（如存在的话），并确定是否采取偏离纠正措施。
-偏离纠正措施（若存在需纠正的偏离）
项目经理审查
升级会员 