项目管理体系.docx

项目管理体系.docx

《项目管理体系.docx》由会员分享，可在线阅读，更多相关《项目管理体系.docx（16页珍藏版）》请在冰豆网上搜索。

项目管理体系

第1章项目方法

1.1项目实施方法

xxx着眼于未来几年业务发展的需要，以本期需求实现为目标。

在项目整体设计上要具备前瞻性、扩展性，以满足新产品上线、新合作伙伴的快速接入。

本项目实施要结合xxx华南电销中心的开展来进行，从目前的需求及调研情况来看，本项目实施要分为四个步骤进行实施。

项目采用迭代式的开发方式来进行，每个阶段实施策略均有需求调研、系统设计、开发、测试及上线的过程。

1.2项目实施原则

1.2.1权责挂钩原则

项目参与方如对某个事件、方法、判断有决策权，则该方承担由此决策造成的成果与失误之责任。

1.2.2职责书面化原则

对较重要的职责或权利，均应以书面方式向项目机构表达，不以书面方式表达的职责可以看成不重要的职责。

1.2.3项目实施方法

鉴于xxx公司长期的项目实践经验，我们认为本项目的实施应该遵循如下方法：

1.2.4目标明确、分步实施

根据项目的需求，制定明确的、可达的实施目标，并且结合现有的业务状态和IT资源，分步骤实施。

1.2.5严格而完善的质量保证体系

项目实施过程是一个集需求分析、系统对接、开发、测试、试运行、维护等全过程的综合质量保证体系。

我们在此项目的实施过程中，从如下几个方面来保证项目的实施质量：

●明确的项目管理目标

✓如期完成项目；

✓用户需求得到确认和实现；

✓妥善处理用户的需求变动；

✓项目成本控制在计划之内；

✓顺利实施系统配置管理；

✓保证对第三方产品或服务的控制和协作。

●全过程的项目监控

✓制定项目计划，提交给xxx保险股份有限公司进行确认，保证xxx保险股份有限公司可以精确、完整的掌握项目进度；

✓依项目计划对项目工作进行监控，并跟踪项目进度，进行必要的里程碑检查；

✓任何一方向对方提交的文档，另一方必须严格按照双方约定在规定时间内确认并签收，以利项目顺利进行。

●有效的日常沟通机制

项目组的日常管理沟通形式是多种多样的，有书面和口头两种形式；项目组口头沟通包括会议、评审、日常接触和讨论等，这一方式简单有效；书面沟通包括会议记录、阶段报告、问题报告、测试报告，工作表等方式，为项目组管理沟通及达成一致意见的备忘录。

项目组开展的日常管理活动包括（详见“沟通程序”）：

✓周例会

✓阶段例会

✓临时会议

✓会议纪要

✓项目工作报告

✓项目状态报告

✓任务分派和跟踪表

✓人员管理

✓问题管理

1.3应用开发管理规范

阶段

规范

交付文档

计划阶段

需求调研

需求规格说明书

系统总体架构说明书

需求分析

需求确认

系统总体方案设计

开发阶段

设计

数据库设计

数据库设计说明书

应用系统概要设计

应用系统概要设计说明书

应用系统详细设计

应用系统详细设计说明书

数据交换平台概要设计

数据交换平台概要设计说明书

数据交换平台详细设计

数据交换平台详细设计说明书

统计分析报表设计

统计分析报表设计说明书

开发

应用系统程序开发及单元测试

程序

数据交换平台开发及单元测试

程序

报表开发及单元测试

程序

测试

集成测试方案制定

集成测试方案

集成测试计划

集成测试计划

集成测试案例编写

集成测试案例

测试测试执行

BUG修改

集成测试报告

验收阶段

用户验收方案制定

用户验收方案

用户验收

用户验收报告

推广阶段

数据准备

系统上线报告

用户操作手册

上线试运行

用户操作培训

1.4项目进度管理

1.4.1项目过程管理

为确保项目按时保质完成，必须控制任务和跟踪里程碑。

项目经理以及各组负责人根据项目特点、客户需求、识别的风险、可能存在的限制安排项目进度；在项目执行过程中定期对所属范围内的项目进展情况进行监控，识别与分析实际进展与计划的偏差原因，采取纠正措施进行调整，必要时进行正式的计划变更。

项目进度管理可以通过以下方式完成：

●进度信息收集和汇总：

每周五下午项目经理收集项目成员的任务完成情况，召开项目周例会分析工作进展，汇总形成报告提交给PMO（项目管理部）。

●进度状态分析：

PMO组织每周一定期的管理例会，xxx项目负责人、xxx项目负责人共同参与，系统地分析整体项目的进度状态，将实际结果与计划结果进行比较，分析里程碑各项任务是否存在偏差，里程碑是否可按预期完成，现存问题和根本原因，共同探讨解决方案，为本周工作做总结安排。

●处理偏差：

当实际结果偏离了原来的计划和目标，项目经理需要根据进度状态分析的结果处理偏差，必要时调整计划和目标。

从呼叫中心整体项目执行过程来看，极少项目是完全按照计划来进行的，因为再好的计划也不能完全预见所有的问题，软件联调，运营商线路，供应商到货等不可控因素，均会导致计划延后，所以预先制订出对策，及时调整工作计划就很重要，但是调整必须合理，xxx承诺调整后的计划必须得到xxx和xxx两方面共同确认后才可生效。

1.4.2项目过程异常管理

当系统项目建设因外部系统原因导致项目时程延长，或者因甲方其它原因导致项目被迫中断，从而进一步形成项目计划被迫延长或中断，导致xxx成本大幅度增加，对此，xxx应该根据延长的不同程度予以补偿，具体补偿的处理办法请参见本项目合同正本中相关部分的约定。

当项目因外部系统原因导致项目进度异常时，xxx项目经理负责与xxx进行有效沟通、商议，允许对项目计划（包括项目集成实施计划）进行有效、合理调整。

项目异常即包括项目时程延长，也包括项目时程缩短和中断.当因外部因素导致项目时程必须缩短时，xxx应该调整原有项目计划和项目集成实施计划的同时，与xxx协商对本项目需求能进行裁减，以适应实际需要。

1.4.3项目过程风险控制管理

项目过程风险控制通过定期和不定期的监督和测量项目执行情况，发现项目存在的偏差，以便采取必要的纠正和预防措施，保证项目组能按时、保质的完成项目目标。

在本项目中，问题与风险管理的活动将遵循下面的原则：

●在项目的开始明确问题与风险管理策略，制定出问题和风险管理计划；

●从项目开始就组织所有各类相关人员集体讨论、进行风险分析确定潜在的风险，更新风险列表，并在定期的项目状态评估中更新；

●分析风险，发现的风险分为二大类：

管理风险与技术风险。

项目应强调在制定计划、安排任务时要优先解决项目中的技术风险，并在精化阶段把所有重大技术风险解决掉；而各类管理风险则通过管理工作来解决；

●当风险发生时，风险就成为了问题，引发问题管理过程后，按照问题管理计划确定的流程进行处理；

●在定期的状态评估和不定期的问题更新后，跟踪问题的解决，进行问题跟踪。

在本项目实施过程中，具体的风险管理活动包括：

●识别出潜在的风险；（包括系统对接，城际专线、中继线路、硬件到货路途故障、管理实施人员辞离、初次上线失败、保监政策因素等多种）

●分析并确定其优先级；

●确定风险对策；

●持续的检查评估风险；

●及时更新风险列表；

。

1.5项目质量管理

1.5.1质量管理是xxx公司战略的重点

xxx管理层始终密切关注公司质量体系的建设和运行情况，并保证和提供体系运行必要的资金和人力等资源。

1.5.2专业化的队伍

xxx公司为保证质量管理更加到位、有效，建立了一支专职的队伍从事质量管理。

他们都具备多年项目实施经验和项目管理经验，具备项目经理管理资质。

1.5.3独立的质量保证员SQA

xxx公司设立了SQA角色，他们直接向公司CQO汇报，独立于项目组之外，不接受项目经理的领导。

独立的审核人员才能确保审核工作的客观性和有效性。

1.5.4良好的组织氛围

经过长期持续不断地进行质量管理体系的建设、培训、宣传及推广，目前，xxx公司已经在整个企业范围内营造了一种良好的质量管理氛围。

这些氛围主要体现在：

●系统的培训，新员工必须接受系统的质量管理体系的培训才能上岗，保证质量管理在公司内良好的继承性；

●良好的执行氛围，按流程办事已经深入到每个员工的心中，已形成按公司流程标准执行的习惯，能够认真贯彻公司的质量意识；

●积极的持续改进意识，很多公司员工已养成质量管理持续改进的意识，能积极的参与的质量改进中；

1.6沟通程序

平滑且顺畅的沟通，是项目实施的前提。

我们将在项目实施过程中采用如下方式保持项目组内部、项目组和xxx之间的无缝交流。

1.6.1周例会

每周五下午，由项目经理组织在现场的双方项目组成员参加周例会。

总结本周工作，形成《项目周状态报告》。

内容包括：

项目进展情况，本周出现的问题和解决办法，下周工作计划，下周任务分派。

1.6.2阶段例会

每个实施阶段结束，项目管理组要组织阶段例会，并邀请xxx保险股份有限公司相关部门参加。

例会内容：

总结汇报阶段工作情况。

由xxx保险股份有限公司提出项目意见书，项目组编写项目反馈意见书及时反馈意见。

1.6.3临时会议

讨论临时出现的问题和争议，寻求解决办法；审批相关人员提交的报告，讨论答复内容。

1.6.4会议纪要

会议纪要是各方达成共识的依据。

项目实施阶段的每次会议，都由xxx公司的客户服务专员将会议讨论内容整理成会议纪要，提交与会人员进行确认。

1.6.5项目工作报告

项目工作报告分为项目工作周报和项目工作月报，项目工作周报在周例会上完成，并提交xxx公司和xxx股份有限公司相关部门，项目工作月报由项目管理组完成并提交xxx保险股份有限公司相关部门。

内容包括：

当期项目进展情况汇报，出现的问题和解决办法，当期工作计划，当期任务分派等。

1.6.6项目状态报告

项目状态报告，包含周状态报告、阶段状态报告用于报告项目进展情况。

周状态报告总结上周出现的问题和解决办法，本周工作计划，本周任务分派。

项目周状态报告，由项目经理每周以例会或邮件的形式汇报双方的项目高层负责人。

阶段总结报告，包含阶段完成的任务实际完成情况，总结工作中的缺失和经验，为下阶段布置工作重点，并对阶段工作目标达成一致意见。

阶段总结报告由项目经理在项目的里程碑处，以阶段总结/启动会议或邮件的方式，汇报双方的项目高层负责人。

1.6.7任务分派和跟踪表

项目组的任务分派记录成分派表，用来明确人员分工和跟踪任务完成情况。

任务分派和跟踪表由项目管理组统一制定，分发和回收，并报xxx保险股份有限公司相关部门备案。

1.6.8人员管理

xxx公司保证项目组成员的稳定性，项目组成员加入本项目后不再负责公司其他工作，保证承诺的工时投入。

意外情况下的人员变动在合理的时间内事先五个工作日告知xxx保险股份有限公司，经同意和项目经理批准后才可安排。

核心技术人员实行更严格的管理，暂时性离开开发所在地需要征得项目管理组和xxx保险股份有限公司的同意。

xxx人员实行每天签到制度，签到表作为项目管理文件之一，定期向xxx保险股份有限公司提供。

1.6.9问题管理

●问题及早报告原则

对于一个问题，报告人必须在问题发生的当日，向项目经理提交报告。

问题没有及早报告，影响项目，由延误报告人承担。

●争议管理

在项目进行中，任何不能达成一致的观点均为争议，争议应立即向上级呈报。

如果最高协调机构仍不能达成一致意见，则遵循谁决策，谁承担决策失误给对方和项目带来的损失之原则。

●失误管理

失误可能是多方面的，失误的及早发现是项目成功的基本保障。

对以下各个事件，必须做出失误分析：

计划有重大改动、经费有较大变化、质量不符、进度不符、成果不符、其它重大事件。

项目经理应给出失误分析报告，提出应对办法。

1.7变更管理

需求变更管理是本次《xxx华南电销中心项目》过程规范中的一个重要管理环节，项目的需求变更管理严格依照变更控制方法监控，需求变更管理流程如下图所示：

1.7.1变更提出

xxx提出需求变更的要求，xxx项目经理召集项目研发、实施施人员与xxx相关项目管理人员就需求变更内容进行沟通和交流，以明确xxx要求。

内容包括：

●变更的详细描述

●变更的理由

●答复方项目经理的签名

●请求日期

项目经理从业务、技术和项目上线期限等角度分析需求变更的可行性，如果存在不可行的变更项，则在与xxx沟通后关闭，否则填写和提交需求变更记录，提交给OPM。

OPM负责协调变更工作并跟踪需求变更的执行状态直到关闭。

1.7.2变更影响分析

项目经理和OPM共同分析，明确由于业务需求变更而导致的变更范围和配置项信息，以及该变更对项目质量、工作量、进度、上线日期等的影响，其结果记录在需求变更记录，然后提交给xxx项目负责中心。

1.7.3启动项目变更请求

xxx项目负责中心基于变更影响分析的结果，判断是否可以开展具体的变更工作。

如果拒绝则变更关闭。

1.7.4变更策划和实施

如果xxx项目负责中心批准变更，则项目经理与相关工作组负责人一起策划变更的具体工作进度，开始执行变更：

首先建立新的需求基准，并以新的需求基准为基础开展后续的工作。

1.7.5变更验证

项目组通过评审和测试等手段不断验证变更内容是否正确，当全部变更完成后，测试组进行测试以验证需求得到正确实现。

如需要，则邀请xxx适当参与变更验证。

1.7.6变更生效

对于项目过程中的需求变更，当所有变更的配置项都通过了验证并建立了新的基准则。

则OPM关闭此项需求变更记录。

1.8开发管理

在本项目中软件配置管理是xxx用来管理软件资产变更的一项规程，由相应的工具、过程和方法学组成，组成了本项目配置管理系统。

1.8.1配置管理人员

项目组中建立专门的配置管理人员，配合项目经理制定配置管理制度，执行配置管理。

1.8.2配置管理计划

配置管理小组根据配置管理制度编写配置管理计划，内容包括：

配置管理需求，配置管理活动，日程安排，工作分派，所需资源等等。

1.8.3配置管理活动

配置管理的日常工作包括：

●定时从各小组收集开发文档和源代码。

●对文档和软件代码按配置管理规范进行严格管理。

●将代码和数据提交测试人员测试。

1.8.4软件配置管理工具

现今的软件开发环境非常复杂，必须具备敏捷的反应能力和快速的反应周期。

开发组织更需要有序的管理机制，确保开发活动在控制之中，避免无序和混乱导致产品和系统失败。

软件配置管理（SCM）就是一种将软件开发过程引入控制的过程。

我们决定采用SVN软件配置管理工具管理项目组的文档和软件源代码。

采用SVN的软件配置管理将包括如下内容：

配置标识——产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。

版本控制——通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。

例如，它将解决哪些修改会在该产品的最新版本中实现的问题。

状态统计——记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。

例如，它将解决修改这个错误会影响多少个文件的问题。

审计和审查——确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。

例如，它将解决目前发布的产品所用的文件的版本是否正确的问题。

生产——对产品的生产进行优化管理。

它将解决最新发布的产品应由哪些版本的文件和工具来生成的问题。

过程管理——确保软件组织的规程、方针和软件周期得以正确贯彻执行。

它将解决要交付给用户的产品是否经过测试和质量检查的问题。

小组协作——控制开发统一产品的多个开发人员之间的协作。

例如，它将解决是否所有本地程序员所做的修改都已被加入到新版本的产品中的问题。

软件配置管理的解决方案涉及面很广，将影响软件开发环境、软件过程模型、配置管理系统的使用者、软件产品的质量和用户的组织机构。

1.9移交管理

项目的移交是项目执行的重要步骤之一，在项目的移交阶段项目的实施方将会提交相应的交付件，完成项目的移交工作。

●用于交付xxx保险股份有限公司的项目成果。

与项目交付成果结果和过程相关的文件，包括需求说明书、系统结构设计书、运行测试方案及测试报告、IVR流程设计说明、数据库设计说明书、录音存储说明、系统运行记录、配置管理记录等等。

交付件交付完毕后，根据不同的内容，将属于系统操作部分的交付件提交给业务系统管理者，属于系统维护部分的交付件提交给维护部门管理者，同时根据系统的不同使用者安排相应的培训。

●在项目实施计划中，xxx公司建议，经xxx保险股份有限公司确认的各种文件交付物。

●项目组沟通意见，双方签字文档。

●各种批准文书的原件，如需求变动书、项目问题控制表等等。

●项目团队成员培训情况记录，客户培训记录。

●项目生命周期中用于沟通的所有文档，包括：

各种报告、会议纪要、重要通知等等

●其它能反映项目内容的资料和文档。

●阶段性文档

在每一项子任务结束后，资料交付时，需提供如下信息：

文档类型、序号、资料名称、资料类别、编写人、产生日期、版本号、密级、介质、备注、特别说明、验收/归档人签字。

在系统交接期间，双方根据资料归档记录，以及xxx公司投标书、项目管理计划、合作协议规定的文档清单和标准，做全面移交工作。

1.10运营管理

系统交付使用之后，为了保证系统在日常运营过程中能够稳定运行，需要制定一套详尽可行的运营管理方案来指导系统的日常运营管理，该方案包括对系统安全、备份、日志查看等工作等方面处理机制和流程的描述。

●日常维护

xxx现场维护组根据维护计划对系统进行日常维护，日常维护包括系统日常核查、系统一般问题的处理、日常备份等工作。

●客户支持

xxx现场维护组对客户在使用系统过程中的问题进行解答。

●应用系统变更

应用方面的变更都需提前向管理部门提交变更申请，获得批准后方可进行变更。

●故障处理

现场系统发生故障的，须按照“系统维护手册”中规定的故障处理流程进行处理，“系统维护手册”中须明确定义故障级别以及针对不同故障级别的处理流程。

故障处理结束后，PM分析故障原因并避免故障再次发生。

●客户培训

系统升级后，根据客户的需求，可对客户人员进行相应的系统应用或维护方面的培训，PM指定合适的人员进行培训。

培训过程中，培训讲师应认真实施培训，记录培训情况，并为每个培训学员填写“客户培训记录”；客户代表签字确认已完成有关内容的培训。

●客户周报

xxx现场维护组向xxx项目管理部门提交项目周报，对一周工作情况进行总结反馈。