案例分析及阅读资料

软件需求是软件开发的最重要的一个输入，需求风险也常常是软件开发过程中最大的一个风险，降低需求风险的一个重要手段就是需求评审，但是需求评审是所有的评审活动中最难的一个，也是最容易被忽视的一个评审。笔者曾经历过以下的几种失败的需求评审： 案例一

某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会开始时间不长，就被在场的某企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中无法实施。该副总提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。 案例二

某软件公司内部举行产品的需求评审会，主要是公司内部的相关领域的专家参加，在评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。 案例三

某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。 案例四

某软件公司在用户处开完物资管理系统的需求评审会后，与会人员在离开会议室时纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。 案例五

某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划的主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。

以上的现象可以在很多项目中都可以看到。概括起来，在需求评审中常见的问题是： ◇ 需求报告很长，短时间内评审者根本就不能把需求报告读懂、想清楚； ◇ 没有作好前期准备工作，需求评审的效率很低； ◇ 需求评审的节奏无法控制；

◇ 找不到合格的评审员，与会的评审员无法提出深入的问题； ……

那么究竟如何做好需求评审呢？ 建议一：分层次评审

我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次： 目标性需求：定义了整个系统需要达到的目标； 功能性需求：定义了整个系统必须完成的任务；

操作性需求：定义了完成每个任务的具体的人机交互； 目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。 建议二：正式评审与非正式评审结合

正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签

1

甚至是网络聊天等多种形式对需求进行评审。两种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这两种方式。 建议三：分阶段评审

应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。

建议四：精心挑选评审员

需求评审可能涉及的人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。 建议五：对评审员进行培训 在很多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行培训，同样对于主持评审的管理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率，避免发生案例一和案例二中出现的现象。对评审员的培训也可以区分为简单培训与详细培训两种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的基本原则，需要注意的常见问题说清楚。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。需要注意的是被评审人员也要被培训。

建议六：充分利用需求评审检查单 需求检查单是很好的评审工具，需求检查单可以分成两类：需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题，检查单也是随着工程财富的积累逐渐丰富和优化的。 建议七：建立标准的评审流程

对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。

建议八：做好评审后的跟踪工作 在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。

建议九：充分准备评审

2

评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。

在实践中细心体会、实施上述的9个建议，相信您定会受益非浅。

3

案例正文：一个项目经理在开发一个为期10个月的项目的三个星期后得到客户通知，项目要在不增加成本，不影响范围和质量的情况下，需要在8个月内完成，项目经理应该怎么做？

分析：一、了解客户计划改变的真实原因

在做项目的很多时候，客户方会要求项目在不增加成本，不影响范围和质量的情况下，提前完成，但是一定有他的理由，也许是你的竞争对手采取的措施，也许是我们在做项目的时候有哪些不对的地方，或者是客户遇到新的其他情况不等，但是在客户提出之后，不能明确的答应也不能以强势的态度拒绝，等了解真正的原因后再做打算。 二、向客户沟通

假如必须提前完成任务，要向客户说明其困难，假如公司真的有实力，那就答应他，并适当的拿出合同进行说明，是否在其他方面给予公司补偿。

如果公司的把握不是很大，那就站在客户的立场为他考虑，本来十天完成的任务现在8天完成，困难时什么，结果会怎么样，是否采取，按照客户的要求完成部分功能，比如为了迎接上级领导检查，那就把系统的表面工作都做好，要是真正的使用的话，那就把不影响工作进行的部分往后推迟等等，一个项目实施后，所有功能在一定的时间都能使用上的几率不是很大，另外也可以采用在主要功能方面做好，次要方面稍往后放等等方法。 三、从公司本身出发

在不影响范围和质量的情况下，提前完成，我们只有在加班或加人中选择，但是一定要谨慎，因为加人是存在一定的风险的，毕竟项目已经进行了3个月。假如公司实在没有办法的话，那就把部分较独立的功能模块外包出去，当然这是下下策了。 四、团队的管理 在这个时候，一定要在团队的管理方面做好工作，无论从人员的到位，还是人员的情绪，或者其他方面等等做到恰到好处。

4

Clearnet公司是国外一家知名的IP电话设备厂商。它在国内拥用许多电信运营商客户。Clearnet主要通过分销的方式发展中国的业务，由国内的合作伙伴和电信公司签约并提供具有增值内容的集成服务。

2000年，国内一家省级电信公司（H公司）打算上某项目， 经过发布RFP（需求建议书）以及谈判和评估，最终选定Clearent公司为其提供IP电话设备。立达公司作为Clearent公司的代理商，成为了该 项目的系统集成商。立达公司是第一次参与此类工程。H公司和立达公司签订了总金额近1000万元的合同。李先生是该项目的项目经理。

该项目的施工周期是三个月。由Clearnet负责提供主要设备，立达公司负责全面的项目管理和系统集成工作，包括提供一些主机的附属设备和支 持设备，并且负责项目的整个运作和管理。Clearnet和立达公司之间的关系是外商通常采用的方式：一次性付账。这就意味着Clearnet不承担任何风险，而立达公司虽然有很大的利润，但是也承担了全部的风险。合同是固定总价的分期付款合同，按照电信业界惯例，10%的尾款要等到系统通过最终验收一年后才能支付。

3个月后，整套系统安装完成。但自系统试运行之日起，不断有问题暴露出来。H公司要求立达公司负责解决，可其中很多问题涉及Clearent的设备问题。因而，立达公司要求Clearent公司予以配合。Clearent也一直积极参与此项目的工作。

然而，李先生发现，立达对H公司的承诺和技术建议书远远超过了系统的实际技术指标，这与Clearent与立达的代理合同有不少出入。立达公司 也承认，为了竞争的需要，做了一些额外的承诺。这是国内公司的常见做法，有的公司甚至干脆将尾款不考虑成利润，而收尾款也成了一种专职的公关工作。这种做 法实质上增加了项目的额外成本，同时对整个的商业行为构成潜在的诚信危机。

对于H公司来说，他们认为，按照RFP的要求，立达公司实施的项目没有达到合同的要求。因此直至2002年，H公司还拖欠立达公司10%的验收款和10%的尾款。立达公司多次召开项目会议，要求Clearent公司给予支持。但由于开发周期的原因，Clearent公司无法马上达到新的技术指标并满足新的功能。于是，项目持续延期。为完成此项目，立达公司只好不断将Clearenet公司的最新升级系统（软件升级）提供给H公司，甚至派人常驻在H公司（外地）。

又经过了3个月，H公司终于通过了最初验收。在立达公司同意承担系统升级工作直到完全满足RFP的基础上，H公司支付了10%的验收款。然 而，2002年底，Clearent公司由于内部原因暂时中断了在中国的业务，其产品的支持力度大幅下降，结果致使该项目的收尾工作至今无法完成。

据了解，立达公司在此项目上原本可以有250万元左右的毛利，可是考虑到增加的项目成本（差旅费、沟通费用、公关费用和贴现率）和尾款，实际上的毛利不到70万元。如果再考虑机会成本，实际利润可能是负值。

导致项目失败，尤其是项目预期的经济指标没有完成，这是非常遗憾的事情。项目失败或没有达到预期的经济指标的因素有很多，其中风险管理是一个极为重要的因素。

5

在上面的案例中，项目的利润值最后可能是负值就是这样的情况。而该项目最终失败的原因主要在于风险控制和风险处理机制。

在很多IT项目中，由于竞争和其他原因造成了风险过度集中在某一个相对弱势的角色身上。在本案例中，立达公司就处于这样的境地：一方面它需要依赖代理Clearent公司的产品生存，另一方面要它还必须要满足用户的具体需求。

我们知道，项目经理有识别和处理风险的责任。通常，项目经理在运作这样的项目时，要充分考虑到自己公司所处的地位，充分发挥自己的作用，平衡各方的利益。

事实上，项目管理知识体系中关于风险管理方面有非常详细的论述。不过，在实际工作中，如果完全照搬国外项目管理的风险识别和控制理论，是很难达到较好的效果。 一般来说，对于国内公司的项目经理来说，除了理解项目管理知识体系中的理论外，还需要在实践中进行总结。在这里，介绍一些容易被忽视的地方。 签合同前的“需知”

一般情况下，如果项目经理在项目合同签订以前加入项目，可以充分利用项目采购管理一章的知识，了解自己公司在项目中的位置，对买方提出的RFP 认真回答，规避潜在的风险，这是非常重要的。对于RFP中过高的要求不能完全满足时，应充分说明，并在以下几个方面有充分的准备和考虑：

1．合同的类型。

通常，在IT项目中，代理商与最终用户的合同类型是很难改变的固定价格合同，但对代理商和设备商之间的合同是有很多讲究的。代理商和国外供货商一般是通过信用证付款，但很多时候，为了拿到订单，供货商通常给予代理商一定的信用额度和付款方式的优惠。代理商应充分利用这一利害关系，在合同签订以前决不能轻易让步。

2．项目实施方对项目的熟悉程度。

通常情况下，做一个成熟项目的风险小，而做新项目的风险高。在本案例中，立达公司是第一次进行类似的项目，并不完全了解其中的风险，更无可利用的历史数 据。因此，在这种情况下，最好采用“让利于人，风险共担”的策略。具体做法是，将已经识别的具有风险的部分外包(即风险转移)，或者单独与供货商签订补充 合同。这样做可能损失了部分利益，但降低了风险，并且减少了很多额外投入。

3．具有明确的规范（Specification），包括设计规范（Design）、功能性规范（Functional）、性能规范（Performance）。

明确的规范是识别风险和规避风险的前提条件。如果已经具有一定的历史数据，可以采用头脑风暴的方式对规范加以确认和识别，这项工作可与风险识别同时进行。 风险的预警和量化

6

在项目的进行过程中，项目经理和项目的拥有人要将风险管理纳入日常工作的重要步骤。要明确成本与风险、成本与时间的关系。在制定完善的风险管理计划的基础上，从以下几个方面入手。

1．建立管理风险预警机制。

对于风险集中的一方，建立管理风险预警是风险管理计划的重要补充。这里的预警是指对有可能超出项目经理管理范围的风险事件的预警。预警机制可由低到高，并 由定期的项目联席管理（多方）会议讨论处理。这样可以减少处理风险事件的响应时间；同时，使高层管理者能够及时介入，处理可能产生的风险。

2．风险的量化。

之所以单独将风险的量化加以论述，是因为很多情况下，项目经理的确已经对风险进行了识别，并采取了应对措施，但并未对此风险带来的影响进行量化（通常可以 以货币或者时间损失加以估算）。量化过的风险是项目经理采用相应对策的前提。像在本例中，立达公司了解Clearent公司升级软件不能按时提供，这本身 就需要量化。这个风险带来的就是10%的验收款和10%尾款的不能按时支付。如果一开始，立达公司能够将付款和风险对应起来，就知道该风险是管理风险，并 且是不能够接受的。

总之，风险集中的项目管理起来是极为复杂的。要尽量在第一时间把事情考虑好，不能指望风险小的一方替风险大的一方承担很多责任。尤其是目前进入中国市场的国外企业很多，情况复杂，IT市场的变化有时很难预测，更应该注意风险带来的影响。

7

如何启动项目?

本文向大家介绍，在项目启动时应该做哪些准备工作。 赵晓东的烦恼

某公司的赵晓东最近心里挺烦。公司前一段签了一个100多万的单子，由于双方老板很熟，且都希望项目尽快启动，在签合同时也没有举行正式的签字仪式。合同签完，公司老总很快指定赵晓东及其他8名员工组成项目组，由赵晓东任项目经理。老总把赵晓东引见给客户老总，客户老总在业务部给他们安排了一间办公室。

项目进展开始很顺利，赵晓东有什么事都与客户老总及时沟通。可客户老总很忙，经常不在公司。赵晓东想找其他部门的负责人，可他们不是推托说做不了主，就是说此事与他无关，有的甚至说根本就不知道这事儿。问题得不到及时解决不说，很多手续也没人签字。 项目组内部问题也不少，有的程序员多 次越过赵晓东直接向老板请示问题；几个程序员编的软件界面不统一；项目支出的每笔费用，财务部都要求赵晓东找老板签字。赵晓东频繁打电话给老板，其他人心 里想，赵晓东怎么老是拿老板来压人。由此，赵晓东与项目组其他人员和财务部的人员产生了不少摩擦，老板也开始怀疑赵晓东的能力。

赵晓东的遭遇相信很多项目经理都亲身经历过，尤其是刚刚开始做行业客户的公司，往往是公司的老板和客户单位的某个主管关系不错或业务人员关系做 得很到位，公司老板希望赶紧做完项目，因此，常常跳过项目启动环节，直接指令项目经理进入实施阶段。结果项目刚开始就麻烦不断。正所谓“好的开始是成功的 一半”。做项目启动是为了形成一个良好的沟通体系，让所有与项目相关的人都理解项目的重要性，同时形成一个由双方老总、项目负责人和项目组成员所构成的三 级沟通体系，确保项目管理的畅通。 造势：创造良好的施工环境

现在很多项目都涉及到用户业务应用的软件开发，在实施中要跟用户的各个层面打交道，但现实往往是用户单位的员工根本不了解IT公司在给自己的企业做什么，因此，签合同时有必要召开一个正式的仪式，向双方员工传递项目的信息，激发公司全体员工对项目的热情。IT公司老板、项目负责人、开发人员、施工人员和用户方的领导、项目协调人、相关部门人员聚在一起，让大家知道双方的合作正式开始。仪式上，双方领导要讲话，特别是用户方的领导要强调项目的意义。据说联想上ERP项 目时就专门召开了全体员工誓师大会，柳传志亲自到会讲话，把ERP项目摆到关乎企业生死存亡的高度，并亲手将一面大旗授予ERP项目的负责人。柳传志还 说，有人说现在上ERP是找死，但现在不上那就是等死，我们与其在这里等死，为什么不去拼搏一把呢？事实证明，这不仅极大地鼓舞了项目组成员的斗志，同时 也使全体员工明白这不仅仅是信息部门的事，而是公司从上到下都要关心的事。 通过这个仪式，双方要组成指导小组或项目管理委员会，由双方总经理牵头，项目负责人为执行人，日常联系由双方指定人员。在签合同时，利用双方人 员到齐的机会，IT公司要把软件功能用通用、专业的语言和用户方的领导、技术人员、业务负责人进行最后确认，因为此时有分歧改正的成本不大。同时，还可使 双方人员彼此认识，清楚各个层次的接口，大家混个脸熟，以后打交道就会更通畅。

8

项目签字仪式可以在用户单位举行（可以节约用户方时间），也可以在酒店举行。要注意：签字仪式要精心组织，场地要大一些，为双方沟通营造一个好 的环境。会前，每个模块负责人要明确自己的客户接口，要找机会和对方单独聊，拉近彼此间的关系。另外，会场上双方老板的融洽气氛会对项目的实施具有一种震 慑作用。 尚方宝剑：明确责权利

项目签字仪式是造外势。在公司也要造内势，让各个部门都知道这个项目能为公司创造哪些经济效益，明确项目组人员和项目负责人，确定项目负责人的 权限。公司财务、采购、人事、技术、销售等部门都要参加，这样才能创造一个良好的内部服务体系，让项目组把主要精力放在为用户服务上。

公司内部要召开项目组成立会，会上最重要的就是颁布一个“项目宪章”，包括项目的内容、项目负责人权限、项目团队成员、项目时间周期、项目需要的设备、 资金等，在宪章规定的范围内，项目经理比总经理大，与此相关的事情，由项目经理负责。这样，人事部在项目实施期间，就可以按照宪章规定，由项目经理来调动 项目人员，而设备采购（往往不是一次性采购，而是根据项目进度购买，这样可以省钱）也就不需要一次次找总经理，只要是宪章规定范围内的，由项目经理签字就 可以了。尤其是在软件开发上，项目组成员一定要清楚用户的需求，不能擅自答应用户增加功能，因为这会带来很大的风险（后面几节我们会具体探讨）。

项目宪章必须由总经理和项目经理签字，并在会上宣读。为了增强团队凝聚力，可以在会上举行项目组宣誓或誓师宣言，形成“成则举杯相庆，败则拼死相救”的团队精神。内部造势不仅可以让各个部门了解项目，创造条件服务项目组，而且可以给项目组成员以压力和动力，意识到项目的意义和团队精神的重要性。项目宪章对项目经理来说就是一把尚方宝剑，联想ERP项目组的幸运就在于一开始就拿到了这把尚方宝剑，而这正是海正公司的赵晓东没有拿到的东西。

在项目宪章的基础上，公司应该形成具体的项目任务书，细分到各部门、个人，发到总经理、专家小组、开发部、财务部、市场部销售部、行政人力资源部等。

营造了内外两个良好的环境，项目启动就是水到渠成的事，项目组成员就可以集中精力投入到实施中去，项目的成功也有了更大的保证。

最后，要提醒项目经理特别注意：在项目合同确定的最后一刻，还要对合同进行最后的审定，合同审定一定要聘请一位专业律师，对合同的一些关键细节进行“咬文嚼字”的审定。 专家 点评

一个项目的成功启动绝不是靠项目组或项目经理就可以的，必须具备内部和外部两个条件，所以，双方的一把手都要高度重视，尤其是在目前中国的公司文化环境下，项目经理需要“项目宪章”作为尚方宝剑，而用户方的信息主管同样需要自己领导的讲话精神作为尚方宝剑。

9

案例背景：

某CRM项目，已经到了试运行阶段，原计划下周二验收。这时PM得知对方主管领导下周三要出国考察，想到对方可能没有心思准备验收的工作，便与对方沟通后把验收时间改到领导回国以后。却不料领导考察了国外的先进管理思想以后，回来决定大幅修改自己的业务管理模式，原有的CRM内容因此有大半失去作用。项目几乎等于要重头再来一次。 请问：遇到这种情况该如何处理？ 相关分析：

重视计划永远是正确的，甚至要想办法让条件成熟的后续工作提前开始。这个案例中的PM就犯了错误。领导要出国，没心思召开验收会是正常的。但是PM应该有很多办法来促成项目的及时验收。

例如说找各业务主管对各模块分别书面签字验收，然后只需要领导最后签字确认即可。或者找公司领导汇报，争取一笔资金，找个名目通过SALES交给领导（通常情况下项目都有回扣点数），同时谈谈马上验收的事宜。反正是在计划安排的时间内，这种顺水人情领导当然乐意。

而且，对于领导去做业务考察这件事，PM居然没有联想到跟自己项目业务的关联，敏感度太低。

10

项目团队如何拥有高的协调性

案例正文：徐家龙最近被公司任命为项目经理，负责一个重要但不紧急的项目实施。公司项目管理部为其配备了7位项目成员。这些项目成员来自不同部门，大家都不太熟悉。徐家龙召集大家开启动会时，说了很多谦虚的话，也请大家一起为做好项目出主意，一起来承担责任。会议开 的比较沉闷。项目开始以后，项目成员一有问题就去找项目经理，请徐家龙给出意见。徐家龙为了树立自己的权威，表现自己的能力，总是身体力行。其实有些问题 项目成员之间就可以相互帮助，但是他们怕自己的弱点被别人发现，作为以后攻击的借口。所以他们一有问题就找经理，其实徐家龙的做法也不全对，成员发现了也 不吭声，因为他们认为我是按你说的做的，有问题你经理负责。 团队成 员之间一团和气，“找徐经理去”、“我们听你的”成为了该项目团队的口头禅。但随着时间的推移，这个貌似祥和和团结的团队在进度上很快出现了问题。该项目 由“重要但不紧急的项目”变成了“重要而且紧急的项目”。项目管理部意识到问题的严重性，派高级项目经理张凤指导该项目的实施。 请问： 该项目问题出在哪里？ 徐家龙应该怎么做？ 分析：1.项目经理的定位

我们先澄清一个概念：什么是项目经理。项目经理就是项目中的总经理，总经理的职责是决策，领导。而不是关注所有的事情。本案例中的项目经理犯的错误在我们身边屡见不鲜，其根源最主要在于：1)项目经理定位不准2）团队无明确的沟通计划 2.只竖向沟通不横向沟通显然不行

作为项目经理,你应该要引导成员相互横向沟通后，无法解决的再竖向沟通或开会协商；这就好比民主集中制，要民主，也要有人说了算，案例中项目经理都是自己拿主意，但他不可能在每方面都是长处，长此以往，团队形成一种风气，压力全转移到项目经理处，项目风险也会越来越大。 3.职责、团队、方法论

一个成功的团队是指由不同技能,才华,工作风格和知识的成员组成的士气高涨的团队.项目经理的职责就是将这些人组成团队并激励他们. 项目经理的技能应包括技术技能和管理技能,坚实的技术基础能够在技术方面对团队起指导作用,管理技能有助于沟通和解决问题.管理技能不仅限于技术方面,还 包括解决问题的能力,估算能力,编制计划的能力,人际和沟通能力.所以本案例出现的问题本质是项目经理对自己的职责没有很好的认识，因此在管理团队的方法 上也就走了偏路。问题从项目组成员形成了一个习惯（有事找徐...)，失去了团队的协做意义，使团队的实际能力得不到体现；到最后使得项目进度出现严重延 迟。

11

在某公司的项目管理课堂上，小李，小王等人正在七嘴八舌地议论纷纷。原来，大家正在讨论小王的公司最近遇到的两个颇为有趣的项目。

据小王介绍，这两个项目分别由两个项目经理来担任。其中，项目经理A属于“谦虚”型，对于客户提出的问题，无论大小都给与解决，客户对此非常满意，然而，项目进度却拖得比较长，而且，客户总想把所有的问题都改完再说，项目已经一再延期。

相比之下，项目经理B显得稍有些“盛气凌人”，对于客户提出的问题，大多都不予理睬，客户对此不是很满意，不过，该项目的进度控制得比较好，基本能够按期完成项目。 话刚一说完，小李就抢着说：“A比较像我，一般在和我的一些战略客户打交道的时候，我基本是有求必应，与客户的关系处得如鱼得水，这样做肯定不会错。就像前天我连合同都写错了，找到客户，人家二话没说就同意改了。你说如果是B的话可能吗？”

小王对此不以为然，“对项目经理来说，成本、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘考虑项目的各要素。对于用户的要求，应该在有限的范围内给与解决，但不可以做出太大的牺牲。一味的迁就用户将会使整个项目失败。” 小林接着小王的话说：“当前，国内的项目一般情况下是由销售处面签单，再由项目经理接手后续的工作，因此客户关系多在事前已经搞定。发生新的情 况后，可以由公司的公关部出面与客户进行协调，项目经理可以在此过程中坚持一下原则，与公司的公关部一个红脸，一个白脸，唱出一出好戏。”

小赵反驳道：“不管怎样，客户才是第一位的。客户可以给你带来收入，也可以给你带来更多的客户和工作，有什么道理不多配合一下他们呢？说实话我对B的做法蛮欣赏的，可惜行不通。因为客户是上帝，如果照B的做法，后果会造成做一次项目丢掉一个客户，太不划算了。” 问题：

1、如果你的项目遇到需求变更问题，你会采用哪种方式去应对？ 2、分析这两种应对需求变更方式的优缺点。

如果纯粹说顾客就是上帝，客户是我们的衣食父母，那么A的就是这种。尊重客户并不意味着迁就客户，毕竟我们比客户要专业，那么我们就必须拿出我 们专业的一面，如果客户有需求变更我们就答应，那么也许这个项目永远也做不完。但是如果我们采取对客户不理不睬的态度，客户一个电话打给公司高层领导，那 么我们肯定也是吃不了兜着走了，必须要用合理的心态来看待需求变更。

避免问题发生的人永远都比解决问题的人来得可贵。 那么对待需求变更，我们也应该从避免变更做起。

这样项目初期的需求范围说明书的确认签字及需求变更流程的确定就显得无比的重要的。

12

需求变更应该纳入合同的体系中，明确规定项目允许需求变更的次数和范围，如果发生重大变更在商务上如何处理，明确权责。做好充分的需求调研、分析工作。

面对需求变更，平静的面对，仔细的分析，能拒绝则拒绝，不能拒绝则积极的接受，和客户明确此次变更将产生的影响，让客户自己来权衡利弊。

13

案例正文：一个项目经理在开发一个为期10个月的项目的三个星期后得到客户通知，项目要在不增加成本，不影响范围和质量的情况下，需要在8个月内完成，项目经理应该怎么做？ 分析：一、了解客户计划改变的真实原因

在做项目的很多时候，客户方会要求项目在不增加成本，不影响范围和质量的情况下，提前完成，但是一定有他的理由，也许是你的竞争对手采取的措 施，也许是我们在做项目的时候有哪些不对的地方，或者是客户遇到新的其他情况不等，但是在客户提出之后，不能明确的答应也不能以强势的态度拒绝，等了解真 正的原因后再做打算。 二、向客户沟通

假如必须提前完成任务，要向客户说明其困难，假如公司真的有实力，那就答应他，并适当的拿出合同进行说明，是否在其他方面给予公司补偿。

如果公司的把握不是很大，那就站在客户的立场为他考虑，本来十天完成的任务现在8天完成，困难时什么，结果会怎么样，是否采取，按照客户的要求 完成部分功能，比如为了迎接上级领导检查，那就把系统的表面工作都做好，要是真正的使用的话，那就把不影响工作进行的部分往后推迟等等，一个项目实施后， 所有功能在一定的时间都能使用上的几率不是很大，另外也可以采用在主要功能方面做好，次要方面稍往后放等等方法。 三、从公司本身出发

在不影响范围和质量的情况下，提前完成，我们只有在加班或加人中选择，但是一定要谨慎，因为加人是存在一定的风险的，毕竟项目已经进行了3个月。假如公司实在没有办法的话，那就把部分较独立的功能模块外包出去，当然这是下下策了。 四、团队的管理

在这个时候，一定要在团队的管理方面做好工作，无论从人员的到位，还是人员的情绪，或者其他方面等等做到恰到好处。

14

某高科技芯片制造企业，研发项目负责人跳槽，辞职几天前报告过一次项目进度完成50%，预算花费50%，而接手人上任后，报告项目进度完成30%,预算花费50%，还有一个关键技术问题无法突破。

1，他们为什么会有不同说法; 2, 你对该企业有什么建议。 他们为什么有不同说法： 1，客观因素上考虑：

a,从进度角度来看：高科技研发项目风险高，进度影响因素大，不可控性较强，造成项目进度无法完全按照主观计划量化,对进度看法可能会有不同；

b,从预算投入角度来看：研发经费投入非线性，可能前期经费投入较大，后期减少. 2，从利益因素上考虑： a,从跳槽者利益出发：

因利益影响存在道德风险：

--谎报进度，为与新东家的谈判争取时间和筹码 --把重要研发成果拿走，带入新东家 b,从接替者利益出发：

因利益影响存在\误报\可能：

--希望能够压报进度，争取经费和时间；

能够在“危机”情况下出成果，升职加薪的谈判筹码 c,从项目团队其他人的利益出发;

因利益影响存在欺蛮可能:

--有意隐瞒项目成果进度，为自己在公司争取地位提供筹码 --跳槽者安排在原东家的“针”，等待重要技术攻关成果； 对该公司的建议 短期危机处理应对：

成立专项小组评估项目真实进度/费用情况，应注意：

1，小组成员应该同时包括该项目项目组内外人员，建议提议接替者为小组执行组长，分管研发的领导任组长；

2，小组的主要职能还应该包括针对项目组留下人员的思想工作；

3，小组工作目标是评估内外部环境，提出继续/中止该项目的具体建议；

15

在项目的执行阶段，项目经理主要关注的工作内容包括：

总结和移交存档各种资源(如设备、文档等)，其目的是使得公司能够不断积累有关的知识。

对软件产品的发展提出建议，供公司领导决策，其目的是为继续拓展市场做准备。 项目成员工作的表彰和最后聚会，一方面是对成员工作的认可，另一方面是提高成员对实施项目的认同感，“高兴而来，满载而归”。 3 总结分析

其实，任何一个项目在执行过程中都会碰到问题的，评价一个项目是否成功并不能以碰到问题的多少作为标准，其标准应是按时、保质实现预先确定的各项指标，比如说系统的功能、系统的性能等等。

在这个项目中，也碰到很多问题，比如： 客户的需求变化 资源的到位 成员的冲突等

这些问题是大部分项目都会碰到的，解决起来其实很简单，请看：

客户需求变化。理解客户业务，使用客户的语言，站在客户的角度思考问题，取得客户的信任;这样最后客户也会站在你的角度替你思考问题的。其实，大部分客户都是通情达理的，问题在于我们实施项目时迈出的每一步。

资源的到位。理解尊重相关部门或合作伙伴的工作，从而让他们也理解尊重我们的工作并配合我们;获得领导的支持;原定资源不能到位时，不要一条路走到黑，一定可以找到替换办法的。

成员冲突。还是那个原则——理解和尊重，在项目中倡导互相的理解尊重，求异存同。求异有两方面含义：一是纯属个人空间，这样会使项目色彩更丰 富;一是项目工作中，每个成员的职责都是不同的。类似的，存同也有两方面含义：一是发掘共同的爱好和话题，缩短彼此距离;一是工作中的共享部分，一定要有 严格的相同标准。

对于项目经理，除了掌握必备的项目基本方法和管理工具(如计划制定、预算编制等)，对项目背景和目标有清楚的理解和认识外，很重要的一点就是与 人交往的技巧了。成功项目经理和失败项目经理的最大差别，可能就在于如何和人打交道，如何和客户打交道，如何和公司领导打交道，如何和项目成员打交道。

21

信息化建设中的甲方项目启动管理

案例：A公司是国内领先的IT设备制造厂商，经过多年的企业信息化实践，网络基础建设和办公自动化建设已经具备相当的规模，并取得了良好的应用效果。同时，以

ERP/SCM/CRM为主体的信息化应用架构也初步建成，此外作为提高产品创 新能力的产品数据管理系统（PDM）也在建设当中。随着公司研发业务管理的不断深化，对产品研发的项目管理提出了更高的要求。虽然公司整体的研发项目管理 体系尚未形成，但研发管理部门仍然希望将部分研发项目的核算用信息化手段来实现，以提高核算准确度。紧迫的需求提到了公司信息化项目部门 的面前。过去的几年，公司在信息化建设方面的投入巨大，难免有一些急于上马的项目投入与产出并不十分理想。而且由于市场环境的迅速变化，相应的业务模式也 在不断的改变，从而给信息化系统的适应性提出了相当高的要求。过去的有些项目启动时期没有很好地考虑到这些问题，造成一些项目盲目启动、盲目建设，建成后 才发现已经不适应业务的变化。因此，公司对于项目上马的决策已经趋于理性，严格要求做好项目启动前的论证工作。在满足当前紧迫的业务需求和长远的战略需求 之间作好平衡。确保项目建设的成功。小W作为信息化项目部任命的项目启动管理的负责人，着手处理该项目启动前的论证工作。小W发现，这个需求在年初规划时 并没有提出项目意向，属于规划外的项目。在与业务部门的沟通中，他发现业务部门对于整体项目管理的模式并不十分清晰，目前需要解决的项目核算问题仅仅是项目管理中非常具体的一个需求，至于项目其它方面的管理，以及如何与产品开发过程结合起来，如何利用产品数据管理系统等等，都没有考虑。项目建设的系统只是一个项目管理的临时解决方案。对方案的风险也没有进行详细的分析。而业务部门认为需求已经十分清晰，项目的价值也是毋庸置疑的，至于以后怎样与研发平台的 产品数据管理系统结合起来，那要等立项后，做出了详细的方案才会有答案。此外，业务部门还推荐了几个产品供应商，希望能尽快选定产品，开展实施。如果在立 项环节出现延误，影响了业务的开展，信息化项目部要承担责任。小W认为业务的要求十分无理，需求、方案、投入产出、风险，以及业界的产品情况等很多问题都 还没有清楚，根本谈不上选型。沟通过程中，业务对小W的工作极为不满，向信息化项目部经理进行了投诉。

在这个案例中，反映了目前企业信 息化项目启动管理中的普遍问题。业务一旦产生信息化需求，总是非常急迫地希望能立刻上马。而从信息化项目管理的角度，如果盲目、仓促地上马信息化项目，往 往导致项目的投入产出分析不清，项目重复建设，组织混乱，给后期的项目实施，项目维护，项目使用带来极大的风险，甚至导致系统建成后被用户弃用。最终使业 务遭受损失。

本案例中，作为企业的信息化部门，在项目启动管理的重要性方面已经有了较为理性的认识，但是在应用中不被业务部门理解，从而导致矛盾的激化。这是双方对项目启动管理的过程没有达成统一的认识。

相对产品供应商而言，企业在项目建设中处于合同意义上的甲方，其项目的启动过程与乙方的项目管理有很大的不同，是一个较为复杂的过程。它往往需要考虑一系 列的问题，如：需求是否合理？是否有必要启动项目？项目可能带来的影响是什么？可能的投入有多大？取得的效益有多大？当前的管理模式是否能支撑？如果不 能，可能要在哪些方面做好变革的准备？业界相关的产品有哪些？哪些是真正适合需求的？

因此，对项目启动管理形成统一的认知，对于实施信息化项目的企业有着非常重要的意义。

22

一般来说，项目的启动管理可以划分为以下几个阶段： 一、意向提出阶段

在意向提出阶段，业务部门发现需要由信息化手段来实现的业务需求，并提出建设信息化系统的期望。由于信息化项目的意向伴随着业务发展的全过程，因此，对于意向的统筹管理与规划对企业的信息化部门始终是一个难题。

对于有集中业务规划期间的企业，意向的产生经常集中在业务规划期间，比如：财年末，业务对自身的模式进行盘点期间，往往产生业务模式的改进或改革的需求，从而对信息化工具产生需求。在这一时间产生的想法或需求，往往不是很成熟，不确定性很大，后期变化的风险也很高。但这一时期，也是意向最集中，最易于统筹规划的时期。信息化部门通常在这一时期，对所有的意向进行收集，分类整理，初步形成项目建设清单。并考虑公司战略重点与资源投入的约束，对项目进行排序，以确定建设重点。

对于不在集中规划时期提出的项目意向，正如案例中出现的一样，往往会影响到原有的整体规划与计划，各方面的论证更应谨慎，比如，项目的必要性、投入的合理性、资源到位的可能性，对已建和在建系统的影响等等。

信息化管理部门可以通过建立一些制度与流程，对业务需求的意向进行引导， 尽量使意向在集中规划时期提出。

意向提出作为项目启动的一个阶段来管理，其意义就在于：对意向进行统筹规划，保证系统建设的整体合理性。 二、需求分析阶段

在受理了项目的意向以后，就进入对项目需求的分析阶段。这一阶段需要有信息化人员与业务人员组成的小组，对业务需求进行详细的调研与分析。采用的方法主要包括各业务层次人员访谈、会议。

在这一阶段，往往出现案例中的情况，信息化人员可能认为业务的需求不清晰，而业务认为自己的需求已经十分清晰。解决这个矛盾的关键在于，要有详细的管理控 制方法，引导业务人员进行需求的细化。如，制定需求分析报告的框架，针对关键点形成文档。一般来说，需求分析包括以下内容： 当前业务流程分析 未来业务流程分析

当前业务与未来业务的差异分析 信息化功能点需求

对将来系统的非功能需求，如：性能需求，环境需求，安全需求等

23

需求的优先次序

需求分析报告形成以后，还需要组织对需求的评审，以达成项目关系人对需求的一致认可。这一过程可包括：

制定评审计划：制定评审的工作计划，确定评审小组成员，准备评审资料。 需求预审查：评审小组成员对需求文档进行预审。

召开评审会议：召开评审会议,对需求规格书进行评审。

调整需求文档：根据评审发现的问题，对需求进行重新分析和调整。

重审需求文档：针对评审会议提出的问题，对调整后的需求文档进行重新审查。 三、可行性方案论证阶段

可行性方案的论证是项目启动阶段的关键活动，它的质量直接影响项目的实施效果。论证小组一般由企业内部的业务与IT技术两方面的人员组成，视项目的重要程度、难度与规模，可能还需要企业外部的专业顾问资源。

可行性方案论证的目的是通过确认管理体系和系统技术构架，从而确认未来的管理和技术方案是否有效。它立足于项目从管理上、技术上、实现上的难点进行阐述，逐步理清楚客户的需求。并在需求的基础上，规划总体解决方案，以作为项目投入产出评估的依据、产品选型的依据，以及后续实施方案的约束。

项目投入产出评估的依据：建立在业务需求分析基础上的项目投入与价值分析，往往是比较粗略的宏观感受。如我们在案例中看到的，业务部门在提出项目核算的信息化需求时，并没有充分考虑它与其它系统之间的关系，这样得出的投入与产出分析也是很粗略的。如果在此基础上，通过设计可行性方案，考虑清楚该项目的定位，与其它系统的关系，相信投入产出的分析将更有说服力。

产品选型的依据：可行性方案的制定是建立在业务需求的基础上，是不受任何产品影响的。因而它是后续产品选型的依据，它使得企业可以在产品选型过程中始终坚持从自身的需求和规划为原则选择产品与方案，而不至于受到供应商解决方案的误导。

实施方案的约束：可行性方案与实施方案是总体设计与详细设计之间的关系。可行性方案描绘了总体的业务方案与技术架构，而实施方案是可行性方案在各方面的细化。 此外，围绕可行性方案从管理上、技术上、实现上对难点进行的阐述，可以有效地开展项目的风险分析，制定项目的风险管理策略，为项目的成功提供保障。 四、产品选型阶段

当可行性方案需要通过选择新的产品来完成时，进入项目启动管理的产品选型阶段。在该阶段，对供应商进行初步的筛选以后，根据需求与方案要求，制定招标文档，接收供应商的

24

项目解决方案，并根据评估标准，组织相关人员对供应商进行评估，选出2个以上的供应商进入商务谈判。并在立项报告审批通过以后，与供应商签署合同。

创建RFP：根据需求阶段与可行性方案阶段分析的结果，制定向供应商招标的文档。 解决方案评估：制定产品选型评估的标准是该活动的核心，它包括：

应用软件评估：对产品本身的功能、性能、体系架构、用户友好性、市场评价、费用等方面进行考察；

软件运行环境评估：对系统运行所需要的服务器、客户机的软硬件配置进行评估。这是很容易被忽略的一部分，又是有可能对后续实施投入影响最大的一部分，尤其是在客户端数量大，环境复杂的情况下。

项目实施评估：在信息系统的建设中，项目实施方法与能力已经成为项目成败的重要环节，因此对服务商实施能力的评估显得尤为重要。评估内容主要包括：实施方法、实施费用、实施周期、实施顾问经验以及对相似实施案例的考察。

培训与售后服务评估：包括考察培训方式、费用、售后服务方式、费用、响应时间等。 供应商评价评估：对供应商的基本面进行评估，如供应商的规模、业绩、合同语言和仲裁地、与客户的合作策略等方面。

效益风险评估：即项目的投入与产出的评估。这是最难评估的一项，当前在信息化项目中尚没有形成较完备的投入产出的量化评估指标，多是采用一些定性的分析与比较。 商务谈判

关于商务谈判的组织与技巧，有许多专门的论述。从信息化项目管理角度上具体来看，商务谈判是在一定的策略指导下，与产品及服务实施商进行的，确定合同条款的过程，目的是最大化的维护公司利益，确定最优的价格和服务条款。

商务谈判的依据是评估通过的解决方案，其过程通常包括：组织谈判小组、制定谈判方案、实施谈判、签署合同。值得注意的是，商务谈判与后续的立项报告审批并没有严格的先后关系，是可以同时进行的。但合同签署必须在立项报告审批完成后才可进行。 五、立项报告审批阶段

立项报告是项目启动阶段的重要文档，在这一阶段，需要将从意向提出、需求分析，到可行性方案论证，到产品选型各阶段产生的重要内容整理形成文档，并任命项目经理、建立项目组织机构，申请项目经费，然后按公司的管理流程，交相关的部门会签，成为确认项目合法性的文件。后序的所有项目活动都要以立项报告为依据。 六、项目启动会阶段

25

有时候，项目启动会被看作一个时间点，一个里程碑，而不是一个阶段。这里将立项批准后，项目启动准备到项目启动会结束这一过程统称为项目启动会阶段。

项目启动的准备工作比较繁琐，具体事宜取决于项目所在的管理环境的要求。在项目启动准备期，可以准备一个项目启动检查清单，以确保项目启动工作的有序，避 免疏漏。一般说来，启动会准备工作包括：建立项目管理制度、整理启动会资料等。其中建立项目管理制度是非常关键而且容易忽略的一项工作，主要包括： 项目考核管理制度项目费用管理制度 项目例会管理制度 项目通报制度

项目计划管理制度：明确各级项目计划的制定、检查流程，如：整体计划、阶段计划、周计划

项目文件管理流程：明确各种文件名称的管理和文件的标准模版，如：汇报模板、例会模板日志、问题列表等。

项目启动的准备工作完成后，就可以召开项目启动会议了。启动会议是项目开工的正式宣告，参加人应该包括项目组织机构中的关键角色，如管理层领导、项目经理、供应商代表、客户代表、项目监理、技术人员代表等。项目启动会的任务包括： 阐述项目背景、价值、目标 项目交付物介绍

项目组织机构及主要成员职责介绍 项目初步计划与风险分析 项目管理制度

项目将要使用的工作方式

从这些我们可以看出，实际上，项目启动会已经涉及到了项目计划阶段的初期内容，这也映证了在PMBOK体系中启动阶段与计划阶段的重迭。

综合上述，我们可以看到，在信息化项目建设中，企业的项目启动阶段要经过意向提出、需求分析、可行性方案论证、产品选型、立项报告审批、项目启动会一系列管理活动的控制，方可完成项目的启动，进入项目实施阶段。做好项目启动管理是企业进行合理的投入产出分析，有效控制项目风险，确保项目成功的关键。

26

电信软件项目管理的误区

参与过电信软件项目的人员都会发现，电信软件项目具有其独特性，但更多的是体现当前国内软件项目的通病。譬如说：需求说变就变；不切实际的进度要求；项目不正常的政治压力；项目前阶段的紧迫及项目后期的拖延验收等，都突现出当前国内软件项目的常见问题。 一直在电信行业也摸爬滚打，算起来也有好几年了。几年项目的经验慢慢在告诉我们一些道理，这些道理都是在以往项目的惨痛经历，有时回想起来，道 理也就那么几条，但真正做到的人却少之又少。“吃一堑，长一智”－－犯错不要紧，最怕的是犯同样的错误。但回想起来，自己的总结还是来得太晚，相同的错误 竟然不止一次地重犯。 误区一：本本主义。

本本主义让诸葛亮失去了街亭；毛主席也不只一次地批判过本本主义的危害性，但历史的错误还是在今日轮回般地出现。

观念：一定要需求明确后再开始设计和开发？

项目管理、软件工程的 理论一套接一套，无数的书本告诉我们，对于软件开发，需求需用户完全明确后才能开始设计和开发。但是，在电信行业，如果按该准则去办事，那只能说明你的经 验还是太欠缺了。过多的项目历程、复杂的政治环境使得用户学会了自我保护。用户对于自己提的需求总是带有随意性及不间断性，但当你提出要需求确认时，用户 会提出要认真评估和论证，当然，论证一轮后还需要领导的层层审批，待整个过程完成后，用户要求的项目时间可能已经过去了一大半了。退一步说，就算是用户较 为爽快地对需求进行了确认，但接下来在开发过程中、甚至是项目上线后，用户新冒出来的一个想法就可以让整个系统的需求完全变样，而最终，用户却不需要负什 么责任，因为他们很认真地告诉你，你缺乏行业的业务基础，对他们的需求没有理解到位。

较好的做法：关于系统面貌，用户永远都无法有一个清晰的模型，除非你能根据用户最初提出的想法去提供一个模型出来，用户再基于它来完善自己的想 法。所以对于电信软件项目，原型法是一个不错的方法。你可能通过成本较低的静态页面来构建系统原型，让用户基于它来修改和补充需求，只有这样，你才有可能 获取到较完整的需求。

同时，你要认识到，如果你不想等项目延期后再和用户理论责任所在的话，那么，你就永远不要等用户需求完全明确下来后才开始设计和开发。当你感觉到需求已经逐渐清晰时，你应该立即开始设计，并对一些较没有争议的地方先行开发，在设计和开发中找问题和明确问题。

误区二：完美主义。

对于电信行业的软件，永远不要有完美主义的想法，不然只会害人害己。许多项目经理出身于技术，身上流淌的是技术般偏执的血液。对于技术人员的通病是完美主义，认为自己设计出来的软件要能够满足用户的终极需求；认为自己设计出来的软件灵活到能满足所有用户个性化的需求。

27

如果是这样，那么实践会告诉你，你的想法会是多么的不堪一击。永远不要有一步到位的想法，因为，用户尚且没有完整终极需求，那么你一次性设计出来的软件怎么可能会满足用户的终极需求？用户的个性要求甚至数据统计要求随时会变，甚至随着基本功能的满足，用户会提出升级需求，那么你的软件怎么可能会满足用户所有个性化的需求？

较为理性的想法是：不要奢求一步登天，永远要有分阶段建设的思路。阶段性目标的准确定义，阶段的准确划分，会给你的项目及时完成提供最大的保 障。相反，追求完美只会令人花费大量的时间在百关键的枝节功能上，并最终导致你软件的设计泛复杂化，甚至复杂和臃肿到技术和进度都无法支撑。

误区三：我的能力强到能同时承担设计和开发甚至测试的角色。

对于某些项目，可能由于资源及进度的因素，对于项目中的关键人员，往往出项目进度的考虑，同时出于对个人能力的充分自信，他们认为，在项目中，自己的能力强到可以同时承担设计和开发甚至测试的角色。

我们不能否认有些人的能力较为出众，对于小型项目，他们担任多个角色可能是游刃有余。但对于复杂的大型项目，角色的频繁切换会令他们筋疲力尽，最终生产力低下，能力最强的人，最终反而成为造成项目进度延期的关键任务承担者。

较为理性的想法是：踏踏实实地承担力所能及的一个角色。如果有设计的能力，那么好好做好设计这份很有前途的职业，永不要同时承担开发工作。如果 资源不够，要想办法协调资源；如果实在没有资源，那么要好好评估阶段目标，或者好好评估项目目标，资源不够的情况下，要学会降低项目期望。

误区四：项目进度延后时要往项目中不断增加人员。

其实项目正常开展后，特别到了业务开发阶段，盲目地添加人员，不但不能加快项目进度，甚至会起到负作用。因为目前国内项目的设计未能明细到任何 一位开发人员可以在未充分了解业务的前题下开发，即是说，人员在投入工作前，需要花很多的时间来熟悉业务，熟悉业务的阶段对项目进度没有任何帮助，甚至为 了帮助新人员熟悉业务，可能会影响现有人员的正常进度。另外，我们还要认识到，要融合成一个团队整体向前推进项目，那么人员的磨合时间是需要考虑的。

较为理性的想法是：当项目有延期的迹象时，第一时间考虑的是现有人员是不是没有磨合好，是不是没有发挥出应有的作战能力。如果答案是肯定的，那 么考虑的对策并不是增加人员，而应该是重新思考和定位原定的项目目标是否过高了。如果真的是目标过高，较好的做法是壮士断腕，减少一些一必要的功能，进而 缩减延期时间。 误区五：当大家都没提问题时，项目应该就没有什么风险。

作为项目经理，应该有项目敏感度，也就是说，项目经理应该对于项目的风险有超乎常人的嗅觉。当大家都没提问题时，并不意味着项目没有什么风险。 大家可能感觉到了风险，但他们怕自己感觉是错的而没有提出；大家也可能感觉到了风险，但他们认为项目失败后不

28

关自己的事，所以没有提出来；大家可能感觉到 了风险，但由于你平时听不进意见，所以大家都不想提出来等等，都可能是不提出的理由。

较为理性的想法是：当感觉到项目有风险时，要认真剖析造成风险的原因，评估每种原因的可能发生率，同时和项目人员交流，进一步验证自己的判断。如果风险属实，那么要对症下药，想出最佳对策，尽量防患于未然，把风险降到最低。 误区六：项目进度论证可行后，那么项目就会沿着进度推进。

对于项目进度，要多考虑偶然事件对于项目进度的冲击。临时的售前支持、政治性会议、临时出差、项目组员请假等原因，都会造成实际情况不能按原定计划来执行。

较为理性的想法是：制定项目进度时，要充分考虑到突发事件，要对风险有所预留。 总而言之，一个电信项目的成功来之不易，要保障其成功，首要的是要避免自己陷入以上的不必要的项目误区。

29

我的软件项目应该如何启动？

（一）案例正文

我们公司是一家软件开发企业。现状是目前有个产品，但是存在很多问题，准备开发新版本，之前版本存在的问题有一部分应该说是开发人员的问题，但是因为我来得时间不长，不甚了解。整个公司都对新版本给予厚望，就目前的情况来说，老板希望技术团队有个大的改造，但是我不想这么做，因为毕竟新人进来不见得合适、而且需要相当一段时间的业务熟悉期。现在老板问我怎么做？我觉得可以有这么几步：

1、老板主持个动员大会； 2、完善部分规范、制度； 3、增加一些激励措施；

4、我同他们加强沟通，了解每个人的具体情况，帮助他们 5、加强项目监控

应该就可以了，实际上主要是营造一个好的氛围。其他还有什么么？希望大家帮帮手，对我很重要，谢谢！

（二）专家点评

专家介绍：卢毅，清华大学MBA，PMP，曾任某高科技公司项目管理副总裁，现任北京商略达项目管理研究中心首席专家，国内著名的项目管理培训师和组织级项目管理体系规划咨询专家。卢毅先生有十多年项目管理实战经验，亲自管理过几千万级的电信行业项目、几百万级的多个电力行业项目和众多的生产制造、流通、物流等行业项目。历任项目经理、项目总监、项目管理部门的总经理、公司分管项目实施的副总裁等职，在项目化经营管理、项目管理方法论、多项目管理和建立公司级项目管理体系等方面有非常独到的见解和实战经验。

卢毅点评：

这个案例反映的是如何在项目启动时做好项目策划，其实这也是我在多次培训课中经常讲到的一个重要概念。案例讲到的一些步骤，还不是太完整和具体，如何在项目启动前做好一次项目策划是至关重要的。具体来讲，有以下几个主要方面：

（1）项目干系人分析：一切项目管理活动都应该从干系人出发！案例提及的干系人主要有老板、技术人员，应该还有需求提出者、项目验收人员等公司其他人员， 却没有提及。从案例描述的情况看，项目经理的做法会有一定的问题，他没有分析各干系人的想法，尤其是他提的步骤里没有就老板想换技术团队的想法做沟通的计 划，将会是一个很大的问题。 （2）明确项目的合理目标：整个公司对新版本都有厚望，说明你很荣幸做了一个众人瞩目的项目，但同时也说明很多人都对项目有期望。在这种情况下，明确了解 和平衡所有项目干系人的期望将非常重要！可惜，案例中的项目经理却一点也没有提及。在项目启动前在各干系人之间达成一致、明确和合理的项目目标将直接影响 项目是否能成功。目标又包括客户满意、时间、成本、质量等因素，这些都需要明确。

（3）清晰的项目范围：项目管理需要定义清晰的目标和范围，这是项目管理非常重要

30

的一步。然而，案例里却没有提及。老版本存在的问题是什么？新版本要达到的需求是什么？哪些是新版本必须要完成的？项目范围不明确将会留下很多隐患。

（4）根据目标和范围确定项目资源需求：在项目前期，需要根据项目目标明确项目资源需求。案例中还提到老板希望更换项目团队中的一些人，项目经理自己又不抬愿意更换成不了解业务的新人，我感到他们沟通很不充分，一方面资源需求不明确，另一方面项目资源保障也许有一定难度。

（5）制定项目计划：项目经理没有考虑时间计划，一般在项目启动时都需要有计划，很难想象没有计划的项目如何执行和监控。

31

关于多项目管理过程中的一些感悟

当面临多项目并 行管理的时候，我们不可能象管理一个项目一样进行从头盯到尾，并且关注其中出现的任何问题，这从精力上来说是不现实的，而且如果你确实企图如此做，唯一的 结果就是把自己弄得很忙碌，而且会突然发现，你不断处于救火的过程中。那么基于此，应该如何进行管理呢？以下是我的一些个人感悟：

清楚团队内部的能力体系：每个团队都是不同的，这个团队使用顺利的方法，并不一定能够在另外一个团队得到复制，管理从根本上而言，艺术性高于技术性。对于比较成熟的团队，团队内部有几个比较成熟，而且责任心强，权力欲强的员工，那么可以使用这几个员工独立承担项目经理的职位，并且给予他们比较高的授权，比如人员的工作任务分配，目标制定等等。你只需要在关键点上进行把控：里程碑，项目目标；项目需求，项目测试过程，依靠自己的经验，从这些要素方面来判断项目是否存在风险？ 产出是否是你所希望看见的？在情况没有到完全不能控制的情况下，尽量不要亲自介入，在项目完成以后，进行良好的项目总结（至少对于项目经理私下的项目总 结）是必须的，至少让他知道，你认为这个项目完成得最优秀的是什么？存在的不足是什么？这样做有几个好处，可以通过这样的宣灌，使得你的管理思路能够逐步 落实下来，而且让你希望培养的项目经理能够在每一个后面的项目得到更多的收获，如果他的项目执行得不好，那么趁这个机会也可以使得他更愿意接受你的看法， 并且给予一定的鼓励，能够激发这个项目经理提高的欲望。如果团队相对是比较弱的团队，那么就相对你首先需要考虑的是：招聘几个适合的项目经理，而不是首先 需要考虑如何培养，那实在是很累的一件事情。当然了，如果实在没有招聘的名额，就该考虑如何培养了。这个问题比较大，以后有空再说吧。

记住，你是最终的负责人，所以你必须对所产出的东西做。授权是分阶段进行的，如果贸然给予一个人授权，结果发现他的能力根本没有到那个层面，你 将面临一个艰难的选择，要么让他走人；要么费尽换了他，结果工作积极性下降；而且在很突然的时候，他离开公司了，如果你真的要那么做，请务必准备好。在团 队比较成熟的时候，你比较好把控了过程，结果也应该不会太差；在一个团队不成熟的时候，请务必适度介入，比如需求阶段的介入，在设计阶段的介入，在测试方 案阶段的介入，在标准和规范化方面的介入等等，看这个团队的不同，都将是必须的。

如果团队能力体系比较强，可以执行一些粗放的管理，对于那些进取性强的员工，这种管理能够为他们所喜爱，同时，他们的责任心也使得他们不会利用 粗放管理的一些漏洞来使你突然发现面临一个烂摊子；但是如果一个团队的能力比较弱，那么，着手点，请务必先放在流程和规范上，只有这样，才能保证至少团队 不会出现大的错误，也许效率被影响了，但是可以防止风险突然爆发；

一下自己的人力分配是否合理，现在大家的项目很少是那种靠着朝九晚五能够完成的，软件行业的项目实际上基本都处于时间压缩得很严重的时刻，那么 在这个时候，请考虑一下自己的人力安排是否合理，是否可以从某几个项目中抽调部分人力来支持某个重点的项目或者危机初期的项目。不要让一部分忙得半死的同 时，另外一部分人非常空闲，这是很杀伤士气的。

不要患上工作饥渴症：很多管理者，特别是从基层一层一层做上来的人，这些人大多数都明白一点；“占据人力”，但是你已经在一个公司属于中高层 了，不要再企图去占据人

32

力了，这对于你将来职业的发展不是说一点好处都没有，而是没有太大的好处了；这时候，你需要的是占据业务。所以，不要为了让手下人 看起来很忙碌，而安排很多意义不大的事情，这样一方面，你手下的员工永远处于忙碌之中，令一方面，也将由于很多杂事，占据你太多精力，从而没有考虑更深远 的问题。记住，当你一直忙碌在日常管理中的时候，你永远是一个小经理，你永远没有机会，用自己的全局观点，进入总监和总经理的层面。让你的员工在必要的时 候，休息一下，他们会工作得更好。

33

信息化建设的项目管理计划、实施和控制

序言

目前，电子政务、企业管理信息化等已成为信息化建设的热点。这些以业务、数据流程信息化为主的建设项目相当复杂。有数据表明，这类信息化建设项目在国内外成功的比例都不是很高。正因如此，项目管理引起这个行业人士的普遍关注。同样，也有数据表明，西方国家的一些企业采用项目管理后，项目成功的比例有显著提高。

作者根据十多年项目管理实践经验，以及研究、培训和咨询的知识积累写就这篇文章，相信对信息化工程项目的建设者会有帮助。

本文涉及信息化建设项目管理的内容包括：项目经过的阶段；项目的计划、实施和控制；开发商对项目的管理；用户对项目的管理；项目的组织问题等。 一、信息化建设的几个阶段

信息化建设项目按时序划分，一般经过可行性研究、系统分析、系统设计、开发和测试、安装调试、运行维护6个阶段。 1、可行性研究阶段

可行性研究阶段段的主要任务是：识别需求，对项目产品进行描述，确定分阶段实施的进度，从业务、技术、经济效益等方面进行可行性研究，形成可行性报告。 2、系统分析阶段

系统分析阶段的任务是：对现行系统进行详细调查，分析业务流程，分析数据与数据流程，分析功能与数据之间的关系。指出现行系统存在的问题和不足之处，确立新系统的基本目标和逻辑功能要求，最后提出分析处理方式和新系统的逻辑模型。这个阶段也称为逻辑设计阶段。逻辑设计解决系统“做什么”的问题。因此，这个阶段是整个系统建设的关键阶段。 系统分析阶段的工作成果为“系统说明书”，这是系统建设的必备文件。系统说明书既要准确又要通俗易懂，用户根据系统说明书可以了解未来系统的功能，判断是不是他们所要求的系统。

“系统说明书”一经通过，就是系统设计的依据，也是将来评价和验收系统的依据。 3、系统设计阶段

系统分析阶段的任务概括地讲，已解决了系统“做什么”的问题，系统设计阶段要回答的问题则是系统“怎么做”。也就是说，根据系统说明书所规定的功能要求，考虑实际情况，具体设计实现逻辑模型的技术方案，即新系统的物理模型。这个阶段也称为物理设计阶段。这个阶段又可分成总体设计和详细设计两个阶段。 这个阶段的技术文档为“系统设计说明书” 4、开发和测试阶段

开发和测试阶段是按物理设计方案付诸系统实现的具体工作，包括开发与调试程序，采购硬件。

这个阶段的工作量很大。在这个阶段，开发工作要重视文档的建设，测试工作需要写出测试分析报告，包括功能“测试分析报告”和“系统测试分析报告”。 5、安装调试阶段

34

本阶段的工作包括：硬件设备与软件平台的安装调试，用户培训，数据文件转换，系统调试与转换等。

安装调试阶段实现现有系统被新系统所替换，需要用户许多部门的参与或配合。为了使系统顺利转换，必须精心安排，合理组织，统筹调度和协调。 6、运行维护阶段

系统投入运行后，需要进行经常性维护和评价，记录系统运行的情况，根据一定的程序对系统进行必要的修改，评价系统的工作质量和经济效益。 上述6个阶段，构成信息化建设项目的全（整个）生命周期。

根据美国项目管理知识体系指南（PMBOK）的定义：项目生命周期开始于项目启动（例如签订承包合同），结束于项目收尾（例如按合同验收）。因此，信息化建设项目生命周期包括系统分析、系统设计、开发和测试、安装调试这4个阶段。参见下图。

本文第二部分内容——项目计划、实施和控制，是基于项目生命周期来考虑的。由于项目管理其实是一种方法论，因此可行性研究阶段的工作也可以按本文第二部分介绍的方法来处理。

二、项目计划、实施和控制 1、整体计划

整体计划的核心内容包括：范围计划、时间计划、成本计划和组织计划。 1）范围计划

项目范围由工作分解结构（WBS）界定。工作分解是一种以结果为导向的分析方法，用于分析项目所涉及的工作。工作分解结构中所包含的全部工作构成了项目的整个范围。工作分解结构是项目管理的一个非常基础性文件，因为它是计划和管理项目进度、成本和变更的基础。项目管理专家认为，没有包含在WBS中的工作是不应该做的。

信息系统建设项目的工作分解结构，第一层通常是由前面所述的项目生命周期的4个阶段组成，第二层则包括每个阶段需要完成的可交付成果，第三层包括第二层可交付成果进一步分解的结果——所有细化的可交付成果，…。

工作分解结构层次的多少，以便于管理为划分标准。相同的项目，不同的人会做出不同的工作分解结构来。工作分解结构最底层的可交付成果叫做工作包。 2）时间计划

时间计划是确定工作分解结构中每个可交付成果的开始和结束时间。时间计划通常用表格或甘特图、里程碑图来表示。网络计划技术中的关键路径分析、并行工程等技术方法，可用来优化时间计划安排。由于有项目管理软件的支持，生成时间计划图表，以及用网络计划技术优化时间安排都变得十分地容易。 3）成本计划

① 制订资源计划资源计划确定了为完成项目中各活动所需要的资源（人、设备、材料）。WBS是项目资源计划最基本的输入。

② 成本估算成本估算是利用WBS、资源需求、资源单价、活动历时估计等成本要素，通过有关算法与工具（项目管理软件或电子表格）算出完成项目所需各种资源的成本估计值。

35

③ 成本预算成本预算是为了确定测量项目实际绩效的基准计划，而把整个成本估算分配到由WBS确定的各工作包上去。成本预算和成本估算通常是同步进行的。

④ 成本基准计划成本基准计划是一种按时间分段的预算，可以用来测量和监控项目成本的绩效。按时段把估算的成本叠加起来即可求得成本基准计划。

4）组织计划组织计划是，利用责任矩阵确定WBS中各工作项的责任单位；利用组织图确定报告关系。但是，组织计划结果的具体形式受企事业单位的组织结构制约。（关于项目的组织问题，在本文第五部分解析）。 2、项目实施

项目实施总是一个阶段接一个阶段地进行的，前一个阶段的结果为下一阶段提供输入。信息化建设项目中，第一阶段的结果“系统说明书”，为第二阶段系统设计提供输入；第二阶段的结果“系统设计说明书”，为第三阶段的开发工作提供输入…。

每个阶段实施工作也都要首先做个计划，这个计划是为完成WBS工作包而采取的行动计划，包括：基于各项活动的基准进度计划，角色、职责分配计划。类似于前面讲到的组织计划，角色、职责分配也利用了责任矩阵这种方法，只不过在这里是把职责分配到个人。 项目子产品、产品实际上产生于项目实施过程中。 3、项目控制

项目控制包括绩效控制和变更控制 1）绩效控制

绩效控制目的是使工作结果与计划保持一致。

上面讲到，项目子产品、产品产生于项目实施过程，因此在这个过程中必须持续测量相对于项目基准计划的绩效，以便将实际绩效和基准计划进行比较，并以此为基础采取相应的纠正措施。

测量绩效的方法主要有两种，一是挣值测量，一是进度跟踪。而且，这两种方法通常是结合起来使用。 ① 挣值测量

挣值测量在西方国家是测量绩效最常用的方法。它综合了范围、成本和进度测量，帮助项目管理队伍评价项目绩效。挣值测量涉及三个关键值：l 计划值（PV）：在规定时间内花费的获得批准的成本预算部分l 实际成本（AC）：在规定时间内完成工作发生的实际成本l 挣值（EV）：在规定时间内实际完成工作的价值不难看出上述三个关键值是三个关于时间的函数。由于函数曲线呈S形状，所以通常称之为S曲线图。

这三个值提供了评价工作绩效的测量尺度。包括l 进度偏差（SV）：SV=EV-PV l 成本偏差（CV）：CV=EV-AC l 进度绩效指数（SPI）：SPI=EV/PV l 成本绩效指数（CPI）：CPI=EV/AC ② 进度跟踪

进度跟踪是输入实际工作进度，然后与基准进度计划比较，找出各项活动进度上存在的偏差。利用项目管理软件进行进度跟踪极为方便、有效。

有了绩效测量结果，接着便是对偏差原因进行分析，进而根据分析结果决定纠正措施。

36

纠正措施没有什么新东西，都是平时习以为常的一些方法，比如对进度偏差有赶工、快速跟进（有些书上叫做并行工程）等措施。理论著作上对这些方法的外延问题讲得很多，原因是在采取这些措施时，要考虑可能带来的许多问题，但这些都不是本文所要描述的内容了。 2）变更控制

变更控制的目的是维护绩效测量基准的完整性。也就是说对基准计划的变更予以控制。 基准计划变更包括：范围基准计划变更，时间基准计划变更和成本基准计划变更。一般说来，只有项目范围变更才会影响测量基准。但是，在某些情况下，进度延误或成本偏差非常严重，需要“重新确定基准计划”才能提供测量进度或成本执行情况的切合实际的数据。 基准计划变更是很慎重的事，应该：l 建立正式的变更程序l 由变更控制领导小组负责批准或否决变更申请l 定义正式文档变更的步骤

前面已经讲了，一般情况下只有范围变更才会影响测量基准。而在信息化建设这样的高科技项目中，范围变更往往是因技术（功能、性能）要求的变化而起。项目管理中讲到的配置管理，讲的是项目过程中的技术管理问题。

配置管理内容包括：l 识别工作项或系统的物理特征和功能特征l 控制这些特征的任何变更l 记录和报告这些变更l 审计这些工作项和系统以证实其与需求相一致。

进行配置管理的目的是，项目过程中任何技术上的变更都要在范围变更中反映出来，并要得到有关各方的一致认可。 三、开发商对项目的管理

无疑，开发商是信息化建设项目中的主角。对项目计划、实施和控制方面的工作，开发商都需要重视。

计划方面信息化建设项目往往带有较多的创新成份和不确定性，项目成果在出来之前，并不确切知道它会是什么样子。因此，用户的需求和任务目标在整体计划中都不容易表述得十分具体，特别是对要实现的功能的规定往往有相当程度的灵活余地。

由于这些原因，整体计划中的工作范围、完成各项工作（由WBS定义）所需的时间和费用都较难以准确估计，所以整体计划工作必定是一个反复修改的过程。实际工作中，人们往往因为“计划赶不上变化”而不愿做计划或只做一个大致的计划。专家认为，项目管理的首要任务是计划！计划！还是计划！先哲说：“凡事预则立，不预则废”。因此，尽管信息化建设项目中存在诸多变数，但细致的整体计划工作是必须要做的。

实施方面项目实施过程中，项目管理队伍必须协调、管理存在于项目中的各种技术和组织接口（界面）。对于信息化建设项目，在系统设计与开发、测试阶段，对各种技术接口的管理极为重要。而在系统分析与安装调试阶段，协调组织界面是项目管理队伍的重点工作。 实施过程中，项目队伍成员必须按计划做事！

比较我们与西方人做事的习惯不难发现，西方人总是按文档（当然首推计划）规定去做事，而我们做事主观随意性较大。应该学习和接受西方人的做事习惯！

控制方面挣值测量作为一种项目监控工具在我国使用得不多。主要原因是我们的项目管理者粗放式管理惯了，不习惯于做较精细的管理工作。当然，在信息化建设这类高科技项目的管理工作中，对工作量完成百分比做比较准确的估计（这是使用挣值测量法的前提）有些

37

困难，也是人们不愿使用这种工具的一个原因。但笔者的体会是：对工作量完成情况做个百分比估计，比不做要好；对于类似项目第二次做时，对许多工作完成情况的估计还是有较好的置信度的。

变更控制可能是信息化建设项目中最需要但又是最困难的事。范围无止境的蔓延常常是让开发商苦不堪言。控制范围蔓延涉及到许多方面的因素，这里不一一讨论了。 四、用户对项目的管理

在项目生命周期内，用户对项目的管理主要在进度控制、范围核实、质量把关等方面。由于通常是采用固定总价合同把项目承包给开发商，因此对成本的控制不是用户主要考虑的问题（当然，非固定总价合同情况除外）。而对范围、进度、质量等方面的管理是基于同样的标准的，即是说项目所有的技术和管理文档以及任何变更后的版本，都是开发商和用户达成一致意见后形成的。

在项目生命周期内，用户项目队伍重在参与。在系统分析阶段，没有用户项目队伍的重要参与就不可能产生好的“系统说明书”，也就不可能有好的项目成果。在安装调试阶段，没有用户项目管理队伍的协调、调度，转换工作就可能陷于混乱状态。在系统设计与开发、测试阶段，用户应着眼于未来的运行维护，派技术人员全程参与工作，其必要性有二：一是未来系统运行维护的重要责任，要求技术人员必须深度了解系统的技术情况；一是系统将来必然会不断升级，要求技术人员能够为升级方案做重要贡献。系统维护人员是了解公司业务的技术专家，不可等同于一般维护人员，也不同于一般网管人员，这点应引起用户的重视。 有些情况下，用户可以雇佣项目监理来协助自己完成项目工作。特别是项目启动前的可行性论证阶段，用户对怎样实现信息化或什么样的信息化解决方案对自己是实用的，可能并不很清楚，这时购买项目监理或咨询公司的服务是很有效的。在项目生命周期内的各阶段，从职能上说，项目监理与项目管理是差不多的。 五、项目的组织问题

对于信息化建设项目，多数开发商、用户单位的内部组织都是传统型（职能型）的，即组织的结构是按职能划分的。在这种结构体系里，对项目的组织往往是非正式的（用户方面更是如此）。所谓的项目经理一般也就是部门内部一个领头干活的人。而另一个极端的现象是，当认为某个项目很重要时，就可能由高层人物来负责这个项目。在一些媒体甚至某些高等教育教材中，我们都能看到有这样的说法：信息化很重要，信息化建设工作应该由一把手亲自抓。

对信息化建设的项目管理工作，由一个领头干活的人负责显然不行，但由一把手亲自抓的观点，也非常值得商榷。

本文开头提过，信息建设工作是很复杂的事情。“复杂”体现在两个方面：一是把业务流程、规范、标准等搞清楚，并据此确定要建一个什么样的系统很复杂；一是技术实现上复杂。负责信息化建设的项目经理，应有这两方面的知识与经验。从开发商方面看，该项目经理应有很好的技术背景，同时要熟悉所服务行业的业务情况；从用户方面看，这个项目经理应非常清楚本单位的业务流程，同时对技术有一定的掌握。

一把手是企业战略层面上的管理者，很难要求他管好信息化建设这样具体而复杂的项

38

目。

保证信息化建设项目的顺利进行，应从组织结构上着手。

矩阵型组织（参见下图）是西方国家许多企业采用的一种项目组织类型。

在这种组织结构里，职能部门经理承担职能性职责，项目经理承担项目职责。所谓扁平化管理指的也是这个意思。

从图中不难看出，项目经理需要在全公司内整合资源来完成项目工作。要做到这点，首先应赋予项目经理必要的权力。高层经理应充分认识到，负责=职责+职权。上图显示出，项目经理和职能经理的权力是平行的。要重视信息化项目建设工作，高层管理者在职能经理与项目经理的权力平衡中就应更倾向于项目经理一边。

这里应该强调的是，矩阵型组织是一种现代型组织结构，重视这种组织结构应用，其意义不仅仅局限在信息化建设过程中，对处在产品或服务转型期的各行业来说，都有重要的现实意义。 结束语

本文阐述了信息化建设中的项目管理。然而，在当今信息化社会里各行业都应重视项目管理。

时代的变化已越来越快。产品生命周期短了，一种型号的产品推出后，很快就被功能更强、性能更好的产品所取代；对服务的要求更高了，与时俱进的人性化、个性化服务是不断摆在人们面前的课题。创新已是这个时代出现频度很高的一个关键词。产品创新需要立项，服务创新也是项目。项目的概念已超越了我们对它的传统认识。因此，我们不仅要在信息化建设中重视项目管理工作，还需要在广泛的社会领域中重视项目管理。

39

IT国内应用软件项目管理的若干问题

随着企业IT建设的深入和国际交往的增多，应用开发的项目管理日益受到重视。国内面向企业客户的应用软件开发项目管理的问题和差距何在?更多的可能是实践问题而非理论问题，以下结合笔者在集团用户、外资企业和国内民营企业的项目经验和思考，作些初步的探讨。 项目管理意识

不能真正区分项目实施和项目管理的工作任务，是目前存在的普遍问题。可概括为“没事做”和“没人做”并存的现象，这往往由开发骨干兼任项目经理所致。一方面，如果设立专职的项目经理，专做项目管理而不做任何分析、设计、编码、测试等具体的技术实施工作，就会感觉“没事做”，或是在打杂。另一方面，由于主要 或全部精力均忙于具体技术工作，各种项目管理任务(如：项目分析/评估、项目计划的制定/检查/调整、上下左右的沟通、专业资源调配、项目组织调整、项目 财务控制、风险分析/对策等)不可避免地疏于顾及，项目管理的事情“没人做”，导致项目控制的问题“积劳成疾”，后悔莫及。

在中、小型项目中，管理任务可能不饱和，有条件的项目经理可以兼任项目技术主管或业务咨询，关键在于要有将项目管理工作区分出来的意识和责任感。 项目成本基础

项 目管理的精髓是必须在规格(Specification)、成本(Cost、Resource)和进度(Schedule)之间取得平衡。而目前国内的系 统集成企业，普遍没有建立专业工程师的成本结构及运用控制体制。因而无法确立和实现项目成本的指标、考核和控制，导致公司与项目经理之间的责任不清。直白 地说，项目经理可以不计成本地申请资源，“韩信点兵，多多益善”，而公司处于两难，答应则可能投入太大，拒绝则必须承担项目失败的责任。上级经理成了项目 经理。

不建立专业资源成本结构，就无从实现项目的成本管理，就不会有真正的项目管理。

项目管理制度

规 范化而且切实可行的项目管理制度，必须因企业、因项目而异。一般而言，应是项目管理原理、企业/行业特点和项目规模/性质、企业开发文化/素质等各种因素 综合的产物。产生的过程应是，由具一定的理论素养、丰富的规范化项目实施经验和总结能力的资深项目管理专家，结合企业的具体情况，有针对性地制定，并经培 训、试行、调整予以落实贯彻。

国内目前的普遍情况，或者是企业无项目管理制度，仅凭个人经验实施项目管理;或者是书生制度，照搬教条，纸上谈兵，束之高阁。其结果是，不仅实际的项目管理无所依循，而且也使项目监管层难以落实项目的间接监控和支持。

40

本文来源：https://www.bwwdw.com/article/vehg.html