头寸管理系统模板itms t-2514e项目管理计划v1

1、宁波科技部【项目名称】项目管理计划信息，仅限在本行交流与使用。在【xx 项目】本文档包含宁波的中，与我行有合作关系的机构与企业可在项目允许的范围内编写、修改与阅读本文档。其他情况下，非我行组织与如需调阅本文档，需得到科技部风险合规部。任何本文档全部或部分内容到第都可能严重损害本行利益，本行保留相关法律权利。当前版本:【1.3】文件状态:草稿【正式发布】作者:【科技项目经理】确认者：【业务项目经理】批准者：PSC版本历史【文档编写说明模版中凡【】中的文字均为模版的注释，在实际套用模版时，应将注释部分去掉。】版本作者日期修订描述变更0.7【科技项目经理】2009-11-5【草稿，提交项目小组】0.

2、8【科技项目经理】项目管理计划初稿【大中型项目在项目前完成，在 时将各分项管理计划做个介绍 后上传到OA项目章程中】【确定各分项管理计划】1.0【科技项目经理】【需求准出PSC 会议审批后定稿。此后主版本号与进度基线主版本号一致】【确定范围和进度基线】1.1【科技项目经理】【进度基线未更新时，本计划若有更新，更新副版本号】【更新 xx 章节】1.2【科技项目经理】【进度基线未更新时，本计划若有更新，更新副版本号】【更新 xx 章节】2.0【科技项目经理】【PSC 进度基线更新时，本计划更新主版本号，主版本号与进度基线主版本号一致】【更新 xx 基线】目 录1引言51.11.21.31.4编写目

3、的5读者对象5术语与缩写解释5参考资料62项目概述62.12.22.32.42.5项目背景6项目初始目标7客户与最终用户介绍8过程裁剪8假设与约束93整体目标管理计划94范围和需求管理计划95进度管理计划106成本管理计划107质量管理计划108人力资源计划128.18.28.38.48.5项目工作小组组织结构图12配备管理计划13责任分配矩阵13变更管理13绩效评价与奖惩措施149沟通管理计划1410风险管理计划1410.110.210.310.4风险管理方法14风险和问题影响矩阵14概率影响矩阵15风险登记册1511资源与采购管理计划1511.1资源1511.211.311.4网络资源16

4、硬件资源16采购计划1612开发活动及计划1712.1开发生命周期模型1713范围基线1813.113.213.313.4需求描述18产品验收标准18项目可交付成果18项目的除外责任1814进度基线1914.114.2项目里程碑计划19进度计划1915成本绩效基线191引言1.1 编写目的编写本文档的目的是把在项目的开发过程中对各项工作任务的员、开发的进度、经费的、硬件和资源条件等问题所作的安排用文档的形式记载下来，以便根据本计划开展和检查项目开发工作，保证项目开发成功。1.2 读者对象本文档适合以下阅读：本项目科技与业务的项目经理；本项目相关业务需求和测试；本项目相关科技设计和开发；本项目相

5、关数据中心支持；本项目相关行和业务部门；科技部相关；科技项目管理部、风险合规部以及相关内外审计；科技部门其他员工；经的本项目相关合作公司；其他。1.3 术语与缩写解释【简明本计划书中涉及的专门术语、容易引起歧义的概念、缩写及其他需要解释的内容。】缩写、术语解 释PSC负责中型及以上项目的 执行，包括可行性调研，全周期目标管控、各方利益平衡和 事项协调，一般 PSC 操作。工作小组组长一般由业务和科技分管副总担任。基线一份经过项目工作小组批准的项目计划，加上或减去经项目工作小组批准的变更。用于与实际绩效比较来确定绩效是否在可接受的偏差范围内。包括范围基线、进度基线和成本基线。1.4 参考资料【以

6、列表或排序的方式给出重要的参考资料的名称、作者、日期等信息。】2项目概述2.1 项目背景【描述项目的背景，为什么要做这个项目，所有的项目均始于某个商业问题，一般百字左右，详细的例子如：随着商业汇票使用量的不断增长和票据市场的迅猛发展，我国票据市场的发展瓶颈也日渐显现。主要表现在：票据交易采用手工、纸质方式，交易成本高、效率低、风险大；缺乏的票据市场，市场交易品种匮乏，融资性票据发展受制约；市场参与主体较少，做市商机制和信用评估机制不健全。这些企业支付和融资活动的发展，影响商业都影响了我国票据市场的进一步发展，不仅制约的业务创新，而且不利于货币政策的传导和实施。电子票据是票据业务未来发展的主要方

7、向，是票据业务创新的重要内容。现阶段，研究建立电子票据业务制度，制定电子票据技术标准，建设相关基础设施的条件已经成熟。发展电子票据是解决目前票据业务和票据市场中存在问题的一个重要方面。电子票据对提高支付服务水平和支付效率，改善票据结构和丰富票据品种，推动的区域性票据市场和性票据市场的形成，提高商业支付结算业务能力和综合竞争力，推动支付系统与电子商务系统的有机结合并以此推动电子商务发展都具有十分重要的意义。具体来说，电子票据有以下优点：一是能提高票据业务的和时效性，优化票据业务的管理和水平，全程票据业务办理的各个环节，有利于对票据业务进行汇总统计和实时监测，防范票据业务风险。采用电子票据后，能大

8、大提高自身的内控水平和机构的水平，遏制名称作者部门日期【项目名称】可行性分析【科技部一部】【2009-10-21】。项目范围在我行科技开发项目中，特指所有包含在项目内的交付物及服务【QC】【HP 的测试管理工具，全程Quality Center。用于管理整个测试过程，包括测试需求与测试案例的编写，测试案例的执行与结果记录，与缺陷生命周期等】【】【客户关系管理】承兑、贴现承兑汇票等行为，减少票据的发生。二是推行电子票据能克服纸质票据易遗失、损坏和遭的缺点。电子票据在系统中，通过可靠的安全认证机制能保证其唯一性、完整性、安全性，降低纸质票据携带和转让的风险。三是能抑制假票、克隆票。在目前的纸质票据

9、中，票据本身以及签章是伪段。虽然在票据的纸张和印制过程中，应用了很多防伪措施，但是仅凭人工肉眼辨别真伪仍存在很大的，一些分子利用、变造的票据凭证和签章骗取和客户的时有发生。推行电子票据后，使用经过安全认证的电子数据流和可靠的电子签名，能够抑制假票和克隆票。四是推行电子票据后，能节省成本，提高票据的标准化水平，简化交易过程，提高交易效率。五是有助于的票据市场的形成，促进的连通和发展。】项目名称：【与项目管理名称保持一致性】项目：【前需要完成项目立项，完成后获取项目】牵头业务部门：其他相关业务部门：主办部门：相关系统：2.2 项目初始目标目标设定 PSC 会议制定的项目初始目标包括业务、质量、范围

10、、需求、成本和进度六个方面，具体如下：【业务目标：业务通过这个项目想要达成的商业或管理目标，从可行性分析中摘录。例如综合合报表于一体，以实现提供一个集产品参数管理、销售、登记过户、客户风险及综的客户视图、产品视图、资产视图的综合性总体解决方案。市场类项目还应包括可测量的预期市场收益，比如预期正式上线 6 个月总x 笔，日均交易额 x 万元，模拟利润 x 元。数 x 个，日均交易质量目标：项目在质量上的要求预估。正式上线后三个月中以上 bug 数少于 x 个，6 级及以上故障/事件 0 次，业务对功能需求/非功能需求满意度达到x。】范围目标：【包括项目所需完成的所有交付物。】见 2.4 “过程裁

11、剪”。【概括成本进度初始目标估算说明中的需求目标，成本目标和进度目标。例如需求目标：项目完成业务目标所需实现的全部需求的量化预估，以方便工作量估算。比如对外接口 80 个（20%）、复杂交易 6-7 个、普通交易 50 个（20%）、数据迁移。外围系统：系统 20 个（25%）交易、系统 40 个（25%）交易、大前置系统 60个（25%）接口。成本目标：在保证质量目标的前提下，完成项目所有范围目标和需求目标的直接成本要求。比如计划完成全部项目工作投入小于 xx 人月，其技 xx 人月，业务 xx 人月，外包xx 人月。软硬件采购控制在 xx 万之内，其中xx 万，硬件 xx 万，实施 xx

12、万。进度目标：在保证质量目标的前提下，完成项目所有范围目标和需求目标的直接时间要求。比如乐观日期 1-悲观日期 1 第一批上线试运行，包括x 模块；乐观日期 2-悲观日期 2 第二批上线试运行，包括】x 模块；乐观日期 3-悲观日期 3 全部正式上线。约束指项目受到的各种条件和资源的限制，如必须在x 日上线（xx 报表 1 月 1 日必须上报）；项目组中 1 个成员无法全勤（业务部门一段时间不在项目里，开发出差或机构要完成其他项目外工作）；在项目开发过程中应当遵循的标准或规范（，求，我行制度规范），相关项目对本项目造成的。】3整体目标管理计划目标设定 PSC 会议设立项目的初始目标，包括范围、

13、成本、进度各分目标，偏差控制在【（最大 25%）】内，在初始目标确认表。需求准出 PSC 会议将批准设立项目基线（范围、成本、进度），偏差计划控制在【（最大 10%）】内，在基线确认表。此后项目实施以基线计划为准，当项目实际进展超出基线且难以追回时，科技项目经理需及时组织召开基线变更 PSC 会议变更基线，在基线变更表。无论设立基线还是变更基线，若成本和进度基线在初始目标范围内，由工作小组组长签署生效，否则需提交项目小组签署。4范围和需求管理计划初步计划在【x 月 x 日】前完成需求规格说明书，在【x 月 x 日】前通过各方需求评审，基本解决评审遗留问题。计划在【x 月 x 日】前召开需求准出

14、 PSC 会议，确定需求基线和项目范围基线。若因需求工作延误到时无法确定整个项目的需求，PSC 会议将仅对已明确部分做需求准出，确定已明确部分的需求和项目范围基线。【若分批准出，表述如下：计划在 x 月 x 日前召开 xx 模块需求准出 PSC 会议，确定 xx模块需求基线。】需求基线设立前，设计开发责任由需求规格说明书编写质量不合标准的需求，由此引起的返工及延误承担。需求基线设立后，任何对既定基线范围内的需求理解错误、无法实现等造成的变更、返工及延误责任由设计开发承担。任何模块未设立基线前，不得开展详细设计和开发工作，由此造成的延误，责任由造成需求延期的门承担。或部需求和项目范围基线一旦设立

15、，一般情况下，单次大于【x】人天的变更仅在项目变更管理流程批准后才被接受。本项目【全周期内/一期等某阶段】预留需求和项目范围的“变更储备”共计【x 人天/人月（请在进度计划里预留）】，当累计变更量超出“变更储备”时，科技项目经理需在一周内组织召开基线变更 PSC 会议，PSC 将批准设立新的基线和变更储备。需求变更影响的工作量评估应累加所有由于这个变更引起的管理、需求、设计、开发、测试等活动的工作量。项目经理月底向 PSC 汇报时，需整理本月项目范围变更情况。5进度管理计划本项目采用滚动式规划技术规划项目进度。在制定进度计划时，遵循交付物到任务，任务到人，分解到周的原则。具体到天的工作分配在项

16、目组每周计划中。中安排，无需体现在进度【（可选）本项目为风险设立应急储备，并将储备的使用情况纳入进度管理中。储备值根据风险登记册中除需求和范围变更外的其他所有风险的风险值总和计提。】项目前，根据给出的需求目标，制定进度目标。作为需求结束的里程碑任务，需求准出 PSC 会议召开时间应预先确定，该任务是否按时按质完成纳入项目进度目标的考核中，因此在立项初期项目经理应确定需求阶段的详细计划，项目各方一致同意后应严格遵守该计划，承担延误的责任。需求准出 PSC 会议将批准设立进度基线。此后项目实施以基线计划为准，当项目实际进度超出进度基线且难以追回时（包括提前结束或延期结束），科技项目经理需及时组织召

17、开基线变更 PSC 会议。无论进度是否正常，项目经理在月底向 PSC 汇报根据汇报模板如实汇报项目进度和里程碑完成情况及偏差分析，制作图。测试阶段是否执试单元测试执行不执行冒烟测试执行不执行集成测试执行不执行系统测试执行不执行用户验收测试执行不执行非功能性测试环节：测试环节是否执试管理部联系人性能测试执行不执行兼容性测试执行不执行7.2 测试方案【在需求准出节点，需细化测试方案】对于系统及测试相关工作的管理计划，参考测试方案。人力资源计划8.1项目工作小组组织结构图项目工作小组组长 牵头业务和科技分管副总PSC主要业务和部经理、项PM技术 PM、业务 PM、外包 PM项目 QA项目管理部 QA

18、A 团队B 团队C 团队成员一成员一成员一成员二成员二成员二成员三科技二级目管理部8.2配备管理计划【说明何时以及如何满足项目对人力资源的需求。例一本项目计划从 2011 年 7 月持续到 2011 年 11 月，每个月计划投入：科技部开发 3 人，运营部业务 2 人，外包支持 5 人。累计约 50 人月。例二本项目每月计划人力资源投入如下表所示：】8.3 责任分配矩阵【 通过清晰地 RACI 图来明确项目各交付成果或活动的责任人，以明确。当项目较大，参与人数较多时，可以在多个层次上制定RACI。例如次的 RACI 可定义项目团队中的各小组分别负责哪些交付物，低层次的 RACI 则可在各小组内

19、为具体工作分配角色职责和职权。】阶段/月份月数每月科技投入每月运营部投入每月外包投入阶段累计投入需求2设计开发与单元测试集成与系统测试UAT 测试233522试运行11135总计7151733658.5 绩效评价与奖惩措施科技项目经理应监督和关注外包勤情况，按照综合部的要求提交相关的出勤和表现，。/周】外包日常出9沟通管理计划10.3概率影响矩阵10.4风险登记册概率风险值0.90.050.090.180.360.720.70.040.070.140.280.560.50.030.050.10.20.40.30.020.030.060.120.240.10.010.010.020.040.08

20、0.050.10.20.40.811.3硬件资源11.4采购计划采购内容数量责任人外部责任人采购提交日期计划收货日期名称级别数量成本项目中的用途获取方式与时间方pc关键/普通1开发环境已存在/借用/免费获取关键/普通1测试环境应用已存在/借用/免费获取测试环境数据库。生产数据库。生产备份网关器。192.1681.1192.172.1.181长需要无线网络，应用12开发活动及计划12.1开发生命周期模型【说明所采用的开发生命周期模型，如瀑布模型、编码修正模型、螺旋模型、修改后的瀑布模型、渐进模型、阶段交付、面向进度的设计、面向开发工具的设计等模型。】13 范围基线13.1需求描述【详细需求请参考xx 项目需求规格说明书】13.2产品验收标准【定义已完成的产品、服务或成果的验收过程和标准例如：运营部验收测试通过；科技部性能测试通过；系统上线 3 个月稳定运行没有x 级及以上故障/事件发生；系统满足 1000 人，xx 指标x。】13.3项目可交付成果【可交付成果除上线的系统外，还包括各种文档交付物，培训等服务。此处列出项目所有可交付成果。科技项目中，典型的可交付成果包括：Xx 范围的源代码、可运行系统；各管理规范定义的交付物；见 2.4其他可能的交付物包括但不限于：数据库设计、缺陷列表、各种培训及培训材料、各种手册指南、各种过程文档表单等。】13.4