项目实施规范Word格式文档下载.docx
《项目实施规范Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《项目实施规范Word格式文档下载.docx（22页珍藏版）》请在冰豆网上搜索。
♦项目标准规范宣导，系统间接口相关问题的管理和协调；
♦负责项目的过程跟踪，协助各子项目组完成重要工作的落实；
♦负责项目采购管理、文档和测试管理。
♦负责各子项目组的集成方案的审核与验证。
同时按集成检查点检查本项目及子项目集成工作，对施工组织方案、组织设备现场调试，现场的安装督导、设备和环境的兼容性验证；
♦负责项目周报的编制与发布；
♦完成业主交办的临时任务。
二、项目组横向管理组织及职责
（1）生产扩容子项目组职责
♦完成二期应用系统开发、通用软硬件采购及安装、调试、集成测试（部分）等工作，二期系统上线与一期系统并行运行。
♦完成清分模型系统开发、通用软硬件采购及安装、调试、集成测试等工作：
♦完成与信息中心系统接口定义、设计、开发和联调测试，能够为信息中心系统提供数据。
（2）扩容子项目组职责
♦新线接入相关工作
♦系统优化升级，新线接入工作的工作目标是完成接入测试，并完成新线接入相关应用生产系统部署与调试，确保系统具备正式接入的条件。
系统优化的年底工作目标是完成所有子系统的软件需求及详细设计的确认，并完成所有子系统的开发及内部模块测试工作，以便在明年顺利开展工厂测试，联调测试等正式测试工作。
♦完成与年底信息中心应用系统需要的接口开发
（3）集中显示平台组
负责集中显示平台工程实施，实现年底系统验收并上线试运行。
（4）基础设施平台组
基础平台建设是本项目正常上线试运行的前提和保证，它包括ACC生产系统扩容、TCC系统扩容、信息中心系统工程的机房基础设施建设、网络及安全系统部署、服务器及存储系统（含数据仓库软硬件）部署等工作。
（5）数据中心组
♦数据仓库对接入源系统的调研
♦数据仓库对源系统的接入以及历史数据的加载
♦数据仓库对应用系统的数据支撑
♦非结构化硬件采购、硬件安装部署；
非结构化产品采购、非结构化产品安装及部署；
主要完成业主提出的第一批次非结构化数据录入工作。
4实施规范的内容
围绕敏捷、高效、务实的目标，本规范分沟通管理、文档管理、风险管理、变更管理、测试与交付管理、质量管理、应急管理、考核管理八个方面的内容。
4.1沟通管理
本节用于指导项目全过程的沟通工作、沟通方法、沟通渠道等各方面的计划与安排。
通过描述本项目实施全过程中进行沟通工作时需要采用的沟通方法、沟通渠道等方面的计划与安排，帮助项目干系人员了解沟通需求，明确需求内容、获取时间及获取渠道。
按照矩阵组织建立沟通层次的基础上，对沟通种类、沟通方法和沟通计划方面说明沟通实施过程，并对沟通方法中所借助的沟通工具给予介绍，最后对沟通活动整体作出要求及出现争议，制定争议解决制度。
4.1.1沟通类别
●内部报告
项目内部的报告机制分为书面报告和口头报告两种。
书面报告采用专门报告模版或Email的形式。
专门报告模版使用经业主、项目及监理确认的项目文档模版。
Email形式为通用的沟通方式，项目内部大部分事务沟通，交流和报告均可使用Email形式进行。
项目团队成员需要根据实际情况对所分配的任务进行完成情况的任务报告，把任务的执行情况及时地报告给相应的负责人。
报告对象根据项目的组织结构，由下至上地进行。
●项目新闻与简报
与项目相关的一些新闻与简报可由两种方式传递给所有项目成员。
对于重大的新闻或项目相关的消息可以通过邮件列表进行新闻发布或简报发布。
对于一些非重大的消息可以由相关负责人Email或口头通知所有项目成员。
●外部沟通
所有外部沟通由项目经理负责。
其他项目成员除非具有项目经理或子项目经理的授权与指派，不得与项目外部人员（包括业主）进行任何直接沟通（需求调研除外）与承诺。
●外部报告
项目外部的报告机制为书面报告。
书面报告分为项目周报、项目月报、项目季报等，报告内容包括（但不限于）项目进度、项目风险及应对措施和项目质量报告，模版使用经业主、、监理确认的项目文档模版。
●公开
任何与项目相关的信息公开活动，统一由项目经理发起与负责，其他项目成员除非具有项目经理的授权与指派，不得擅自进行任何公开活动。
●外部调查
任何与项目相关的外部调查活动，统一由项目经理或子项目经理发起与负责，其他项目成员除非具有项目经理或子项目经理授权与指派，不得擅自进行任何外部调查活动，包括任何书面调查和口头调查（需求调研除外）。
4.1.2沟通方法
项目建设期间，将使用正式的程序来促进交流。
沟通方法包括（但不限于）：
●报告
主要指项目周状态报告，项目经理将与业主方项目经理一起工作，编制状况报告，分发给业主、监理和。
●临时会议或直接交谈
按需要组织会议进行沟通，或直接与相关人员（不限于项目组成员）进行讨论，会后以邮件或会议记录形式记录沟通和讨论结果。
●电话或电话会议
对于异地或者涉及非项目实施地点人员的沟通以电话或电话会议为主，此类电话或电话会议视为与面对面会议同等的作用，要求记录沟通和会议结果，并以邮件的形式对结果进行确认。
●传真
对于重大事项，可通过传真通知业主、监理和。
●电子邮件
电子邮件可以有效提高沟通效率、降低项目成本，本项目视邮件沟通记录与纸质记录具有同样的作用，要求各方在收到需要应答的邮件时必须给予回复，未在规定期限内回复的成员，默认接受邮件发送人的安排并同意邮件发送人的意见。
●会议
项目会议必须按照规定的频度和时间准时执行，会议必须提前准备，安排主持人和记录员。
本项目涉及会议主要包括（但不限于）：
a）周项目例会：
审查总体状况、项目时间表和状况报告中提到的未决问题，提出问题，解决问题（可会上处理）；
追踪问题，风险，和依赖条件；
确定下周计划分工。
b）项目启动会议：
使项目参与人明确本次项目的目标，工作范围，本项目实施的方法及各自的角色和职责。
c）设计联络会：
承建单位向建设单位及其代表提供系统设计的信息资料及详细介绍，并提供机会讨论和澄清有关设计方面的各种问题。
d）协调沟通会：
针对项目执行过程中的遇到的风险和问题进行多方沟通协调解。
e）专题协调会（监理）/业务专题会（招标文件）:
为解决项目实施中的专项问题，合同各方与专题有关的负责人及专业人员参加的不定期会议。
f）验收会：
在初步验收、最终验收等验收环节，召开验收会。
g）技术评审会：
在项目实施过程中，根据需要甲方有权提出召开专家技术评审会，专家由甲方指定，乙方需根据技术评审会的意见和结论对系统相关内容进行整改落实。
h）其它会议：
为保证合同的顺利执行，甲方和乙方可商定在必要的时候召开会议，讨论并解决本项目工程进行中出现的问题。
说明：
本计划涉及范围为项目，对各子项目内部沟通管理由各子项目自行规定。
4.1.3沟通计划
沟通分为内部沟通和外部沟通两个方面。
内部沟通是指项目组内，与各子项目组、子项目组与子项目组间、项目组成员间的沟通动。
沟通工具
辅助上述提到的各种沟通方法，方要求各专项项目组采用统一的沟通/汇报工具，具体如下：
一、工作联系单制度
工作联系单是为了有效解决本工程实施过程中存在的问题，增加项目相关各单位之间的工作沟通而制定的联系方式。
工作联系单采用统一格式编制，适用于项目相关各单位之间有关工程的工作问题解决的联系。
工作联系单应用流程为：
1.签发工作联系单的单位依照具体要求填写联系单，经负责人审核签字后发送，并交监理单位统一登记、备案和跟踪。
2.工作联系单主送单位和涉及单位应在一周内将填写完回复意见的联系单返回签发单位，并返回建设单位，由建设单位备案。
3.每周工作联系单的情况在周例会上进行通报。
工作联系单模板如下所示：
工作联系单
编号：
主题
问题级别
□正常□急□紧急
联系人
签发时间
年月日
联系方式
签发人
发文单位
涉及单位
□建设单位□监理单位
□设计单位□承建单位
主送单位
问题描述及影响
解决建议
联系及处理要求或建议
□请审核□请审阅修改□请传阅
□请审批□请回复□其它（注明具体要求）
接收单位
接收时间
回复意见
签名：
备注
二、沟通中所示用的文档模板
本项目中各类沟通所使用的文档模板如下表所示，各子项目在沟通时如需下列模板，请向监理或来索取相应模板。
4.1.4沟通效果要求
1、会议类沟通
●各专项项目组在组织沟通会议前，要求会议召集人确认好会议资源、分发会议议题及材料，确认与会人是否准时参加，或者替代人等；
●对应评审类的会议，要求不能参加的评审人员，通过邮件给出评审意见，会议主持人需将邮件评审意见在评审会予以说明；
2、现场协调
●现场项目资源定期给予识别，出现资源短缺，要求十五日内向项目经理和业主提出资源申请。
●对于硬件采购设备的厂商沟通，各专项项目组的采购负责人在成方的牵头下组织实施采购设备的出厂检验、开箱检验等活动。
4.1.5沟通争议解决处理
●评审出现的问题争议
由评审组织者组织意见分歧人员会后进一步沟通确认，如果未果，则提交由业主、监理、组成的仲裁组进行仲裁解决。
●项目管理等方面问题争议
对于此类问题的争议解决，采用逐级汇报仲裁的方式进行解决。
即首先应向产生争议的群体所属上层负责人进行汇报，由上层负责人给予仲裁。
如果上层负责人无法给予仲裁，应继续向上汇报。
●与业主有直接关系的问题争议
对于此类问题，各专项项目组向方上报，由方为统一出口，向业主和监理进行汇报，由业主的仲裁解决。
对于沟通中出现的争议，按照由下往上、先内后外的方针，逐级进行协调和仲裁。
各级仲裁人员的职责和范围分工如下表所示：
4.2文档管理
指导本项目实施建设中的文档管理方面活动。
4.2.1文档管理方法
（1）责任划分
各子项目负责对本子项目的文档成果物进行配置管理，并需要根据的要求及时反馈成果物的状态，负责管理把握项目整体成果物的状态。
（2）受控文档类型
♦软件工程类文档：
项目实施过程中的所有输出文档；
♦项目管理类文档：
编制的项目管理体系文件、的项目管理类文档、各子项目组需向提交的项目管理类文档，如子项目计划，子项目的阶段里程碑总结报告等；
♦外来文件：
包括采购设备厂商提供的与设备相关的技术说明书/测试报告、业主提供的文件、国家标准及法律法规等；
♦图纸：
项目建设输出的工程图纸、各子项目组的图纸清单等。
（3）文档编制
1）各子项目根据所需编写文档的模板、规范要求进行文档编写；
2）各子项目组对所编写的文档进行内部评审；
3）评审通过后，文档编写人员向所在子项目组申请文档编号；
4）文档编写人员添加编号后，提交文档进行上报审批。
♦上报审批时，应按照、监理和业主的顺序，进行逐层审批。
♦对于技术方案类文档，还应通过业主指定的专家审批。
（4）文档发布
1）正式文档发布的机构有两个：
项目管理办公室和总工办，所有由发布的文档都由这两个组织向业主、监理、设计院、项目组成员。
2）各子项目组发布的文档分成两个部分：
子系统内部文档和外部文档。
♦内部文档是子系统内部交流、沟通、备案用所产生的文档，由各子系统自行管理。
♦外部文档是子系统间或各承建单位之间的交互文档，这部分文档在发布之前先以电子邮件的形式根据文档的内容发送给项目经理，由其审核后再做发布。
（5）文档发放使用
发布及管理的文档由管理员统一进行文档发放管理。
1.电子类文档，文档管理员向文档使用申请人指明文档存放的项目配置库路径，使用者通过递交申请后，由配置管理员添加相应的权限后，方可访问；
2.纸质类文档，文档使用填写文档领取申请，经相关责任人审批签字后，文档管理员复印发放，并做文档发放去向记录。
注：
对于子项目组的纸质类文档，文档管理员确认文档领取申请签字后，由子项目组文档管理员进行文档发放。
（6）文档保存与归档
文档由负责保存，各子项目文档由各子项目负责保存，各子项目有责任将子项目的文档状态及时向进行通告，由子项目组织的有多方参加的会议沟通的相关记录文档需在处备案。
文档需由专人进行管理，纸质文档需保存在文件柜中，电子文档需保存在受控的配置库中。
文档归档需按照业主的要求来实施。
（7）文档日常管理
1）每季度对文件柜进行季度盘点，核实记录与实际文档的是否一一对应，以保护记录的有效性；
2）对文件夹损坏的，及时更换，标签遗失的，及时粘贴；
3）项目组内人员发生异动，文档管理员需对文件返还情况，在工作交接单上给予签字确认。
（8）文档变更管理
1）纸质类文档变更，在文件夹中将新版本文档置顶，并根据文件递交部门的要求，保留前一版本文档至保管期限后，进行作废处理，及时更新文档归档清单；
2）电子类文档变更，在所变更的文档变更履历中添加变更内容，再次提交项目配置库。
4.2.2文档编写过程
本项目围绕着可操作性、务实的指导原则，把项目的全生命周期过程流程与要求进行梳理与划分。
从成、子项目组、监理、业主各方如何进行配合做了详细的要求与说明。
（1）各项目组工作任务和范围划分过程
和用户根据招标文件的要求和各子系统投标文件的表述，对整个项目的工作内容和范围按各子系统进行划分，划分完毕和各子系统承建商进行沟通，确认各子系统承建商的工作内容和工作范围，接口规则，项目执行计划。
研究各承建商的计划找到各系统建设过程中的相互依赖关系，对其进行分析，做为项目总体计划编制的输入条件。
（2）项目预备启动会议
完成项目面向各子系统承建商的任务划分（草案），项目实施规范（草案）、项目总体架构（草案）、接口和标准管理（草案）、基于年内的目标及实施计划（草案）后，可以召开项目的预启动会，用户、和各子系统承建商进行交互，对草案中的问题进行调整和修改形成可操作的计划和内容规范。
（3）项目启动过程
预启动会议结束后，根据业主和各承建商的意见做相应的调整，确认后召开项目启动会议，落实整个项目总体计划、实施规范、架构及标准和基于年内目标达成的实施计划，要求各承建商共同遵守。
项目启动后，由各子项目组向监理提请开工申请（项目实施总体进度计划、年内项目实施计划、技术架构、组织及资源安排），监理转发业主和，并召集内部讨论，会签监理、意见、主架构师和质量经理意见。
子项目组审核开工申请没有通过，则给出具体意见，各子项目组根据要求重新申请。
通过则由子项目组在开工申请上签字确认，并提交业主，由业主的对应进行审批，如审批通过，监理发出开工通知，并转发给成项目经理和执行副经理。
（4）项目计划过程
依本项目的特点，项目的软件开发计划有一个关键的里程碑，各子系统首先要围绕年底目标编制出自己的项目计划，上报给用户和，由和用户牵头，各子系统负责人共同参与，根据项目各项目组工作任务和范围划分的成果物对整个项目计划做调整，以实现项目年底的总体目标。
同时各子项目组还要制定整个项目的实施计划，提交计划报审表：
开发项目报软件开发计划、软件配置管理计划、软件质量保证计划；
集成项目报采购与施工组织计划、接口配合计划给成和监理，用户、、监理对计划进行讨论，会签三方意见，通过则子项目组可以按计划实施。
（5）需求分析设计过程
各子项目组在软件需求深入调研与分析的基础上，编制软件需求规格说明，并在征得业主对软件需求规格说明的认可后，提交软件需求报审表（附软件需求规格说明）给成和监理，主架构师召集内部讨论，会签监理、意见，通过则主架构师在软件需求报审表上签字确认。
审批通过则由监理组织召开需求评审会，子项目组、总工办、项目管理组、监理、在评审报告上确认签字，提交业主，由业主方进行审批。
（6）概要设计过程
软件概要设计完成后，子项目组提交软件设计报审表（附软件概要设计说明、数据库设计说明）给成和监理，业主授权、监理审核，、监理均审核通过后，由监理方将报审材料和审核意见报业主处进行备案。
项目进入详细设计和编码阶段。
业主如对收到的备案材料有异议，可要求、监理方重新审核。
（7）详细设计和编码过程
子项目组在详细设计和编码完成后，子项目组提交出厂测试计划报审表（附详细设计说明、软件测试计划、软件测试说明（含测试用例）、可执行程序生成说明等文档）给成和监理，业主授权、监理审核意见，、监理均审核通过后，由监理方将报审材料和审核意见报业主处备案。
项目进入出厂测试阶段。
在出厂测试报审前，监理方适时召集业主、子项目组、、承建方召开系统演示会，由监理方归纳各方达成一致的修改意见，形成会议纪要，责成子项目组在出厂测试阶段处理。
（8）出厂测试过程
子项目组依据出厂测试计划进行出厂测试（包括对用户文档的正确性测试），完成后提交产品交付申请表（附软件出厂测试报告、用户手册、安装部署手册、产品安装盘、产品源代码和源代码交付说明等）给成和监理，方和监理方分别出具意见（如同意则需附各方产品交付测试计划和测试说明）报业主处；
审批通过则业主在交付产品验证申请上签字确认，进入产品交付测试阶段。
（9）产品交付测试过程
和监理同时对交付产品进行测试，在任何一方测试不通过的情况下，如果达到重新出厂测试的条件，直接要求子项目组重新出厂测试，并建议业主对承建方进行惩罚；
如不需要重新出厂测试，通知子项目组进行整改，处理结果抄送业主处。
如测试通过，监理和分别编制测试报告提交业主。
业主接到监理和的测试报告后在成、监理、子项目组的配合下组织业主内部测试，如通过测试，业主组织编制业主测试报告，业主在测试报告上签字确认，由监理通知子项目组产品交付验证通过，进入系统部署阶段。
（10）系统部署过程
子项目组提交部署申请（附部署实施方案）给成和监理，业主召集内部讨论，会签监理、意见，通过则业主在部署申请上签字确认，并提交业主领导小组审批。
审批通过则由业主协调落实业主方部署运维人员，由监理通知子项目组实施部署，方现场汇同子项目组进行部署测试并在子项目组部署实施报告上签字，由子项目组报监理方，监理方审核通过并签字后提交业主处，审核通过后业主在子项目组的部署实施报告上签字确认，由监理通知子项目组提交初验申请。
4.3风险管理
为规范项目管理，保证项目顺利实施，对项目实施过程进行风险管理及防范，以防止风险对项目造成影响。
本节对专项（子）项目组内、子项目组外定义了风险汇报及处理机制，本项目部及所属各专项（子）项目部需遵从执行。
4.3.1风险管理策略
根据业主及监理的要求建立风险管理策略。
1）确定风险来源，风险来源涵盖内部风险和外部风险，包括但不限于：
2）确定风险分类。
风险的分类包括但不限于：
3）确定风险控制策略。
a.定义风险的危险度（风险一旦发生对项目造成的威胁程度）。
危险度划分为四个等级：
致命：
风险的发生会对项目的目标造成极大影响，导致目标无法完成。
严重：
风险的发生可能导致目标无法达成，或者项目计划不能顺利执行。
一般：
风险的发生对项目产生影响，但不足以影响项目目标的达成。
轻微：
项目组在现有情况下可以承担风险带来的影响。
b.定义风险的发生概率（风险发生的可能性）。
发生概率一般划分为3个等级：
高：
大多数情况下可能发生或发生的概率在75%以上
中：
某些情况下可能发生或发生的概率在25%-75%之间
低：
只在某些特定的情况下才可能发生或发生的概率在25%以下
c.定义风险的优先级。
风险优先级有助于使有限的项目资源得到最有效的应用，避免将过多的资源投入到不可避免的风险或对项目影响很小的风险上。
根据风险的危险度和发生概率，一般将优先级划分为4个等级，即I,II,III,IV，如下表：
d.定义风险管理要求。
根据风险的优先级，定义不同的风险管理要求，举例如下表：
e.确定风险缓解措施的启动标准。
风险缓解措施的启动标准用于明确在何种情况下，项目应该执行风险缓解措施。
4.3.2风险管理办法
（1）风险识别
各专项（子）项目经理组织项目成员和其他相关干系人参与风险识别活动。
参考项目部定义的风险来源识别项目的风险，将识别出来的风险记录到“风险管理表”中。
a.在进行风险识别前要明确业主和监理的管理要求，同时尽可能收集项目的有关资料，包括项目背景、项目需求、项目目标、技术方案、WBS、估计结果等，以从中识别项目的风险。
b.风险识别并不仅限于项目策划阶段，在项目执行的任何阶段，各专项（子）项目经理和项目组成员都应该关注新风险的识别。
（2）风险分析
1.各专项（子）项目经理和项目组成员对识别出来的风险进行分析，确定每个风险的分类、生存期、危险度和发生概率。
2.参考定义的风险优先级的确定方法，根据风险的危险度和发生概率确定风险的优先级。
（3）制定风险管理措施
各专项（子）项目经理和项目组成员参考定义的风险管理要求，制定风险管理措施。
1.确定风险的缓解措施。
2.确定风险的应急措施。
3.根据风险的优先级，确定风险的跟踪频率。
4.针对风险缓解措施和风险应急措施，各专项（子）项目经理指定措施的责任人。
5.各专项（子）项目经理将上述信息记录在“风险管理表”中。
（4）风险跟踪
1.各专项（子）项目经理根据确定的风险跟踪频率，对风险进行跟踪：
a.监控风险状态，记录状态变更。
风险的状态包括：
（1）已识别：
风险已经被识别
（2）已发生：
风险已经发生且转化为问题
（3）已消失：
风险消失，不会对项目产生影响
b.对风险的危险度、发生概率、生存期进行重新分析并计
升级会员 