it项目管理部职责

it项目管理部职责（通用8篇）

it项目管理部职责 篇1

从毕业至今，大小的项目做了一些，有不少成功的喜悦，也有很多失败的教训。今年由于工作需要，我以软件项目负责人的身份参加了接入网统一网管系统开发的整个过程。从中学到了不少知识，有许多体会,想将自己的感受写出来，与大家共勉。

软件项目管理是一个庞大而复杂的系统工程，当前业界对于软件开发流程有不少规范和定义，如CMM和ISO9000。在该管理体系的管理下是可以开发出高质量的软件产品。但是由于该体系较适合于大型而且复杂项目的团队开发，真正实施尚需要时间和过程。而我们当前执行的项目，一般只有10个人左右，要实施软件工程难度更大。我认为：虽然项目大小不一，但管理方法是相通的，要做好软件开发工作，就必须加强有效管理。

大家知道，“软件危机”起源于一些大型项目的不断延迟甚至失败。与大项目相比，小项目具有以下特点:

· 项目功能相对较少 ；

· 开发人员较少；

· 开发周期较短。

小项目看起来比较简单，比较容易成功，人们往往容易忽视小项目的管理，其实这是一种误解。

据我了解，小项目开发中容易出现以下问题：:

1、开发之前没有认真地进行项目可行性和工作量的估计。

往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差距。

2、没有真正的设计过程。

开发人员少，不同人员的程序之间交互、接口相对少一些。开发周期短往往是几个人从头到尾负责一个项目，几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档来规范各自职责和项目细节。

这种做法潜在的危险之一是有人可能会对所讨论的接口、结构理解有偏差，可能会造成以后的返工。

另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按时完成分工任务后，才发现各个模块组合起来却无法形成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。

第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，难以理解以前别人做好的代码，又要从头做起。另外，没有文档的程序，日后维护和版本升级都比较困难。

3、不经过单元测试而直接进入系统测试。

造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。

针对以上问题，我认为在开发过程中必须处理好四个关键问题，严格把关，可以大大提高软件的质量。

这四个关键问题为：人员、规范、测试、时间控制。

一、合理配置人员

首先软件开发是一项长期艰苦的工作，所以一个团结、协作的团体才能在规定的时间内完成一个质量上乘的软件项目。团队中的每个人必须积极融入到整个集体中，不能互相推诿，更不能互相埋怨和指责，正确的态度是大家在充分信任的基础上团结协作，互相帮助，主动承担任务, 利用集体的智慧获得成功。整个团队就是一部机器，只有每一个齿轮都能正常运作，才能生产出优质的产品。

合理配备人员是成功完成软件开发项目的切实保证。所谓合理配备人员应包括按不同阶段适时运用人员，恰当掌握用人标准。一般来说，软件项目不同阶段、不同层次技术人员的参与情况是不一样的。图一是典型的软件开发人员参与情况与实际人员需求差异曲线图。

如人员配置不当，很容易造成人力资源的浪费，并延误工期。特别是采用恒定人员配备方案时，在项目的开始和最后都会出现人力过剩，而在中期又会出现人力不足的情况。

为开发人员创造出一个人尽其才的环境也是项目成功的重要环节，让他们能得心应手的施展自己的才华，特别在工作安排上要煞费苦心，针对每个人不同的特长，根据项目的具体环境和条件来合理安排人员在恰当的岗位上。

项目负责人是一个团队的核心，其综合素质直接影响项目的成败。合格的项目负责人具有高超的领导才能和强烈的科技意识和较强的业务处理能力；具有敏锐的洞察力，能瞄准目标，实事求是，精心组织，坚决果断，灵活应变，享有信誉；善于制定计划，解决问题，沟通信息；具有良好的市场意识和交际能力。当然同时满足这些条件比较困难，但是他应该具有实现这些素质的条件，并注重经验的积累、素质的提高、能力的培养。并能从以下几方面严格要求和培养自己：

以身作则：只有身先士卒，各方面以身作则，才能得到广大开发人员的认可和信任，才能树立较高的威信。

果断抉择：负责人的重要任务是决策，特别是有多种选择的情况下，一个正确的选择往往事半功倍。

善于交际：他必须积极对外联络，充分利用外部资源，例如其他部门做过类似项目者，可以向他们取经甚至直接获得源码。这对一个项目争取时间，避免重复工作很重要。

善于协调：协调几个人的工作比自己完成一段编码更重要。由于协调不力，将影响开发。所以项目负责人除完成自己的编程任务外，必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。

善于制定计划：在开发前，可将明确的开发任务通过文档传递给每个开发人员，让大家都熟悉设计模型，都清楚自己所做的工作在整个系统中处于什么地位，这样有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。

沟通问题：团队沟通不是技术问题，但却是一个最能影响工作效率的问题。沟通及时、集思广益、步调一致，才能取得胜利。

二、严格执行软件开发规范

软件开发需要严格按照软件规范实施。用手工作坊式的方式来开发软件，其结果必然失败。从项目的用户需求分析、系统分析、编码、调试、测试、发布都需要一步一步完成，不能轻视或忽略任何一步骤。前部分没有完成好，不要贸然进行下一步。越是项目起步阶段，越是要注意按照规范进行。

如前所述，因为开发软件项目规模较小，很容易忽视规范化，而随心所欲，没有计划，想到哪做到哪，其最终的结果是失去控制。其实项目小正是实现软件规范化管理的好时机，规模

小，涉及的管理方面有限，管理实施起来比较容易。CMM等规范标准不是轻而易举就能实现的，但是可以借鉴它的思想和方法，先在小项目上实现规范化管理，培养人员的规范和意识，为以后实现大项目的CMM等规范打下良好的基础。

特别需要重视软件开发中文档管理。那种认为只要产品做出来可以运行，何必花费许多精力去做文档的观点是错误的。经过实践，我深刻体会到，没有文档会带来很多问题。用文档去引导开发过程，抛弃随心所欲的开发模式。就象工厂工人师傅按照图纸生产零件一样，否则很可能会得到次品甚至是废品，给后来开发者留下一堆没有意义的“垃圾”产品。我认为文档应该是开发中阶段（ｍileStone）结束的标志，每个阶段后，都需要提交相应的文档，而且要确保文档的质量。

确保文档质量的最有效方法就是评审，提交文档后，项目负责人组织相关人员对该文档进行审核，在充分讨论的基础上进行文档的重新修改和审核直到满足项目要求。文档应该是贯穿整个过程的主线，在不同的阶段，需要不停地对文档进行完善，使之真正成为全体项目人员的智慧结晶。

三、重视测试

测试是软件开发中容易忽视的问题，许多人认为开发的主要工作是编码，其实不然，在没有严格执行开发流程的开发活动中，测试可能是唯一能确保软件质量的方法和手段。而越是松散的项目越轻视测试活动，它既没有固定的测试组织，又没有程序员间的交叉测试，更没有考虑过有效的测试流程和方法，他们的软件质量完全建立在对程序员能力信任的基础上，这是很不安全的。

测试是对软件产品质量的检验和评价。它一方面检查软件中存在的质量问题，同时对产品质量进行客观的评价。

我们一般把发现的错误bug(我们也称为缺陷defect)按严重性分为四类：死机(系统崩溃或挂起)、致命(使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的)、严重(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)、一般(界面拼写错误或用户使用不方便)。

我们也把发现的错误按优先级分为三种：高、中、低。一般是某错误对用户接受或使用影响越大其优先级越高。

要完成严格的测试，就必须建立规范的系统测试流程，有专人负责执行，而且开发人员要积极配合，不要认为测试人员是在给自己找麻烦，测试人员查找的错误可能是程序员无法发现的错误。

一般的测试流程应该是：

1、项目组提交系统测试申请给测试中心指定帐号。由专人检查文档格式和完备性。

2、检查合格后交给该产品对应方向的研究人员，评价其内容的有效性和真实性。

3、检查合格后由测试中心主任审查并通过，成立测试组，指定测试组长(可暂时没有组员)。

4、测试组长根据该产品的申请报告、测试设计和以往测试数据，制定测试方案。

5、测试中心主任审核通过测试方案后，根据测试方案指定测试组成员，并由支持组完成其他支持任务(如：设备的配备、测试数据库的建立、网络权限的修改„„)。

6、测试期间测试组根据测试方案进行实际测试，记录并跟踪测试缺陷报告，填写测试记录。测试组长与项目组(测试经理)经常沟通，并获取产品的更新版本。同时，测试组长审查、修改并提交所有缺陷报告，保证随时掌握产品的质量情况，并监督测试进度。

7、产品进行到一定阶段后(标志是测试缺陷报告库中所有的报告处于归档状态)，由项目组和测试组长共同决定产品进入稳定期测试。稳定期测试版本之前的版本必须在显著位置标明为测试版字样。

8、稳定期测试期间所发现的缺陷报告也需要记录在测试缺陷报告库中，并在稳定期结束后由双方(有时可能也有市场方面的意见)共同决定对这些缺陷的处理方式。如果需要改动产品，则重新开始稳定期，否则通过稳定期测试。

9、测试组长对于通过稳定期测试的产品填写综合测试报告，测试中心依此发布产品发行通知。

10、测试组对整个测试过程和产品质量进行总结和评价，形成文档并备案。同时，将测试过程中对测试设计的改动纳入基线（是已经通过正式复审核批准的某规约或产品，是软件开发中的里程碑）。最后，组长整理并在指定地点保存相关测试数据和测试样张。

11、测试中心解散测试小组。

另外，在系统测试阶段，我们要求测试小组要进行一些常规内容测试(如：Y2K测试，病毒检查、裸机测试、加密检查、说明书检查„„)，并要求写入测试方案中。

测试应该在现实的环境中进行。所谓现实环境就是与用户实际使用的环境相同或相近，因为开发环境和用户使用环境有很大区别的，而开发的产品最终是要交给用户使用的。如果没有办法模拟用户环境，则程序员可能必须自己开发一些模拟程序来模拟现实环境。特别是与硬件配合的项目，因为在程序调试时硬件可能没有完全完成，这时就必须开发模拟硬件的程序，否则开发的进度可能无法保证。

四、时间控制

开发人员最担心 “领导不断催促，可系统提交日期一拖再拖”，项目负责人对此一筹莫展，束手无策。开发活动如同一个黑箱子，资金扔进去了，人员扔进去了，设备资源扔进去了，但不知道什么时候会出来结果，更没有把握出来的东西是否是用户所要的东西。为避免人力、物力、财力浪费，要做好项目计划，进行有效的时间控制。

软件项目管理过程开始于项目的计划，在做项目计划时，第一项活动是估算。现在已经使用的技术是时间和工作量的估算。因为估算是其他项目计划活动的基石，而且项目计划又为软件工程过程提供了工作方向，所以我们不能没有计划就着手开发，否则就会陷入误区。软件项目的进度安排主要是考虑软件交付用户使用的这一段开发时间的安排。进度安排的准确程度可能比成本估计的准确程度更重要。软件产品可以靠重新定价或者靠大量的销售来弥补成本的增加，但进度安排的落空会导致市场机会的丧失或者用户不满意，而且也会导致成本的增加。因此在考虑进度安排时要把人员的工作量与花费的时间联系起来，合理分配工作量，利用进度安排的有效分析方法严密监视软件开发的进展情况，以使得软件开发的进度不至于被拖延。

在作进度安排时要考虑的一个主要问题是任务的并行性问题。当参加项目的人数不止一人时，软件开发工作就会出现并行情况。因为并行任务是同时发生的，所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。另外还应注意关键路径的任务，这样可以确定在进度安排中应保证的重点。常用的进度安排方法有两种，即甘特图（Gantt Chart）法和工程网络法。

项目怎么样才能算做好了，也是各有各的看法，我对项目成功的定义为，“三赢”的项目，才算是真正成功的项目。三赢包括，用户满意；公司满意；项目参与人员满意。

为用户服务、让用户满意：用户指提供资金并且最终使用项目结果的所有人员，项目的开发过程和最终结果，要让用户认可、使用，并让用户说好。此为一赢。

让公司满意：项目开发要按时保质保量地完成，并为公司积累项目经验、知识储备，包括项目、人才、技术、市场等各方面的储备。此为二赢。

让项目参与人员满意：要让开发人员在项目中专注地完成任务，免受项目之外的因素干扰。正常、优秀地完成项目，对开发人员本身也是一种巨大的鼓励。还要让供应商深知其设备、软件的使用情况，让项目的成功成为供应商的成功，为下一次的更好合作打下基础。

it项目管理部职责 篇2

一、项目范围管理相关概念

范围的概念包括产品规范和项目范围两方面内容, 其中产品规范指产品或服务所包含的特征或功能, 项目范围指为了交付具有所指特征和功能的产品必须要做的工作。

项目范围管理是指保证项目范围规定的工作得以顺利完成的所有管理过程。这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。简而言之, 项目范围管理就是:做什么?不做什么?包括什么?不包括什么?

二、项目范围管理的作用分析

在现实的IT项目管理中, 可以看到很多范围管理不到位而导致项目失败的例子。现从以下三个方面对项目范围管理的作用进行分析。

1、确定项目范围可提高项目成本、时间和资源估算的准确性。

如果项目的具体工作内容不明确, 项目的成本、时间和所需资源就不明确, 项目完成的不确定因素将大大增加, 面临巨大的危机。

2、确定项目范围有助于清楚地分派责任。

在明确项目包括那些具体的内容、具体有哪些要求、完成的产品应达到什么要求等内容后, 就为清楚地分派任务提供了必要的保障。

3、项目范围、时间、成本三个约束条件是相互影响、相互制约的。

时间、成本和范围构成一个稳固的三角形, 如图1所示。 (图1)

大多数项目都会有明确的完成日期、成本和范围的限制。时间、成本和范围三个要素被称为项目成功的三大要素。

在三角形中, 任何一边都不可能孤立地改变, 如果项目范围扩大, 必然导致项目成本增加和项目工期的延长。不成比例的变化与孤立的改变某一边是一样的, 都将破坏三角形的结构, 最终招致项目失败。因此, 有效的范围管理更像一门艺术, 可以帮助项目经理在已经确定的时间和成本下完成项目目标。

三、影响项目范围管理的常见因素分析

影响项目范围管理的因素很多, 经分析有以下几种:

1、IT企业没有完善的项目管理体系来指导项目管理工作。

此种情况下, 项目的成败完全依靠项目经理个人的管理、领导能力, 大部分项目都是以失败而告终, 因此建立健全项目管理体系是至关重要的。

2、项目范围的定义不够明确, 不能量化, 可验证程度低。

很多时候都是一些定性的要求, 例如“用户界面友好, 可操作性强, 便于使用及维护”等, 类似这些模糊的界定往往是导致后续项目扯皮的根源。对项目范围的明确定义, 有经验的项目经理及系统分析人员将起到关键性的作用。

3、客户本身原因造成项目范围管理上的困难。

主要包括两方面原因:一是客户本身无法确定清晰的范围定义;二是客户有意拖延明确的范围定义。

针对第一种原因, 要向客户方介绍或带领其参观已经完成的项目, 消除对方的疑虑, 清晰对方的思维。针对第二种原因, 如果处理不好, 不但无法做好范围管理, 还会影响双方的合作关系, 影响到可能存在的后续业务。此时, 项目经理要组织人员做好攻关, 软硬兼施, 让客户方负责人真心投入, 提高对方领导的重视程度, 加深项目干系人对各阶段性工作的印象, 扩大范围定义在客户方单位的认知度和影响面。

4、合同方面的原因造成项目范围难以管理。

在合同签订前销售人员为了能够尽快签单, 往往对客户会有一些不切实际的承诺, 在客户的印象中项目产品已经是无所不包了, 使得客户产生很多不切实际的期望。另外, 国内IT企业签订的合同一般都比较简单, 很少对项目范围有明确规定, 造成项目的范围存在很大的不确定性, 留下了很大的隐藏风险。合同签订后项目小组和客户要有一个渐进的项目范围交互、降低期望的过程, 否则容易出现观点冲突, 对项目的推进造成影响。

四、如何做好项目范围管理

要做好项目范围管理工作必须先了解项目范围管理的一些科学过程, 然后认真按照这些科学过程进行项目的范围管理。依据美国项目管理协会 (PMI) 项目管理知识体系指南 (PMBOK) 中给出的严格定义, 其中包括启动、范围计划、范围定义、范围核实、范围变更控制等内容。

1、项目启动过程。

项目启动是正式承认一个新项目的存在或一个已有项目进入下一个阶段的过程。该过程有一个重要的输出文档是项目章程, 项目章程粗略地规定项目的范围, 这也是项目范围管理后续工作的重要依据。项目章程规定项目经理的权利以及项目组中各成员的职责, 还有项目其他干系人的职责, 这也是在以后的项目范围管理工作中各个角色如何做好本职工作有一个明确规定, 保证后续工作可以更加有序地进行。项目一般是由市场需要、经营需要、客户需要、技术进步、法律要求等一个或多个需要而启动的。

2、项目范围计划过程。

范围计划的核心工作是编写正式的项目范围说明书和范围管理计划。范围计划编制是将产生项目产品的所需进行的项目范围渐进明细和归档的过程。做范围计划编制工作需要参考很多信息, 通常它对项目范围已经有粗线条的约定, 范围计划在此基础上进一步深入和细化。范围说明书在项目干系人之间确认或建立了一个项目范围的共识、作为未来项目决策的文档基准。在进行项目范围规划时, 必须慎重考虑与权衡工具、数据来源、方法、过程与程序, 以及其他因素, 确保为项目而付出的努力与项目的大小、复杂程度和重要性相称。

3、项目范围定义过程。

范围定义指的是把项目产出物进一步分解为更小的、更便于管理的许多组成部分。一个好的范围定义可以提高对项目成本、项目工期和项目资源需求估算的准确性;为项目的绩效度量和控制确定一个基准;便于明确和分配项目任务与责任。在这个过程中, 项目组要建立一个工作分解结构 (WBS) 。WBS的建立对项目的意义非常重大, 它使得原来看起来非常笼统、模糊的项目目标一下子清晰起来, 使得项目管理有依据, 项目团队的工作目标清楚明了。如果没有一个完善的WBS或者范围定义不明确时, 变更就不可避免地出现, 很可能造成返工、延长工期、降低团队士气等一系列不利后果。

4、项目范围核实过程。

范围核实是通过参与者的行为正式确定项目范围的过程。它要求回顾生产过程和生产成果, 以保证所有项目都能准确、满意地完成。这个过程是范围确定之后, 执行实施之前各方相关人员的承诺问题。一旦承诺表明你已经接受该事实, 那么你就必须根据你的承诺去实现它。

5、项目范围变更控制过程。

范围变更控制是指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行为与教训总结。再好的计划也不可能做到一成不变, 关键是对变更进行有效控制。

客户在项目开始之前不能明确所有的需求, 随着业务的发展、客户认识的提高, 客户的需求也在发生变化, 客户提出变更是不可避免的。变更并不可怕, 可怕的是随意的、没有控制的变更。为了使变更有序, 需要与客户一起, 建立变更控制委员会 (CCB) , 制定严格的变更制度、变更流程, 将一切非必要、非紧急、不合理、非高层领导意图的“无效变更”屏蔽掉, 同时采用变更申请表格和配置管理工具有效地管理变更。

五、总结

影响IT项目最后成功的因素是多方面的, 包括项目管理的九大知识领域。有效的IT项目范围管理对项目的成功运作具有重要的意义, 范围管理的成功与否直接影响到对项目进度、质量、成本的有效掌控以及对项目风险的控制。

参考文献

[1]吴吉义, 殷建民, 信息系统项目管理案例分析教程[M], 北京, 电子工业出版社, 2006.33.

IT服务项目管理实践 篇3

关键词 IT服务 项目管理 责任和挑战

中图分类号： TP393 文献标识码：A

1 IT服务管理的重要性

1.1 业务的快速变化对IT部门提出了更高的要求

面对全新的业务环境，IT部门将面临多方面的压力与挑战：

（1）当业务需求更快速的变化时，如何能更快速响应业务、及时推出新IT系统？

（2）当面临更多法律法规的管控要求时，如何保证IT系统合规、安全、稳定的运行？

（3）当业务对信息技术依赖性逐渐增强时，如何实时掌握系统运行质量？

（4）当用户愈加成熟从而提升服务质量意识时，如何提升服务效率和服务质量？

1.2 IT服务管理项目组织特点

（1）广泛参与度。IT服务管理项目经理首先要明确的一点是面向业务的，与所在企业及企业所处商业环境密不可分，所以IT服务管理的推行应当秉承着作为企业资产有机组成部分原则去做。另外一点需要清晰认识到，IT服务管理不能一蹴而就，而是长期的、阶段性的、持续推进的事情，通常需要3到5年的持续改进。

IT服务管理项目咨询方的参与是很必要的，主要有以下原因：

提供专业方法论；

提供行业经验；

帮助决策；

协助推动项目；

实施指导和支持。

（2）矩阵式管理。矩阵式管理将组织按两个或两个以上维度划分，比如按照职能和流程角色。矩阵式管理的应用方式简单来说就是资源调配，需要资源了就按照某个维度去调配，用完了再还回去。

IT服务管理项目组就是个典型的矩阵式管理组织，项目团队中的成员来自不同的部门，有他们所在职能的工作还要承担项目中的相应角色并承担一定的义务，这样多种角色多头汇报的情形在项目推进过程中就难免发生“扯皮”现象了。这样本来想要提高效率的管理方式却可能导致管理成本、沟通成本增加的结果。

（3）项目组织结构。

将流程Owner角色的部门领导放在推行组，并作为项目任务的监督者，这样对增强沟通及减少“扯皮”现象会有所帮助。

1.3 考核与激励

与好的工作效果相关的三个方面：自己喜欢当前的工作，领导分配的任务不得不完成，任务会被考核并与自身绩效挂钩。项目组织结构中可以完成前两步，而在绩效与激励方面先要同老板沟通，提供2～3个适合所在企业的方案得到认同后再与人力资源讨论、落实。

1.4 动态交互性

IT服务管理项目团队的组成是甲、乙双方共同参与，双方通过高度互动共同完成知识转移和渗透，主要形式包括：

培训，管理体系培训、IT服务管理流程培训、流程设计培训、工具应用培训、实践培训等；

访谈，现状调研阶段、阶段性实施后成果访谈等；

讨论，报告、例会、临时会议、咨询等；

宣传，共同制作内刊、宣传材料、问题、内部培训等；

内审，从项目启动后就应当开始建立这种自发的改进制度。

这个互动过程起初会借助乙方的经验来运行，甲方要主动参与和学习慢慢的将经验知识转移为自己的工作内容，有明显效果的应当定位制度固化下来比如内训，比如内审。

1.5 长期性

IT服务管理项目不是交钥匙工程，不是贴标签工程，更不是可以一蹴而就的，它是对工作习惯和管理方式的改变。虽然有ITIL有Cobit等最佳实践，但还是需要根据自身业务特点因地制宜、循序渐进、稳扎稳打的落实，依据项目范围及企业规模不同可能需要3～5年甚至更长的时间进行持续改进最终与业务融合。

2 IT服务管理项目责任和挑战

2.1 主要职责

（1）炼材：选人、沟通、激励是主旋律，锻炼队伍、培养人才是目的。

企业推行IT服务管理项目，主要是解决实际中现存的问题然后是效益，但无论前后都涉及到业务领导、部门负责人、职能承担者等，那么依照IT服务管理项目解决哪方面问题、实现哪方面效益不同项目经理应当选取不同的人来参与，包括企业内部、咨询公司、厂商的人员的选取。

（2）成事。

做成一件事情涉及到多方面，企业文化、计划、组织等，说到底识别并规避风险，然而是不是可以将与IT服务管理项目相关的风险都识别出来，识别出来的是否都能解决？行业相异、企业不同、具体情况更是千差万别，这里仅说一些常见的风险。

组织架构变动，一方面人员职责不明确，另一方面人心浮躁，这两点都足以阻碍项目的推进；最好的规避措施就是等待组织架构变动完成后再推进项目，如果在项目进行中组织架构变动，为组织架构变动预留足够的时间是个明智的做法。

过度依赖咨询公司。咨询公司可以带来体系化的知识与客观的建议，可以比喻为甲方的“拐杖”，无论是对业务的理解、IT服务管理落地还是长久的应用，甲方都是主角。规避措施可以使以下几种：

拥有对企业业务有深刻理解并有丰富IT服务管理经验的帶头人；

建立一只甲方自己的IT服务管理队伍，结构上分成三个方面：包括具备IT服务管理意识的业务端、对业务端支持的IT服务管理团队以及质量体系监控方；

领导的高度重视；

熟悉企业业务的咨询公司；

明确的阶段性目标，切实可行的项目计划、WBS，以及被认同的预算。

2.2 关键技能

（1） 领导能力。

由于IT服务管理项目结构的特点，项目成员有业务或技术高层担任的管理者代表、其他部门的经理或员工。在这种情况下采取参与式或顾问式的的领导方式会比独裁式或命令式的更为有效，实际上在平衡利益、争取意见一致性方面的阻力也会较小，明确了领导方向也就给项目成功定下了一个基础。

有了适合的领导方式，就需要团结各方力量协同工作，关键在于建立“信任”。可以從以下几方面去考虑：

律己：言行一致，如果要求别人加班或者细致的工作，要让自己先做榜样；

用人不疑：授权相对于职能不要反差太大，一旦明确授权就要充分信任，建立起战友般的友情与忠诚；

正向引导：使团队成员充分了解项目结果和利益，通过生动描绘目标达成的结果使大家了解实现项目的收益。

（2）沟通能力。

IT服务管理项目经理必须是一个良好的沟通者，他要与项目团队成员、各相关部门、咨询公司、产品厂商等进行定期的沟通。只有通过有效的沟通，才能确切了解各方面实际的情况，发现潜在问题，制定解决方案，协调关系、集结资源使项目向着期望的方向前进。

（3）人际交往能力。

良好的人际交往能力可以影响周围人的思想及行为，在项目推进中IT服务管理项目经理会与项目团队成员或者高层管理者进行说服和协商工作，比如出于公司整体考虑，需要利益平衡将改进的进度延后。

（4） 时间管理能力。

良好的时间管理能力可以说是项目成功的一个必要条件，列出一些常见的时间管理技巧；

优先计划管理：按重要程度和紧急程度来确定先做什么后做什么，如：重要紧急的优先分配时间完成，重要不紧急的每天都持续一段时间做，不重要但紧急可以安排给别人做，不重要不紧急的最好不占用团队时间；

适用时间计划工具，编制计划并进行跟踪，有时候一个CheckList效果也不错；

把工作授权给他人：不必每一项工作都事必躬亲，授权给部下一样干的好而且还能锻炼队伍；

拥有良好的心态：压力并非来自已经解决的事情，而是来自未能克服的困难。

2.3 面临的主要挑战

（1） 组织结构与项目范围的变化。

IT服务管理项目不一定都会遇到组织结构与项目范围的变化，但如果你碰到了，可以肯定的是有很多事情都要变，包括指定的计划、铺垫的关系以及和领导预先的沟通甚至承诺。坦然面对这些，这种事情并非无法克服。无论如何，这种变化通常是高层管理者在变革过程中平衡公司内部各种利益的方式，从长远来看对IT服务管理项目执行和贯彻是有好处的。

（2）跨部门协调与沟通。

无论是对内提供服务的内部IT还是对外提供服务的IT服务供应商，在做IT服务管理项目的时候都会涉及到跨部门的协调与沟通。而IT服务管理主要是针对管理精准化、规范化的一种项目，推行过程中一旦涉及到利益的平衡就会有得失，相应的跨部门的沟通就会遇到阻碍。

措施：与管理者代表沟通，制定规则；定义每周例会，相关部门的流程经理都要参与，必要时也可以邀请职能经理参与；会议中可以将跨部门协调、沟通有难度的拿出来讨论，并记录会议纪要，会后将会议纪要分发至相关人员。

2.4 IT服务管理项目实施中沟通问题

IT服务管理应用场景很多，有的是运维环境、有的是呼叫中心、有的是BPO形式的对外服务，项目团队中会有技术专家、业务专家、管理专家，这样沟通的时候就会有问题。

通常技术专家在谈论的时候会用到联通性、延时、流量、丢包率、MTU描述网络性能，用DAS、NAS、SAN来告诉别人我们的存储是怎样的，或者开个玩笑“写SQL，Delete的时候竟然忘了用where”，在笑的前仰后合的时候很难说另外两组专家有何想法。

业务专家很清楚IT服务是什么，他会说我关心的是服务产品化，可以持续的快速复制，让我们在竞争环境中处于有力地位提升市场占有率，还要控制成本；当然毛利率高了他们才有收益，了解业务的技术专家会这么想。

管理专家两方面都会了解一些，而且说明问题的时候总能深入浅出“瞧，CMDB是个逻辑库，你可以把AIX想成一个装满白菜、萝卜的大柜子，而我们只要有个列表……”不过，这可能让系统管理员表情显得不自然。

这些日常的话语并非问题或者冲突本身，只是借用的一种方式，这说明我们可能忽略了一些本该有的沟通，有时是内部的、有时是外部的。

参考文献

[1] 杨坤，王玉.IT项目管理[M].北京：机械工业出版社，2008.

[2] 欧立雄，成功的项目管理[M].北京：机械工业出版社，2008.

it项目经理的职责具体有哪些呢 篇4

2. 负责对应领域业务访谈、需求收集与分析、方案设计、业务描述文档编写、系统功能的测试与验证等。

3. 负责研发领域简单IT解决方案的制定与推行。

4. 负责所属领域小型项目的管理与执行。

5. 组织用户进行单元、集成测试与验证。

6. 发现、提高、解决应用系统运行中存在的问题，包括使用不便、功能不足、流程缺点等。

7. 应用系统的日常使用问题解答与定位支持、简单数据技术问题的处理以及处理因用户操作导致的异常问题。

★ 工程项目经理的具体职责

★ 工程项目经理工作的具体职责

★ 系统集成项目经理的具体职责表述

★ 测试项目经理职责

★ 物业项目经理职责职责

★ 项目经理工作职责描述

★ 项目经理工作职责都有哪些

★ 物业项目经理的职责描述

★ 行政复议的具体职责

IT数据库管理岗位职责 篇5

2.负责Oracle数据库(ERP数据库、生物部Waters数据库、物流部CIMS数据库）的性能分析和维护工作，如表空间的维护、日志文件的维护。

3.负责Oracle数据库(ERP数据库、生物部Waters数据库、物流部CIMS数据库）的书籍访问权限的分配。

4.负责报据用户部门的需求在办好相应的审批手续后进行数据库后台操作，如数据的导入、导出、修改等工作。

5.负责公司内部SQL数据库(ACCPAC系统HR系统的数据库、其他应用程序的数据库）的备份和恢复工作，数据库的备份利用SQLServer自带备份工具执行，需要每日进行，并记录备份结果，恢复工作主要是根据用户部门的需求进行，另外每半年要在用户部门配合的情况下进行一次恢复测试。

IT项目管理案例 篇6

一个公司的IT部门分为规划部和研发部，规划部负责出方案，和客户谈单，规划部门的人对业务熟悉，但是不熟悉软件技术和项目管理，研发部有开发组长（开发经理），属于技术能力很强，在团队中很有影响力，但是不熟悉业务，不擅长沟通协调。两者都不是项目经理的最佳人选，但是又必须有一个PM角色对项目目标负责，但是这两者立了谁，都不合适（谁做另一个人的上级都欠妥）。于是有人提出了“双项目经理”概念，由两个人来共同承担这个角色，在职位上是平等的，但是需要定义一个对上级负责的人，面对上级是一个人，决策由两人互补长短来进行，但是这需要这两人有非常高的默契协作能力。这个“双项目经理制”，可行吗？

参考答案：

在一个团队里面，没有一个清晰的领导人员，最容易造成权责模糊，执行力下降。更何况文中都说到两位高级人才，无论谁压着谁都不好，说明两人的领导能力旗鼓相当，如果两人发生权利之争，又该如何保证项目如期进行呢？本身业务和软件技术两个领域相差的就比较远，两位项目经理对自己不熟悉的领域会一些看不到的东西，但是很容易为了自身的脸面而坚持自己的观点（国人还是比较看重这个的）。建议：由软件技术的人出任PM，最大限度可以保证项目正常进行完成，同时熟悉业务的人员以顾问或监督的形式参与项目，监督项目的进度以及质量，但是不可以插手项目具体的工作。

案例2

1.如果你遇到这种恶性挖人的情况，你会选择什么方式处理？如何挽回劣势？

2.在现在已经成为定局的情况之下，你会采取何种方式对B公司人员进行的项目进行控制

参考答案：

1.如果遇到这种恶性挖人的情况，（1）对公司内的管理进行反省，制定策略，尽量重新召回以前的员工；

（2）要镇定，尽量采取措施重新组建核心团队，将损失减到最小；

（3）利用行业舆论和法律手段加以解决；

（4）大家都把问题摆在桌面上谈，通过协商解决处理，达到双方共赢。

2.控制项目可以首先对项目进行跟踪，在项目的整个实施过程中对项目状态以及影响项目进展的内外因素进行及时的、连续的、系统地记录和报告。其次对项目进行控制，以事先制订的计划和标准为依据，定期或不定期地对项目实施的所有环节的全过程进行检查、分析、建议和咨询，发现项目活动与标准之间的偏离，提出切实可行的实施方案，供项目的管理层进行决策。

（1）建立项目的基准计划；

（2）收集有关项目进展情况的信息；

（3）寻求偏差；

（4）对偏差的原因和趋势进行分析；

（5）采取措施来纠正偏差。

最后，对项目变更进行控制并把握以下原则：

（1）把项目变更融入到项目的计划中去；

（2）选择影响最小的方案；

（3）所有的变更在准备变更申请和评估之前，必须与项目经理进行商讨；

（4）及时发布项目变更信息。

案例3

问题：

（1）、你认为该案中存在的真正问题是什么？

（2）、该案例是否反映了现实生活中的一个真实场景，为什么？

（3）、尼克是不是一个好的项目经理？为什么？

（4）、要成为一个更好的项目经理，尼克本应该怎么做？

（5）、上级管理人员应该怎样去帮助尼克？

（6）、你预测本案例的结局会怎样？

参考答案：

案例中存在的真实问题：管理混乱。

（一）、尼克从技术人员，直接被提升为项目经理，而没有经过相应的项目经理知识培训。尼克做首席软件开发员，只能证明他的技术水平够强。但不能代表，他有能力去管理一个团队，能够将进度、资源、质量协调的很好。并且被指派的尼克做项目经理未必能够服众。从这点上，可以看出该公司在人才的培养上有很大的问题，强行指派不是解决问题的好办法。

（二）、工作的安排，尼克做为首席的软件开发员，其担任的开发任务是相当的大的，而做为项目经理其工作量更比一般的开发人员大的多。尼克任项目经理后，势必难在二者之间把握平衡，必将造成二者都作不好的结果。

（三）、工作量的科学估算。

（1）工作量需要通过科学的方法进行估算，来确定合理的进度。不能强行指定项目时间。即使有其他资源的增加，也要通过合理估算，才能确定。

（2）该案例确实反应了现实生活的一个真实场景。从其中的一点可以看出，比如开发时间确定的共十三个月，三年换三个项目经理的原因，可能也就是基于此，每年一个项目经理，就是因为在十三个月的时间内，没能完成指派的任务。

（3）尼克是一个好的开发人员，未必是一个好的项目经理。原因如第一条第1项所答。

（4）成为一个好的项目经理

1、首先，要具备项目经理素质，参加项目经理知识的培训。

2、转换角色，从技术转为管理。培养新的首席开发员。

3、与管理层沟通，合理安排项目进度。

（5）上级管理人员应该提前对尼克进行项目经理知识的培训，帮助尼克在项目中树立威信。为尼克配备好接替的开发人员。

（6）预测尼克在一年后，会成为该项目离职的第四个项目经理。

案例4

但事后，公司进行了二个月封闭式开发，没有让Y的参与，项目组留下Y一个人呆在公司。所有的工作就没有Y的工作，但项目开发的进度和交流进展很顺利，项目初期成果得到了客户的认可。这时公司应部门经理的要求开除了项目经理Y，理由是不热爱公司，对项目没有兴趣。

• 问题：

1.在这四个多月的时间内，项目经理Y在T公司是失败，还是成功？

2.项目经理Y离开后，部门经理Z利用现有环境，有能力把项目带好吗？

参考答案：

部门经理毕竟是项目经理的上级，如果部门不够大，项目经理更加要小心，需要经常和部门经理沟通，必要的时候直接和高层沟通。Y在项目的管理上成功，尤其他给团队带来了新的工作方法及合理的项目制度，并取得了很好的效果，应该说在这方面他是成功的。

但作为一个项目经理人，人际关系尤其是高层之间的政治关系考虑的不够，虽然和项目团队成员保持了较好的关系并得到了他们的信任，但没有恰当利用这一点，以至最后失败。对一个项目经理人来说，高层之间的政治关系、对项目的支持程度以及对你个人的信任程度，是相当重要的，而Y恰恰忽略了这一点。Y在管理项目上有成功的一面，但他没处理好项目中政治因素，很显然，Y的成功将大大损害Z的利益，而且Z有高层的强力支持。

我想Z已经失去了对开发团队的控制，虽然开始还算顺利，一碰到困难，项目团队中的成员那时就不会团结一致去解决问题，因为团队成员积极性受到了伤害，也已经失去了协作精神。而显然Z在方面的能力是不足的。

案例5

如何平衡，董事们提出了各自的想法。董事C的看法：把他增选进董事会，然后兼任公司技术负责人。董事Z的看法：我们需要的是懂管理，能带领员工扩大经营规模，创造效益的经理，既然他不行，那就撤职让他专干业务，那不就行了吗。现在的企业对人的管理不必太顾虑，该咋办就咋办。董事S的看法：把他调回，给他3000元苦劳奖，开个离职欢送会，大家吃顿欢送饭。

作为董事长的你，如何平衡？

参考答案：

如果我是该公司的董事长的话,我会作如下的分析：首先,我需要决定这个经理能否继续胜任项目管理的职位。一个好的项目经理需要许多非技术的技能来有效地完成工作,包括:沟通、组织、订预算、解决问题、谈判与影响、领导和班子建设等。

如果我的董事会成员和我都相信,这个经理当前并不具备这些技术,也没有足够的时间来培训他的话,我们就要尽快找到一个新的项目经理来替换他,如果项目的绩效没有达到期望,那么他必须接受他无法继续这个角色的现实。

现在我们来作是否要让他留在公司的决定.。他的技术才能有目共睹,并且如果他真是个工作认真,勤奋和敬业的雇员,那么公司仍能从他身上获益。当然,前提是有那么一个他和公司都能认同的合适的职位，这就和懂事Z的建议相一致。

把他增选进懂事会的方案只有在公司真正需要一个技术负责人的时候才是可行的。但是,将他提升到一个新设立的职位上,无论对公司还是雇员个人来讲,都没有太大的好处。

浅析如何做好IT项目管理 篇7

从概念上讲, IT (Information Technology, 即信息技术, 简称IT) 项目管理是根据管理科学的理论, 结合IT产品开发的实际, 保证工程化系统开发方法顺利实施的管理实践, 为了使IT项目能够按照预定的成本、进度、质量顺利完成, 从而对成本、人员、进度、质量、风险、文档等进行分析、管理和控制的一系列活动。

2 IT项目管理的重要性

随着信息技术的飞速发展, 信息技术的应用已成为社会各行各业所不可或缺的, 成为了企业发展的重要因素之一。电信、银行、医院、钢铁、制造、石化、食品等各大行业纷纷引用了信息化管理的先进理念, 凭借ERP、CRM、电子商务等信息系统及信息应用, 提升了企业自身的实力, 增强了企业在市场中的核心竞争力和影响力。

与此同时, IT项目中“黑洞”也应运而生:项目无法按期完成、项目合作方的工作难以协调、用户需求经常变动、工作质量难以保证, 给企业带来为了愈来愈多的损失。这种情况说明了IT项目开发及管理过程中, 存在着许多的问题, 需要更多的重视和研究。

没有运用IT项目管理是面临如此众多问题的主要原因之一。IT项目管理作为一种科学的管理手段, 是为了使IT项目能够按照预定的成本、进度、质量顺利完成, 而对成本、人员、进度、质量、风险等进行分析和管理的一系列活动。因此, 对于以“项目”为基本运作单位的各软件开发企业, 都在积极地将IT项目管理引入开发活动中, 对软件开发实行有效的管理。因此, 决定一个IT项目实施成功与否, IT项目管理无疑起着举足轻重的作用, IT项目管理已经是公认的软件开发企业的核心竞争力之一。

3 如何做好IT项目的管理

IT项目管理不同于其他的项目管理, 它涉及到企业的管理变革和流程再造, 是一个相当复杂的过程, 任何一个环节上的小小失误, 都有可能使整个IT项目功亏一篑。那么如何做好IT项目管理呢?除了要严格遵照项目的启动、计划、执行、控制和收尾五个过程有步骤地完成之外, 从管理角度上还应做好以下几方面的工作。

3.1 系统、全面地做好需求调研与分析

IT项目管理中的需求调研与分析是提高软件质量的基础也是决定一个IT项目成败的关键。正确掌握了项目的整体概念, 从而掌握好项目的需求、资源、工期、质量这四个要素之间的平衡关系, 是整个IT项目成功最坚实的理论基础。因此, 系统、全面地做好IT项目的需求调研与分析是至关重要的。

即使是天下最无能的领导, 都知道在作报告时要先从宏观上讲一、二、三、四、五, 再从细节上讲A、B、C、D、E。需求分析不像侦探推理那样从蛛丝马迹着手, 而是应该先了解宏观的问题, 再了解细节的问题, 如下图 (图1) 所示:

一个软件系统 (S) 的涉及面可能很广, 可以按不同的问题域 (D) 进行分类, 每个问题域对应于一个软件子系统, 即:S={D1, D2, D3, …Dn};问题域Di由若干个问题 (P) 组成, 每个问题对应于子系统中的一个软构件, 即:Di={P1, P2, P3, …Pm};问题Pj有若干个行为或功能 (F) 组成, 每个行为对应于软构件中的接口, 即:Pj={F1, F2, F3, …Fk}。

按照这种结构进行需求调研与分析, 从而编写出来的需求说明书, 对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。

此外, 在编写需求说明书时还应注意两个问题:

(1) 最好为每个需求注释“为什么”, 这样可让程序员了解需求的本质, 以便选用最合适的技术来实现此需求。

(2) 需求说明不可有二义性, 更不能前后矛盾。如果有二义性或前后相矛盾, 则要重新分析此需求。

3.2 全盘了解项目信息, 制定项目计划

一个良好的计划对IT项目的管理至关重要, 好的计划是项目成功的一半, 但其所花费的时间应尽量缩短, 以使项目尽快进入受控状态, 并为以后的实施阶段留出充裕的时间。在制定项目计划时, 首先要全盘了解项目的目标、范围等各项信息, 明确项目中包括哪些工作内容, 优先级顺序以及相互之间的依赖关系, 继而合理地分配资源、安排进度、估算成本, 设置项目的重要里程碑。

项目计划的意义在于通过制定计划来预测在现有的资源情况下能否完成项目的目标, 完成项目目标的把握程度和主要风险, 将大项目目标进行分解和细化, 以对项目有更加深入的理解;项目计划是后续项目跟踪控制的基础, 可以及时发现偏差并纠正;项目计划是项目管理持续改进的基础, 在项目结束时可以总结和分析与计划的差异, 分析各种数据和偏差, 及时改进我们的方法和过程, 积累数据。可见, 制定项目计划是IT项目管理中必不可少的重要一环。

3.3 树立正确的项目风险管理意识

所谓风险管理, 是指对风险从认识、分析乃至采取防范和处理措施等一系列过程。具体地说, 就是指风险管理的主体通过风险识别、风险分析和风险评估, 并以此为基础, 采取主动行动, 合理的使用回避、减少、分散或转移等方法和技术对活动或事件所涉及的风险实行有效的控制, 妥善地处理风险事件造成的不利后果, 以合理的成本保证安全、可靠地实现预定的目标。项目风险管理的实质, 是针对项目进行过程中各种各样的风险事件, 在合理分析评估的基础上采取合理的对策, 促进项目管理目标的实现。

目前, 项目风险管理已被认为是减少IT项目失败的一种重要手段。要真正搞好IT项目的风险管理, 首先要树立正确的项目风险意识, 确立具体的目标, 制定具体的指导原则, 规定风险管理的责任范围。项目风险管理应贯穿于IT项目建设的整个过程之中, 特别是在IT项目的可行性研究和计划阶段, 风险管理的应用尤为重要。在IT项目的前期阶段面对的不确定因素较多, 因此在这一环节推行风险管理对提高项目计划的准确性和可行性有极大的帮助。

3.4 切实有效地做好项目跟踪控制

有一条管理格言说:“没有跟踪就不算完成”。做好项目跟踪控制就是为了保证项目能够按照预先设定的计划轨道行驶, 使项目不要偏离预定的发展过程。项目跟踪的目的是发现项目的偏离和问题, 而项目控制的目的则是纠正偏离和解决问题。所以两者密不可分, 跟踪是为控制服务, 而只要对跟踪的内容控制了才能够真正达到效果。

在IT项目管理中, 由于许多不确定因素的存在, 例如项目需求的变更, 使得项目实施过程几乎不可能完全遵照计划来执行, 因此, 随时跟踪项目实施进程, 及时发现实施中的问题, 并能够切实有效地修正项目计划, 使整个项目处于控制之中, 是确保IT项目有序执行的重要保障。

3.5 掌握IT项目管理中的沟通技巧

IT项目中有很多工作需要充分地沟通。确立项目目标, 达成共识需要沟通;明确职责, 分工协作需要沟通;工作汇报, 意见交流还离不开沟通。沟通障碍往往会造成项目多次返工, 事倍功半, 严重时还会酿成不可挽回的损失, 导致项目以失败告终。

沟通是人员、技术、信息之间的关键纽带, 是IT项目成功所必须的。1995年, 斯坦迪什集团研究发现, 与IT项目成功有关的三个主要因素是:用户参与、主管层的支持、需求的清晰明确。所有这些因素都依赖于拥有良好的沟通技巧。IT项目管理人员除了在项目前期编制良好的沟通计划外, 更要懂得如何科学地管理团队, 如何艺术化地与项目干系人进行沟通, 站在各角色人的立场上, 想客户之所想, 急客户之所需, 这样才能做到通过IT项目成果使客户得到最大的收益, 让客户满意, 这样才能实现一个IT项目的成功性目标。

最后, 引用国家统计局计算中心应用开发部主任的一句话作为总结:“对于项目实施, 我们的目标是一致的:希望项目交付的产品及其功能、性能能满足预定期望。为此, 我们需要对项目进行科学的管理。在这漫长的实施过程中, 我们体会了这种科学管理的严酷, 也确实分享了这种科学管理所带来的益处。”

摘要：项目管理作为近年来一门新兴的管理科学, 以其独特的思路、创新的理念逐渐在社会生活中显示出巨大的效益。此文特别就IT行业中软件项目开发及实施应如何管理作了浅显的分析。首先从IT项目管理的概念及重要性等方面进行了阐述与实例分析, 然后通过五个不同的侧面, 针对如何做好IT项目管理提出了一些个人建议。

关键词：项目管理,信息技术,沟通,风险管理

参考文献

[1]杰克.吉多.詹姆斯, P.克莱门斯.成功的项目管理[M].第2版.北京:机械工业出版社, 2004.

[2]David C Hay.需求分析[M].北京:清华大学出版社, 2004.

项目型企业的知识管理及IT实现 篇8

项目型组织要保证做正确的项目和正确地做项目，就需要利用知识管理的手段和方式，借助先进的信息技术平台，在组织内部有步骤、分阶段地开展知识管理活动。

由于项目运作的一次性和独特性，使项目型企业不论是传统的如建筑、房地产等工程类项目型企业，还是高新技术产业、设计研究、咨询等服务型项目型组织，都面临同样的挑战，即如何积累项目的最佳实践，提高项目的及时交付能力，重复项目实施的成功。知识管理的有效实施将有效应对这种挑战。

根据对多家项目型企业的知识管理咨询经验，AM咨询认为，项目型企业实施知识管理可以实现三大目标：

★ 项目知识经验积累: 通过项目案例库实现所有项目过程文档和经验总结的积累，从而形成项目型企业的核心财富。

★ 项目的快速交付：通过提炼项目运作过程中的标准方法，提高项目的快速复制能力，使每一个新的项目站在一个较高的起点上，在已有经验的基础上进行，避免了每个新项目都是从“零”开始。

★ 人才培养和经验复制: 项目管理人才和专业人才的缺乏是项目型企业发展普遍面临的瓶颈，通过知识管理可以系统地梳理专家经验，通过知识的学习共享进而加速人才的培养，使企业和员工个人通过知识管理实现双赢。

项目型企业的知识该如何管理

对于项目型企业知识管理的实施，AMT咨询认为，首先要识别项目型企业需要哪些核心知识，一个完善的知识分类体系反映了该企业业务的内在逻辑和核心知识。知识分类体系构建的核心是根据业务部门工作的习惯和需要的信息，重点分析客户、项目、人员、文档、工作流之间的关系，从传统的单维度的文档管理转变成多维度的知识管理，图1为某项目型企业的知识分类体系示例。

我们可以从显性知识和隐性知识两个维度来具体分析项目型企业的核心知识及其管理方式。

◆ 显性知识的知识管理方式

项目型企业的显性知识主要包括各种项目过程文档、产品信息、外部资料等等，显性知识管理的主要目标是形成企业稳定的、可积累的知识分类体系，以便于知识的沉淀和获取。

通过长期的业务运营和项目运作，很多项目型企业都积累了丰富的显性知识，那么这些知识应该如何管理呢？这里，我们介绍几种适合项目型企业的显性知识管理方式：

项目案例库：项目型企业对知识管理需求的重点在于如何积累各产品在运作过程中的成功模式，并逐步建立和形成产品模式的最佳实践，并以项目案例库和知识地图的形式进行管理和展现。项目型企业的项目案例库，内容一般包括：项目过程文档管理、项目中的经验总结。项目案例库的建立可以使项目成员在任何需要的时候都可以很方便的找到之前的类似项目，为目前工作提供有参考价值的经验以及借鉴各种可复用的知识成果。

知识地图：知识地图是一种帮助用户知道在什么地方能够找到知识的知识管理工具，知识地图是一种向导，它本身并不是一个知识的集合，而是关于知识来源的知识，知识地图指向的是知识源。知识地图不仅能揭示知识的存储地，通常也能揭示知识之间的关系，知识地图的最终目标是帮助企业员工实现知识的共享。

通过项目案例库和知识地图，可以将存在于企业中的丰富的知识转化成为可分享、可复用的知识资源，让各部门、各项目组的知识转移和分工协作更加容易，使项目成员可以参考更多的以往成功项目的工作经验，降低项目运作的成本，提升项目运作的效率。

◆ 隐性知识的管理方式

项目型企业的隐性知识主要包括：项目运作的经验、教训、技能、思维方式等。这些知识看不见，摸不着，但是这些隐性知识对于项目型企业的作用较显性知识更有效，更有价值。因此，对隐性知识的管理方式实际上就是使隐性知识显性化。

AAR是一个结合了技术和人的因素的快速报告的方法或工具，是一个简单而有效的过程，供团队用来获取从过去的成功和失败中得到的经验教训，以便改进未来的表现。它为团队提供反思一个项目、活动、事件或任务的机会，让团队成员参与诊断和评估过程的形式来加强他们的学习过程，并同时提供关于团队表现的反馈。

警示报告是一种通过建立快速响应的机制和渠道，将经验教训、重要问题的解决方法快速在整个组织内部进行扩散的一种知识管理工具。组织中的不同团队在工作过程中经常会碰到一些实效性强，对其他团队又有重要参考价值的问题与疑惑，通过警示报告可以迅速将解决方案传递到可能需要的团队那里去，避免组织内部不同的团队间重复解决同样的问题，避免组织犯同样的错误。

导师制是一种应用非常广泛的知识管理工具，类似于以前“帮传带”的师徒关系。它是指为每一位新员工有针对性的指定一位导师(Mentor)，这位导师通过正式与非正式的途径将自己的知识传授给新员工，使新员工能够在新的工作岗位上更好地适应和发展。导师一般由企业里富有经验的资深员工担任，他有培养和指导别人的责任和义务。对新员工来说，借助导师的经验也可以早点进入工作状态 。

员工黄页是一个特定的员工名单目录，通过查询促进内部某个领域、某个知识点的员工与需要该知识的员工之间的交流，从而促进知识在组织内部得到传播和共享。员工名单目录里面包含了员工擅长的知识信息，通过查询的方式让大家都知道：谁能够帮助我？

CoP（Community of Practice），实践社团。实践社团是由一群专业工作者所组成的正式或非正式的团体，社群因为共同的兴趣或目标而聚集在一起。他们有着共同的关注点，通过在不断发展的基础上相互影响，加深在这一领域的知识和专业技术。

内部演讲是组织内部的一种非正式的交流与培训活动，是互相学习的渠道、充分共享的工作氛围与环境，有利于经验的交流与思想火花的碰撞，是一种有效的知识管理工具；内部演讲也是员工充分展示自我的舞台。

上面我们介绍了六种隐性知识的管理方式，那么这些方式如何在项目运作中应用呢？

图2清晰地展现六这6种隐性知识管理方式适用的项目阶段。

如何保障项目型企业的知识管理有效实施

其实，很多项目型组织已经意识到知识管理的重要性，但真正地实施起来还是有一定难度。因此，在具体的实施过程中需要注意一下几点：

◆ 知识管理需要和业务紧密结合

大部分项目型组织已意识到知识管理的重要性，但实施起来依然难以推行，其存在的最大问题是知识积累和业务过程相脱离。具体表现为项目实施过程中重点关注进度，忽略相关知识文档的同步提交和保存，相关文档往往是在项目结束后再整理，这就导致知识的完整性和时效性无法保障，很多宝贵的资料散落在各项目组内部。另外，企业内独立的知识管理部门往往脱离业务部门，通过知识管理平台收集到的都是一些和核心业务关系不大的文档资料。

“1＋1＋1”解决方案（项目型组织的项目管理、流程管理、知识管理有机集成）是解决知识管理与业务过程脱节问题的一种很好的方式。这种解决方案的核心在于项目过程和知识管理过程的同步。在项目活动和流程环节的每一步明确相应的输出文档和参考文档以实现显性知识的传播。通过对输出文档制订模板和样例，对于以往的项目最佳实践予以提炼，同时相关的参考文档可方便项目组快速地获取相关的知识资料，从而实现快速学习和交付。

知识管理的核心价值在于和业务过程紧密结合，发挥作用。 在流程梳理优化的基础上，在流程的每一个关键节点上，我们需要找到最佳做法，并大面积共享，从而提升流程的执行效果，而非简单的执行效率。

◆ 知识管理需要有共享的文化来保证

知识管理最终需要形成一个共享的文化来保证。如果没有文化的保证，项目就非常容易失败。据一个学者的研究调查发现，有高达54%的企业主管认为知识管理的最大障碍来自于组织文化层面。

为什么文化的作用如此重要？这文化就如企业的空气一样，其质量状况如何，直接会影响到所有员工的身心健康。由于其辐射圈很大、继承性很深，要想净化它并不容易，而一旦得以净化则会对企业所有员工的行为规则产生影响。

塑造有利于知识管理的项目型企业的共享文化应关注以下几个方面：

＊ 使员工具有积极的知识取向。员工聪慧、好奇、愿意自由探索，管理人员鼓励知识创造和运用，高度评价各种学习活动。

＊ 使员工愿意与别人共享知识。员工没有和别人共享自己知识的原因主要有两个：一是没有时间和精力来共享知识；二是不愿与别人分享成功经验，相信自己的价值及工作保障在于独有的专业技术和经验。

＊ 与原有的企业文化相融合。公司原有的企业文化有时并不利于知识管理，甚至会妨碍人们共享知识，如在一些大的设计公司里，设计师们往往对个人设计有很高的成就感，因此不屑于使用已有的设计。但知识管理要真正在公司中有效的实施，就必须要考虑到公司已有的文化，因为要改变它是一个非常困难和长期的事情，尤其是当一个公司的文化已被实践证明是非常有效时，就没有必要对其做大的改变。

＊ 应取得企业高层管理者的支持。高层管理者的支持有利于在公司内形成知识管理的氛围，也可以取得资金或其他资源的支持。

“分享”是知识管理的核心理念，是团队建设的基础，也是知识管理成败的难点和重点。每个想实施知识管理的企业，都可以拿起“文化”这把镜子照照自己，看着你的现在，想像你的未来。

◆ 知识管理的IT实现

管理和业务的需求最终要落实到IT系统上实现。“1＋1＋1”解决方案对于IT系统的实现提出以下特殊功能需求：

权限管理要求：对于流程和知识的管理，如何使“合适的人在合适的时间看到合适的知识信息”，对系统权限管理提出比较高的要求。在项目管理过程中，比较特殊的就是根据项目的授权，如项目的文档根据项目组成员自动进行授权。

项目任务、工作流程、项目文档的三位一体：可按照项目类型和项目级别定义所对应的项目过程标准化模版，包括项目工作任务分解，相应的流程和每个活动相关的项目文档定义，实现项目任务、工作流、项目文档管理的统一，从而通过IT系统使知识共享和复用得到强制进行。

项目过程标准化模板的积累与应用：项目实施完成后，可将实际实施的项目导入到组织经验知识库中进行提炼、完善与改进，从而形成新的项目标准模板。项目建立时，系统会根据项目的类型和项目的重要级别所对应的项目过程标准模版自动初始化项目，实现知识的再利用。

项目动态知识地图的生成：可按照项目、项目阶段、项目类型等动态地提取相关的知识资料生成知识地图，以进行项目知识的聚类展示，从而以简化信息检索过程，提高知识获取的便利性。

经营分析和决策支持：随着项目型组织的持续积累和发展，如何基于以往的数据进行提炼挖掘，形成知识以支持高层决策也是信息系统需要考虑的新需求。对于项目型组织经营分析可从客户、项目、人员和知识四个维度去分析，其中客户和项目是业务管理的核心，而人员和知识构成项目型组织的核心竞争力，是项目型组织成长和发展的基础。通过经营分析体系构建稳定的分析结构，通过对历史数据的各种分析从而促进项目型组织的持续改进和优化。