第一篇：系统集成项目案例分析
系统集成项目案例分析
本章收集了实际项目中的大量案例，每个案例侧重点各不相同，是对前22章知识 点的综合运用。不仅需要动手实践项目管理中的硬技能，例如网络图、挣值分析以及成 本财务分析等，还需要能够灵活运用项目管理中的软技能，例如沟通协调、需求变更以 及项目管理中的一些常见原则等。
本章案例分析所要用到的信息化及系统集成专业知识主要涵盖如下方面。
(l)信息化建设基本知识。
(2)软件工程。
(3)面向对象设计。
(4)软件以及硬件体系结构知识。
(5)计算机网络知识。23.1项目管理硬技能案例 23.1.1
人力资源负荷的优化对很多项目来说是至关重要的一个问题，而利用网络图中非关 键路径任务上的浮动时间是最常用的方法之一。
案例场景
为了更好地利用资源和对资源进行有效地管理，项目组重新对项目计划进行了调 整。调整后的各项工作的工作持续时间、所需要的人力资源类型及其相应的工作量估计 如表23-1所示。
表23-1游戏软件开发项目调整后的工作时间和工作量估计表
【问题2] 根据表23-2，进行人力资源平衡的优化，并绘制该项目的人力资源负荷图。23.1.2现金流分析案例
在立项阶段，经常需要对项目未来的现金流状况进行分析，并作出相应的财务数据 分析。
案例场景
某软件公司拟开发一套建筑施工项目管理软件，该软件应具有项目管理计划的编制 及项目的动态管理功能。该软件开发项目的基础数据如下。
(1)该项目从2004年7月1日开始，周期为180天，项目总投资600万元。
(2)该软件从第二年开始销售，预计当年销售收入为500万，各种成本为200万； 第3年销售收入为800万，各种成本为300万；第四年开始正常销售，正常销售期间预 计每年的销售收入为1000万元，各种成本为500万元。
(3)根据上述数据，假设项目成本与收入均在年末核算，通过分析计算该公司从项 目开始当年到第6年的现金流量情况，包括每年的现金流出、现金流入、净现金流量、累计净现金流量、现值和累计现值，如表23-3所示。
【问题1】
请根据表23-3现金流量表中的数据，计算该项目自投资当年起的静态投资回收期和 动态投资回收期（要求列算式），并说明两者存在差异的原因。
【问题2]
如果该行业的标准动态投资收益率为20%，请问该项目的投资是否可行。23.1.3动态回收期及净现值分析案例
对于很多项目来说，必须要考虑到资金的时间价值，因此经常要引入动态回收期和 净现值的计算。
案例场景
某软件公司拟开发一套建筑施工项目管理软件，该软件应具有项目管理计划的编制 及项目的动态管理功能。该软件开发项目的基础数据如下：
(1)该项目从2004年7月1日开始，周期为180天，项目总投资600万元。
(2)该软件从第二年开始销售，预计当年销售收入为500万，各种成本为200万。第3年销售收入为800万，各种成本为300万；第四年开始正常销售，正常销售期间预 计每年的销售收入为1000万元，各种成本为500万元。
(3)根据上述数据，假设项目成本与收入均在年末核算，通过分析计算该公司从项 目开始当年到第6年的现金流量情况，包括每年的现金流出、现金流入、净现金流量、累计净现金流量、现值、累计现值，如表23-4所示。
【问题l】
请根据表234现金流量表中的数据，计算该项目自投资当年起的静态投瓷回收期和 动态投资回收期（要求列算式），并说明两者存在差异的原因。
【问题2】
如果该行业的标准动态投资收益率为20%，请问该项目的投资是否可行。23.1.4挣值分析案例
“挣值管理”是项目管理中非常有用的一种绩效分析的方法。它通过对预算成本、实际完工工作量和实际发生成本三个基本指标的计算可以作出对项目成本和工期状态的 准确评估。
案例场景
在认真分析新型柜式空调生产建设项目各项费用的基础上，最终制定的各项工作的 成本预算修正结果如表23-4所示。假设该项目已进展到第21旬，你对项目前20旬的实 施情况进行了总结，有关执行情况汇总于表23-5中。
【问题1]
计算前20旬每项工作的挣值并填入表23-5中，请至少写出一项工作挣值的计算公式。
【问题2]
计算该项目到第20旬末的挣值(EV)。
【问题31
计算该项目前20旬已完成工作量的实际成本(AC)。
【问题4]
根据以上结果分析项目的成本执行情况和进度执行情况。
【问题5]
假设该项目目前的执行情况不会影响到未来，未来将按计划执行，请估计项目完成 时的总成本(EAC)；为了保证项目成本目标的实现，你将会采取哪些对策？ 23.1.5需求评窜案例
把握住清晰、完整和准确的需求是对项目进行有效控制和管理的前提，而需求评审 又是需求管理阶段一个至关重要的工作。但是，需求评审往往是所有评审活动中最难，也常常是最容易被忽视的。
以下是在实际项目管理中几种常见的、失败的需求评审。
案例场景
案例一
某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会 开始时间不长，就被在场的某企业的一位副总B先生打断，认为A先生提出的方案不适 合本企业，A先生提出的管理改进方案在企业中无法实施。该副总提完意见后，与会的 用户方人员纷纷跟随B先生的意见提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。
案例二
某软件公司内部举行产品的需求评审会，主要是公司内部相关领域的专家参加。在 评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果致使会议出现了混 乱状况，主持人无法控制局面，会议大大超出了计划评审时间。
案例三
某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上 宣读多达上百页的需求报告时，用户明确提出昕不懂，致使会议不得不改日进行。
案例四
某软件公司在用户处开完物资管理系统的需求评审会后，与会人员在离开会议室时 纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。
【问题】
请提出一些建设性的意见，如何能够召开成功的需求评审会议？ 23.1.6风险箐理案例
在项目中，风险是无处不在的，而风险叉往往是项目管理者最容易忽视的。因此，对很多项目来说，做好风险的识别、分析、监控和管理工作是保证项目成功、减少项目 损失的一个关键。
案例场景
C公司是国外一家知名的电信设备供应商，在国内拥用许多电信运营商客户。C公 司主要通过分销的方式发展其在中国的业务，由其在国内的合作伙伴与电信公司签约并 提供系统集成服务。
2000。年，国内一家省级电信公司(H公司)打算上马一个项目，并通过发布RFP（需 求建议书）以及谈判和评估，揖终选定C公司为其提供相关电信设备。国内某集成公司（L公司）作为C公司在中国国内的代理商之一，成为了该项目的系统集成商。L公司是 第一次参与此类工程。电信公司（H公司）和L公司签订了总金额近1000万元的合同。张先生是L公司负责该项目的项目经理。该项目的施工周期是三个月，由国外电信设备 供应商C公司负责提供主要设备，L公司负责全面的项目管理和系统集成工作，包括提 供主机、外设及相关附属设备，并负责项目的整个运作和管理。C公司和其代理商L公 司之间签署的是设备采购合同，一次性付款，这就意味着C公司不承担任何项目风险，而L公司虽然有很大的利润，但是也承担了全部的风险。L公司和客户H公司之间签署 的是集成服务合同，合同类型为固定价分期付款合同，按照惯例，10%的尾款要等到系 统通过最终验收一年后才能支付。
项目实施3个月后，整套系统安装完成。但自系统试运行之日起，不断有问题暴露 出来。H公司要求L公司负责解决，可其中很多问题涉及C公司的设备问题。因而，L 公司要求C公司予以配合，C公司也一直积极参与此项目的工作。
然而，随着对项目的阶段性测试工作的展开，H公司发现系统的实际技术指标远远 没有达到当初L公司在最初的技术建议书上的承诺。对于H公司来说，他们认为，按照 RFP的要求，L公司实施的项目没有达到合同的要求。因此，直至2002年，H公司还拖 欠L公司10%的验收款和10%的尾款。L公司多次召开项目会议，要求C公司给予支持。但由于开发周期的原因，C公司的设备无法马上达到新的技术指标并满足相关的功能。于是，项目持续延期。为完成此项目，L公司只好不断将C公司的最新升级系统（软件 升级）提供给H公司，甚至派人常驻在H公司（外地）。
又经过了3个月的艰苦调试，H公司终于通过了最初验收。在L公司同悫承担系统 升级工作直到完全满足RFP的基础上，H公司支付了10%的验收款。然而，2002年年 底，C公司由于内部原因暂时中断了在中国的业务，其产品的支持力度大幅下降，结果 致使该项目的收尾工作至今无法完成。
作为项目经理，L公司张先生简单估算了一下，在此项目上公司原本可以获得250 万元左右的毛利，可是考虑到增加的项目成本（差旅费、沟通费用、公关费用和贴现率）和尾款，实际毛利不到70万元。如果再考虑机会成本，实际利润可能是负值。
导致项目失败，尤其是项目预期的经济指标没有完成，这是非常遗憾的事情。项目 失败或没有达到预期的经济指标的因素有很多，其中风险管理是一个极为重要的因素。
【问题】
从L公司角度，讨论一下该项目失败的原因及其避免的方法。
分析提示：
(1)风险识别与分析的方法。
(2)适当的商务承诺。
(3)选择适当的商务合同。
23.1.7公司组织结构对项目管理的影响
公司组织结构对项目管理的影响是显而易见的，不同的组织结构都有其相应的优点 和缺陷。而对于矩阵型的组织结构来说，有效的沟通和协调能力对于项目经理往往是一 个非常大的挑战。
案例场景
某软件公司以产品开发和项目为其主要业务。公司目前发展势头良好，正在建谩中 的项目有5个左右，已经立项的有10个左右，还有若干项目正处在验收和后期维护阶段。
公司实行的是强矩阵式管理模式，专职的项目经理往往一个人带多个项目，职能部 门内部也有担任项目经理工作的人员。但是，瓷源的调配成了项目经理、职能部门经理 在项目实施过程中塌棘手的问题。项目经理每个人都身兼数职，对项目进度难以控制，而多数项目在进行耐，资源的调配是由各个职能部门经理安排的，职能部门经理对质量 进行监督，项目经理耍做进度控制，可是却没有分配资源的权力，从而引发出关于公司 内部管理流程和职责定位的问题。
【问题】
在强矩阵管理的模式下面，项目经理与职能部门经理对公司资源的调用如何协调？
分析提示：
(l)项目章程明确责任。
(2)项目经理和职能经理的协调。23.1.8项目变更管理案例
在项目执行中，变更往往在所难免。但是，无序和随意的变更会对项目的成功造成 极大的危害。这就要求项目管理者在项目的前期做好需求的导出和定义工作，并在项目 执行中有切实可行的变更管理方法和流程。
案例场景
小张是国内某IT系统集成企业的项目经理，目前正在负责国内某省一个企业的信息 系统项目的建设工作。作为项目经理，小张根据合同中昀相关条款，在计划阶段简单地 罗列出了项目中几项必须应当完成的工作。甲方的项目经理由这个企业的信息中心领导 担任，此系统集成项目涉及到甲方的许多业务部门。在项目实施中，甲方的销售部门、财务部门和人力资源等多个部门都向小张提出了变更要求，而其有些要求甚至是相互矛 盾的。面对这些变更，小张尝试向甲方的各个业务部门做说服和解释工作，但甲方却引 用合同中的相关条款作为依据要求小张实现这些新增加的变更要求。而这些合同条款要 么太粗、不够明确，要么小张与他们有不同的理解，因此小张感到左右为难，既不能对 这些变更要求简单地全盘接受，又不能生硬拒绝。但如果不能尽快改变这种现状，完成 项目看起来是遥迢无期。
【问题】
该问题产生的原因是什么？如何解决？
分析提示：
(l)WBS详细分解。
(2)CCB的成立。
(3)变更流程的建立。
(4)客户对需求和项目工作说明书的确认。23.2软技能案例
23.2.1范围定义案例
‟
项目的范围管理影响到信息系统项目的成功。在实践中，“需求蔓延”是信息系统失 败最常见的原因之一，信息系统项目往往在项目启动、计划、执行，甚至收尾时不断加 入新功能，无论是客户的要求还是项目实现人员对新技术的试验，都可能导致信息系统 项目范围的失控，从而使得信息系统项目在时间、资源和质量上都受到严重影响。
阅读以下关于信息系统项目管理过程中范围管理方面问题的叙述，回答问题1～问 题3。
案例场景
Perfect公司原本是一家专注于企业信息化的公司，在电子政务如火如荼的时候，开 始进军电子政务行业。在电子政务的市场中，接到的第一个项目是开发一套工商审批系 统。由于电子政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着全部信息，其中包括部分机密信息；政务外网可以对公众开放，开放 的信息必须得到授权。
系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须 一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进 入政务内网系统。
张工是该项目的项目经理，在捕获到这个需求后认力电子政务建设与企业信息化有 很大的不同，有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。在项目交付时，虽然系统完全满足了保密性的要求，但用户对 系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70%的代码 重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写了部分代码才通过 验收。由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也 超出原计划的100%。
【问题1]
请对张工的行为进行点评？
【问题2]
请从项目范围管理的角度找出该项目实施过程中的主要管理问题？
【问题3]
请结合你本人实际项目经验，指出应如何避免类似问题？ 23.2.2工作要点的案例
阅读以下关于信息系统项目管理过程中项耳范围管理方面问题的叙述，回答问题
1、问题2。
案例场景
M集团是Perfect公司多年的客户．Perfect公司已经为其开发了多个信息系统。是近，M又和Perfect公司签订了新的开发合同，以扩充整个企业的信息化应用范围，张工 担任该项目的项目经理。
张工组织相关人员对该项目的工作进行了分解，并参考了公司同M曾经合作的项 目，评估得到项目的总工作量为60人月，计划工期6个月。
项目刚刚开始不久，张工的高层经理s找到张工。s表示，由于公司运作的问题，需要在4个月内完成项目，考虑到压缩工期的现实，可以为该项目再增派两名开发人员。
张工认为，整个项目的工作量是经过仔细分解后评估得到的，评估过程中也参考了 历史上与M企业合作的项目度量数据，该工作量是客观真实的。目前项目已经开始，增 派的人手还需要一定的时间熟悉项目情况，因此即使增派两人也很难在4个月内完成。如果强行要求项目组成员通过加班等方式实现4个月完成的目标，肯定会降低项目的质 量，造成用户不满意。
因此，张工提出将整个项目分为两部分实现，第一部分使用三个半月的时间，第二 部舒使用三个月的时间，分别制定出两部分的验收标准，这样不增派开发人员也可以完 成。高层经理认为该方案可以满足公司的运作要求，用户也同意按照这种方案进行实施。
6个月以后，项目在没有增加人员的前提下顺利地完成，虽然比昂初计划延长了半 个月的工期，但既达到了公司的要求，客户对晟终交付的系统也非常满意，项目组的成 员也没有感受到很大的压力。
【问题1]
请指出张工是如何保证项目成功的？
【问题2】
试结合案例指出项目范围管理的工作要点？ 23.2.3范围确认案例
阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述，答问题卜— 问题3。
案例场景
Perfect公司刚刚和M签订了一份新的合同，合同的主要内容是处理公司以前为M 公司开发的信息系统的升级工作。升级后的系统可以满足M公司新的业务流程和范围。由于是一个现有系统的升级，项目经理张工特意请来了原系统的需求调研人员李工担任
520
系统集成项目管理工程师教程
该项目的需求调研负责人。在李工的帮助下，很快地完成了需求开发的工作并进入设计 与编码阶段。由于M公司的业务非常繁忙，M公司的业务代表没有足够的时间投入到 项目中，确认需求的工作一拖再拖。张工认为，双方已经建立了密切的合作关系，李工 也参加了原系统的需求开发，对业务的系统比较熟悉，因此定义的需求是清晰的。故张 工并没有催促业务代表在需求说明书中签字。
进入编码阶段后，李工因故移民加拿大，需要离开项目组。张工考虑到系统需求已 经定义，项目已经进入编码期，李工的离职虽然会对项目造成一定的影响，但影响较小，因此很快办理好了李工的离职手续。
在系统交付的时候，M公司的业务代表认为已经提出的需求很多没有实现，实现的 需求也有很多不能满足业务的要求，必须全部实现这些需求后才能验收。此时李工已经 不在项目组，没有人能够清晰地解释需求说明书。最终系统需求发生重大变更，项目延 期超过50%，M的业务代表也因为系统的延期表示强烈的不满。
【问题1]
请对张工在项目管理工作中的行为进行点评。
【问题2]
请从项目范围管理的角度找出该项目实施过程中的问题。
【问题3]
请结合你本人的项目经验，谈谈应如何避免类做的问题。23.2.4客户关系管理案例
沟通是指人际之间传递和沟通信息的过程，对于项目取得成功是必不可少的，而且 也是非常重要的。沟通的主旨在于互动双方建立彼此相互了解的关系，相互回应，并期 待能经由沟通的行为与过程相互接纳及达成共识。
在信息系统项目中，项目干系人之间的沟通贯穿项目整个生命周期。很多专家认为，信息系统项目失败的重要原因就是沟通的失败。
阅读以下关于信息系统项目管理过程中客户沟通管理和客户关系管理问题的叙述，回答问题l～问题3。
案例场景
Perfect公司是一家中小规模的软件公司，公司研发人员不到20人，主要从事纺织 机械行业企业管理信息系统的开发。经过一些开发项目的积累，逐步形成了适合该行业 企业的财务管理软件和企业资源计划系统ERP软件两大产品。由于Perfect公司销售人 员的努力工作，目前Perfect公司业务较繁忙，逐步进入高速增长阶段。
一个月前，Perfect公司销售人员赵某参加了国内某大型纺织机械集团公司D公司的 信息化建设项目招标工作。赵某在多次向Perfect公司技术部门提出要求技术人员配合，参与项目建议书编写工作，要求没有得到人员落实的情况下，独立完成了该招标的项目 建议书。由于报价合理，同时在向D公司提供的项目建议书中，提出了一套相当全面的 实施方案和较理想化的信息化建设思路，结果Perfect公司顺利中标。
根据投标文件中做出的实施进度承诺，项目一周后正式立项。由于Perfect公司业务 繁忙，一时无法从其他项目组抽调研发人员到新成立的项目小组，人力资源部门临时招 聘了张工和其他5名软件工程师。由于张工具有较强的技术水平和丰富的项目管理经验，被正式任命担任诙项目的项身经理。
张工接手此项目后，认真阅读了当初向D公司提供的项目建议书，很快发现了项目 中存在的技术难题，于是在签订技术开发合同过程中就该问题对D公司做了较详细的说 明，D公司最终勉强接受了张工的建议并签订了合同，合同中未再包含项目建议书中无„ 法实现的功能需求。
Perfect公司与客户方签署了技术开发合同后，张工立即组织了项目组中两名软件工 程师一起开始需求调研工作，但在需求调研工作中，D公司变得越来越不配合，总是强 调项目建议书中所描述的无法实现的功能需求，并提出当初之所以选择Perfect公司，就 是因为Perfect公司的项目建议书中描绘的这些功能是其他公司不能提供的。
为了取得D盆司方面的支持，张工亲自做了大量的技术尝试去完成这些功能，但经 过多方技术论证，该部分功能在目前的条件下是很难成功的。对该部分功能的技术论证 已经持续了一个多月，没有取得任何实质性的进展。作为项目经理，张工感到相当大的 压力和责任。
【问题11
请对Perfect公司销售人员赵某在执行此项目过程中的行为进行点评。
【问题2】
请结合你本人的实际项目经验，谈谈项目客户关系管理的重要性。
【问题3】
请对张工解决此问题提出建议。23.2.5变更控制案例
阅读以下关于信息系统项目管理过程中项目变更控制和客户沟通管理问题的叙述，回答问题1—问题3。
案例场景
PERFECT公司是某市一家大型股份制软件企业，公司研发人员达到200人，主要 从事电子政务应用系统和金融信息系统等方向的研发。PERFECT公司具有较强的政府 背景，公司副总经理兼技术总监张工原为该市政府信息中心总工程师，3年前创立了 PERFECT公司。
目前，PERFECT公司正在进行该市某政府机关的办公自动化系统研发，系统主要 由公文管理、档案管理、公共信息、会议管理、领导办公、电子邮件、个人办公、业务 管理和事务预警系统管理等子系统组成。
由于PERFECT公司具有较好的技术和产品积累，经过5个月时间，整个系统于3 个月前按进度计划开发完成，目前系统处于试运营阶段，运行情况良好。但是，项目一 直没有结项，项目中出现了几个以下问题。
(1)频繁的需求变更。由于客户属于机关单位，客户不断提出一些变更，项目组就 要处理变更需求。
(2)客户的工作效率低、节奏慢，很小的内部分歧也需要开会讨论。在项目实施过 程中，严重单方面拖延实施进度，使项目不能按计划结项，造成项目延期。
(3)客户同PERFECT公司关系特别密切，不能完全按照合同进展，对合同规定的
阶段验收不予回应，这些问题需要公司老总出面才能协调，项目经理控制协调明显乏力。
项目经理李工原为该项目的系统分析师，主要负责系统技术架构和系统分析设计，开发后期由于原项目经理王工离职原因，被任命为新项目经理。
【问题1:1
请分析导致电子政务项目产生上述问题的原因，对于电子政务建设组织管理的关键 是什么？
【问题2]
请结合你本人的实际经验，谈谈如何有效控制电子政务项目的需求变更以及用户需 求变更的处理方法。
【问题3]
请对李工解决此问题提出建谀。23.3综合运用案例
23.3.1电子政务项目案例
1．项目背景
随着电子政务的普及，政府机关的信息化进程不断加深，刚刚进入2001年，北方 的工业化重镇滨海市市政府正式推出《滨海市市政府电子政务发展纲要>，其电子政务 二期工程在年初也正式立项并得到批准，这标志着该市的电子政务二期工程开始启动。
市信息化办公室负责整个工程的开发与实施，其首要任务包括在该市电子政务一期 工程已经完成的电子政务专网的基础上，实现政府机关全部网络化，并实现无纸化办公。与此同时，还要建设相应的配套服务设施，政府网站等，总投资3000万元。
此项目经过方案设计、公开招投标、专家评审，于2001年5月确定了承包商A公 司作为项目总包，全部工期预计5个月，整个项目年底前完成。此项目包括了以下子项 目：
(1)计算机机房建设；
(2)政府办公大楼的综合布线工程：
(3)政府办公大楼全 楼的网络系统、服务器设备的集成：(4)滨海市政府办公自动化软件平台的开发。并在 符合安全规范的基础上，实现内外网的隔离和信息交换，确保能够顺利并入电子政务 专网。
„
2。项目遇到了问题
签约后承包商项目组进入该项目现场实施，项目分为软件开发、硬件集成和综合布 线三个实施部分。负责软件部分的项目经理是贺工，A公司任命他牵头负责整个项目的 实施，于是，他从A公司售前经理唐工和销售经理胡工手中正式接过了整个项目。由于 他深知这次中标的主要原因还是报价较低和完全承诺了苛刻的工期要求，因此内心一直 忐忑不安。但由于A公司是该市的著名IT公司，其总经理李总已经下了决心，一定要 保质保量按时地完成滨海市的政府信息化项目，决不能有半点差错。于是，A公司派出 了副总经理王总亲自主管该项目，三个项目组也都是由A公司的精兵强将组成。虽然A 公司还在南方某市进行着另外两项电子政务工程的实施工作，但A公司王总认为，家门 口的事情都办不好，还有何面目见家乡父老，况且滨海市的电子政务第二年还将上第三 期，将要建设呼叫中心、社保信息系统等大型项目，所以征得A公司李总同意后，各分 公司各个项目技术人员重新调配，采用矩阵式项曰管理模式，前提是以首先保证这个项 目为原则。
布线和硬件建设方面进展相对软件开发比较顺利。软件开发在该项目中实际上是难 度最大的一块内容。由于滨海市政府机关关系复杂，工作流程比较烦琐，再加上工期非 常紧，因此甲方很重视，要求很高。A公司项目负责人及主要开发人员在开发计划、进 度安排、需求调研上与甲方进行了一周时间的沟通，总体比较顺利，项目很快完成了需 求调研阶段。由于滨海市信息化办公室主管领导正在出国考察，因此项目评审暂时搁置，于是项目直接进入到系统设计和编码阶段。计划中的第一阶段是完成功能开发，第二阶 段是界面确认和性能优化。至此，由于A公司已经拥有了成型的商业化办公软件(BG-2系统)，王总认为下面的只是定制工作了，对年底完工充满了信心。建设方对A公 司的进度也比较满意，主管该项目的市信息办领导向市委汇报：项目进展顺利，年底前 一定请市长给该项目剪彩。
在一个月后，系统已经进入第二阶段的界面确认和性能优化工作。但是在系统的第 一次阶段性审查中，A公司的项目方案却受到了专家组（由外聘专家和本地政府领导组 成）的批评，认为该系统的设计没有充分体现滨海市政府办公的实际需求，而是过多地 沿袭了A公司的商业化办公软仲的流程，一句话，针对性不够，责成信息化办公室立即 对项目进行补救。两周后，方案在第二次评审会上又遭到了质疑，而且由于这次评审加 大了滨海市市政府各个主管领导和相关处室领导的比重，大家对方案评头论足、与A公 司争执不休，而且许多意见是与当初需求调研时不同或改进的，或者就是主管领导进行 调整导致意见完全不同的，最终会议几乎没有达成统一的意见，这使A公司王总十分难 堪，只得答应补充技术人员，再进行更进一步的需求调研。
可就在这个时候，南方的电子政务项目出现了问题，A公司李总不得不把项目组里 面的一部分原有人马调去南方“救火”。又过了一周，在各方参加的项目协调会上，A 公司王总无奈地提出聘请专业的信息化咨询顾问公司介入该项目，帮助A公司完成该 项目。
3．介入项目
于是，国内著名的信息化咨询顾问公司B公司进入到项目中。本项目的咨询总监由 谢经理担任，对于眼前的僵局，他没有急于拿出咨询方案，而是首先对A公司的项目经 理贺工和韩工进行了沟通。
访谈之一
负责项目技术总体工作的贺工对项目目前的状况发表了自己的意见：通过对目前项 目的状态进行分析后，他认为A公司目前已经遇到的问题如下。
(1)用户需求难以确定。市政府中很多用户很明确政府信息化的作用，也找到了实 施方向，但对于自己在其中的需求很模糊，所以这次项目中他们要么就是各部门提出很 多杂乱的要求交给A软件公司，要么就是请A公司自己通过调研整理出需求，然后请用 户确认，但随着项目的开展，往往需求的想法也随之发生变化，变化是需要的，但是变 化太频繁、变化的幅度大，直接影响了项目的实施进度和效果。
(2)工作量难以确定，导致项目总体进度无法把握。用户需求不确走导致工作量不 确定是原因之一，更重要的原因是迄今为止仍然缺少有效的技术与方法来事先估算系统 分析与系统设计所需要的时间。尽管经验很重要，但因为电子政务发展很快或系统本身 更新也很快，解决方案越来越细，越来越专业，很多大系统也是首次“开发”或使用，估算的计划与实际往往有偏差。还有另外一个原因就是系统实施过程中出现的不确定因 素，例如政府人员变动、部门定位受到改革的巨大冲击等。
(3)项目实施难以按期完成。项目不能按期完成现在已经是明摆着的了，这也是用 户抱怨最多和最强烈的。可以说大多数子项目都不能如期完成，或者会留有“尾巴”，有 的甚至很可能会导致整体项目失败。而目前不用说无人可调，即使人力增加，实际效果 也无法保证。
(4)用户方没有及时了解问题。在这类信息化项目过程中，往往坏消息向上传递的 速度较慢，报喜不报忧几乎是所有组织存在的通病，实施过程中出现的问题往往被中层 过滤掉，不能及时反映到管理和决策的高层中去，有时候用户也碍于情面私下解决，导 致出现的问题不断积累，出现的错误不能及时纠正，直到评审会上才暴露出来。而这时 已经发展扩大积累到难以纠正，或者调整的代价太大，就像现在的状况。
(5)项目组内部的工作方泫的不一致。由于项目组技术和管理人员被临时抽调在一 起，甚至是来自不同分公司，以往工作方法不尽相同，所以在工作中难免会造成冲突，尤其在项目进展不顺时，互相埋怨和推卸责任使项目也受到影响。本项目中，各个项目 经理对于目前的局面意见不一，几乎没法协调统一工作。
所以贺工认为，本项目已经很难进行下去了。
访谈之二
直接负责项目需求调研工作的韩工对此也发表了自己的意见：“我屉怕做政府的项 目”，他认为政府项目的“围城”难以逾越。对此也许是看到贺工在场，他没有直接说明 对本项目的看法，只是对谢经理谈到了他两年前的一段相似的经历：
韩工原是内地某市一家软件公司C公司的技术经理，大大小小的项目也做过了十几 个，一年前来到A公司，对于政府项目他颇具发言权，他认为虽然近两年电子政务很热，好多公司都把政府行业作为发展的重点，但是有些项目并不好作，原因一言难尽。
首先是需求调研的结果难以控制。两年前，C软件公司承接了一个金额为几十万元 的政府OA项目。项目金额虽然不大，却被该公司内部定为“力保”的项目，配备了公 司展强的项目经理、组建了一支十凡人的开发队伍，公司并且指示该项目组可以随意调 配所需资源。如此重视该项目的原因一方面因为源于对电子政务的重视，另外很重要的 一个原因是软件公司正是在该政府部门管辖范围以内，论起级别来，公司的老总也不过 是该部门的处级干部。然而，双方地位的不对等使得项目实施过程凭空增加了几分难度： 客户稍有不满，便会直接给老总打电话，而这是较件公司上上下下一致惧怕的。
其间政府错综复杂的关系令项目经理诚惶诚恐、如履薄冰，却仍然不能避免麻烦的 发生。在项目展开始的需求阶段，软件公司就尝到了苦头。做软件项目最怕的就是用户 需求模糊，几乎和现在的项目一样，他们从客户这里无法得到一个明确的需求是让软件 项目组最为头疼的事情。当时，政府信息办这边共有3个人，3个人都略懂技术，虽然 所知有限，但是按理说，提出需求应该不是什么难事。但是因为客户这边没有配备专门 的、专业的技术人员来负责确认，因此提出的项目需求朝令夕改，光是项目需求这个程 序就用了两个月的时间，项目不得已只好延期。然后，客户以项目不能如期交付为理由，投诉到公司（所以这次韩工直接到基层作需求调研，可结果依然不理想）。
随着项目一步步地进展，接下来所发生的事情表明，需求阶段出现的这段插曲并不 是偶然的，其间暴露出来的问题几乎贯穿了楚个项目始终。为了保证客户满意，韩工领 导的项目组对客户言听计从，但是，客户觉得自己懂技术，经常指手画脚，可实际上他 们并非专业人员，很多技术程序并不十分明白，无法理解软件公司的方案实质，与之沟 通也往往没有结果。另一方面，叉对软件公司有很强的防范心理，放在嘴边上的一句话 足：“别以为我们不懂”，言外之意是“别蒙我们”，诸如此类，令项目经理们苦不堪言。最要命的是，这3人中没有指定一个明确领导，又都想借此项目攒些“政治资本”，所以 对这个项目的掌控欲望都很强，而项目组是哪边也不敢得罪，哪边也得罪不起。公平地 讲，需求总是变化，也不光是人的因素，在目前的情况下，很多政府职能在不断调整变 化当中，这也给项目正常进行增掭了很大难度：项目进行当中，“客户那边可能就是调整 一个部门，但是我们这边可能前边的开发就都白做了，又得从头干起，而客户并不理解 这些，他觉得是应该的。做这个项目比做多少企业项目都累！这个项目打单的时候价格 就给压得很低，再这么个折腾法儿，这回公司肯定是赔钱了！”韩工如此感慨（这与本项 目也几乎一模一样）。
“当然，上述问题当然也不仅仅是客户方面的问题”。韩工认为项目经理也是关键，从软件公司方面来讲，项目经理对政府内部业务不熟悉，同时由于双方地位的悬殊，因 此很难得到政府客户的有效支持。很多政府机关在IT项目中，相关的责权不够分明，同 时缺乏协调性。这无形中增加了项目的实施难度，同时也很容易埋下隐患。
另一方面，很多项目中，作为公司代表的项目经理、甚至是公司级领导在本公司所 能调配到的资源也很有限。事实上，在一般的公司中，项目经理甚至很难调配公司资源。现在很多的软件和系统集成公司运用的是矩阵式管理模式，为了凸显对项目管理的重视，项目管理部往往被独立出来。理论上来说，这样做可以让项目经理更自如地组织各方资 源实施项目，但实际上由于成本原因，公司的技术人员有限，使得项目经理无法组织有 效的工作。两方夹击之下，项目经理根本无法真正地执行项目管理职责。如果再加上公 司内部项目冲突（就像现在），就会更加加剧这种情况。
4．A公司的两份项目管理文档
与A公司的两位项目经理沟通完，咨询顾问公词谢经理陷入了苦恼，整个项目目前 是一团乱麻，许多事情都需要从头捋清，尤其在这个阶段咨询顾问公司才进入，当然也 是各方对其的信任，但他也明显感到这个项目的沉重。作为顾问咨询方的负责人，咨询 顾问团队正在等着他作出判断，A公司也催促着要咨询公司的具体实施方案，希望咨询 公司能够对这个项目起到提纲挈领的作用。
他沉思之后，觉得整个项目的最大问题应该还是项目管理问题，A公司的项目管理 到位了吗？带着疑问他马上找到A公司的王总，向对方提出了自己了解到的情况，同时 也充分向其了解听取了A公司对本项目整体管理的思路。两个小时后回到自己的办公室，谢经理整理着王总刚刚谈到的《项目经理工作职责》和《项目管理操作手册》，他觉得王 总的介绍应该表明项目中A公司应该进行了相关管理，也有相关文档，但为什么结果不 好呢？他突然意识到，项目的进展不顺利，恐怕还是落实问题，国内许多公司的标准化 文档做得很好，质量控制条理也头头是道，但说的与实际操作却不是一回事。他于是对 手中的两份文档仔细地分析起来，希望能从中找出一些症结。
A公司项目经理工作职责（梗概）
1．项目启动阶段
在项目意向明晰后，项目销售和售前经理的工作职责为：查阅资料，确定助手，刮 定下一步计划。
(1)查阅资料主要分两方面：-方面是OA的技术实现，一方面是政府的日常运作 流程。
(2)助手的主要工作内容是在技术和业务方面与项目经理有互补作用。
(3)制定下一步的计划：和客户面对面的沟通，了解客户的期望以及对项目的认知
第23章案例分析
527 情况，了解客户的业务；进一步了解相关技术；编写设计方案，协助投标。
2．项目实施阶段
(1)项目组织。
项目实施经理在经过分析之后，从各部门抽调人员组成项刚团队，然后召开第一次 项目会议，根据公司现实情况做了鼓励和动员，通报项目的目标和时间，分派相应的职 责给每一个人。
本项目具体的项目组织结构和角色如下。
项目总监：王总
项目经理：贺工
系统架构设计师：黄工
OA开发组经理：贺工
网站开发组经理：吕工
机房建设和网络布线组经理：谢工
系统集成组经理：隋工
(2)项目实施。
①在项目组织结构和角色确定后，项目经理组织“系统架构设计师”成员共同工作，在基于先前提交的计划基础上，进一步细化WBS和项目的实施计划。
②在计划制定之后，项目的成功与否就要看计划的执行，以及针对实际情况进行应 变的能力。
@相对于技术人员，项目经理的工作重点是调度资源、监督和控制进度、指导工作。
④项目经理和各方面人员的沟通是确保项目顺利进行的有效手段。
⑤根据项目的情况，项目经理确定应用软件的开发分两阶段：第一阶段是完成功能 开发，第二阶段是界面确认和性能优化。确保软件开发更容易控制。
@依照甲方要求，进行必要的阶段性评审。
⑦加强删试工作，保证项目质量。
3。验收阶段
在项目的验收阶段，项目经理主要关注的工作内容如下。
(l)总结和移交存档各种资源（如设备、文档等），其目的是使得公司能够不断积累 有关的知识。
(2)对软件产品的发展提出建议，供公司领导决策，其目的是为继续拓展市场做 准备。
(3)总结分析本项目的成败得失。
A公司项目管理操作手册（梗概）
项目经理在项目进行的各阶段，工作内容如下。
(1)工作职责和内容。
(2)所提交的交付物。
(3)所关注的项目里程碑。
(4)需要控制的关键要素。
(5)各种计划外情况的处理和控制。
(6)需要整理和存档的文档。
1．项目启动阶段
(1)可行性研究、初步需求分析、编制项目立项书、项目章程。
(2)交付物如下。
①项目立项书，内容包含项目目标描述、确定项目经理、项目启始和结束时间。
②项目章程。
⑨项目可行性方案。
④项目初步需求分析报告。
2．项目计划阶段
(l)编制各类项目计划，目的是指导项目的实施，它具有现实性和有用性。
(2)将各项计划交用户确认。
(3)具体包括项目整体管理计划编制、范围计划编制、范围定义、历时估算、进度 计划编制、资源计划编制、成本估算、成本预算、质量计划编制、人力资源计划编制、组织计划编制、沟通计划编制、风险识别、风险应对计划编制和采购计划编制等。
(4)在项目范围计划中最重要的是WBS分解结构。
(5)主要交付物有项目整体管理计划、软件客户化计划、工程实施计划、项目集成 测试计划、项目联网测试计划、软件产品开发计划、软件产品质量管理计划、需求分析 计划、需求规格说明书、产品设计计划、概要设计说明书、详细设计谠明书、产品实现 计划、测试计划书、配置管理计划、软件分包申请、软件分包开发计划、培训需求计划 表和开发立项申请报告等。
．(6)项目里程碑。用户确认各项计划。
(7)关键控制点。范围、进度、质量、成本计划及项目整体管理计划。
3．实施阶段
(1)项目整体管理计划的实施。针对项目进行中的变更提出《项目×X内容变更 申请》。
(2)采购管理的询价。根据《项目软、硬件购买清单》和《软、硬件供应商清单》，通过广告和招标等方法，确定合适的卖主，生成《项目软、硬件购买建议书>。
(3)采购管理的资源选择。根据《项目软、硬件购买建议书>、客户和公司的购买条 件，通过与卖方的谈判和估算，生成《××软件购买合同》或《××设备购买合同》。
(4)采购管理的合同管理。根据各种采购、购买合同和实际中的使用情况，以及卖 方提供的发票，通过本方对采购物品的使用情况反映和本方的支付系统，对本方支付系 统生成《××设备（软件）付款申请》、对发生的合同变化生成<××设备（软件）订 购变动报告》、为项目验收提供各种来往信件。
(5)质量管理的质量保证。根据质量管理人员对项目进行的质量测量的结果《项目 第×周运行情况报告》，对项目提出质量改进和调整。
(6)人力资源管理的团队建设。根据《项目人员名单》、《项目阶段计划》、《项目人 员职责列表》和收到的各种对项目人员的反馈，通过项目组建时的奖惩机制，生成《项 目第×周××人的工作情况记录》，并对其进行工作改进的要求。
(7)沟通管理的信息发送。根据项目进行中的工作结果（包括《项目第×周问题汇 总》、《项目第×周任务完成表》等）、《项目干系人清单》、《项目阶段计划》，分别向相 关人等发送或收到相关人等的《项目第×周周报》、《项目第×日日报》和《项目阶段 报告》。
(8)范围管理的范围审核。根据《项目工作范围说明》、《项目工作分解结构图》等 内容，让客户确认，得到客户认可的《项目工作内容确认书》。
4.收尾阶段
(1)项目经理在收尾阶段的主要工作有管理收尾和合同收尾。
(2)管埋收尾涉及为了使项目干系人对项目产品的验收正式化而进行的项目成果验 收和归档，具体包括收集项目记录、确保产品满足昂终规范、分析项目是成功或有效、保存项目信息以供将来使用。
(3)合同收尾是指确认一个合同的所有管理事务己全部完成，亦即此合同已经实实 在在地完成了，即供方已交付了所要求的货物或完成了所要求的服务，合同各方已经检 查并接受了货物或服务。
(4)主要交付物有项目档案、正式验收的文件、吸取的经验教训的文档、合同文件、正式收尾的文件。
(5)里程碑：正式收尾的文件(Contraot Completion Statement)。
①主要控制文档的完整性，文件的正式性。
②防止没有正式的项目结束文件。
谢经理打定主意，看来目前的问题不仅仅是项目的管理粗放，并且没有落到实处，而且项目管理的大环境也不好，所以要想改变现状，首先要作的就是两件事：-是规范 项目，建立双方的工作信任平台；二是针对A公司的问题，提出有针对性的改进意见。之后，在此基础上再制定出针对本项目特点的、针对项目中需要特别注意的、工作重点 明确的咨询工作计划。
【问题1]
针对本项目，你认为电子政务项目的难点在哪些方面？试对应设计本项目咨询公司 的咨询项目纽织机构。
【问题2]
你认为目前项目发生的停滞症结在哪里？原因是什么？咨询公司对应目前的局面 应该如何采取措施？
【问题3:1
贺工对项目目前状况的分析都提出了哪些问题？是否正确和全面？应采取的解决 措施有哪些？
【问题4]
韩工以前经历的项目与当今的项目相同的问题都有哪些？能认为这些都是这类项 目本身的特性所决定的吗？你认为韩工的分析是否正确和全面？并从项目管理角度分析 是否可以避免？如何避免？
【问题5]
从其项目管理操作手册分析A公司的项目管理是否存在问题？提出如何解决的咨 询建议。
23.3.2南方电信项目案例
项目背景
中国新兴集团公司地处华南，是这几年新兴的、专门服务国内电信营运商的集团公 司。经过艰苦卓绝而又十分经典的一轮销售战役，新兴公司赢得了一个富有市场战略意 义的合同：为南方移动21个业务区开发并实施其网管系统。公司领导非常高兴，希望能 乘胜追击，漂亮地执行好这个合同，然后顺势拿下受这个合同影响较大的华南其他4省 的网管系统。
项目目标、任务
本项目为南方移动直放站和室内覆盖网管系统一期工程，目标是建立一个能够同时 监控各个厂家GSM、CDMA直放站、室内覆盖系统的网管系统平台，在2003隼2月～ 2003年6月底的4个月的时间里，接入包括全省21个业务区所有在网运营的直放站及 室内覆盖设备。整个工程以全省现有直放站及室内覆盖统一网管系统和2004年工程目标 的业务量为基础，并充分考虑将来的扩容需求。
网管项目实施过程中通过对网管中心功能的增强、对新设备网管功能的开通以及对 旧设备进行整改或升级，达到100%的接通率。
因为业务的需要，同时也是中国移动的要求，客户方非常重视这个项目。事前客户 方就按中国移动的规范再加上自己的技术要求拿出了一份本项目的技术规范，要求新兴 公司按该技术规范进行项目实现（简称该规范为《技术》，该规范是合同的附件），同时 也要求新兴公司对该项目配备足够的资源，做好项目管理，务必按约定的时间使新系统 上线使用。客户方指派处长郭军负责协调这个项目。
新兴公司（以下简称“公司”）委任了王东为项目经理，王东的部门经理张廷为项目
第23章案例分析 531 总监。张廷是公司工程部的经理，也是公司的元老之一。工程部是负责合同实施的部门。项目组的初始成员由工程部的5位工程师和研发部的3名工程师组成。公司项目管理部 派了一位QA负责质量方面的管理工作。按公司平常的工作规程，各部门跟本项目相关 的责任如下。
·工程部：总体负责合同执行、项目实施，包括软件部分和接入部分。
·研发部：负责协助网管软件的定制。公司在电信网管方面有较好的积累，研发部
是公司原网管解决方案的开发部门。
·项目管理部：负责指导和监督各项目的项目管理工作。
·销售部：负责销售及收款工作，在项目过程中篇要一定程度配合项目实施小组的 工作。
·商务部：负责设备和外购软件的采购、发货以及外包服务的选择等商务运作。本
合同在本项目中需要从国内外采购一批网络设备。
1．项目计划部分
被委任为这个项目的项目经理后，王东心理有点复杂。一方面是因为接了一个比较 重要的项目、公司领导根重视所以比较*奋；另一个方面，他对项目感觉没底，心里有 点儿空荡荡的。王东对网络还算熟悉，但对软件编程不是很熟，自己觉得只能算还行。进公司快两年了，对公司的运作制度和项目管理制度也算比较熟悉，项目做过好几个，也算是有～定经验的项目经理了。
王东的回忆：
知道我负责这个项目后我比较关心的是项目的时问要求和人员问题。项目合同我大 致看过，时间已经定死了，4个月，6月底要上线。人员方面给我派了本部门的4人和研 发部的3人。我们需要完成什么工作呢？软件开发扣2 1个业务区的接入，按《技术规范》 徽，4个月的时问连我在内8个人能完成吗？说实话，这就是我一心里最没底的 地方。
这个项目的工作范围应该是明确的、固定的，《技术规范》我还没看过呢！但这么多 工作4个月是否能完成可能谁也不清楚，这“4个月”是销售部门跟甲方商定的，估计 甲方有要求有压力，而销售部想起来觉得也差不多就定下来了，事前工程部一点儿都不 了解；8个人够还是不够呢？谁都不清楚，没有概念。我还是先做项再计划吧。
公司里有一套项目管理的制度，按照项目计划模板去填就可以了，我花了差不多一天多按以下顺序填好了计划模板中的各主要部分。
·项舄概迷和约束。
·项目组织和报告渠道，·项目过程和方法。
.WBS。
·项目规模、工作量估计．
·进度计划。
(1)项目概述和约束
①关于项目目标没有太多需要考虑的地方，这些目标之类我都是基本上照抄我上一 个项目的相同内容。客户／用户的内容也很简单。
⑦关于软件总体功能描述在（（技术规范》里都有，我只写了一句话概括了网管的 功能。
③关于主要约束，我主要写了进度约束。
·需求分析：2003.2.17-2003.3.7
·总体设计：2003.3.10-2003.3.31
·详细设计：2003.4.1-2003.4.30
·编码：2003.5.7-2003.5.31
·测试：2003.6.1-2003.6.30
·初验：2003.7.1
·终艟。：2003.9.20
本项目不存在成本和资源约束。
④本项目与公司其他项目和部门没有依赖关系。
(2)项目组织和报告渠道
①我分了两个组：软件组和网络组。软件组由李鹏负责，网络组由我负责。
⑦我把以下各角色的责任都描述出来了。
·项目总监（张廷）
·项目经理（我）
·软件组长（李鹏）
·网络组长（王东）
·项目支持（李克明，主要负责质量保证）
③报告渠道。
·项目组周例会，项目组内每周召开。
·给客户的双周报，向客户即甲方汇报项目情况。
·项目报告，每双周向公司江报项目情况。
(3)项目过程和方法
①在软件方面，我们按常规的软件瀑布型过程进行开发，其他没有特殊的技术 方法。
②因为开发工作时间有限而且看起来不复杂，我裁剪了代码走查、弱化了总体设计、详细设计、单元测试和配置管理的工作。
(4)工作交付物及WBS
①项目的最终交付物是可正常运行的南方省级网管系统及相关文档，包括如下
内容。
·网络系统软件的可执珩印洒。
·系统技术手册。
·合同规定由我方提供的设备。
·达到氍技术规范》要求的网络系统。
@按项目的时问顺序，按照想象中的一件件工作我基本上分解出项目的工作分解结 构。每件工作我都标注上其输出，走部分工作都在三五天以内，少数是10天左右．软件 部分的工作基本土是接软件开发生命周期进行分解的，接入部分的工作基本上按各地区 工作的时序进行分解。
(5)项目工作量估计
有了WBS估算项目舰麒和工作量就比较方便了。先为每一项子任务估算一个工期和 占用的资源，然后可以很容易地累加出总工作量。不过，既然总工期已经定死了是4个 月，那我定义的各任务的时间都是从速一最大的约束出发凑出来的。
(6)进度计划
按第一项的进度约束我定叉了几个里程碑。
(7)其他
因为还有风险日志，所以我不需要在项目计划中针对风险作什幺计划，等项目启动 后，接风险日志的格式再处理也不迟．
有了计划棋板，项目计划确实好做多了，不过对这个项目而言有不少地方我还不太 有把握，例如WBS、任务工期及进度安排、资源安排、项目工作量等。但因为有横叛的 格式，我还是按大致的估计填上了些内容，总不能空着。
王东把项目计划提交给都门经理张廷和公司项目管理部。
张廷拿到这份计划，他最关心的是能不能按公司领导的时间要求完成这个项目。从 进度安排方面看，蜃后的完工日期是符合合同要求的，这份计划没问题。另外，从组织、责任、沟通渠道、工作交付物和WBS等方面基本上都是常规的一些内容，每个项目大 体上都是写这些内容，也都看不出有什么问题。他问了一下王东：“做好这个项目没什么 问题吧？公司高层领导可是很重视的啊。”
王东也想不出有什么重要的问题，就说：“现在项目还没开始，也没什么问题。时间 方面现在心里没底，我努力争取吧。人员方面以后要是有什么需要还请老总您老人家多 支持l"
张廷说：“您千万别}现在每个项目都很紧张，能给你抽出8个人已经很不容易了，你知足吧！”
公司项目管理部小林问了张廷对这个计划有什么意见，张廷说没有。小林看看项目 计划的格式、内容基本符合要求，而且部门经理也没意见，就批准了这份项目计划。
按项目计划，项目软件部分的第一大项工作是进行需求分析。这方面工作王东让软 件组长李鹏全权负责。甲方这边的负责人郭处让他手底下的小凌负责跟李鹏来谈软件需 求。小凌和另外两位甲方的人员针对未来的网管系统各个功能分别提出他们的想法，李 鹏他们就逐一跟他们谈逐一作记录。虽然谈需求进行得不是很有规律，但是最后需求分 析还是按时完成了，得到了一份关于该项目网管系统的需求说明书。该说明书对系统的 各个功能、使用方法都提出了要求，有些要求非常具体。
李鹏告诉王东说这份需求文档的内容虽然有些方面提得比较细，但有不少地方跟《技 术规范》不一致，想商量商量怎么处理。最后他们觉得这份需求有些地方是对《技术规 范》的发展，有些地方是细化，体现了甲方现在对网管系统的实现要求，与其到测试或 验收时再处理，还不如现在就考虑。王东把需求文档提交给了甲方请他们审阅。
设计、编码工作基本是以需求文档为基础而进行的。
项目工作铺开后，大家才发现项目的工作没有原来计划的那么简单，有些工作在原 WBS中是没有的，还有不少工作是计划外的，这都占用了项目成员的很多精力。王东习惯性地感叹：“意外太多了！怎么我们做的每一个项目都有这么多意外，原来做出来的计 划就没有办法顺利地执行下去，计划没有变化快啷】”这样，项目计划就没办法按原来的 进度要求走下去了，原来每个人的正常工作节奏全都被打乱了，每个人都很忙。
关于接入部分的工作，王东去了南方某省需要接入的好几个地方才发现甲方各地准 备工作根本没准备好，这将会严重地影响整个项目的进度，而这些准备工作原本是新兴 公司希望甲方在接入工作开始前就做好的，甲方也曾说他们将负责把各地所有的接入准 备工作都做好。王东问各地的相关负责人这个项目的工作怎么安排，负责人的回答大同 小异，基本上都说省局为这个项目召集他们开过会，具体的工作也都考虑过或做过一些 工作，不过现在工作特别忙，有部分工作也没顾上，有些人还说曾想好好完整地规划好 要做的所有准备工作，但也不清楚准备工作具体都需要做哪些。王东又打电话问负责这 个合同的销售代表老杨：“关于接入的准备工作当初跟甲方是怎么定的、怎么交待的？” 老杨说：“哎呀小李，你不找我我还想找你呢，签完合同就不知道这个项目怎么样了。你 说各地市的接入准备工作吗？他们说是他们负责的呀，我就没多管，你是不是该督促他 们一下啊？”
接入工作的进展也影响到了软件开发的工作，按原计划到5月中旬应该可以进行软 件调试的网络环境没按时就绪。
按王东的项目计划研发部虚该在4月初额外派3个人来三、四天帮他们解决一个技 术问题。时间到了4月初研发部却没动静，王东急了，打电话问人怎么还不过来，研发 部经理诧异地问：“你什么时候跟我说过这事？”王东说：“我都写在计划里了！计划也 发给过你了！”研发部经理说：“每天文件这么多，我怎么可能把你的每一个字都细看 呢？”
还有一件更麻烦的事：公司为甲方所订购的一批网络设备到货时间将会耽误项目的 进度，国内供货部分还好一点，国外供货最晚的要到7月中旬左右才会到货。王东又感 叹：“天不助我啊！”
王东每两周都会跟郭处沟通一次项目的情况，郭处知道了设备到货时间的问题后问 王东：“你们公司没有去考虑过这个问题吗？”
5月22日，甲方高层领导来到开发现场听项目组的汇报并观看系统演示，为了表示 重视，公司领导和张廷也来了。当时系统并没有完全开发完毕，大家只看到了主要的功 能模块。
看完后，甲方领导表达了意见。
(1)对项目的进度极不满意。
(2)系统演示出的功能与《技术规范》不一致，母后的验收将以《技术规范》为 标准。
(3)从项目前阶段的工作过程可以看出新兴公司投入到项目中的资源不足，希望新 兴公司领导充分重视该项目。
(4)为对项目的沟通和监督，从当天开始甲方将每8个工作日来现场听取项目汇报 并观看演示。
公司领导对甲方的意见非常意外，立即让王东汇报项目情况。王东的汇报中提到了 资源不足。领导问项目组的8个人他是怎么使用的，王东说从项目开始到现在他们都很 忙。领导无话可说，又问王东要增加多少人，王东说估计4人左右。领导说虽然公司很 重视这个项目，但现在公司资源非常紧张，需要王东详细规划出这4个人怎么使用的一 个计划然后再审批。王东觉得这样很麻烦，本来项目工作就很多，还要把耐间浪费在这 种形式化的表面文章中，但俗话说胳膊不能跟大腿拧、好汉不要跟领导顶，还是简单写 了这4个人各分配哪个方向的工作作为计划交了上去。
在随后的几次汇报中，甲方领导在观看软件演示时多次提出了修改意见。对于这些 意见李鹏提出这属于项目范围变更，要求按变更来处理。但郭处说这不是范围变更，软 件功能本来就该做成这样子，是开发组理解错了，不存在变更不变更的问题。为了能够 说服郭处，李鹏和王东详细查阅了《技术规范》，结粜悲观地发现在很多地方《技术规范》 并没有清楚描述要做成什么样，所以报难判定甲方的意见是不是属于变更。既然是这样，就只有满足甲方的要求了。
项目的麻烦开了头就刹不住，估计项目的时间目标是不可能实现的了，不知道客户 的高层领导和公司的高层领导要怎么着急呢，唉……
现在回过头来看项目的计划，王东觉得这项目计划其实真的没什么用，项目是活的 计划是死的能有用吗．}还不如不做！只不过公司有制度，不做不行罢了。
2．项目执行保障部分
客户领导的意见让公司领导对这项目异常重视，几个人陆续派来了。
关于设备到赞的问题，公司领导责成公司商务营运部门抓紧催货。没到货之前怎么 办昵？张廷召集相关的人开会，大家出谋划策，决定从公词和客户两边先凑或借部分可 用的设备，在佛山先建一个示范点，把示范点的做法制定为规范，等设备到货后再COPY 到其余20个点，这样能大大地节省后期接入工作的时间。经与甲方商量，甲方很赞成，之后示范点设备的筹集很顺利，随后的示范点接入和调试工作也都很顺利。
王东又感叹了：“还是客户的力量是无穷的呀！以前关于这些问题我也给张廷写过周 报，我写过可能会有设备到货时间的问题，会有资源不足的问题，会有需求变更的问题，但都是石沉大海，现在客户领导一发话问题解决得真快！”
王东的回忆：
项目的气氛紧张了很多，由于巨大的进度压力，我规定全体人员每天都加班到晚上 9点半以后，周末也不休息。连续加班一段时期之后大家好像非常疲惫，全组人员一起 吃饭时话也不太多了，情绪变得不高了，积极性、工作效率等各方面都明显下降了。
以前项目组开周例会大家还挺积极，七嘴八舌地提出不少建议，而现在大家无精打 采没什么话，除了王耕田偶尔发发牢骚或讲个段子。真是无可奈何：既然大家都这样，干脆以后周例会也别开了，我每周大致问一下大家的工作情况就算了，反正大家都忙，顶多是我一个人多辛苦点，辛苦我不怕。
我发现如果以各项目成员为节点画一张项目信息流劫的示意图，有些人好像会成为 信息的“梗阻”，个别人居然趋向于成为“孤岛”。不过，我觉得人的性格是很难说的，强求大家都像王耕田那样特爱说话也不可能。
管人真是麻烦！这些问题让我作为项目经理很难做工作，公司对项目的支持还是不 够，公司应该把人管理好，这些人才能为项目服务好。
李鹏的回忆：
详细设计、编码和单元测试工作的结果让我不满意，客户也不太满意，项目进度也 被拖延不少。王东和我一分析原因，觉得其中很大一部分原因是项目组里有几个成员不 太熟项目所用到的开发技术，无论是测试还是编码问题都比较多，工作的反复比较多，表现也不专业，设计写出来五花八门、各有各路，编码更是天女散花，要多花有多花，急得我恨不能上去自己把所有工作全都做究。王东安慰我说公司派来的人也不可能所有 的都是高手，这也是正常的，我们自己不能急，习惯了就好了。
来自公司研发部的人让王东觉得不好管理，他们中的部分人是身兼数职的，我们都 能看到，有时候他们会回公司忙他们别的工作，有时候他们人在项目现场但不停地为了 别的事情打电话。都是为了忙公司的事情，大家都能体谅。但有一次我觉得心里不舒服： 软件的总体设计是请研发部的肖大跃做的，大跃是“大拿”，那段时间同祥是特别忙，匆 匆忙忙花两天时间做出总体设计来，文档中以前项目的“痕迹”都没删干净。本来我觉 得在设计评审时QA和大家可能会找出不少问题来，但这个QA没经验，评审前没让大 家认真阅读，我觉得参加评审的人员里阅读了一小时的都算不错的了。评审时因为有人 马上要出差所以很快就过了一遍，两小时都不到！除了改了改笔误、删掉原来的一些不 该出现的“痕迹”外没谈出什么大问题来。另外，大家有一个心态觉得这是大跃的东西 应该没什么问题，大跃可是多大多复杂的系统都做过的“大拿”！但我怀疑这次大跃可能 连伐技术规范>都没细看。后来事实还真证明我的怀疑是对的，客户在测试的时候发现 我们的功能跟程技术规范》不一致，我们追根溯源一查，原来是大跃的设计照着旧系统 做的，没考虑这个项目的要求．唉，耽旌我们一个多星期的时间啊。
说到这个QA，我还觉得有点不明白，设了QA他就应该把项目质量方面的事情全 都管理起来对吧？但他全都管得了吗？他还是要我采负一些责任，还说我没尽到责任！但我到现在也没整明白在质量方面有哪些责任是该我负的，我也不清楚我具体负责的需 求，设计、编码、测试这些过程里质量该怎么管。他说他的项目质量计划里写到了，我 怎么就觉得那玩意儿是个形式呢？没有用！
甲方的小凌对小周所做的模块不满意，王东本来就对小周不满意，于是详细了解了 小周的工作情况，感觉小周虽然聪明但不踏实，有些工作该做但没做得很好，有些工作 虽然不起眼但他该做没做。王东直截了当地对小同提出批评了。小周报不服，说：“说我 该干没干？可我头到尾没有清楚地得到过指示要我去做哪几件事情，跟我交待过我要负 责这一块，可是领导，这一„块‟到底多大谁知道啊?您认为我该做什么最好跟我明确 出来，要不然我根难猜。说我没干好？„好‟到什么程度能不能也一起告诉我？再说了，那些做得慢的您怎么不去考核一下？要是大家都考核，我应该还算好的呢！”
小周还提到了让王东和李鹏不太好回应的一件事：正是因为他们俩决定把单元测试 和系统测试的部分工作简化了才导致了后来出现的一些莫名其妙的问题。当时他们也是 想赶进度，没想到现在省不了时间反而为了查找和排除这些问题费了几倍的时间。什么 叫偷鸡不着蚀把米？嘿嘿【王东从小周的眼神里看出了这个意思。
对小周的批评屉后也只能不了了之了。
让王东觉得比较麻烦的还有客户。客户是上帝，上帝是给钱的人，上帝随便咳嗽一 声也绝对要注意听着；客户．还是合作者，没有他们配合项目的工作不可能完成。不想不 知道，一想就发现项目里有很多事情需要客户（或协调第三方厂家）去做而且他们能做 得好的，例如：
①提供各地的设备类型、数量、监控状况和监控协议。
@对不符合统一协议的c网设备进行整改和升级。
@提供整改后的各地区需接入的站点信息。
④提供可联调的实际站点。提供联调配合计划。
⑤对被接入的设备进行接入联调，并提交联调报告。
@外挂监控站点的接入实施工作。
让王东头疼的是客户经带不做好他们该完成的工作。下面这些是郭处、小凌或客户 的其他人让王东经常头疼的话。
(1)“最近太忙，上周说的事还没顾上。哎你们这边差不多了吧，培我看看！”
(2)“下周一要三个人配合测试？你怎么不早说？今天都周四了，我们怎么来得及安 排人手出来啊？往后推一周吧？”
(3)“这种事也要我们做？你们这么熟，人又这么多，顺手一弄就完了，啊，就这么 定了吧。”
(4)“这事我这种小兵管不了，我负不起这责任，你们还是找我们领导去吧！”
(5)“那是使用部门的事，跟我没关系，你找他们吧……”
对这些话，王东都不知道怎么对付才好。
项目的压力超乎寻常地大，客户每8个工作日的检查对项目组来说是个很大的负担，而不是能解决问题的帮助，部门经理张廷和公司项目管理部经常追着问项目进度。
每天都有新的问题涌来、每天都有新的压力，来自客户的、来自公司的、来自项目 组成员的，进度方面的、资源方面的、技术方面的、乱七八糟方面的l面对这些铺天盖 地而来的信息、问题、压力，王东觉得再下去就要崩溃了！
王东感叹的是为什么每一个项目都不顺、都这么麻烦，是自己运气不好？公司的问 题？还是行业、客户的问题？
3．项目控制部分
项目一开始公司领导和部门领导就一直希望这个项目能按目标完成，目标显然不可 能达到时又寄希望于修订后的目标能够达到。项目经理被要求努力地去控制好项目以达 到各方面的目标。
王东的回忆：
一个事先没有预料到的情况严重地干扰了项目的进展：甲方颔导每8个工作日的视 察有时满意有时很不满意，但不管怎么样都会提出一堆意见和要求，这样好那样不好，要这样下次别让我看到那样等等。项目有项目原来的进度计划，每天干什么都有安排，而为了满足这些要求原来的安排全都被打乱了。甲方提出的这些意见有的跟《技术规范》 一致、有时不一致，一开始我和李鹏还想部分顶住，但因为甲方领导层次较高，我觉得 他要是震怒可能公司领导又会很紧张，同时也不希望因为我不同意满足甲方的要求让甲 方向高层领导投诉，这样会让我很被动。
这种对修改要求的满足一旦开始就很难停止，这样项目就陷入了很被动的循环，刚 把上次的要求改好了，想回复正常的开发节奏，新的一轮又开始了。这让我觉得就像转 轮里的小白鼠，自己永远不知道什么时候是尽头，直到累死为止，而外人觉得你在干你 该干的事情。
变化永远都在发生，这是极其讨厌的事情，说实话，我现在很怕听到这种坏消息，但这种消息从项目一开始到后来还是很多。
(1)网络设备到货比预期晚。
(2)甲方的接入准备工作没做好。
(3)甲方的开发配合工作没按计划做好。(4)项目资源的可用性发生变化。(5)技术难题的难度超乎意料。
这些变化只要一出现就让我们没办法按计置|j走下去。
公司要求我控制的两个最重要的方面是项目进度和项目成本。
美于项目成本，我也想控制，但我实在不知道除了控制项目赧艄费用外还有什么措 施可用，反正项目费用预算的总额现在还没超，除了这一点其他的情况都无法判断，所 以也就没办法控制。
关于项目进度控制，我现在觉得是一个很虚无缥渺的事情，讲得实在一点就是：如 果项目没有意外，项目的进度你就能控制得住，有了意外你就控制不住，就这么回事！
另外，公司让我们每个月都要进,f带-值分析，累死人又没有用，唉……
关于项目周例会：项目组一开始还开周倒会，例会内容有如下两项。
(1)每人汇报上周的工作情况，有没有完成任务。
(2)确定下周工作的任务安排。
后来周例会也不开了，基本上都由王东依次问大家的工作情况再安排一下下周的 工作。
张廷觉得这个项目各方面似乎都处于失控状态，问王东他对项目都有哪些控制措 施，王东说了一堆，张廷觉得都没到点子上。他问王东：“你觉得项目怎么样才能控制得 住？”
王东觉得不好回答，想了一想说：“第一要防止意外发生，第二要靠运气!”
这个项目确实基本处于失控状态。
在进度方面，原计划是7月1日初验，后来改成8月10日，然后再改成10月8日，然后……里程碑目标一拖再拖，眼看目标显然不可能达到就又把进度目标修改一次，每 次都有客观原因（公司项目管理部事后总结发现，要求进度目标延期或项目预算增加的 每一个项目都有绝对充分的理由、都有一大堆客观原因）。
在项目费用方面，报销的费用倒是不多，但整个公司里谁也没概念：这个项目现在 已经花了多少钱，还允许项目可以再花多少钱。
在项目质量方面，一句话就可以概括：时间和资源换质量。各个环节都出了不少问 题，大部分问题是用人和时间去换的，小部分问题就算了，以后再说了，顾不上了。
最后，项目在12月5日终于通过初验了。涉及到这个项目的所有人好像都舒了一 口气，但没有人有多少笑容。本来所有人对这个项目的期望值都挺高的，但现在落差太 大了。项目的成本远远超出了预算，无法不超，因为拖延了这么长时间、增加了这么多 人。王东知道的只停留在超出预算的数字上，但公司领导考虑的是：这个项目我们赚到 钱了吗？我们赔了多少钱？以后这种项目还能做吗？
各位项目成员也不开心，辛苦了这么长时间，项目没有一个值得大家高兴的结果，
第二篇：2012下半年系统集成项目管理工程师_案例分析(掌中宝)
六、历年考点分析
考核的题型主要是采用“原因题”与“方法题”的模式，即问题1要求找出问题产生的原因，问题2提出解决问题的方法，比如，试题一种问范围管理存在的问题，接着问项目经理该如何办（从项目经理的角度提出解决问题的方法）。
通过上表的分析，我们可以得知进度管理考了4次，整体管理考了4次，质量管理考了4次，合同管理考了2次，成本管理考了4次，范围管理考了3次，配置管理考了2次，风险管理考了1次，服务管理考了1次，收尾管理考了1次。其中本人2011年5月对案例分析进行了押题，押了7个，命中5个，本人将在2011年11月考试中继续押题，敬请大家期待！
在进行案例分析答题的时候，遇到自己不会做的，也要写点东西，另外，案例的评分标准是达到点子上就有分的！还有，比如标准答案只有4条，你答了6条，只要多答2条，没有理论错误，都是不影响的，因此，我建议大家在答题的时候，可以尽量的多写。前提是不能违背理论知识。本人觉得，案例分析的考察也是对基础知识的掌握进行一个评测，只是出题的方式不一样而已，因此，我建议大家一定要掌握好基础知识，总以为上午选择很容易，忽悠了基础知识的学习，其实，我建议大家一定要认真学习好基础知识，基础知识掌握好了，不管是以选择、还是问题、又或是填空的形式出现，这都是没有问题的，万变不离其宗！
七、案例分析要点
（1）可行性研究---------不是重点，建议不做过多的学习！１．主要内容
１、技术可行性分析；２、经济可行性分析；３、运行环境可行性分析；４、其他方面的可行性分析，如法律、社会道德等 ２．可能产生的原因
１、没有进行系统的可行性分析；２、调研不充分，不了解该技术是否成熟；３、没有调研国家政策或法律法规是否允许 ３.可能遇到的风险
１、技术风险；２、政策风险；３、市场风险（２）整体管理－－－－重点，一定要弄懂！整体管理工程负责项目的全生命周期管理、全局性管理和综合性管理。全生命周期管理意味着项目整体管理过程负责管理项目的启动阶段直到项目收尾阶段的整个项目生命周期。全局性管理意味着项目整体管理过程负责管理项目的整体包括项目管理工作、技术工作和商务工作灯。综合性管理意味着项目整体管理过程负责管理项目的需求、范围、进度、成本、质量、人力资源、沟通、风险和采购、根据每个项目的实际情况，项目整体管理的重点随项目的不同而有所变化。项目整体管理知识域包括保证项目各要素相互协调以完成项目所需要的各个工程。主要包含： １.项目启动
１）制定项目章程
输入：合同 工作说明书（ＳＯＷ）组织过程资产 输出：项目章程 ２）选择项目经理
２.制定初步范围说明书 输出初步的项目范围说明书 ３．项目计划管理
１）项目计划制定 输出：项目管理计划 ２）项目计划执行
３）指导和管理项目执行 ４．整体变更控制 ５．项目收尾
包括合同收尾和管理收尾。合同收尾就是按照合同约定，项目组和业主一项项的合规，检查是否完成了合同所有的要求，是否可以把项目结束掉。也就是我们通常所讲的项目验收；管理收尾是对于内部
来说的，把做好的项目文档等归档，对外宣称项目已结束，转入维护期，把相关的产品说明书转到维护组，同时进行经验教训总结。历年考了：
项目不能收尾的原因，促使验收要采取的措施，公司应采取的管理手段？ 项目整体管理计划的内容，项目整体管理中存在的问题及补救措施？ 如何做好整体管理应该从下面着手，大家考试的时候可以根据案例中主人公的做法和题目要求选择几点进行回答：
１、建立企业级的项目管理体系和工作规范，管理上不乱 ２、明确可交付物
３、培训学习项目管理知识，提高管理能力 ４、做好经验的总结，和各项计划 ５、做好整体管理，项目过程
６、加强变更管理与控制，建立变更流程与体系 ７、要有项目启动―――可行性分析 ８、要制定项目章程
其中，整体管理还有可能会和配置管理一起考 １、可能出现的问题
１、缺乏项目整体管理和权衡；２、缺乏变更管理控制规程；３、缺乏项目干系人沟通；４、缺乏配置管理；５、缺乏整体版本管理；６、缺乏各种单元测试和集成测试； ２、主要内容
１、制定配置管理计划；２、配置项识别；３、建立配置管理系统；４、基线化；５、建立配置库；６、变更控制；７、配置状态统计；８、配置审计 ３、应对措施
１、针对目前系统建立基线；２、梳理变更脉络，确定统一的最终需求和设计；３、梳理配置项及其历史版本；４、对照最终需求和设计逐项分析现有配置项及历史版本的符合情况；５、根据分析结果由干系人确定整体变更计划并实施；６、加强单元接口测试与系统的集成测试或联调；７、加强整体版本管理
（３）范围管理――――重点，一定要弄懂！
范围管理确定在项目内包括什么工作和不包括什么工作，由此界定的项目范围在项目的全生命周期内可能因种种原因而变化，项目范围管理也要管理项目范围的这种变化。项目范围的管理，是通过５个项目管理过程来实现的：
（１）编制范围管理计划：制定一个项目范围管理计划，以规定如何定义、检验、控制范围，以及如何创建与定义工作分解结构。
（２）范围定义：这个过程给出关于项目和产品的详细描述，这些描述写在详细的项目范围说明书里，作为将来项目决策的基础。
（３）创建工作分解结构：将项目的可交付成果和项目工作细分为更小的、更易于管理的单元。在项目范围管理过程中，最常用工具就是工作分解结构（work breakdown stniture ,WBS）.工作分解结构是一种以结果为导向的分析方法，用于分析项目所涉及的工作，所有这些工作构成项目的整个工作范围。WBS为项目进度管理、成本管理和范围变更提供了基础。
（４）范围确认：该过程决定是否正式接受已完成的项目可交付成果。（５）范围控制：监控项目和产品的范围状态，管理范围变更。１、如何定义范围？
项目范围的管理就是根据客户目标形式系统功能，并经过用户确认的过程。范围管理是保证对项目应该包括什么和不应该包括什么进行相应的定义和控制。涉及定义和控制哪些是项目范畴内的，哪些不是。功能需求不是由客户或用户提供的，是项目组成员在理解目前的人工作也后分析出来的结果。
２、范围管理的基本内容：确定项目需求、定义规划项目范围、范围管理和实施、范围的变更控制管理以及范围核实等。
３、范围说明书和项目章程、合同的区别：
章程是项目的组织管理文件，章程规定了项目的立项、组织、权限等，范围说明书详细说明了为什么要进行这个项目，明确了项目的目标和主要的可交付成果，是项目班子和任务委托者之间签订协议的基础，也是未来项目实施的基础，并且随着项目的不断实施进展，需要对范围说明书进行修改和细化，以反映项目本身和外部环境的变化。在案例考试中可能会出现这样的情况：
1、没有挖掘到全部隐性需求，缺乏精确的范围定义；
2、没有有效的范围管理，造成二次变更；
3、没有对风险进行有效管理；
4、没有对质量进行有效控制；
5、对范围控制不足；
6、没有和客户进行需求确认
针对可能出现的问题，那么，我们应该怎么应对呢？（范围管理应对措施）--但是这只是一个比较综合性的措施，具体要根据案例中得具体情况进行具体的分析！
1、对项目范围进行清晰定义，并根据定义对工作进行分解，制定WBS；
2、对项目进行合理估算，对工作量有量化的把握；
3、对项目范围进行有效控制；
4、重新定义项目范围必须得到高层和客户的确认；
5、进行沟通管理，协调多个项目干系人之间的矛盾。（4）进度管理----重点，一定要弄懂 项目进度管理包括6个管理过程：
（１）活动定义：确认一些特定的工作，通过完成这些活动就完成了工程项目的各项目细目。（２）活动排序：明确各活动之间的顺序等相互依赖关系，并形成文件。
（３）活动资源估算：估算每一活动所需要的材料、人员、设备以及其他物品的种类与数量。（４）活动历时估算：估算完成各项计划活动所需工时单位数。
（５）制定进度表：分析活动顺序、历时、资源需求和进度约束来编制项目的进度计划。（６）进度控制：监控项目状态、维护项目进度及必要时管理进度变更。进度管理需要掌握的知识点： １、工作量及工期的计算； ２、制定网络图；
３、甘特图、里程碑图、网络图的区别； ４、PERT;５、如何优化工期；
６、跟踪项目进度的方法；
①要求WBS尽量细化，明确各项活动间的关系，画出正确的网络图（双代号或单代号网络图），制定出合理的项目计划；②要对项目计划的执行进行及时监控，并要有一个执行标准来及时纠偏；③设定项目的里程碑，对每个里程碑进行评审，以确定是否进入下一阶段；④要有一个好的变更控制系统来控制变更控制流程，做好变更管理；⑤要使用项目管理的工具软件，提高项目管理的工作效率。进度管理可能出现的问题以及可以采用的办法，其中还要注意可能会和成本一起考！１、团队成员没有及早参与，需求分析耗时长，要早起参与进项目
２、经验不足，进度计划制定不准，采取有效的历时估算方法和网络计划技术，制定进度计划 ３、考虑项目期间特定时期会对进度产生影响
４、增加人手，聘请更有经验的人员，或找兼职人员 ５、加班 ６、并行
７、重新估算后面的工期 ８、加强沟通，减少变更 ９、加强控制，避免返工 １０、外包
１１、加强沟通，先完成关键需求
１２、增加资源有时可能压缩工期有限
１３、关注关键路径，在关键路径上加资源，有效果 １４、关注里程碑
１５、加强进度与成本、风险、质量等知识点的协调
上面说了一下解决措施，但是一定要根据题目中得真实场景案例进行答题！
其中，下面的一些知识点，我建议大家也要掌握：
１、活动定义：为得到工作分解结构中最底层的交付物执行的一系列活动，对这些活动的识别以及归档的过程叫做活动定义。
工具：分解、模板、流动式规划、专家判断、规划组成部分
输入：工作分解结构、项目范围说明书、组织过程资产、项目管理计划
输出：项目活动清单是项目活动的主要输出，他列出了一个项目所需开展和完成的全部项目活动。项目活动清单是根据WBS通过进一步细化得到。
２、活动排序：确定活动之间的依赖关系，形成文档
工具：PDM（前导图，单代号网络图）、ADM（箭线图，双代号网络图）输入：项目活动清单、活动属性、项目范围说明书、组织过程资产 输出：项目网络图、更新的活动清单、更新的活动属性 ３、活动资源估算
工具：专家判断、自上而下的估算、估算软件 输入：组织过程资产、活动清单、资源可用性 输出：活动资源需求、活动清单（更新）４、活动历时估算
工具：专家判断、类比估算：以过去类似项目活动的实际时间为基础，通过类比来推测估算当前项目所需的时间、参数估算、三点估算：（乐观+4个正常+悲观）÷6 ５、制定项目进度计划
项目进度计划要经过多次反复调整才能最后完成，项目进度计划不变是相对的，而变化是绝对的。工具：CPM（关键路线法）--能够决定项目最早完成时间的一系列活动，他是网络图中最长路径，具有最好的浮动时间或时间差；PERT（计划评审技术）：活动时间期望值=（乐观+4个正常+悲观）÷
6、活动时间的标准差=（悲观-乐观）÷6：持续时间的压缩（缩短关键路径上的活动历时，可以采用赶工（费用交换），快速跟进（并行处理）等方式。资源对进度的影响
（１）一般情况下，项目活动历时与投入的资源数量成反比，即投入的资源数量越多，活动历时越短。但是，当针对某一活动的资源投入数量达到一定规模时，再增加资源的投入不会进一步缩短项目活动历时，也就是资源投入递减规律。
（２）非关键路径上的活动历时只对项目产生较小的影响或不产生影响，而关键路径上活动历时的延误，则会直接影响到项目工期。因此每当缩短项目工期时，应对首先考虑在关键路径活动上增加资源。
可以采用哪些方法来跟踪项目的进度，以确保项目能够按进度计划完成？
（1）基于WBS和工时估算制定活动网络图，制定项目进度计划；（2）建立对项目工作的监督和测量机制，依据项目进度基线和日常项目进展报告，比较进度偏差（SV）和进度效率指数（SPI），进行偏差分析；（3）确定项目里程碑，并建立有效的评审机制；（4）对项目中发现的问题，及时采取纠正措施，并进行有效的变更管理；（5）使用有效的项目管理工具，提高项目管理的工作效率。（5）成本管理-----重点，一定要弄懂
项目管理受范围、时间、成本和质量的约束，项目成本管理在项目管理中占有重要地位。项目成本管理就是要确保在批准的预算内完成项目。具体的项目成本管理要靠制定成本管理计划、成本估算、成本预算、成本控制等4个过程来完成，其中：
（１）制定成本管理计划-----制定了项目成本结构、估算、预算、和控制的标准。（２）成本估算----编制完成项目活动所需资源的大致成本。
（３）成本预算----合计各个活动或工作包的估算成本，以建立成本基准。（４）成本控制----影响造成成本偏差的因素，控制项目预算的变更。下面的一些知识点必须掌握： 1.成本估算
步骤：1）识别并分析项目成本的构成科目；2）根据已识别项目成本科目，估算每一成本科目的成本大小；3）分析成本估算结果，找出各种相互替代的成本，协调各成本科目之间的关系工具：类比估算法（专家判断）、自上而下估算法（优点：简单易行，花费小；缺点：准确性差）、自下而上估算
法（优点：准确性高；缺点：耗时，成本高）、参数模型估算法 输入：项目范围说明书、项目管理章程、WBS和WBS字典、风险事件 输出：成本估算结果、成本估算支持细节、更新的成本管理计划 2.成本预算
成本预算的作用：1）按计划分配项目资源，保证各项工作得获得需的各种资源；2）一种控制机制，对项目各项工作的成本预算记性适当的调整；3）为项目提供一把标尺，可以及时掌握项目的进度情况
输入：项目范围说明书、工作分解结构、WBS字典、活动成本估算、成本管理计划 输出：成本基准 项目资金需求 请求的变更 更新的成本管理计划 3.成本控制
成本控制的主要目的是分析造成实际成本与成本基准计划发生偏差的因素并采取纠正，确保其向有利的防线发展
成本控制的内容：监控实际成本与计划成本的偏差、确认费用偏差都被记录、避免不正确不合适或者无效的费用变更发生、对发生成本偏差的工作包实施管理，有针对性采取纠正措施、防止因成本控制引起的项目范围、进度和质量方面的问题
输入：成本基准、绩效报告、变更请求和成本管理计划
输出：修正的成本估算、预算更新、纠正措施、变更需求、经验教训
工具：成本变更控制系统（申请成本变更，批准成本变更，变更成本预算）、绩效预测、项目绩效评估、偏差分析、趋势分析、挣值分析、计算机辅助 PV（计划值)：计划工作的预算费用
AC（实际成本）：已完成工作的实际费用 EV（挣值）：已完成工作的预算费用
ETC（剩余工作的成本估算）：=总的PV-已完成的EV CV（成本偏差）：CV=EV-AC CV﹥0 成本节约 CV﹤0超支
SV（进度偏差）：SV=EV-PV SV﹥0 超过进度 SV﹤0落后进度
CPI（成本绩效指数）：CPI=EV/AC CPI﹥1 成本结余 CPI﹤1成本超支 SPI（进度绩效指数）：SPI=EV/PV SPI﹥1 进度超前余 SPI﹤1进度滞后 完工估算（EAC）
公式1：EAC=AC+ETC（实际支出+剩余工作的新估算）
适用情况：过去的实施情况表明原来所作的估算彻底过时，条件变化，原来的估算不合适 公式2：EAC=AC+BAC-EV（实际支出+预计完成项目的总成本-已完工作的预算）适用情况：未来的实施不会发生类似的变化 动态投资回收期：
（累计净现金流量折现值开始出现正值得年份数-1）+（1-上年累计净现金流量折现值/当年净现金流量折现值）
投资收益率=1/动态回收期*u65297*0.0% 项目成本失控原因
项目成本控制工作是在项目实施过程中，通过项目成本管理尽量使项目实际发生的成本控制在预算范围之内。如果项目建设的实际成本远远超出批准的投资预算，就表明出现了成本失控。发生成本失控的原因主要以下几点。
（1）对工程项目认识不足：
①对信息系统工程成本控制的特点认识不足，对难度估计不足。
②工程项目的规模不合理，一个大而全的项目往往导致工期很长，而且导致工程实施的技术难度太高，导致技术人员的投入方面跟不上工程建设的需要，并且建设单位各部门对信息系统工程的接受能力和观念的转变跟不上信息系统建设的需要。
③工程项目的设计人员和实施人员缺乏成本意识，导致项目的设计不满足成本控制的要求。
④对项目成本的使用 责任感，随意开支，铺张浪费。（2）组织制度不健全
①制度不完善
②责任不落实。缺乏成本控制的责任感，在项目各个阶段和工作包没有落实具体的成本控制人员
③承建单位项目经理中没有明确的投资分工，导致对投资控制的领导督查不力。（3）方法问题
①缺乏用于项目投资控制所需要的有关报表及数据处理的方法。
②缺乏系统的成本控制程序和明确的具体要求，在项目进展不同阶段对成本控制制度的要求不明确，在项目进展的整个过程中缺乏连贯性的控制。
③缺乏科学、严格、明确而完整的成本控制方法和工作制度。
④缺乏对计算机辅助投资控制程序的利用。
⑤缺乏对计划值与实际值进行动态的比较分析，并及时提供各种需要的状态报告及经验总结。（4）技术的制约
①由于进行项目成本估算发生在工程项目建设的早期阶段，对项目相关信息了解不深，项目规划设计不够完善，不能满足成本估算的需求。
②采用的项目成本估算方法不恰当，与项目的实际情况不符，或与所得到的项目数据资料不符。③项目成本计算的数据不准确或有漏项，从而导致计算成本偏低。
④设计者未对设计方案进行优化，导致项目设计方案突破项目成本目标。⑤物资或设备价格的上涨，大大超过预期的浮动范围。⑥项目规划和设计方面的变更引起相关成本的增加。
⑦对工程实施中可能遇到的风险估计不足，导致实施成本大量增加。信息系统的项目成本估算的困难主要包括： １）需求信息的复杂性。
２）开发技术与工具的不断变化。
３）缺乏类似的项目估算数据可供参考。４）缺乏专业和富有经验的人才。
５）信息系统研发人员技术能力的差异。
６）管理层压力与误解在对项目成本估算时，应该避免以下的常见错误：①草率的成本估算。②在项目范围尚未确定时就进行成本估算。③过于乐观或者保守的估算。（6）质量管理----重点，一定要弄懂
项目质量管理包括了确保项目满足其各项要求所需的过程。他包括了担负全面管理职责的各项活动：确定质量方针、目标和责任，并通过质量策划、质量保证、质量控制和质量改进等手段在质量体系内实施质量管理。
项目的质量管理可以分解为质量策划、质量保证与质量控制三个过程。
质量策划是指确定与项目相关的质量标准，并决定如何达到这些质量标准。
质量保证是定期评估总体项目绩效的活动之一，以树立项目能满足相关质量标准的信心。质量控制是指监控具体的项目结果以判断其是否符合相关的质量标准，并确定方法来消除绩效低下的原因。
整个项目质量管理过程可以分解为以下4个环节：（1）确立质量标准体系
建立适当的质量衡量标准是进行项目质量管理的前提性的关键性工作。根据企业在实施项目方面的整体战略规划与项目事实上计划，实施项目的主体企业首先要确立衡量项目质量的标准体系。衡量项目质量的标准一般包括项目涉及的范围、项目具体的实施步骤、项目周期估计、项目成本预算、项目财务预测与资金计划，项目工作详细内容安排、质量指标要求以及客户满意度等。需要注意的是，项目质量指标体系一定要具备完整性、科学性与合理性，项目实施各相关主体应该事先进行讨论与沟通，以保证其完整、无漏洞，又具备较强的可实施性。（2）对项目实施进行质量监控
要在项目执行过程中采取有效措施来监控项目的实际运行。在项目实施过程中，根据要求收集项目实施过程中得相关信息，观察、分析项目实施进程中得实际情况以便监控。为了达到有效监控项目的目的，可以利用的监控措施与沟通渠道包括：①正式的监控与沟通渠道，例如项目进度报告、项目例会、里程碑会议、各种会议纪要等。②非正式的监控与沟通渠道，例如与项目小组成员或最终用户进行交
谈与讨论，与企业管理层进行非正式的交流等。
在这个环节上，要根据项目质量标准体系的要求，通过有效的监控措施和渠道，全面、客观地跟踪及反映项目实施的实际情况。（3）将实际与标准对照
把项目实施过程中的实际表现与项目质量衡量标准进行比较，分析出差异。在监控与跟踪项目实际运行状况时，往往需要解决这样一些问题，比如，“项目进展如何”“如果发生了项目假话执行结果与质量标准偏离的情况，是如何造成的”等。通过对项目实施相关衡量指标的综合分析，为客观评价项目质量状况提供依据，帮助项目决策人迅速、有效地对项目的实际进展情况进行监控与管理，从而可以根据需要采取有效措施来保证项目实施接着既定的轨道运行。（4纠偏纠错
根据具体情况采取合理的纠正措施。经过比较与分析，如果发生偏差，就要采取适当的措施进行纠正，让项目实施回到正轨。可供选用的纠正措施包括：重新制定项目计划、重新安排项目步骤、重新分配项目资源、调整项目组织形式、调整项目管理方式等。一般而言，为了保证项目不偏离正常轨道，按照既定计划走向成功，保证纠正措施的合理性与有效性，需要项目的实施主体事先了解一些项目质量管理基础知识与相关案例，确保纠错措施的有效性。
全面质量管理有4个核心的特征：即全员参加的质量管理、全过程的质量管理、全面方法的质量管理和全面结果的质量管理。1.质量计划编制
工具：成本绩效分析法、质量基准分析、流程图法（因果分析图）、实际设计法、质量成本分析（质量成本分为预防成本、评估成本、缺陷成本）
输入：项目章程、项目管理计划、项目范围说明书、组织过程资产
输出：质量管理计划、质量测试指标、质量核对表 2.执行质量控制
工具：测试、检查、控制图、因果图（石川图）、帕累托图（排列图或主次因素分析图）、统计抽样、流程图、趋势分析
3.质量保证与质量控制的区别：质量保证是针对项目实施过程的管理手段，质量控制是针对项目产品的技术手段。
4.软件质量从六个方面来衡量：性能、可靠性（包括容错性和健壮性）、可用性、安全性、可修改性（包括可维护性。可扩展性。结构重组、可以执行）、功能性
5.造成质量问题的原因有五大方面：人、机器。原材料、方法和环境
项目的质量控制工作是一个系统过程，应从项目的全过程入手，全面、综合地进行控制，项目的质量控制主要从以下2个方面进行。项目产品或服务的质量控制，项目产品或服务的质量控制是一个诊断和治疗的过程，当产品生产出来以后要检查产品的规格是否符合需要的标准，并消除生产的偏差，质量控制活动包括计划、测试、记录和分析。项目管理过程的质量控制，项目管理过程的质量控制，项目管理过程的质量控制是通过项目审计来进行的，项目审计是将管理过程作业和成功实践标准进行比较所作出的详细检查，考虑以下5个方面：度量项目质量的实际情况、与质量标准进行对比、识别存在的质量问题和偏差、分析质量问题产生的原因、如有必要进行纠偏、如何进行质量保证？质量保证是质量系统内实施的所有计划的系统性活动，是保证质量管理计划得以实施的一组过程和步骤，旨在证明项目满足相关的质量标准，质量保证采用主要工具和技术有质量计划、质量审计、过程分析、和质量控制技术和工具以及其他过程中获得的变更请求、质量控制测量、实施的变更请求等，通过这些技术和工具得到的信息作为质量保证的依据，提出请求的变更，以提高组织的质量政策、过程和程序的效率和效益。请指出QA与QC的联系和区别? QA和QC两者基本职责QC：检验产品的质量，保证产品符合客户的需求：是产品质量检查者；QA:审计过程的质量，保证过程被正确执行，是过程质量审计者；QC进行质量控制，向管理层反馈质量信息；QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。这就是QA和QC工作的关系。
项目质量管理可能问题？
1、没有制定可行的质量管理计划并积极实施；
2、没有全面的质量管理进展情况报告；
3、沟通方式
单一或不全面，容易误导用户，致用户不必要的担心。项目质量管理主要内容？
质量责任与人员职责；组织结构；程序与过程；质量控制的方法、工具与重点；质量管理所需要的资源；验收标准
如何实施质量保证？
执行质量管理计划，采用质量保证的工具和技术，提出相应质量整改措施 如何制定过程改进计划？
质量管理计划包括：质量政策，质量目标。质量管理活动。具体归纳为：1.质量责任和人员分工。2.组织结构；3.程序与过程。4.质量控制的方法、工具、重点（质量评审、质量保证方法）。5.质量管理需要的资源。6.验收标准。质量保证体系包含？
1.是否制定明确的质量计划；2.是否建立健全专职的质量管理机构；3.是否实现管理业务标准化，管理流程程序化；4.是否配备必要的资源条件。5.是否建立了一套灵敏的质量信息反馈系统。如何进行质量保证？（补充）
制定质量标准，制定质量控制流程，建立质量保障体系。
实施质量保证的方法：1.首先执行项目的质量管理计划；
2、采用质量保证的工具和技术；
3、提出相应质量整改措施，如建议的纠正措施、对项目计划可能的更新、对组织资产可能的更新、变更请求。如何控制产品的质量？
1、强有力的领导；
2、建立组织级项目管理体系
3、建立组织级质量管理体系
4、建立项目级激励制度
5、理解质量成本
6、提高项目文档质量（项目文档应有针对性、精确性、清晰性、完整性、灵活性、可追溯性）
7、发展和遵从成熟度模型。
文档的种类和作用：
1、用户文档；
2、开发文档；
3、管理文档
作用：
1、桥梁和交流作用；
2、明晰责任；
3、更好的理解系统；
4、进行项目质量管理。
质量文件包括：项目质量文件包括：质量保证大纲，技术文件，质量工作计划，质量成本分析。救火队的原因（项目质量常常遇到的问题）：
1、项目交付成果本身有缺陷，例如不稳定或功能不完美；
2、项目交付成果没有实现预定的功能需求；
3、项目在需求分析阶段对用户的需求分析提炼精度不够，没有挖掘到部分重要的需求；
4、随着时间和环境的变化，客户产生了新的需求；
5、由于文档的不完备，一方面导致用户不能解决一些使用问题，另一方面还使得文虎工作的效率提不高。质量控制的工作应做好以下几方面内容：
1、对维护工作进行质量控制，做好相关文档工作；
2、在有条件情况下，开始对已交付系统进行文档建设，尤其是用户手册的建设工作；
3、建立组织级的质量管理体系和相关的标准及规范，取得高层领导的支持和信任，开展整体质量控制关键的培养，在以后工作中实施严格的质量控制工作。质量保证工作的作用：
1、是保证质量的一个重要环节；
2、为持续的质量改进提供基础和方法；
3、为项目干系人提供对于质量的信任；
4、项目质量管理的重要内容；
5、与质量控制共同构成对质量的跟踪和保证。
质量管理强调的是全面质量管理，全过程质量管理，而不仅仅是测试工作所能保证的，项目实施过程中的每一个工作都会对项目质量产生影响。
（7）人力资源管理---比较重点，建议要弄懂！
项目人力资源管理包括制定人力资源管理计划、项目团队组建、团队建设与管理的各个过程，不但要求充分发挥参与项目的个人的作用，还包括充分发挥所有与项目有关的人员-----项目负责人、客户、为项目作出贡献的个人及其他人员的作用，也要求充分发挥项目团队的作用。项目人力资源管理包括如下过程：
（１）项目人力资源计划编制：确定与识别项目中得角色、分配项目职责和汇报关系，并记录下来形成书面文件，其中也包括项目人员配备管理计划。
（２）项目团队组建：通过调配、招聘等方式得到需要的项目人力资源。
（３）项目团队建设：培养提高团队个人的技能，改进团队合作，提高团队的整体水平以提升项目绩效。
（４）项目团队管理：跟踪团队成员个人的绩效和团队的绩效，提供反馈，解决问题并协调变更以
提高项目绩效。
这些过程互相之间有影响，并且同项目管理其他知识领域中的过程相互影响。处理人际关系涉及许多技能，其中包括：
（１）领导、沟通、谈判、协商及其他管理技能。
（２）授权、激励士气、指导、劝告及其他与处理个人关系有关的技能。（３）团队建设、冲突解决及其他与处理团队关系有关的技能。
（４）绩效评定，招聘，留用，劳工关系，健康与安全规定，及其他与管理人力资源有关的技能。编制项目人力资源计划
人力资源计划编制是决定项目的角色，职责以及报告关系的过程。项目的角色有可能是个人，也有可能是团队。他们要么属于组织内部，要么属于组织外部，或是两者的结合。人力资源计划编制也会创建一个项目人员配备管理计划。
工具：组织结构图、OBS(组织结构分解)、RAM（责任分配矩阵、人力资源模板、非正式的人际网络 输入：活动资源估计、环境和组织因素、项目管理计划
输出：角色和职责、项目的组织结构图、人员配备管理计划 项目团队建设的两个目标
１、提高项目团队成员的个人技能，以提高他们完成项目活动的能力。
２、提高项目团队之间的责任感和凝聚力，以更好的团队合作提高工作效率。项目团队的四个阶段：形成→震荡→正规→表现
团队建设的关键：激励理论、影响和能力、提高有效性
马斯洛需求理论有两个基本论点：
1、人的需求取决于他已经得到的和尚未得到的。
2、人的需求是分层次的。生理的需要、安全的需要、感情的需要、尊重的需要、自我实现的需要。信息系统团队的建设与发展的建议：
1）对团队成员要有耐心、友好及信心；2）解决问题而不责备人；3）经常召开会议，注重项目的实现以及长期有效的结果；4）把项目团队建设计划放到项目计划中去，让项目干系人有更多的了解；5）教育培养团队成员，提供培训机会，使团队成为一个有效的整体；6）认可个人和团队的成绩；7）尽早的进行团队建设，使整个项目生命周期中进行项目团队建设。管理项目团队
工具和技术：1）观察和谈话 1）项目绩效评估 3）冲突管理 4）问题日志 知识性员工的特点及管理方法：
具有很强的独立性和自主性，注重自我引导和自我管理；忠诚度低，流动性强；工作过程难以监控；具有实现自我价值的强烈渴望；个性突出
管理放大：沟通，重视，信任，承诺，支持，创新，学习和合作；管人要想管事转变，充分体现个人意愿和价值，侧重监管工作进度，质量和结果；激活个体的主观能动性，建立公平公正和公开的内部竞争环境；要完善薪酬激励机制，全面推行绩效考核管理，满足员工素质不断提高的个人需求，激发知识员工的工作热情和创造力；在职业教育和职业生涯设计相结合，营造实现自我价值的广阔空间。针对选定的项目，根据项目的特点，需要的角色如下： 管理类岗位：如项目经理
工程类：系统分析师，软件设计师，程序员，测试工程师，美工，网络工程师，主机人员，实施人员：行业专家
辅助类：文档管理员、秘书等 组建项目团队，明确责任
建设项目团队：提高个人绩效，提高责任感和凝聚力
管理项目团队：（1）跟踪个人和团队的执行情况，提供反馈（2）协调变更，以提高项目的绩效，保证项目进度（3）注意团队的行为，管理冲突，解决问题（4）评估团队成员的绩效 人力资源可能问题：
１、缺乏足够的项目管理能力和经验；
２、兼职过多，经理和时间不够用，顾此失彼；
３、没有进入管理角色，定位错误，疏于对项目的管理； ４、新人缺乏培训和全程的跟踪和监控；
应对措施
１、事先制定岗位的要求、职责和选人的标准，并选择合适的人选
２、对工作进行全面估算，如果有人负荷过重，需要找人代替，解决负载平衡问题 ３、事前沟通并对相应人员明确要求，明确角色的轻重缓急，促使尽快转换角色 ４、上级应该注意平时对人员的培养和监控 ５、采用激励理论与实际制度相一致 ６、加强团队建设的活动 ７、形成共同的行为准则
８、争取公司认可的奖励机制，认可成员的工作 ９、绩效考核
１０、招聘掌握技能的人员加入项目团队
１１、做好人员风险分析，制定相应的计划与措施 １２、采用项目管理管理系统，提高工作效率 如何组建团队成员？
1.实现分派；2.谈判；3.采购；4.虚拟团队。如何激励团队？ 1.一般管理技能（如沟通、交流）；2.培训；3.团队建设活动（如周例会、共同解决问题、拓展训练）；4.共同的行为准则（如基本准则、规章制度）；5.尽量集中办公（如同地办公、封闭开发）；6.认可和奖励（恰当的奖励与表彰措施）成功团队的标志、特点：
１、团队的目标明确，成员清楚自己工作对目标的贡献； ２、团队的组织结构清晰，岗位明确；
３、有成文或习惯的工作流程和方法，而且流程简明有效； ４、项目经理对团队成员有明确的考核和评价标准； ５、组织记录性强；
６、互相信任，善于总结和学习。如何设别并管理干系人？
作为项目干系人分析的第一步，需要先仔细识别出本项目的全部干系人。项目经理需要对项目干系人有一个全面的了解，在心中有一张完整的项目关系人结构图，以后无论是启动、计划还是执行、问题处理和收尾，都需要系统全局地思考问题，切忌头痛医头、脚痛医脚。
在项目干系人识别中，对甲方项目干系人的识别和分析更是重中之重，在识别出项目干系人之后，还需要分析干系人之间的关系和历史渊源，如果不做这进一步的分析，会在项目过程中遇到不小的麻烦。如何对待项目中出现的冲突？
１、运用冲突解决办法正确解决双方冲突；
２、提高自己的技术能力，行使专家权力说服冲突双方，获得双方信任； ３、对消极怠工员工行使强制力让其努力工作；
４、和团队成员增强沟通和交流，获得团队成员的信任； ５、跟踪个人和团队的执行情况，及时反馈和协调变更； ６、实行奖励制度以激励团队。管理项目团队的常用方法：
观察和对话、项目绩效评估、冲突管理和问题日志 冲突产生的原因：
项目的高压环境、责任模糊、多个上级的存在、新科技的流行。冲突解决的办法：问题解决、妥协（求同存异、撤退、强迫）
新技术风险解决办法：培训、自制—外购分析、招聘掌握该新技术的人员、风险分析与防范。5种权力：合法的权力、强制力、专家权力、奖励权力、潜示权力 X型管理需要注意：
１、把握好软硬件措施，有功奖、有错罚； ２、明确任务分配和跟踪任务执行情况；
３、和项目团队成员增强沟通，增进信任；
４、关注资源符合情况，灵活调整任务分配和项目进度计划，尽量让资源平衡； ５、注意项目高压下团队成员的情绪，正面处理冲突；
６、修改不合理和错误的项目进度计划，听取各方面意见和建议。（8）沟通管理-----比较重点，建议要弄懂 项目沟通管理包括如下过程：
① 沟通计划编制。确定项目干系人的信息和沟通需求：哪些人是项目干系人，他们对于该项目的收益水平和影响程度如何，谁需要什么样的信息，何时需要，以及应怎么样分发给他们。② 信息分发。以合适的方式及时向项目干系人提供所需信息。③ 绩效报告。收集并分发有关项目绩效的信息，包括状态报告、进展报告和预测。④ 项目干系人管理。对项目沟通进行管理，以满足信息需要者的需求并解决项目干系人之间的问题。
沟通管理计划编制过程一般分为如下几个步骤：
（１）确定干系人的沟通信息需求，即哪些人需要沟通，谁需要什么信息，什么时候需要以及如何把信息发送出去。
（２）描述信息收集和文件归档的结构。
（３）发送信息和重要信息的格式，主要指创建信息发送的档案，获得信息的访问方法。通常，沟通计划编制的第一步就是干系人分析，得出项目中沟通的需求和方式，进而形成较为准确的沟通需求表，然后再针对需求进行计划编制。沟通管理计划的主要内容：（１）项目关系人沟通要求。
（２）对要发布信息的描述，包括格式、内容和详尽程度。（３）信息接收的个人或组织。
（４）传达信息所需的技术或方法，如备忘录、电子邮件或新闻发布等。（５）沟通频率，如每周沟通等。
（６）上报过程，对下层无法解决的问题，确定问题上报的时间要求和管理链（名称）。（７）随项目的进展对沟通管理计划更新与细化的方法。（８）通用词语表。
常用的沟通方式的优缺点或特点介绍如下
1、书面与口头、听和说
书面的沟通方式优点是清晰，二义性少以及可以作为备忘录，也可作为双方沟通的证据。而缺点是缺乏人性化，如某些勇于较为生硬的话，容易使双方的关系出现矛盾。
2、对内与对外
项目经理通常采用不同的方式进行对内（项目团队内）和对外（对顾客、媒体和公众等）的沟通。对内沟通讲究的是效率和准确度，对外沟通强调的信息的充分和准确。对内的沟通可以以非正式的方式出现，而对外的沟通要求项目经理以正式的方式进行。
3、正式与非正式
通常情况下，正式（如报告、情况介绍会等）的沟通是在项目会议时进行的，而非正式（如备忘录、即兴谈话等）的项目沟通属于大多数场合的方式。
4、垂直与水平
垂直方向（从下到上或者从上到下）沟通的特点是：沟通信息传播速度快，准确程度高。水平方向沟通的特点是：复杂程度高，往往不受当事人的控制。沟通管理对组织过程资产的影响表现在如下方面 ① 经验教训记录 包括问题的起因、所采取纠正措施以及有关信息发布的其他各种经验教训。记录下来的经验教训可成为本项目和项目实施组织的历史数据库的组成部分。② 项目记录
项目记录可包括函件、备忘录以及项目描述文件。这些信息应尽可能地以适当方式有条理地加以保存。项目团队成员也往往在项目笔记本中保留个人记录。
③ 项目报告
正式和非正式项目报告将详细说明项目状态，其中包括经验教训、问题记录单、项目收尾报告和其他知识领域的成果。④ 项目演示介绍
项目团队正式或非正式地向任何或所有项目干系人提供信息。这些信息要切合听众需要，介绍演示的方法要恰当。⑤ 项目干系人的反馈
可以发布从项目干系人收集的有关项目实施的消息，并根据该信息改进或修改项目的未来绩效。⑥ 项目干系人通知
可就解决的问题、审定的变更和一般项目状态问题向项目干系人通报。沟通管理可能问题：
１、内部管理有问题，监管不力
２、没有或极少与客户进行直接沟通 ３、现场管理制度执行不力 ４、总包与分包责任不清
５、客户获取的信息失真，总包推卸责任
６、客户自己本身的问题，包括资金、管理水平等 ７、可能监理工作没到位 沟通管理应对措施
１、做好干系人分析
２、发挥总包的牵头和监理的协调作用
３、对共用资源可用性进行分析，引入资源日历 ４、解决冲突
５、监理健全项目管理制度并监管其执行 ６、采用项目管理信息系统 可能问题和应对措施的补充
１、缺乏沟通，合作氛围不够
２、及时信息分发，加强沟通，让客户了解项目具体情况 ３、注重沟通技巧，建立融洽的合作气氛
４、没有对团队成员的沟通需求和沟通风格进行分析 ５、没有开一个高效的会 ６、沟通方式单一 ７、没有冲突管理
８、开高效会议的做法
９、分析成员的沟通风格，从而采用相应的沟通方式 １０、多种沟通方式
１１、采用一些沟通模板 １２、加强冲突管理
１３、采用一些沟通模板 １４、加强冲突管理 １５、多供应商的沟通
１６、解决冲突，包括干系人对项目期望之间的冲突、资源冲突等 １７、做好干系人分析，调研各集成商的沟通需求 １８、周期性沟通
１９、突发事件的协调 有效沟通的方式有？
１、使用项目信息系统辅助沟通，用于收集、综合、分析项目管理过程输出的工具和技术； ２、建立沟通基础结构，是一套工具、技术和原则，为项目信息传送提供基础； ３、使用项目沟通模板；
４、把握项目沟通基本原则，沟通内外有别，非正式沟通有利于关系融洽，采用对方能够接受的沟通风格、沟通升级原则、扫除沟通的障碍； ５、发展更好的沟通技能；
６、认识和把握人际沟通风格； ７、良好的冲突管理； ８、召开高效的会议 沟通和需求获取：
１、制定完善的沟通管理计划
２、在和客户沟通之前学习和项目相关的背景知识 ３、用经验和技巧引导客户对需求进行明细化
４、对超出需求范围的需求或不合理的需求，应有技巧地说服客户 ５、使用多种方式和客户进行沟通 应该怎么提高项目例会的效率？
１、事先制定一个例会制度。在项目沟通计划中，确定例会的时间，参加人员范围以及一般议程等。
２、放弃可开可不开的会议。在决定召开一个会议之前，首先明确会议是否必须举行，还是可以通过其他方式进行沟通。
３、明确会议的目的和期望结果。
４、发布会议通知、在会议通知中要明确：会议目的，时间，地点，参加人员，会议议程和议题。事先明确会议议程和讨论问题，让参会人员提前做准备。
５、在会议之前将会议资料发送到参会人员。对已需要有背景资料支持的会议，应事先将资料发给参会人员，以提前阅读，直接在会上讨论，可以有效节约时间。
６、可以借助视频会议设备。对于异地参会人员或者需要演讲的场合，可以借用一些必要的视频设备，可以使会议达到更好的效果。
７、明确会议规则。制定会议主持人，明确会议主持人的职责，支持人要对会议进行有效控制，并营建一个活跃的会议气氛。
８、支持人要事先陈述基本规则，例如明确每个人的发言时间，每次发言只有一个声音主持人根据会议议程的规定控制会议的节奏，保证每一个问题都得到讨论。
会议后要总结，提炼结论。支持人在会后总结问题的讨论结果，重审有关决议，明确责任人和完成时间。
会议要有纪要。如果将工作的成果、完成时间、责任人都记录在案，则有利于督促和检查工作的完成情况。
做好工作会议的后勤保障。很对会议兼有联络感情的作用，因此需要选择一个合适地点，提供餐饮、娱乐和礼品，制定一个有张有弛的会议议程。对于客户或合作伙伴参加的会议更要如此。可采用的促进有效沟通的措施如下：
（１）对项目组成员进行沟通需求和沟通风格的分析
（２）对于具有不同沟通需求和沟通风格的人员组合设计不同的沟通方式
（３）除了进行项目例会外，可以通过电话，电子邮件、项目管理软件、OA软件等工具进行沟通（４）正式的沟通的结果应形成记录，对于其中的决定应有人负责落实（５）可以引入一些沟通模板
（６）在项目组内部培养团结的氛围并注意冲突管理
沟通渠道的数目：n(n-1)/2(9)合同管理---重点，一定要弄懂 按信息系统范围划分的合同分类
１、总承包合同
２、单项项目承包合同 ３、分包合同
按项目付款方式划分的合同分类 １、总价合同
２、单价合同
３、成本加酬金合同 项目合同签订的注意事项
１、当事人的法律资格：当事人订立合同，应当具有相应的民事权利能力和民事行为能力。２、质量验收标准：质量验收标准是一个关键指标。如果双方的验收标准不一致，就会在系统验收时产生纠纷。
３、验收时间：当事人没有约定设备的交付时间或者约定不明确的，可以协议补充，不能达成协议的，依照合同有关条款或交易习惯确定。若仍不能确定，则供货可以随时履行，采购方也可以随时要求履行，但应当给予对方必要的准备时间。４、技术支持服务
５、损害赔偿：原则上，委托方与被委托方都具有损害赔偿这项权利，但比较多的情况是因为承建方对于企业实施信息系统的困难估计不足，结果陷入到期后难以完成项目的尴尬局面。
６、保密约定：当事人在订立合同过程中知悉的商业秘密，无论合同是否成立，不得泄露或者不正当的使用。泄露或不正当地使用该商业秘密给对方造成损失的，应当承担损害赔偿责任。７、合同附件：合同生效后，当事人就质量、价款或者报酬、履行地点等内容没有约定或者约定不明确的，可以协议补充，不能达成补充协议的，按照合同有关条款或者交易习惯确定。
８、法律公证：为避免合同纠纷，保证合同订立的合法性，当事人可以将签订的合同拿到公证机关进行公证。经过公证的合同，具有法律强制执行效力。关于合同不明确情况的处理
（１）当事人对标的物的质量要求不明确的，按国家标准和行业标准。没有这些标准的，按产品通常标准或符合合同目的的标准。
（２）履行地点不明确的，按标的性质不同而定：接受货币在接受方，交付不动产的在不动产所在地，其他标的在履行义务方所在地。履行地在法律上具有非常重要的意义，他可以确定由谁负担，货物的所有权何时何处转移，货物丢失风险由谁承担等，在诉讼中，也是确定管辖权的重要依据，所以签订合同对履行地条款要特别注意。
（３）履行期限不明的，债务人可随时履行，债权人可随时要求履行，但应给对方必要的准备时间，在这里特别提醒债权人要注意诉讼时效，关于随时履行受不受诉讼时效的制约目前仍有争议，不过最好在时效以内主张权利。
（４）履行费用负担不明确的，由履行义务一方负担。履行费用是履行义务过程中各种附随发生的费用。在合同中应该考虑各种费用的分担，如果没有约定，视为由履行义务一方承担。以上关于处理各种条款不明情况的法定标准，是根据长期交易形成的规律确定下来的，不管对谁有利和不利，都得按这个规定去履行。当然，最好还是把合同条款定的明确而严密些。１、主要内容（阶段）
合同前期管理------合同谈判、合同签订
合同执行期管理------合同履行、合同变更、合同终止 合同收尾管理--------合同收尾
2、可能会出现的问题
合同没订好，没有就具体完成的工作形成明确清晰的条款 甲方没有对需求及其变更进行统一的组织和管理 缺乏客户/用户参与
甲方无法进行跨部门协调
在合同各阶段进行范围管理（应对措施）合同谈判阶段：
１、取得明确的工作说明书或更细化的合同条款 ２、在合同中明确双方的权力和义务，尤其是变更
３、采取措施，确保合同签约双方对合同的理解是一致的 计划阶段
编制项目范围说明书
创建项目的工作分解结构
制定项目的范围管理计划 执行阶段
在项目执行过程中加强对已分解的各项任务的跟踪记录 建立与项目干系人进行沟通的统一渠道 建立整体变更控制的规程并执行
加强对项目阶段性成果的评审和确认 项目全生命周期范围变更管理
在项目管理体系中应该包含一套严格、实用、高效的变更程序
规定对用户的变更请求应正视提出变更申请，并经双方项目经理审核后，视不同情况，作出相应处理合同和详细范围说明书的作用
合同是买卖双方形成的一个共同遵守的协议，卖方有义务提供合同制定的产品和服务，而买房则有义务支付合同规定的价款
项目范围说明书详细描述了项目的可交付物和产生这些可交付物所必须做的项目工作 合同是制定项目范围说明书的依据（10）采购管理----重点注意招投标 编制采购计划
对采购作出计划，以确定哪些项目需求可以通过采购产品、服务或成果。编制采购计划需要解决的问题是：是否需要采购、如何采购、采购什么、采购多少以及何时采购。
用于采购计划编制工作的技术和方法主要有自制、外购决策分析，以及专家咨询 工作说明书与项目范围说明书的区别：
工作说明书(SOW)是项目对所要提供的产品、成果或服务的描述。SOW与范围说明书的区别是在于，工作说明书市对项目所要提供的产品或服务的叙述性的描述，项目范围说明书则通过明确项目应完成的工作而确定了项目的范围。
工作说明书应相当详细地规定采购项目，以便潜在的卖方确定他们是否有能力提供这些项目。项目范围说明书描述了项目的可交付物和产生这些可交付物所必须进行的项目工作，项目范围说明书在所有项目干系人之间建立了一个对项目范围的共识，描述了项目的主要目标。询价
询价就是从潜在的供应商处获得项目建议书（项目方案）或标书。招标
按照《中华人民共和国招投标法》，可以分为招标、投标、开标、评标、中标、签订合同等过程，招标有可以分为邀请招标和公开招标。公开招标，是指招标人在指定的报刊、电子网络或其他媒体上发布招标公告，吸引众多的企业单位参加投标竞争，招标人从中优化选择中标单位的招标方式。邀请招标，也称选择性招标，由招标人根据潜在供应商的资信和业绩，选择一定数目的法人或其他组织（一般不能少于3家），向其发出招标邀请书，邀请他们参加投标竞争。开标
应该在招标文件确定的提交投标文件截止时间的同一时间公开进行，开标地点应该为招标文件中预先确定的地点。开标由招标人主持，邀请所有投标人参加。评标
应有业主组织的评标委员会在开标后独立进行。评标委员会由招标人的代表和有关技术、经济等方面的专家组成，成员为5人以上单数，其中技术、经济等方面的专家不得少于成员总数的2/3.决标：即最后决定中标人。通常由招标机构和业主共同商讨决定中标人。
授标：中标人确定后，招标人应当向中标人发出中标通知书，并同时将中标结果通知所有未中标的投标人。
招标人和招标人应当自中标通知书发出之日起三十日内，按照招标文件和中标人投标文件订立书面合同
几个法律规定的日期
在招标文件要求提交投标文件截止时间至少十五日前，招标人可以以书面形式对发出的招标文件进行必要的澄清或者修改
招标人有权也应当对在招标文件要求提交的截止日期后送达的投标文件拒收
依法必须进行的招标项目，自招标文件开始发出之日起至提交投标文件截止之日止，最短不得少于二十日
（11）文档文和配置管理，比较重要要搞懂，喜欢喝变更一起考 配置管理是为了系统的控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科，配置管理包括四个主要活动：配置识别、变更控制、状态报告和配置审计
配置库可以分成动态库（开发库、程序员库、工作库）、受控库（主库）、静态库（软件仓库）和备份库4种类型
（1）动态库：也称为开发库、程序员库或工作库，用于保存程序员当前正在开发的配置实体。动态库通常包括新模块、文档、数据元素或进行修改的已有元素。动态库是软件工程师的工作区，由工程师控制
（2）受控库：也称主库或系统库，是用于管理当前基线和控制对基线的变更。受控库包括配置单元和被提升并集成到配置项中的组件。软件工程师和其它人员可以自由的复制受控库中的组件或单元，然而，必须有适当的权限授权变更。受控库中的单元或组件用于创建集成、系统和验收测试或对用户发布的构建
（3）静态库：也称软件仓库或软件产品库，用于存档各种广泛使用的已发布的基线；静态库用于控制、保存和检索主媒介
（4）备份库：包括制作软件和相关构架、数据和文档的不同版本的复制品。在各点的及时备价。可以每天、每周或每月实行备份 １、制定配置管理计划
在项目启动阶段，项目经理首先要制定整个项目的开发计划，它是整个项目研发工作的基础。总体研发计划完成后，配置管理的活动就可以展开了，如果不在项目开发之初制定项目配置管理计划，那么配置管理的许多关键活动就无法及时有序的进行，而它的直接后果就是造成项目开发状态的混乱，并注定使项目管理活动成为一种救火的行为。由此可见，在项目启动阶段制定项目配置计划是项目成功的重要保证。配置管理计划由CMO制定，主要内容是制定配置管理策略，编写配置管理计划，评审配置管理计划。
２、配置识别与建立基线 ３、建立配置管理系统 ４、版本管理
５、配置状态报告 ６、配置审核
（12）变更管理—项目管理过程中，一切可能会变更。要重点掌握 变更的常见原因：
（1）产品范围（成果）定义的过失或疏忽（2）项目范围（工作）定义的过失或疏忽（3）增值变更
（4）应对风险的紧急计划或回避计划
（5）项目执行过程与项目基准要求不一致带来的被动调整（6）外部事件
变更管理的基本原则：
变更管理的原则是首先建立项目基准、变更流程和变更控制委员会（也叫变更管理委员会）。包括以下内容：
（１）基准管理。基准是变更的依据。在项目实施工程中，基准计划确定并经过评审后（通常用户应参加部分评审工作），建立初始基准。此后每次变更通过评审后，都应重新确定基准。
（２）建立变更控制流程。建议或选用符合项目需要的变更管理流程，所有变更都必须遵循这个控制流程进行控制。流程的作用在于将变更的原因、专业能力、资源运用方案、决策权、干系人的共识和信息流转等元素有效地综合起来，按科学的顺序进行。
（３）明确组织分工。至少应明确变更相关工作的评估、评审和执行的职能。
（４）完整体现变更的影响。变更的来源是多样的，即需要完成对客户可视的成果、交付期等变更
操作，还需要完成对客户不可视的项目内部工作的变更，如实施方的人员分工、管理工作和资源配置等。
（５）妥善保存变更产生的相关文档，确保其完整、及时、准确、清晰，适当的时候可以引入配置管理工具。国内使用较多的配置工具有 Rational ClearCase、Visual SourceSafe和Concurrent Versions System。项目变更控制委员会或更完整的配置控制委员会（Configuration Control Board,CCB），或相关职能的类似情况，是项目的所有者权益代表，负责裁定接受哪些变更，CCB由项目所涉及的多方人员共同组成，通常包括用户和实施方的决策人员。变更的程序：
(1)提出与接受变更申请
变更提出应当及时以正式方式进行，并留下书面记录，变更的提出可以是各种形式，但在评估前应以书面形式提出。（2）对变更的初审 变更初审的目的如下：
①对变更提出方施加影响，确认变更的必要性，确保变更是有价值的。②格式检验，完整性校验，确保评估所需信息准备充分。③在干系人间就提出供评估的变更信息达成共识。④变更初审的常见方式为变更申请文档的审核流转。（3）变更方案论证
变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供CCB决策。常见的方案内容包括技术评估和经济评估，前者评估需求如何转化为成果，后者评估价值和风险。（4）项目变更控制委员会审查
审查过程，是项目所有者据变更申请及评估方案，决定是否批准变更。评审过程常包括客户、相关领域的专业人士等。审查通常是文档会签形式，重大的变更审查可以包括正式会议形式。审查过程应注意分工，项目投资人虽有最终的决策权，但通常在专业技术上并非强项。所以应当在评审过程中将专业评审、经济评审分开，对涉及项目目标和交付成果的变更，客户的意见应放在核心位置。（5）发出变更通知并开始实施
评审通过，意味着项目基准的调整，同事确保变更方案中的资源需求及时到位。项目基准的调整，包括项目目标的确认、最终成果、工作内容和资源、进度计划的调整。需要强调的是，变更通知后，不只是包括实施项目基准的调整，更要明确项目的交付日期、成果对相关干系人的影响。如变更造成交付期的调整。应在变更确认时发布，而非在交付前公布。（6）变更实施的监控 要监控的，除了调整过的项目基准中所涉及变更的内容外，还应当对项目的整体基准是否反映项目实施情况负责。通过监控行动，确保项目的整体实施工作是受控的。变更实施的过程监控，通常由项目经理负责项目基准的监控。管理委员会监控变更明确的主要成果、进度里程碑等，可以委托监理单位承担监控职责。
（7）变更效果的评估
变更评估可以从以下几个方面进行。①首要的评估依据，是项目基准。
②还需结合变更的初衷来看，变更所要达到的目的是否已达成。
③评估变更方案中的技术论证、经济论证内容与实施过程的差距并推进解决。（8）判断发生变更后的项目是否已纳入正常轨道
项目基准调整后，需要确认的是相应的资源配置和人员是否及时到位，更需多加关注。之后对项目的整体监控应按新的项目基准进行，涉及变更的项目范围及进度，在变更后的紧邻监控中，应更多地关注，当确认新的项目基准已经生效则按正常的项目实施流程进行。有可能的问题：
１、对用户的要求未进行记录
２、对变更的请求未进行足够的分析，也没有获得批准 ３、在修改的过程中没有注意进行版本管理
４、修改完成后未进行验证
５、修改的内容未和项目干系人进行沟通 导致的后果
１、缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握
２、缺乏对变更请求的分析可能会导致后期的变更工作失误
３、在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原；另一方面，对于组织财富和经验的积累也是不利的
４、修改完成后不进行验证则难以确认变更是否正确实现
５、未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致之处（13）风险管理----稍微重点掌握下
项目风险管理就是项目管理班子通过风险识别、风险估计和风险评价，并以此为基础合理地使用多种管理方法、技术和手段对项目活动涉及的风险实行有效的控制，采取主动行动，创造条件，尽量扩大风险事件的有利结果，妥善地处理风险事故造成的不利后果，以最少的成本保证安全、可能地实现项目的总目标。简单地说，项目风险管理就是指对项目风险从识别到分析、评价乃至采取应对措施等一系列过程，它包括将积极因素所产生的影响最大化和使消极因素产生的影响最小化两方面的内容。项目风险管理过程包括如下内容：
①风险管理规划：决定如何进行、规划和实施项目风险管理活动。②风险识别：判断哪些风险会影响项目，并以书面形式记录其特点。
③定性风险分析：对风险概率和影响进行评估和汇总，进而对风险进行排序，以便于随后的进一步分析或行动。
④定量风险分析：就识别的风险对项目总体目标的影响进行定量分析。⑤应对计划编制：针对项目目标制定提高机会、降低威胁的方案和行动。
⑥风险监控：在整个项目生命周期中，跟踪已识别的风险、预测残余风险、识别新风险、实施风险应对计划，并对其 有效性进行评估。
风险的特性：客观性、不确定性、随机性、相对性、可变性、阶段性 风险管理计划编制
工具：风险核对表、风险管理表格、风险数据库模式
输入：企业环境因素、组织过程资产、项目范围说明书、项目管理计划 风险识别主要内容包括：
１、识别并确定项目有哪些潜在风险：（风险识别的第一目标）２、识别引起这些风险的主要因素：（风险识别的第二目标）
３、识别项目风险可能的后果。（风险识别的第三目标，采用定性分析）工具和方法： １）文件审查
２）信息收集技术：
德尔菲法（有助于减少数据方面的偏见）
头脑风暴法（也叫集思广益法，充分发挥集体智慧，提高风险识别的正确性和效率）访谈法
３）检查表：检查表的一个优点是它使风险识别工作快而简单，它的不足之处在于我们不可能编制一个详尽的风险价差表，检查表的使用者可能会被表中的条目局限。４）假设分析 ５）图解技术
因果图：也叫石川图或鱼刺图，用于识别风险的成因。
系统或过程流程图：反映某一系统内部各要素之间是如何项目联系的，并反映发生的联系机制 输出：风险记录
已识别的风险列表
风险的征兆或警告信息 潜在风险应对方法列表
风险根本原因 更新的风险分类 项目管理计划（更新）定性风险分析
风险定性分析包括对识别风险进行优先级排序，风险定性分析是建立风险响应计划优先级的快速有效的方法，为定量分析奠定基础。定性风险分析的方法：
１）风险概率与影响评估 ２）概率和影响矩阵 ３）风险数据质量评估 ４）风险分类
５）风险紧迫性评估 定量风险分析
定量风险分析是指对定性风险分析过程中作为项目需求存在的重大影响而排序在先的风险进行分析，并就风险分配一个数值。定量风险缝隙是在不确定情况下进行决策的一种量化方法，该过程采用蒙特卡罗模拟以及决策树分析等技术。风险应对计划编制
输入：风险管理计划、风险记录 工具和技术：
１、负面风险（消极风险、或威胁）的应对策略：1）规避2）转移3）减轻 ２、正面风险（积极风险、或机会）的应对策略：1）开拓2）分享3）提高 风险监控
风险监控的目标：
１）识别和度量项目的风险
２）努力避免项目风险事件的发生
３）积极消除项目风险事件的消极后果 ４）重新吸取项目风险管理经验和教训 风险管理可能出现的问题 １、项目范围的风险 ２、项目进度的风险
３、项目人力资源的风险 ４、项目质量的风险 ５、客户方面的风险 风险管理应对措施
１、项目范围尽可能清晰的界定
２、项目进度制定需要充分考虑各种潜在因素，适当留有余地和柔性
３、合理利用赶工及快速跟进等方法，充分利用资源，争取保质保量完成任务 ４、实施双方因对人员认真的评估，制定适当的奖励措施 ５、对用户进行培训，让用户的需求更加合理（14）收尾管理----稍微重点掌握下
项目收尾阶段是以某种正式的活动作为结束标志：主要是完成项目交付成果的检验，由承建方将完成的成果交与用户方，业主（用户）确认成果符合合同规定。项目收尾工作的另一重要内容是从项目中获得相关经验，以便指导和改善未来项目的运作和实施。项目收尾的具体内容主要是项目验收、项目总结和项目评估审计。
项目的正式验收包括验收项目产品、文档及已经完成的交付成果。
验收需要正式的验收报告。对于系统集成项目，一般来讲，需要正式的验收测试工作。验收测试工作可以由业主和承建单位共同进行，也可以由第三方公司进行，但无论哪种方式都需要双方认可的正式文档为依据进行验收测试。
如果验收测试未获通过，则应立即查找原因，一般会转向变更环节进行修改和补救，如果项目验收测
试正式通过，则标志着项目验收的完成。通常，系统集成项目的验收工作包括： １、系统测试
２、系统的试运行 ３、系统的文档验收
４、项目的最终验收报告 项目总结
项目总结属于项目收尾的管理收尾。而管理收尾有时又被称为行政收尾，就是检查项目团队成员及相关干系人是否按规定履行了所有责任。实施行政结尾过程还包括收集项目记录、分析项目成败、收集应吸取的教训、以及将项目信息存档供本组织将来使用等活动统一为一个整体。项目总结内容和意义
① 了解项目全过程的工作情况及相关的团队或成员的绩效状况。② 了解出现的问题并进行改进措施总结。
③ 了解项目全过程中出现的值得吸取的经验并进行总结。
④ 对总结后的文档进行讨论，通过后即存入公司的知识库，从而纳入企业的过程资产。项目评估、审计
项目评估的意义是将项目的所有工作加以客观的评价，从而对项目全体人员的成果形成绩效结论。好的项目评估会引导后续项目的开展，并对项目过程的改进起到很重要的作用。项目的审计应由项目管理部门与财务部门共同进行，相关的审计项目应在项目成本管理中列出。在项目收尾的时候，对已经列出的支出和收入进行财务审计，对不合理的支出和收入加以分析，为改进项目的管理服务。
存在的问题，如何补救，项目总结的主要内容是什么？（2011年5月的考点）（15）服务管理----稍微重点掌握下
计算机信息系统集成的资质是指从事计算机信息系统集成的综合能力，包括技术水平、管理水平、服务水平、质量保证能力、技术装备、系统建设质量、人员构成与素质、经营业绩、资产状况等要素。计算机系统集成资质等级由高到低依次分为一级、二级、三级和四级。监理单位资质由高到低分为甲、乙、丙三个等级。
监理工作的主要内容可以概括为：“四控三管一协调”，即投资控制、进度控制、质量控制、变更控制；合同管理、信息管理、安全管理；沟通协调。
《资质证书》有效期为4年，获证单位每年进行一次自查，并将自查结果投资认证工作办公室备案；资质认证工作办公室对获证单位每两年进行一次年检，每4年进行一次换证检查和必要的非例行监督检查。检查结论分为“通过”“降级”和“取消”三种，每两年对系统集成项目经理进行一次年审，年审结论分为“合格”“不合格”和“不在岗”三种，一次年审“不合格”或“不在岗”者，降低其资质等级一次，连续两次年审结论为“不合格”者，取消其资质。连续两次年审结论为“不在岗”者，需重新申请资质。逾期不参加年审者，视为自动放弃资质。被降低资质等级的系统集成项目经理，一年以后才能重新申请原资质等级，被取消系统集成项目经理资质证书的，两年以后才能重新申请系统集成项目经理资质。
《信息系统工程监理资质证书》有效期为4年，届满4年更换新证。甲级、乙级资质由工业和信息化部负责年检，丙级由省市信息产业主管部门负责年检。
信息系统工程实行总监理工程师负责制，总监理工程师行使合同赋予监理单位的权限。当前我国信息系统服务管理的重要内容如下： 计算机信息系统集成单位资质管理 信息系统项目经理资质管理
信息系统工程监理单位资质管理 信息系统工程监理人员资质管理
IT项目审计是指对IT项目的规划、开发、实施、运行和维护等各个环节进行评价，确保其符合企业经营目标的过程。
信息系统安全的特性：信息的完整性、可用性、保密性、抗抵赖性、可控性（其中完整性、可用性和保密性为基本安全特性要求）。
【案例分析】
J公司是一家系统集成公司，最近公司签订了应急项目的合同，是以公司自主产品为主的解决方案，但主方案为在开发产品，包含中心和前端设备种类很多。需要挑选一位项目经理，组建一个项目团队。由于公司正同步进行多个项目，没有足够数量的项目经理，而该项目又必须马上开始，于是公司领导决定任命L担任此项目的管理工作。L接到任命后，立即开始着手组建项目团队，对团队进行任命，唯一没有任命生产环节的负责人。产品还在不断的开发过程中，但是项目实施工期在进一步逼近。采购的设备要到4月中旬才到公司，多设备的联合调试还要在4月底进行，5月中旬完成设备到现场的任务。
问题1：请问项目本案例中出现几个问题项目管理相关的问题？
问题2：如果你被临时委托生产的负责人你应该怎么做才能满足项目整体连接调试和发货的需求？ 问题3：如果你是项目经理应该如何制定项目计划 【案例的分析】
问题1：在该案例中，出现了以下问题。① J公司对项目经理的选择出现了一些问题 ② 项目团队组建有重要的纰漏，对自主产品和公司的工作流程不了解。③ 在设备采购的时候没有进行很好的把控，使大量的任务不能提前实施。④ 整体计划过于理想化。没有留出应急的时间，没有对风险进行分析和规避，产品为正在开发的产品有很多东西需要验证。
问题2：如果我是生产的负责人应该怎么做： ① 沟通项目经理和项目上下环节的干系人，明确工作范围和工作说明； ② 将工作结构分解：创建WBS将工作需求分解，进行活动排序以及资源估算。制定进度计划表。③ 根据进度计划表，采取必要的措施，如：采取外包、增加资源、快速跟进的方式解决整体联调以及供货的时间问题，尽快的赶进度。（由于产品在不断的开发中完善，所有并行的方式为解决进度问题的最佳方案）
问题3：项目的整体管理计划内容：
作为本项目的负责人在制定本项目整体计划的内容： ① 应包含项目整体介绍或概述包括：项目名称，项目以及项目所需满足需求的简单描述，发起人的名称，项目经理与主要成员的姓名，项目可交付成果，重要资料清单。② 项目组织情况的描述包括：组织结构图，项目责任，其他与组织或过程相关的信息。③ 项目计划中用来描述项目的管理和方法主要包括：管理目标，项目控制，风险管理，项目人员，技术过程。④ 项目计划中用来描述项目任务的那部分应当参考范围管理计划的内容，主要包括：主要可交付成果，与工作有关的其他信息。⑤ 项目进度信息部分主要包括：进度概要，进度细要，与进度有关的信息。⑥ 项目计划整体项目预算主要包括：预算概要，预算细要，与预算相关的其他信息。
第三篇：系统集成项目经理(下午案例分析考试题)
㈠实施项目中擅自变更，好心办坏事 在一个正在实施的系统集成项目中出现下述情况，一个系统的用户向系统他认识的一个开发人员抱怨系统软件中的一项功能问题，并且表示希望能够修改，于是，该开发人员就直接对系统软件进行了修改，解决了该想问题，问题
一、上述情况中存在的问题：
1、对用户的要求未进行记录；
2、对变更请求未进行足够的分析，也没有获得批准；
3、在修改过程中没有注意进行版本管理；
4、修改完成后未进行验证；
5、修改的内容未与项目干系人进行沟通。
问题
二、上述情况会导致的结果：
1、缺乏对变更请求的分析可能会导致对产品的变更工作出现欠缺，与其他工作不一致等问题，对项目的进度、成本、质量方面也会产生一定的影响；
2、缺乏对变更请求的记录可能会导致对产品的变更里是无法追溯，并会导致对工作的产物的整体变化失去把握；
3、在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原，造成成本损耗和进度拖延，另一方面，对于组织财富和经验的积累也是不利的；
4、修改完成后不进行验证则难以确认变更是否正确实施，为变更付出的工作量也无法得到承认；
5、未与项目干系人进行沟通可能导致项目干系人之间的工作出现不一致之处，进而影响项目的整体质量。问题
三、配置管理中完整的变更处理流程：
1、变更申请，应记录变更的提出人、日期、申请变更的内容等事项；
2、变更评估，对变更的影响范围、严重程度、经济和技术可行性方面进行评估；
3、变更决策，由具有相应权限的人员或机构决定是否实施变更；
4、变更实施，由管理者指定的人员在受控状态下实施变更；
5、变更验证，由配置管理人员或者受到变更影响的人对变更结果进行评价，确定变更结果和预期相符，相关内容进行了更新，符合版本管理的要求；
6、沟通存档，将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档，如提出的变更在决策时被否决，起初时记录也应予以保存。
㈡如何开好例会
老张是某个系统集成公司的项目经理,他身边的员工始终在抱怨公司的氛围不好,沟通不足.老张非常希望通过自己的努力来改善这一状况,因此他要求项目组成员无论如何每周都要参加例会并且发言,但对例会应如何进行,老张却不知如何规定,很快项目组成员就抱怨例会目的不明,效率太低,缺乏效果,等等.而且由于在例会上意见相左，很多组员开始争吵，甚至影响到人际关系的融洽。
问题一：问题产生的可能原因：
1、缺乏对项目组成员的沟通需求和沟通风格的分析；
2、缺乏完整的会议规程，会议目的，议程、职责不清，缺乏控制，导致会议效率低下，缺乏效果；
3、会议没有产生记录；
4、会议没有引发相应的活动；
5、沟通方式单一；
6、没有进行冲突管理；
问题二：提高项目例会的效果的方法：
1、事先制定一个例会制度，在项目沟通计划里，确定例会的时间，参加人员范围，一般议事议程等；
2、放弃可开可不开的会议，在决定召开一个会议之前，首先应该明确会议是否必须举行，还是通过其他方式进行沟通；
3、明确会议的目的和期望的结果，明确要开的会议的目的，是集体讨论一些想法，彼此互通信息还是解决面临的一个问题，并确定会议的效果是以信息同步为结束还是要讨论出一个确定的解决方案；
4、发布会议通知，在会议通知中明确：会议目的、时间、地点、参加人员、会议议程和议题。有一种被广泛采用的决策方法是：广泛征求意见，少数人讨论，核心人员决策。许多会议不需要全体人员参加，因此需要根据会议的目的，来确定参会人员的范围。实现应明确会议的议程和要讨论的问题。可以让参会人员提前做准备；
5、在会议之前把会议资料发放到参会人员手中。对于需要有背景资料支持的会议，应是先将资料发给参会人员，以提前阅读，直接在会上讨论。可以有效地节约会议时间；
6、可以借助视频设备。对于有异地成员参加的会议，或者需要演示的场合，可以借助于一定的视频设备，以提高会议效果；
7、明确会议规则。指定主持人，明确主持人的职责，主持人要对会议进行有效控制，并营造一个活跃的会议气氛。主持人要实现陈述会议的基本规则，例如明确每个人的发言时间，每次发言只有一个声音，主持人根据会议的议程规定控制会议的节奏。保证每一个问题都得到讨论；
8、会议后要总结，提炼结论。主持人在会后总结问题的讨论结果，重申有关决议，明确责任人和完成时间；
9、会议要有纪要，如果将工作的结果、完成时间、责任人都记录在案，则有利于检查工作的完成情况；
10、做好会议的后勤保障，很多会议兼有联络感情的的作用，因此需要选择一个合适的地点，提供餐饮、娱乐和礼品，制定一个有张有弛的会议议程。对有客户和合作伙伴参加的会忆尤其如此。问题三：除了项目例会外，老张还可以采取的有效沟通措施：
1、首先应该对项目组成员进行沟通需求和沟通风格的分析；
2、对于不同沟通需求和沟通风格的成员设置不同的沟通方式；
3、除了项目例会之外，可以通过电话、电子邮件、项目管理软件、OA软件进行沟通；
4、正式沟通的结果应该形成记录，对于其中的决定应该有人负责落实；
5、可以引入一些标准的沟通模板；
6、在项目组内培养团结的氛围。
㈢人力资源管理在实施项目中的应用 王先生是负责某行业一个系统集成项目的项目经理，因人手比较紧张，王先生从正在从事编程工作的高手中选择小张作为负责软件子项目的项目经理，小张同时兼任模块的编程工作，这样导致了软件子项目的失控。
一、软件子项目失控的原因：
1、小张缺乏足够的项目管理经验和能力；
2、小张身兼二职，精力和时间不够用，顾此失彼；
3、小张没有进入管理角色，只关注于编程工作，疏于对项目的管理；
4、高级项目经理王先生对小张的工作缺乏事先培训和跟踪监督。
二、王先生应该这样做才能让小张成为项目经理，并避免项目失控：
1、事先要制定岗位的要求，职责和选人的标准，并选择合适的人选；
2、高级项目经理应对小张的工作进行全面的估算，如果小张的工作确实负荷过重，需要找人代替小张正在从事的技术工作，解决负载平衡问题；
3、要事前沟通，对小张明确要求，明确角色的轻重缓急，促使小张尽快转换角色；
4、上级应该平时注意对人员的培养和监控。
三、项目集成团队的角色构成1、针对选定的项目，根据项目的特点，需要的角色如下：
⑴管理类岗位：项目经理；⑵工程类岗位：架构师、分析师、网络工程师、软件工程师、测试工程师、和实施人员；⑶行业专家；⑷支援类：文档管理员、秘书。
2、组建项目团队、建设项目团队、管理项目团队所需的活动
⑴组建项目团队，明确责任，制定责任分配矩阵，制定组织结构图和职位描述；⑵建设项目团队，提高项目团队的个人绩效，提高项目团队个人之间的信任感和凝聚力，已通过更好的合作提高工作效率；⑶管理项目团队，跟踪个人和团队的执行情况，提供反馈、协调变更，以提高项目的绩效，保证项目的进度，项目管理团队还必须注意团队的行为，管理冲突，解决问题评估团队成员的绩效。
㈣甲方总是不验收项目？
某项目主要工作已基本完成,经核对项目未完成项目任务清单后,终于可以提交客户方代表老刘验收了。验收过程中老刘提出了些小问题,项目经理张斌带领团队很快妥善的解决了这些问题,但是随着时间的推移,客户的问题似乎不断.时间已超过了系统的试用期,但是客户仍然提出一些小问题,而有些问题都是客户方曾经提出过,并基本上已经解决了的问题.时间一天天的过去,张斌不知道什么时候项目才能验收,才能得到最后一批款项。
问题一：发生这件事情可能的原因：
1、合同缺乏以下内容：
⑴项目目标中关于产品功能和交付物的清晰描述；⑵项目验收标准、验收步骤和方法(流程)⑶对客户的售后服务承诺；
2、项目实施过程控制中出现问题：⑴在项目实施过程中没有及时传递绩效报告给客户，因此客户对项目进展和质量状况不了解；⑵没有让客户及时对阶段交付成果签字确认；
3、由于没有售后服务的承诺，客户担心没有后续的保证；
4、合作气氛不良，客户存在某种程度的抵触情绪，双方缺乏信任感，客户对项目质量信心不足，怕承担责任，因此不愿签字。
问题二：张斌应该怎么办：
1、就项目验收标准和客户达成共识，确定哪些主要工作完成就可以验收通过；
2、就验收的步骤方法和客户达成共识；
3、就项目已经完成的程度让客户确认，例如出具系统使用报告，让客户签字确认；
4、向客户提出明确的服务承诺。使客户没有后顾之忧。
问题三：应当吸取的经验和教训：
1、项目合同中要规定项目成果的正式验收标准，验收步骤，验收流程，和运营维护承诺等内容；
2、⑴加强项目执行过程中的控制包括：制定变更控制流程，按流程进行变更的进行变更的评估，审核、实施、记录、确认等工作；⑵加强项目沟通管理包括：及时向客户提供绩效报告，让客户了解项目进展，设置对阶段性成果的验收，并让客户对阶段性交付成果进行签字确认，项目文档要齐全，使项目进展有据可查。⑶加强计划执行的控制：制定详尽的项目管理计划(包括进度管理计划，成本管理计划的分项管理计划)，按计划实施和检查；
3、项目经理还应注重和客户交往的技巧，努力促成双方的良好合作氛围。㈤如何完成献礼项目
J公司2008年3月中标某市公安局的人口管理系统开发项目，因该是要在2008年11月举办某大型国际会议，因此公安局要求人口管理系统一定要在2008年7月1日前投入使用。强某是负责这个项目的项目经理，虽然他进公司不到三年，但他已成功管理过2个类似的项目，被大家称之为救火队长，而强某也对自己信心十足，但这次和以往不同的是强某还同时管理着另外两个项目，而这个人口管理项目工期要求紧，他能调用的人手少。
该人口管理项目属于升级项目，原来的系统是J公司开发，是C/S结构，智能管理本地城区常住人口，新的人口管理系统是B/S结构，要既能管理城区人口又能管理郊区常住人口，市辖县常住人口和流动人口，而公安局要求该新系统首先把流动人口管理起来，该项目从技术角度可以分为网络改造和软件开发，而软件又分为界面，业务流程和数据库三个子系统，他们团队共有6人，其中有人做过类似的C/S结构的项目，而公司刚刚结束的网络项目与本次承担的网络改造项目在技术上架构方面几近相同，只是规模不同，公安局要求新系统能够支持移动接入，而项目团队中没有一人接触过移动技术，强某凭直觉知道以现有的人员在2008年7月1日前完成项目是不可能的。
问题
一、请说明强某可以用什么方法和技术来估算项目的工期。
问题
二、请说明强某可以采取哪些方法来压缩工期，以使项目在2008年7月1日前完成。
问题
三、请说明强某可以采用哪些方法来跟踪项目的进度，以确保项目按时交付。问题
一、强某可以估算项目的工期的方法：
1、明确定义项目的工作分解结构（WBS）；
2、由于是升级项目，所以部分工作的工期估算可以采用类比估算法；
3、由于新增移动接入模块，可以联系业界专家，采用德尔菲法进行估算；
4、对于WBS进行足够细化后，可依据历史数据采用参数估算或三点估算进行进一步历时估算。问题
二、使项目在2008年7月1日前完成，强某可以采取的方法：
1、与客户进行沟通，梳理业务需求中的关键需求，与客户进行协商能否在期限前先完成关键需求，其他部分分期交付；
2、制定出合理可靠的技术方案，对其中不熟悉的部分，采取外包的方式；
3、清晰定义各功能模块之间的接口，然后进行并行工作；
4、明确目标，责任和奖惩机制，提高员工的工作绩效；
5、必要时，进行赶工。
问题
三、强某跟踪项目的进度的方法：
1、基于WBS和公式估算制定活动网络图，制定项目工作计划；
2、建立对项目的监督和测量机制；
3、确定项目的里程碑，并建立有效地评审机制；
4、对项目中发现的问题，及时采取纠正和预防措施，并进行有效地变更管理；
5、使用有效的项目管理工㈥副总裁的项目就能优先吗？
某电子政务项目涉及到保密信息，项目建设的资源尤其是人力资源，必须从甲方内部获得，如果把项目的部分任务交给分包商，一方面要征得甲方同意，一方面，要求分包商具有相应的保密资质，而保密资质的审核需要很长的时间，这将严重危及到项目的交付日期，当项目团队内的工程师完成90%的编程和测试任务时，项目承建单位的一位副总裁承揽了一个新的项目，他把程序员，测试工程师，从该项目上调走去从事新的项目。
问题
一、请简要说明发生上述情况的可能原因。
问题
二、简要叙述如果项目经理希望继续推进该项目，应如何进行？
问题
三、请简要叙述如何处理多个项目之间的资源冲突。
问题解答：
问题
一、发生上述情况的原因：
1、可能是单位没有对项目进行统一管理，谁的权大谁的项目就获得优先支持。
2、副总裁承揽了新的更重要的项目。
3、项目经理忽略了单位内部可能的竞争性项目的出现所带来的风险。
4、可能是本项目的绩效不好，已失去了单位有关方面的支持。
5、可能是重要干系人如客户、公司高层管理者内定项目暂停或者下马。
问题
二、项目经理希望继续推进该项目，应当：
1、如果经评估后，认为项目尚可，就应写出反应该项目现状与前景预测的报告，向主管领导汇报，说服和沟通，陈述该项目的重要性和预期利润，如果项目下马会造成的损失等，已得到及时和满足要求的资源支持。
2、因本项目要保密，所以要用本单位可靠和能干的人员，如果单位人手不够，尽量让本单位其他非涉密项目去社会招聘或者外包。
3、如果只剩下不到10%的工作，应说服原来的团队成员加班赶工完成项目。
问题
三、处理多个项目之间的资源冲突：
1、建议单位统一管理所有的项目和资源，制定资源在项目之间的分配，2、定期检查项目的执行情况，根据项目进展情况和企业整体绩效重新安排项目的优先顺序，从资源上支持重要的和进展良好的项目。
3、外包
4、必要时，增加资源
5、建立项目管理体系，设立项目管理办公室，统一管理单位所有的项目。
㈦如何保证项目按期完工
某系统集成公司现有员工50多人，业务部门分为销售部，软件开发部系统网络部等，经过近半年的酝酿后，一月，公司的销售部与银行签订了一个银行前置机的软件系统项目，合同中规定，6月28日前系统必须投入试运行，在合同签订后销售部将此合同移交给了软件部，进行项目的实施。项目经理小丁经历了五年的系统分析和设计工作，但这是他第一次担任项目经理，小丁兼任系统分析工作，此项目还有两名1年工作经验的程序员，1名测试人员，2名负责组网和布线的系统工程师，项目组的成员均参加项目工作。
在承担项目之后，小丁组织大家制订了项目的WBS，并依照以往的经历制订了本项目的计划，简单描述如下：
1、应用系统子系统
(1)1月5日-2月5日，需求分析
(2)2月6日-3月26日，系统设计和软件设计
(3)3月27日-5月10日编码
(4)5月11日—5月30日，系统内部测试
2、综合布线
2月20日—4月20日，完成调研和布线 3，网络子系统
4月21日-5月21日，设备安装联调 4，系统内部调试验收
(1)6月1日—6月20日，试运行(2)6月28日，系统验收
春节后，在2月17，小丁发现系统设计刚开始，推测3月26日根本完不成系统设计 问题
一、问题的可能原因：
1、项目部没有及时让软件部参与项目早期工作，需求分析耗时过长；
2、项目经理经验不足，进度估算不准确；
3、项目资源分配不足，缺乏专门的系统分析和设计人员；
4、工作安排没有充分利用分配的项目资源，资源有闲置；
5、在安排进度时，可能未考虑节假日的因素。问题
二、，保证项目整体进度不拖延，建议小丁应该：
1、向职能经理申请增加特定资源，特别是要增加系统分析设计人员；
2、临时加班、赶工，尽可能补救耽误的时间，或提高资源的利用效率；
3、将部分阶段的工作改为并行进行；
4、对后续工作的工期重新进行估算，并考虑节假日问题，修订计划尽量留有余地；
5、加强沟通，争取客户能够对项目范围，以及需求、设计、验收标准、进行确认，避免后续频繁出现变更；
6、加强对阶段工作的检查和控制，避免后期出现返工。此外，如有可能还可以采取外包和采取缩减范围等方法，不建议在本案中用。
问题
三、典型的信息系统集成项目的进度、时间管理的过程和方法：
1、活动定义；
2、活动排序；
3、活动资源估算；
4、活动历时估算；
5、制定进度计划；
6、进度控制
资源配置对进度的制约：在一般情况下，项目活动的历时与项目的规模成正比，与投入的资源数量成反比，即投入的资源数量越多，活动历时越短，但要注意，任何活动都有其压缩点，当活动的历时已达到自身的压缩点后，增加再多的资源也无法压缩活动历时。在一非关键活动的一个较大时间延误也许只对项目产生较小的影响㈧如何定量的管理项目的进度
一个预算100万的项目，为期12周，现在工作进行到第八周，已知成本预算是64万，实际支出是68万，挣值为54万。
问题
一、计算成本偏差CV，进度偏差SV，成本绩效指数CPI,进度绩效指数SPI.CV=EV-AC=54-68=-14万元 SV=EV-PV=54-64=-10万元 CPI=EV/AC=54/68=0.794 SPI=EV/PV=54/64=0.843
问题
二、根据给定数据画出该项目的预算成本，实际成本和挣值图
问题
三、对以下四表，分别分析其所代表的效率，进度和成本情况，针对每副表所反映的问题，可采取哪些措施？㈨如何让甲方对项目质量放心和满意 某信息技术有限公司中标了某大型餐饮连锁企业集团的信息系统项目，该项目包含单点管理，物流系统，和集团ERP等若干子项目，由该信息技术有限公司的高级项目经理张先生全面负责项目的实施，张先生认为此项目质量管理的关键在于系统的进行测试。
张工制订了详细的测试计划用来管理项目的质量，在项目实施过程当中，他通过定期发给客户测试报告来证明质量是有保证的，可是客户总觉得有什么不对劲，对项目的质量还是没有信心。
问题
一、客户对项目没有信心的原因可能是：
1、张工没有为项目制定一个可行的项目质量管理计划并积极地实施；
2、仅向用户提交测试报告而没有提交全面质量管理进展情况报告（或实施报告），沟通方式单一（或不全面），容易误导客户，容易导致客户不必要的担心。
问题二、一般地，项目的管理计划包括的内容：
1、质量责任与人员分工（或职责）；
2、组织结构；
3、程序与过程（或项目的各个过程及其依据的标准）；
4、质量控制地方法、工具、与重点（或质量评审、质量保证方法）；
5、质量管理所需的资源；
6、验收标准。
问题
三、张工应该如何实施项目的质量保证：
1、张工应该首先执行项目的质量管理计划；
2、采用质量保证的工具和技术（如编制质量计划时所采用的工具和技术、质量审计、质量控制、过程分析与基准分析）等；
3、提出相应的质量整改措施，如建议的纠正措施，对项目计划的可能的更新，对组织资产可能的更新，变更请求。项目的质量控制与质量保证的区别与联系：
1、质量计划是质量控制和质量保证的共同依据；
2、达到质量要求是质量控制和质量保证的共同目的；
3、质量保证的输出是下一阶段质量控制的输入；
4、一定时间内质量控制的结果也是质量保证的质量审计对象，质量保证的成果又可以指导下一阶段的质量工作，包括质量控制和质量改进；
5、质量保证一般是每隔一定时间如阶段末进行的，主要通过系统的质量审计来保证项目的质量（或质量保证是按质量管理计划正确的去做）；
6、质量控制是实时监控项目的具体结果，以判断他们是否符合项目的相关标准，制定有效方案，以消除产生质量问题的原因（或质量控制检查是否做的正确并进行纠正）。
(十一)与领导工作风格不一样怎么办？
钱某新接手一个信息系统集成项目的管理工作，根据用户的业务要求，该项目要采用一种新的技术架构，项目团队没有应用这种架构的经验，钱某的管理风格是 Y型的，在该项目启动之初，为了调动大家的积极性，宣布了多项激励措施，如按期用该技术架构搭建出系统原型有奖，并分别公布了具体的奖励金额，在项目实施期间，为了激励士气，经常请大家聚餐，由于单位领导属于X型的管理风格，很多餐票都不予报销，而在项目实施现场，因施工人员技术不过关，导致一台电源烧毁，钱某也悄悄在项目中给与报销，负责新技术架构的架构师经历多次失败后，总算凭自己的经验和探索搭建出了系统原型。最后，虽然项目的实际进度、成本和质量等目标大体达到了要求，钱某自我感觉尚可，项目好歹也通过了验收，但他当初关于奖励的承诺并没有兑现，有人甚至认为他和领导一唱一和，钱某有苦难言。
问题
一、请概括出钱某在人力资源管里方面的问题。
问题
二、钱某应该用那些措施进行团队建设，如何应用自己的Y型风格有效地管理项目？
问题
三、请叙述钱某的单位和钱某应该如何处理新技术开发和项目管理之间的关系。
问题解答：
问题
一、钱某在人力资源管里方面的问题：
1、奖励政策没有得到领导的同意（或支持、沟通）
2、Y型管理风格没有与切实可行的规章制度（或措施、机制）相结合3、钱某的管理风格没有与直接领导的管理风格相协调
4、没有对员工进行培训
5、没有配备有经验的人员（或人力资源获取方式单一）
问题
二、钱某应该用那些措施进行团队建设
1、一般管理技能（如沟通、交流）
2、培训
3、团队建设活动（如周例会、共同解决问题、拓展训练）
4、共同的行为准则（或基本原则、规章制度）
5、尽量集中办公（或同地办公、封闭开发）
6、认可奖励（或恰当的奖励与表彰措施）如何应用自己的Y型风格有效地管理项目
1、Y性的管理风格，要与切实可行的规章制度相结合，与领导风格相一致，或相适应
2、加强对团队成员的培训，或教育
3、加强激励与约束并重
问题
三、请叙述钱某的单位和钱某应该如何处理新技术开发和项目管理之间的关系。
1、培训
(十二)中途接手的项目如何完成某系统集成商B负责大学城A的3个校园网的建设，是某弱电总包商的分包商，田某是系统集成商B的高级项目经理，对三个校园网的建设总负责。关某、夏某和宋某是系统集成商B的项目经理，各负责其中一个校园网的建设，项目建设方聘请了监理公司对项目进行监理。
系统集成商B承揽的大学城A的校园网的建设项目，计划从2002年5月8日启动，至2004年8月1日完工，期间因项目建设方的资金问题，整个大学城的项目延后5个月，其校园网的开工日期也顺延到2005年1月1日，期间田某因故离职，其工作由系统集成商B的另一位高级项目经理包某接替，包某第一次拜访客户时，客户对项目状况非常不满，和包某一起拜访客户的有系统集成商B的主管副总、销售部总监、销售经理和关某，夏某和宋某3个项目经理，客户的意见如下：
1、你们负责的校园网进度一再滞后，你们不停的保证又不停的延误，2、你们在实施自己的项目过程中，不能与其他承包商配合，影响了他们的进度
3、你们在项目现场，不遵守现场的管理规定，造成现场的混乱
4、你们的技术人员技术太差，对我方的询问，总不能及时答复
5、……….听到客户的意见，包某很生气，而关某、夏某和宋某也向包某反映项目现场的确混乱，他们已完成的工作经常被其他承包商搅乱，但责任不在他们，至于客户的其他指控，关某夏某和宋某则显得无辜，他们管理的项目不至于那么糟糕，他们的项目进展和成绩客户一概不知，而问题却被扩大和扭曲。
问题
一、发生上述情况的原因有哪些？ 问题
二、承建方应如何与监理协同？ 问题
三、如何制定有多个承包商参与的项目沟通管理计划？
问题解答：
问题
一、发生上述情况的原因：
1、自己内部管理有问题，至少监管缺位或不得利
2、集成商B没有或很少与客户直接沟通
3、没有建立现场管理制度，或者现场管理制度不严密或不明确，现场管理制度执行不力
4、总承包商和分包商责任不是十分清楚
5、客户从总承包商和分包商获得的信息失真，总承包商报告渲染了问题，推卸责任
6、客户自己本身的原因，如资金、管理水平
7、可能本项目的监理工作没有到位 问题
二、承建方与监理协同应该：
1、承建方应该认识到位，承建方和监理方不是对立关系，他们有共同的目标：把项目搞好
2、双方都采用项目的管理方法承建方配合问题
三、多个承包商参与的项目沟通管理计划的制定：
1、做好干系人分析，调研各集成商的沟通需求
2、发挥总承包商的牵头作用和监理方的协调作用
3、对共用资源的可用性分析，引入资源日历
4、解决冲突，包括项目干系人对项目期望之间的冲突，资源冲突等。
5、建立健全项目管理制度，并监管其执行
6、采用项目管理信息系统
㈩三参数关系 分析 措施图1 AC>PV>EV 效率低 进度拖延
投入超前 提高效率，例如，用工作效率高的人员换一批工作效率低的人员，赶工，工作并行以追赶进度，加强成本监控图2 PV>AC>=EV 进度效率较低 进度拖延
成本支出与预算相差不大 增加高效人员投入，赶工，工作并行以追赶进度图3 AC>=EV>PV 成本效率较低 进度超前
成本支出与预算相差不大 提高效率，减少人员成本，加强人员培训和质量控制图4 EV>PV>AC 效率高 进度提前
投入延后 密切监控，加强质量控制
(十三)如何签订和履行合同
小李是国内公司的项目经理，负责西南某省的一个企业信息系统项目建设的管理。在该项目合同中，简单列出了项目承建方应该完成的工作，据此小李自己制定了项目的范围说明书，甲方的有关工作由其信息中心组织和领导，信息中心主任兼任该项目的甲方经理。可是在项目实施过程中，有时是甲方的财务部直接向小李提出变更需求，有时是甲方的销售部直接向小李提出变更需求，而且又是这些需求又是矛盾的，面对这些变更需求，小李试图用范围说明书来说服甲方，甲方却动辄用合同的响应条款作为依据，而这些条款要么太粗，不够明确，要么小李与他们理解不同，因此小李对这些变更需求不能简单的接受或拒绝而左右为难，他感到很沮丧，如果不改变这种状况，项目看来是遥遥无期。问题
一、问题产生的原因：
1、合同没有制定好，没有对具体完成的工作行程明确清晰的条款；
2、甲方没有对各部门的需求及其变更进行统一的组织和管理；
3、缺乏变更/拒绝的准则；
4、由于乙方对项目的干系人及其关系分析不到位，缺乏足够的信息来源，范围定义不全面，不准确；
5、甲乙双方对项目认可和承诺；
6、缺乏项目全生命周期的范围控制；
7、缺乏客户/用户参与。
问题
二、在合同谈判、计划和执行阶段应该：
合同谈判阶段：
1、确定明确的工作说明书或更细化的合同条款；
2、在合同中明确双方的权利和义务，尤其是关于变更问题；
3、采取措施，确保合同签约双方对合同的条款理解是一致的。
计划阶段：
1、编制项目范围说明书；
2、创建工作的分解结构；
3、制定项目的范围管理计划。
执行阶段：
1、在项目执行过程中加强对易分解的各项任务的跟踪和记录；
2、建立与项目干系人进行沟通的统一渠道；
3、建立整体变更控制的规程并执行；
4、加强对项目阶段性成果的审核确认
项目全生命周期变更管理：
1、在项目管理体系中应该统一有一套严格、适用、高效、的变更程序；
2、规定对用户的范围申请变更请求、应正式提出变更申请，并经双方项目经理审核后，作出相应的处理。问题
三、合同的作用，详细范围说明书的作用，以及两者之间的关系
合同法规定，合同是平等主体的自然人、法人、其他组织之间设立、变更、终止民事权利义务关系的协议。合同是买卖双方共同遵守的协议。卖方有义务提供和保证规定的产品和服务。而买方有义务支付合同规定地价款。
项目范围说明书详细描述了项目的可交付物，和产生这些可交付物必须做的项目工作。项目范围说明书在所有项目干系人之间建立了一个对项目范围的共识，描述了项目的主要目标能使团队能进行更详细的
第四篇：系统集成项目管理案例分析教程 案例二团队协作
案例二团队协作
阅读以下关于信息系统项目管理过程中质量管理方面问题的叙述，回答问题1至问题3。
5.2.1案例场景
重庆市某行业关键应用IT系统(A系统)的建设工程由希赛信息技术有限公司(CSAI)中标，CSAI是国内一家大型IT系统集成商，企业通过了ISO9000质量体系认证和CMM3级认证，对信息系统工程建设有着比较成熟丰富的经验。
CSAI总部设在长沙，有软件研发中心。CSAI为A系统建设所组建的项目小组由两个部分组成：一是总部长沙负责进行软件开发工作；二是重庆现场负责进行信息系统的本地化实施，本地化实施的内容包括网络系统建设、主机系统安装调试、应用软件的运行环境建设、现场测试、客户需求跟踪、客户关系协调等。其中，应用软件开发的管理工作由长沙软件中心负责，A系统的配置
管理工作由现场负责。
CSAI对A系统应用软件开发的控制非常严格，可是，由于A系统在实施的过程中，用户不断地提出新的需求，催促要CSAI满足，而且，A单位的领导对进度非常关心，经常突袭检查，要求CSAI演示所建设的应用系统的功能。CSAI现场项目经理李工也试图通过与用户进行沟通，以求解决需求的频繁变更问题，解决用户对进度的要求等。
CSAI对现场项目经理有关于维护良好客户关系的绩效考核指标，因此，李工不敢怠慢客户所提出的要求，但为了达到A用户所提出的需求变更、进度变更，李工想法让长沙研究所满足客户的需求变更，这样，长沙研究所的软件开发工作量就大大增加，而且，常常赶不上客户对项目进度的要求。
在寄托于总部无望的情况下，李工为了在工程进度方面满足用户的愿望，于是决定将部分应用软件系统代码在现场进行开发。现场开发的目的主要是加快了软件开发的进度，李工的决定也确实很奏效，大大加快了应用软件开发的进度。但是，当应用软件系统投入运行后，系统故障的发生频率却非常高，经过对故障的分析，李工发现，这些故障当中，由现场所开发的软件与长沙总部所开发的软件在协同工作中所暴露的问题尤为普遍，比如，现场所修改的软件代码，在长沙总部下发统一版本软件的时候常常被替换而丢失功能，A应用系统的本地化功能太多太偏而很难与统一版本融合。
另外，由于现场抽调人员参与应用软件开发，现场本应做的配置管理工作也被耽搁了，如网络系统的配置(设备访问权限、路由、IP规划等)、主机访问权限规划、应用系统访问权限规划、应用环境参数规划等，这些现场运行环境参数，按照B公司的管理制度，是应当编制文件存档的，但李工却没有安排人员来做这些工作。
由于网络系统庞大，中心机房设备繁多，参与工程建设的人员按照各自的习惯进行系统的配置，这样，在工程投入运行后，由于各部分配置的不规范，常常引起局部配置的变更给系统运行带来严重事故。曾经在一次配置变更过程中，由于应用系统密码的修改，导致系统停止业务半天，给用户造成了严重的损失和不良影响。
【问题1】(8分)
请以300字内回答，李工对所遇到的问题的处理方法是否恰当。李工所做出的决定的主要缺陷是什么？造成问题的原因主要是什么？
【问题2】(8分)
请以300字内回答，团队协同工作时，在软件版本方面会造成哪些问题，应当采取什么措施以避免问题的出现？
【问题3】(9分)
请以300字内回答，在IT应用软件开发工程中，怎样进行项目现场与总部软件开发团队的有效配合？
5.2.2案例分析
CSAI虽然通过了CMM3级认证、ISO9000认证，但CSAI的管理工作未必就能按照规范来开展，有不少公司只是将这些认证作为投标竞争时的砝码而已。因此，我们在建设工程项目的时候，不但要看IT系统集成商具不具备这些认证，还应采取有效的手段考核IT系统集成商的质量保证计划。对IT系统集成商进行考核，简便可行的方法就是让集成商在项目开工前提交质量保证计划，并对质量保证计划进行评审，通过后要求集成商严格执行。通常，过程能力成熟度高(指实际)的IT企业，在实际工程与质量保证计划之间的一致性会完成得较好，而过程能力成熟度低的企业(指实际)，实际工程与质量保证计划之间的一致性会完成得相对较差。
【问题1】
我们都知道，信息应用系统的变更尤其频繁，而频繁的变更必然影响到信息工程项目的三大目标。通常与客户接触最多的是现场项目经理，引导客户需求对项目经理就非常关键，项目经理引导得好，项目的开发就会非常顺利，反之，就会使项目组疲于奔命。优秀的项目经理是既能够让项目组成员“睡大觉”，又能保持良好的客户满意度。
CSAI项目经理李工与用户的沟通存在问题。善于沟通的人，一言明百理；不善于沟通的人，百言不明一理。项目经理与客户的沟通，不是指项目经理善于说话，善于高谈阔论就能够解决问题，更为关键的是项目经理要具备足够的引导项目建设的能力。作为现场项目经理，不是只做一个传话筒，客户说什么就是什么，而是应当与客户进行深入交流，深入分析客户所提出的问题，合理引导客户的需求，要有主见。
李工在CSAI进行客户满意度考核，客户又有大量需求的前提下，显得无所适从，手忙脚乱，而做出了不合适的决定。
一是客户的需求，只要我们能够合理引导客户，客户的需求变更不可能有那么频繁，有很多需求变更是可以让用户暂时放弃的，或有的需求变更可以让用户在另外的工程项目中去实现，比如建议用户建设=期工程。我曾经见到一位项目经理在一个工程项目中，客户提出了一个需求，项目经理安排组员加班三天三夜完成了，告诉客户方主任，客户主任大吃一惊，说：“我并没有要求你们实现这个需求啊，我只不过向你们咨询一下而已”。
客户与我们的项目经理交谈，并不是都谈需求，有很多时候，客户可能是谈到自己的想法、心得体会、建议等。客户方面也往往有很多员工，一位员工有一种思想，十位员工就有十种思想，要统一这十种思想，项目经理就得付出更多的努力，要与用户方面的主管人员达成一致，而且，很多时候是必须要用户的主管人员去统一他们的意见。否则，应用系统的开发就存在很大制约因素。很多项目经理面对公司客户满意度的考核，面对客户无休止的需求，常常不能采取正确的应对方法，该说的不敢说了，该讲的不敢讲了。应用软件工程在建设阶段，优秀的项目经理应当是能够引导用户思路的项目经理，而不是让用户领导项目经理的项目建设思路。项目经理应当知道，任何一个客户都更注重项目建设的结果，在项目建设的过程中，项目小组与建设单位之间可能存在着很多次交流，甚至争论，但只要我们能确保项目建设的结果让用户满意，用户是终会给予好评的。
【问题2】
二是对CSAI资源的利用不当，李工把本不属于现场的工作内容，让现场工程师来完成是严重的失误，现场工程师仓促上阵，没有纳入CSAI统一的软件开发质量管理体系。虽然能够临时快速解决问题，但也会埋下故障隐患，而故障隐患的爆发却是在工程建设的后期。这种做法只能让员工疲于奔命。在项目管理中，如果项目组成员总是处于应急、救火的状态，是不可能高质量地完成工作任务的。作为项目经理，不但要关心项目的进展，还应当关心自己的成员，要让项目小组成员在高效率、高质量的状态下工作。
三是忽略了现场应该做的重要工作，应用系统的配置管理工作对现场来说是很重要的。混乱的配置管理，也会导致系统运行中发生严重的质量问题。
即使李工非要在现场进行开发不可，那也应当自觉地将现场所开发的软件，与公司总部所开发的应用软件进行统一的管理。特别是要注意，现场开发的缺点是对需求的把握太随意，由于开发人员与用户直接接触，用户的想法可能有很多偏激的成分，也容易被现场开发人员设计到应用软件系统中，从而导致现场版本与统一版本难以融合，特别是对有些需求的满足，可能涉及到软件系统体系架构的变更，这样就更难处理了。而现场临时决定的软件开发，管理工作怎样和总部的管理工作融合到一起，项目经理是应当考虑的，要么是由总部来控制，要么是现场自觉与总部配合。
【问题3】
我们在工程现场实施的时候，对于所遇到的系统问题，有的是能够迅速解决的，也有暂时无法解决的。对于暂时无法解决的问题，我们常常采取迂回的方式绕过去，以保证工程项目的进度。但是对于应用软件系统的开发来说，现场不能只是绕过去而已，还应当及时向总部报告，应当建立一个系统故障管理平台，记录所有发现的软件故障，逐一报告研发中心进行解决，并跟踪解决情况。
为有效解决现场与总部的配合问题，可以建设一个基于Internet的开发管理平台，现场所遇到的问题，及时汇报到管理平台，由总部管理人员分配解决。现场也可通过管理平台主动与总部沟通软件开发问题，协调一致，避免总部统一版本更新时丢失现场所开发的功能。配置管理也是涉及到工程质量的。我们做企业级的应用系统，都应当考虑到系统割接的平滑性，配置变更的平滑性，在进行配置规划的时候就应当考虑配置的变更怎样才能实现平滑过渡，否则，就很可能使运行的系统在进行配置变更的时候进入瘫痪状态。而良好的配置管理，又是实现配置变更平滑过渡的有力支持。
5.2.3参考答案
【问题1】(8分)
现场用户的需求是不可能有尽头的，但作为项目经理要能够把握住用户的需求，特别是要合理引导用户需求，切不可让用户怎么说就怎么做。
积极响应客户需求要从多个方面着手考虑，不要只从技术上考虑问题，技术引导、合同变更、人力资源等各个方面都应当考虑。
临时的现场开发工作，大多数都不可能与公司总部的软件开发融为一体，而且管理工作常常是自上而下的，李工忽略了这点，顾此失彼，导致项目问题的发生。
造成项目问题的原因有以下几点：李工对需求把握随意；控制不严；李工与客户沟通不到位；李工没有向客户提交合理的进度计划，或没有按时提交进度报告；项目实施无计划，或计划不能得到客户认可，客户不满意。
【问题2】(8分)
团队协同开发软件时，很容易出现软件版本管理不善带来的软件系统故障。同一软件系统代码不能同时由多人进行修改。
项目现场为应急而擅自更改软件代码，而常常没有将更改纳入统一的版本管理，很容易造成总部发行新版本软件时，替换软件而丢失了现场所进行更新的代码，从而造成系统故障反复出现。
李工如果一定要进行现场开发，应当委托现场合适的人员，或亲自督促现场所进行的开发工作与总部所进行的开发工作在软件版本方面保持一致，处理本地过于偏激的需求要与总部协商一致的情况采取合理措施控制统一版本。
【问题3】(9分)
项目现场应明确自己的工作职责范围，要自觉与总部门形成密切的配合。
现场所做的开发，应与总部所做的开发纳入同一个软件版本管理。
当现场发现软件故障时，应当及时向总部报告。建立故障管理表，记录并跟踪软件系统故障解决情况。
建设一个软件开发交流平台，如基于Internet的管理平台，管理工程现场所提出的问题，调度、跟踪解决工程现场问题。
现场工程人员与总部人员应多交流，通过各种方式，如及时通信软件、电话、电子邮件等，必要时，可组织研发部给现场工程人员进行培训。
第五篇：系统集成项目管理案例分析教程 案例二沟通渠道
案例二沟通渠道
阅读以下关于信息系统项目管理过程中团队建设和项目沟通管理问题的叙述，回答问题1至问题3。
7.2.1案例场景
希赛信息技术有限公司(CSAI)是由某集团投资建立的致力子为教育行业提供针对信息技术咨询、开发、集成的专业应用解决方案提供商，在“数字化校园”领域具有多年的研发经验和相当数量的客户成功案例。经过长时间的使用和改进，系统已经日趋成熟，获得了广大用户的信赖。目前通过和有关银行的合作，综合考虑了学校的需求，为“数字化校园”推出了软、硬件结合的“银校通”完整解决方案。
半个月前，CSAI和U大学合作建设的“银校通”项目正式立项。由于CSAI已有比较成熟的产品积累，项目研发工作量不是特别大。张工被任命担任该项目的项目经理，主要负责项目管理和用户沟通等工作。张工两个月前刚从工作了五年时间的B公司辞职来到CSAI，由于B公司主要从事电子政务信息系统的集成，故张工在“数字化校园”的业务方面不是特别熟悉。
项目组成员还包括李工、小王、2名程序员和1名测试人员，李工主要负责项目中的技术实现，小赵和小高2名程序员主要负责程序编码工作，小王负责项目文档的收集和整理。在CSAI，李工属于元老级的人物，技术水平高也是大家公认的，但李工在过去作为项目经理的一些项目中，工作上常由于没有处理好客户关系为公司带来了一些问题。
小王的工作虽然简单但是格外繁重，因而多次向张工提出需要增派人员，张工也认为小王的工作量过大，需要增派人手，因此就事多次与CSAI项目管理部门领导沟通。但每当CSAI项目管理部门就此事向李工核实情况时，李工总是说小王的工作不算很多，而且张工的工作比较轻松，让张工帮助下小王就可以了，不需要增派人员。因而CSAI项目管理部门不同意张工关于增加项目组成人员的建议。
张工得到CSAI项目管理部门意见反馈后，与李工进行了沟通，李工的理由是张工的工作确实不多，总是帮别人提意见，自己做得不多。所以李工认为张工有足够时间来帮助小王完成文档工作。张工试图从岗位责任、项目分工等方面对李工的这个误解进行解释，又试图利用换位思维的方法向李工说明真实情况，但李工依旧坚持自己的看法，认为张工给自己的工作太少。
【问题1】(8分)
什么是项目沟通管理中的沟通渠道，沟通渠道与沟通复杂性的关系怎样，试根据沟通渠道的计算公式计算该项目小组内部沟通渠道的数量。请用300字以内文字回答。
【问题2】(9分)
请用500字以内文字分析该项目中存在的主要项目管理问题，并针对问题提出建议。
【问题3】(8分)
请用200字以内文字结合你本人的实际经验，就软件项目中如何改进项目沟通提出实质性的建议。
7.2.2案例分析
【问题1】
沟通渠道(Communication Channels)是项目中沟通的排列组合数量，看起来像联系所有参与者的电话线的数目。
CC = N(N-1)÷2其中CC表示沟通渠道 N表示项目中成员数
比如当项目团队有3个人时，沟通渠道数为3×(3-1)÷2=3;而当项目团队有9名成员时，沟通渠道数为9 ×(9-1)÷2=36。由于沟通是需要花费项目成本的，所以应尽量控制团队规模，避免大规模团队中常常出现的沟通不畅的问题。
沟通的复杂性会随着项目中人员的增加而增加，项目沟通渠道急剧增加，沟通偏好差异化矛盾上升。地理位置和文化背景也会影响到项目沟通的复杂性。如果利益相关者来自不同的国家，那么通常在正常的工作时间安排双向的沟通会非常困难甚至不可能。语言障碍也可能给沟通带来一些问题。接收者对信息的解释很少与发送者想的一模一样。因此，提供多种沟通方法和一个能促进坦诚对话的环境是很重要的。
根据项目案例的场景描述，项目组成员包括张工、李工、小王、2名程序员和1名测试人员。项目组成员总数为6人，根据沟通渠道数计算公式，该项目小组内部沟通渠道的数量为6 ×(6-1)÷2=15。
【问题2】
根据案例的场景，项目经理张工两个月前刚来到C公司，在C公司从事的“数字化校园”的业务方面不是特别熟悉，在C公司张工的资质相对较浅。李工是C公司的元老级人物，一个资质比较老的技术人员。根据项目经验，项目经理没有威信，一般工作很难开展。为了项目目标的实现必须依靠技术人员的积极配合，作为项目经理张工应该加强团队建设，逐步树立自己的威信，消除项目组成员沟通中的一切障碍，保证团队沟通顺畅。根据项目案例的场景描述，项目中出现的主要问题集中体现在三个方面：
(1)项目经理角色定位问题
作为项目经理，张工应该能较好地把握全局。对于软件开发项目，工作量估算、人力资源管理和沟通管理等方面显得特别重要，张工在这些方面存在较大的欠缺，尽快熟悉公司业务是张工成为合格的项目经理必须解决的首要问题。
特别地，针对小王的问题。张工必须充分地了解小王文档编写工作的实际情况，以客观地判断小王是否真的因为文档太多而忙不过来，还是因为小王的工作方法不当、工作效率低导致“忙不过来”。根据自己了解到的实际工作状况决定是向C公司项目管理部门还是帮助小王改进工作方法、提高效率解决小王忙不过来的问题，以避免不必要的人员和成本增加。
(2)团队建设与协作方面的问题
C公司项目管理部门对张工担当项目经理没有做充分的授权，对张工缺乏必要的信任和支持。李工自恃是C公司的元老级人物，技术水平高而对张工的项目管理工作没有认可。事实上，软件企业中常存在这样的角色，很多时候也为项目管理带来了许多问题。项目组成员总体缺乏协调和配合，表现出对立与矛盾的僵化局面。
对于李工，他的问题可能是技术人员可能都有的通病，认为沟通不是什么真正的工作，技术工作才是项目成功的关键问题，而且确实不知道张工每天在做些什么。
(3)沟通不畅
该项目组沟通上存在很大问题，张工或许应该先自我检讨一下，与领导之间的沟通是否存在什么问题。其次，在李工的方面，其实对待技术人员用“尊重”一般都比较有效，建立良好的个人关系，从各个方面去关心你的项目组成员，尤其是关键人物。“元老级人物”是麻烦的制造者，但如果项目经理关系处理得当，有时可以把负面影响转变为正面。
项目组所有成员，特别是张工、李工、小王应该相互理解和支持，保持充分的沟通，毕竟作为一个项目团队，理解和沟通是很重要的，没有畅通的沟通这个基础，项目进展也是不可能很顺利的。张工应该加强与李工的交流，甚至应该加强一下私人关系，否则总有类似的成员向领导说反话的话张工的工作会受到很大干扰。如果李工的不合作精神依旧，可以考虑让李工离开自己的团队，另行委派别的技术人员。
【问题3】
根据软件企业项目管理实际情况，改进项目沟通的建议包括：
(1)使用项目管理信息系统(PMIS)辅助沟通
项目管理的复杂性要求有合适的工具辅助项目管理人员进行项目管理工作。项目管理信
息系统(PMIS)是用于收集、综合和分析项目管理过程输出的工具和技术。通常用来支持项目从启动到收尾的各个方面，可分为人工系统和自动系统。这里主要指能够帮助项目进行范围管理、时间管理、成本管理、采购管理、风险分析等综合功能的管理信息系统。PMIS一般包含两块核心的功能—计划和控制。计划系统主要围绕质量、时间、成本三大目标，辅助完成项目计划工作，如工作结构分解(WB S)、进度计划(网络图、甘特图)绘制、CPM、成本计划等。控制系统重要提供一些控制手段，以领导和协调项目组织的各种要素，包括人力资源、工程设计、原材料和财务等部门。
(2)建立沟通基础结构
沟通基础结构(Communications Infrastructure)是一套工具、技术和原则，为项目信息传送提供一个基础。工具包括电话机、传真机、电子邮件、项目管理信息系统、视频会议系统、文件管理系统及文字处理程序等；技术包括报告指导方针、文档模板、会议基本规则和程序、决策过程、解决问题的方法、冲突解决和协商技术及与此相似的技术；原则包括提供开放式对话的环境，使用“率直交谈”和遵照公认的工作道德规范。
(3)使用项目沟通模板
为使项目中日常沟通更容易，组织项目管理部门需要为一般的项目沟通建立一些范例和模板，如项目章程、绩效报告和口头状态报告等。以往项目的好文档是范例的丰富的来源。书面的和口头的范例和模板对于从来没有写过项目文件和做过项目陈述的人来说，特别有帮助。文档模板需要进行维护和升级，以适应项目实际工作要求的需要。建立和维护项目管理文档模板文件库是组织项目管理部门重要工作职责之一。
(4)把握项目沟通基本原则
在信息系统项目中，为了提高沟通的效率和效果，需要把握：沟通内外有别；非正式的沟通有助于关系的融洽；采用对方能接受的沟通风格；沟通的升级原则；扫除沟通的障碍等基本原则。
(5)发展更好的沟通技能
有些人似乎天生就有很好沟通能。有些人则有学习技术技能的诀窍，但很少发现有人天生就拥有上述两种技能。然而，沟通技能和技术技能都能学习提高。多数IT专业人员因其技术技能而得以进入这个领域。然而，多数人发现沟通技能是提升职位的关键，特别是如果他们想成为优秀的项目经理。
沟通技能培训通常包括角色扮演活动，通过这些活动让参与者建立协同的观念。培训课还为参与者提供机会去发展在小组中沟通的特殊技能。着重于表达能力的培训课通常把参与者的表现记录在录像带上。多数人对他们在录像带中看到的言语上的特殊习惯感到惊讶。喜欢这种提高他们技能的挑战。在沟通和表达培训方面很小的投资就能为个人、项目和组织带来巨大的回报。这些技能比他们在技术培训课上学到的许多技能有更长的生命力。
(6)认识和把握人际沟通风格
认识和把握人际沟通风格，针对不同沟通风格的人，“个性化定制”，采用对方喜欢的方式去沟通，就会取得好的沟通效果。
要解决由于文化背景、工作背景、技术背景等因素造成的人们沟通过程中编码和解码过程中的偏差，需要了解影响沟通的重要因素之一人际沟通风格。不同的人表达同样的事会用不同的方式，原因是人们拥有不同的人际沟通风格。人际沟通风格可以简化为四种类型，即理想型、实践型(操纵型)、表现型(亲和型)、理性型(分析型)，四种风格有各自的表现特征。
(7)进行良好的冲突管理
冲突管理是利用沟通技能创造性地处理项目冲突的艺术。冲突管理的作用是引导这些冲突的结果向积极的、协作的而非破坏性的方向发展。许多信息系统项目都具有很高风险，这些项目要求项目组成员付出巨大努力，花费高昂，占用重要的资源，对组织内的工作方式有
广泛的影响。当风险高时，冲突就不可避免；当潜在的冲突高时，良好的沟通就是必要的。在这个过程中，项目经理则是解决冲突的关键人物。
解决冲突的五种基本策略包括：问题解决(Problem Solving)；妥协(Compromise)；圆滑(Smoothing)；强迫(Forcing)和撤退(Withdrawal)等。
(8)召开高效的会议
会议是项目沟通的一种重要形式。一个成功的会议能成为鼓励项目团队建立和加强对项目的期望、任务、关系和责任的工具。失败的会议会对一个项目产生负面的影响。例如：一个糟糕的启动会议(kickoff meeting)—在项目或项目阶段开始时举行的会议。所有重要的利益相关者在会上讨论项目目标、计划等等—可能会使一些重要的利益相关者决定不再支持该项目，许多人抱怨他们的时间浪费在一些不必要的或者缺乏计划的、糟糕的会议上。
7.2.3参考答案
【问题1】(8分)
沟通渠道(Communication Channels)是项目中沟通的排列组合数量，看起来像联系所有参与者的电话线的数目。
沟通的复杂性会随着项目中人员的增加而增加，项目沟通渠道急剧增加，沟通偏好差异化矛盾上升。地理位置和文化背景也会影响到项目沟通的复杂性。如果利益相关者来自不同的国家，那么通常在正常的工作时间安排双向的沟通会非常困难甚至不可能。语言障碍也可能给沟通带来一些问题。接收者对信息的解释很少与发送者想的一模一样。
根据案例的场景描述，项目组成员包括张工、李工、小王、2名程序员和1名测试人员。项目组成员总数为6人，根据沟通渠道数计算公式，该项目小组内部沟通渠道的数量为6 ×(6-1)÷2=15。
【问题2】(9分)
根据案例的场景，项目中出现的主要问题集中体现在三个方面：
(1)项目经理角色定位问题
作为项目经理，张工应该能较好地把握全局。对于软件开发项目，工作量估算、人力资源管理和沟通管理等方面显得特别重要，张工在这些方面存在较大的欠缺，尽快熟悉公司业务是张工成为合格的项目经理必须解决的首要问题。
(2)团队建设与协作方面的问题
C公司项目管理部门对张工担当项目经理没有做充分的授权，对张工缺乏必要的信任和支持。李工自持是C公司的元老级人物，技术水平高对张工的项目管理工作没有认可。事实上，软件企业中常存在这样的角色，很多时候也为项目管理带来了许多问题。项目组成员总体缺乏协调和配合，表现出对立与矛盾的僵化局面。
(3)沟通不畅
该项目组沟通上存在很大问题，张工或许应该先自我检讨一下，与领导之间的沟通是否有什么问题。其次，在李工这一方面，其实对待做技术的人用“尊重”一般都比较有效，建立良好的个人关系，从各个方面去关心你的组员，尤其是关键人物。“元老级人物”是麻烦的制造者，但如果项目经理关系处理得当，有时可以把负面影响转变为正面。
【问题3】(8分)
根据软件企业项目管理实际情况，改进项目沟通的建议包括：
(1)使用项目管理信息系统(PMIS)辅助沟通。
(2)建立沟通基础结构(Communications Infrastructure)。
(3)使用项目沟通模板。
(4)把握项目沟通基本原则。
(5)发展更好的沟通技能。
(6)认识和把握人际沟通风格。
(7)进行良好的冲突管理。
(8)召开高效的会议。
点击咨询 