项目管理系统及知识转移.docx

项目管理系统及知识转移.docx

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

项目管理系统及知识转移

项目管理及知识转移

1项目管理面临的挑战1

2项目管理流程3

2.1项目管理流程.3

2.2项目生命周期.4

3需求管理6

3.1需求工程内容.6

3.2需求分析.6

3.3需求变更.7

4创建工作分解结构9

5时间管理11

5.1项目时间管理的过程.11

5.2项目时间管理工具.11

6成本管理13

7风险管理15

8变更管理16

9知识和文档管理18

1项目管理面临的挑战

在企业的项目管理过程当中，常常会遇到项目进展不顺利的情况，有时候项目甚至会失败。

真正的项目管理人员必须有能力对项目进行预判，并及时加强管理采取必要措施，同时还要积累经验，帮助团队吸取教训。

如何有效地管理项目，解决项目过程中遇到的诸如以下问题：

统一协同：

项目进展过程不同阶段分别用不同的工具管理，数据不能有效整合，部门

间形成信息壁垒；

全局视图：

缺乏管理层项目汇总全局视图，难以实时掌控众多项目的进展与情况；

项目进度：

分散的信息，无效率的流程，项目进度不可控，项目过程不透明，项目周

期难交付；

资源管理：

如何查看项目的资源需求？

如何更好的分配和协调资源？

如何在组织级层

面管控资源利用率？

质量管控：

如何统筹考虑项目风险防控、技术评审、系统测试、质量保障，全面保障

交付高质量产品？

知识积累：

项目实施中，能否不断积累知识和经验？

有效的知识如何被反复的利用？

绩效决策：

项目人员工作量如何考核？

项目管理哪些方面需要改善？

如何解决？

2项目管理流程

该方案专门针对企业项目管理面临的问题，帮助企业有效管控项目及研发全生命周期，通过一个全面的组织级项目管理平台，帮助企业实现项目及管理的“过程透明化”和提升组织级项目管理能力；从横向上让项目团队能在组织级层面全面跟踪项目的需求、进度、质量和成本；

从纵向上打破业务部门与外包团队的壁垒，全面贯通项目的需求、计划、开发和测试；为高层领导提供多项目信息的全局视图，帮助宏观监督和调控多个项目并提供直观的管理手段。

2.1项目管理流程

在项目管理的流程中，每个阶段都有自己的起止范围，有本阶段的输入文件和本阶段要产生的输出文件。

同时，每个阶段都有本阶段的控制关口，即本阶段完成时将产生的重要文件也是进入下一阶段的重要输入文件。

每个阶段完成时一定要通过本阶段的控制关口，才能进入下一阶段的工作。

启动

制定项目章程

制定项目初步

范围说明书

需求分析

项目知识转移

变更日志

初步范围说明书

收集、分析、细化需求定义项目范围

确认范围、控制范围

需求文档

时间管理

成本管理

质量管理

变更管理

风险管理

结项

估算成本、制定预算

创建WBS

（工作分解结构）

控制成本

控制质量

识别风险、定性风险分析

定量风险分析、规划风险应付措施

控制风险

了解、评估、执行变更

变更控制

质量保证制度

风险应对措施

2.2项目生命周期

项目监控

成本估算文档

质量控制标准

项目生命周期管理是从项目的立项阶段、各里程碑阶段（需求、设计、开发、测试）、到

结项阶段，整个项目生命周期的管理。

实际工作中根据不同领域或不同方法再进行具体的划分。

在项目生命周期运行过程中的不同阶段里，由不同的组织、个人和资源扮演着主要角色。

根据项目具体情况，定义项目生命周期的流程，包括所有可能的状态和工作流操作。

审批通过

审批通过

审批通过

结项完成-关闭

3需求管理

需求管理是指在组织范围内协作并管理需求、功能点、项目的创意，以及和需求相关的任何功能或技术设计文档。

通过将来自各个业务部门的需求有效的过滤筛选，并且进行组织和合并，把需求按照业务系统进行组织和管理；同时对于需求的版本和基线提供有效管理，保证需求的有效性、完整性和正确性。

通过整合,可以直接基于需求有效驱动开发和测试。

3.1需求工程内容

项目需求工程包含以下内容：

需求工程

需求管理

需求开发

3.2需求分析

需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图，需求分析常用的方法有：

1）问答分析

做什么/解决什么问题？

谁做？

怎么做？

输入输出有什么？

约束、限制条件？

2）用例分析

Rose

Visio

表单

3）功能点分析

系统、子系统、模块、功能点，自顶向下、逐层细化

4）原型分析

功能

业务要素

操作特性

3.3需求变更

随着项目的进展，用户和开发方对需求的了解越来越深入，原先的需求文档很可能存在错误或不足。

另一方面，市场会发生变化，原先的文档也可能跟不上当前的市场需求。

可见需求变更总是不可避免的，有些是为了修正缺陷，有些属于增强功能。

对项目开发小组而言，变更需求通常意味着要调整资源、重新分配任务，并修改前期的工作成果，有时要付出较大的代价。

如果动不动就变更需求，某些项目也许永远不能按时完成。

为此，需求变更必须遵守利大于弊的原则。

需求变更通常按变更申请一审批一更改一重新确认的流程进行。

提交变更申请书需求变更申请书

变更相关工作

4创建工作分解结构

工作分解结构（简称WBS）跟因数分解是一个原理，就是把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。

即：

项目→任务→工作→日常活动。

工作分解结构以可交付成果为导向，对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。

WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。

（一）分解原则

1）将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成；

2）每个任务原则上要求分解到不能再细分为止；

3）日常活动要对应到人、时间和资金投入。

（二）任务分解的方法

1）采用树状结构进行分解；

2）以团队为中心，自上而下与自下而上的充分沟通，一对一个别交流与讨论，分解单项工作。

（三）任务分解的标准

1）分解后的活动结构清晰，从树根到树叶，一目了然，尽量避免盘根错节；

2）逻辑上形成一个大的活动，集成了所有的关键因素包含临时的里程碑和监控点，所有活动全部定义清楚，要细化到人、时间和资金投入。

WBS工（作分解结构）示例：

软件产品版本3.0

管理

培训资料培训资料培训资料培训资料

图：

工作分解结构示例

5时间管理

项目时间管理，主要工作包括定义项目活动、任务、活动排序、每项活动的合理工期估算、制定项目完整的进度计划、资源共享分配、监控项目进度等内容。

时间管理工作开始以前应该先完成项目管理工作中的范围管理部分。

如果只图节省时间，把这些前期工作省略，后面的工作必然会走弯路，反而会耽误时间。

项目一开始首先要有明确项目目标、可交付产品的范围定义文档和项目的工作分解结构（WBS）。

由于一些是明显的、项

目所必须的工作，而另一些则具有一定的隐蔽性，所以要以经验为基础，列出完整的完成项目所必需的工作，同时要有专家审定过程，以此为基础才能制定出可行的项目时间计划，进行合理的时间管理。

5.1项目时间管理的过程

1）活动定义：

涉及确定项目团队成员和项目干系人为完成项目可交付成果而必须完成对

具体活动（WBS）；

2）活动排列：

设计确定项目活动之间的关系，并形成相应的文档；

3）活动历时估算：

估计完成具体活动需要的工作时间；

4）制定进度计划：

分析活动顺序、活动历时估算和资源要求，制定项目进度计划；

5）进度计划控制：

控制和管理项目计划的变更。

5.2项目时间管理工具

甘特图、网络图和关键路劲分析.

图:

甘特图

6成本管理

项目成本管理指为保障项目实际发生的成本不超过项目预算，使项目组批准的预算内按时、按质、经济高效地完成既定目标而开展的成本管理活动。

项目成本管理过程：

1）项目资源计划；

2）项目成本估算；

3）项目成本预算；

4）项目成本控制（实施过程中）；

5）项目成本预测（实施过程中）。

IT项目的资源按其使用特性分为以下三类：

1）项目环境资源：

通用的标准化的资源，如：

软件和硬件；

2）可重用资源：

多个项目中可以重复使用的资源；

3）人力资源：

项目实施所需要的人员以及人员的可得情况。

图:

人力资源估算

7风险管理

对项目风险从识别到分析，乃至采取应对措施以及风险跟踪等一系列过程的管理，主要包

括：

风险识别、风险量化、风险对策。

风险状态跟踪包含:

风险识别

风险量化

跟踪风险进展情况

设置风险预警级别

风险复用与借鉴

风险和具体项目关联风险可以和具体的项目关联，根据风险在项目里面的预警级别，来判断风险的影响力。

通过不断的风险积累来形成完整的风险库，保障项目的正常进行。

风险管理示例:

初始状态

新建风险

风险

--责任人跟踪中

风险规避成功

风险已规避

规避失败

转为问题跟踪

问题

--责任人跟踪中

问题已解决

问题已解决

升级问题返回

问题升级

图:

风险管理

8变更管理

变更管理是对项目中突发的，可能导致项目计划严重推迟的重大变更进行管理。

目的是评估该变更是否一定要发生，是否有其他更好的解决方案规避或者减轻影响，同时也通知所有干系人变更后的结果。

有些大型项目设有专门的变更委员会。

变更申请内容包括变更原因，变更方案等。

有效地识别变更和准确地分析变更影响，变更申请通过后，及时将变更的内容通知给所有干系人，保证变更实施后的结果得到一致的执行。

项目变更管理的目的是以一种对于项目影响最小的方式改变现状。

它包括以下主要内容：

1）了解变化。

在项目实施过程中，项目组织要经常关注与项目相关的主客观因素，及时发现和把握变化，认真分析变化的性质，确定变化的影响，适时进行变化描述。

2）进行变更处理。

当变化了的各种因素影响到了项目的顺利实施时，项目组织必须及时进行计划变更，以确保项目目标的实现。

项目计划的变更应征得项目主体的同意，项目组织还应及时向其反馈变更及变更执行情况。

3）监控变更合理性。

变更处理总是根据项目实施的客观需要进行的，但并不是每次变更都是合理的。

开始

干系人提出变更请求

项目团队了解变更

团队评估变更对影响

团队判断

是否变更

变更是否

涉及基准

取消

知干系人新变更日志

通过

记录

执行

总结经验教训

更新组织过程资产

结束

项目经理批准变更

通知干系人

CCB

校验

图：

项目变更管理流程图

更新

通知干系人

9知识和文档管理

知识的重复开发和充分利用知识资源。

知识主要是以文档的形式保存下来，因此，知识转移中项目文档管理是最核心的内容。

项目文档管理，是指在一个系统（软件）项目开发进程中将提交的文档进行收集管理的过程。

通常，文档管理在项目开发中不是很受重视，当发现其重要性时，往往为时已晚。

整个项目可能因此变得管理混乱，问题产生后无据可查。

文档管理对于一个项目的顺利进行有着至关重要的作用，其关键性不容忽视。

作为管理完善的项目文档，管理者完全可以依顺它的轨迹看清整个项目进展的脉络，同时通过对阶段性文档的把握使整个项目质量得到很好的掌控。

制定一套完整有序的项目文档管理规定十分必要。

管理者结合实际情况制订出适合自身的文档管理规定。

例如，从项目周期角度可分为开发文档、产品文档、管理文档；更细致一点还可分为l4类文档文件，具体有：

可行性研究报告、项目开发计划、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、用户手册、操作手册、模块开发卷宗、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

这样的分类细化了项目进度中各个阶段所需管理的文档。

项目文档在各个阶段的提交情况示例: