举例说明之前工作中最失败的案例或者项目,失败原因是什么
篇一：项目范围管理案例
第2章 项目范围管理案例
项目的范围管理影响到信息系统项目的成功。在实践中， 需求蔓延”是信息系统失败最常见的
原因之一，信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能，无论是客户
的要求还是项目实现人员对新技术的试验，都可能导致信息系统项目范围的失控，从而使得信息系
统项目无论在时间、资源和质量上都受到严重影响。
2．1 案例一：范围定义
阅读以下关于信息系统项目管理过程中范围管理方面问题的叙述，回答问题1至问题3。
2.1.1 案例场景
希赛信息技术有限公司(CSAI 原本是一家专注于企业信息化的公司，在电子政务如火如荼的时候，开始进军电子政务行业。在电子政务的市场中，接到的第一个项目是开发一套工商审批系统。由于电子政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着全部信息，其中包括部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。
张工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同，有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。在项目交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致 70％的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写的部分代码才通过验收。由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也超出原计划的 100％。
【问题1】请不超过 300 字，对张工的行为进行点评？
【问题2】请从项目范围管理的角度找出该项目实施过程中的主要管理问题？不超过200字回答。
【问题3】请结合你本人实际项目经验，指出应如何避免类似问题？不超过200字回答。
2.1.2 案例分析
这是一个失败的项目，张工在项目管理中既有闪光点，也有失败的地方。但项目管理中的任何差错都会影响项目的结果，而范围管理的失误对项目的影响更为明显。模糊的项目范围定义、错误的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。
张工对项目范围有一定的把握。在范围定义中，张工发现了不同行业间具有不同的特点，电子政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求，政务内网与政务外网是该行业一致的标准，这与企业信息化是完全不同的。张工捕获到该需求，并对这个
需求进行了清晰的定义，根据瀑布模型的要求，对设计和实现都进行了严格的控制，因此在系统交付时完全满足了用户对保密性的要求。在这一点上，张工是成功的。如果在范围定义时忽略了行业标准，项目肯定会招致更大的失败。
但用户界面的风格和操作的便捷性也属于系统范围的一部分。与系统运行环境一样，我们通常称这类需求为隐性需求。这类需求往往不是由用户直接提出，而且受行业特点决定的范围所约束。对于电子政务来说，系统保持一致的风格非常重要。作为政府对公众开放的窗口而言，并不需要很强的个性化，但一致的界面风格可以体现出政务的严肃性。考虑到全体民众层次差异较大，大多数访问系统的用户一般都没有接受过系统使用的培训，操作的便捷性也是政务系统必须实现的功能之一。很明显，对于这些系统的隐性需求张工没有充分考虑，从而导致一而再，再而三的变更。
对于软件项目，所有的需求都必须经过清晰的定义，这些需求都是项目范围的一部分。张工仅仅注意了其中的一部分，而忽略了用户界面，最终导致项目的失败。
对于电子政务信息系统，尤其是面向公众开放的信息系统，范围定义更加困难。这些系统的最终用户几乎不会参加需求开发的工作，他们的需求都是间接的，通过政府部门的负责人传递到项目组。但最终用户的意见对项目的结果会有巨大的影响，这是就对范围管理提出了更高的要求。
除了在范围定义方面的问题外，张工在范围确认和范围控制方面也存在不小的失误。当系统第一次更改时，就应该意识到系统界面风格和操作便捷性的重要性。这时应该清晰地定义系统的界面风格和操作风格，并设法进行确认。如果采取了恰当的措施，第二次的变更是完全可以避免的。
在刚刚进入一个陌生领域的时候，其中充满了各种各样的风险。隐性的行规和行业特点都是项目范围的风险。面对这些风险，即使再细致的调研也无法完全避免，也不能完整定义系统的范围。
因此可以考虑采取原型法等方式来提前暴露风险，减少风险带来的损失。因此在案例中，张工也没有进行充分的风险管理，采用严格的瀑布模型增加了风险发生后带来的损失。
对于这个案例，缺乏良好的设计也是很明显的缺陷。用户界面中耦合了大量的业务逻辑，这必然增加变更的代价，从而导致大部分代码重写。若在项目初期意识到界面变更的风险，随之采用良好的设计，将表现层和业务逻辑彻底分开，系统变更的代价也会小得多。
综上所述，项目经理张工在整个案例中，针对范围管理做了一些工作，但不全面，在风险管理和质量管理上也都存在缺陷。
有了上面的分析，这道题就很容易作答。项目的闪光点在于对系统运行环境进行了清晰的定义，并最终满足了用户的要求；但不充分的范围定义和范围确认招致了项目的失败，而采用了抗风险能力较弱的瀑布模型和低质量的设计又雪上加霜，最终导致项目延期100%.
因此第一题答案的要点就很明确了：
(1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。
(2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付的重大变更。
(3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。
(4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。
(5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。对于第二题，是在第一题的基础上考察对范围管理的理解，因此可以忽略在其他领域的问题。在范围管理中主要包括如下内容：
(1)范围管理计划。
(2)范围定义。
(3)工作分解。
(4)范围确认。
(5)范围控制。
在本案例中，没有专门设计到范围管理计划和工作分解的内容。从表面上看，范围定义存在明显的缺陷。但案例中提到系统又发生了第二次变更，由此可见，张工在范围确认和范围控制上也存在不足。若在问题第一次出现时就进行有效的范围确认和范围控制，则完全可以避免第二次的变更。
因此，第二题的答案要点如下：
(1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。
(2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。
(3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。
在完成第二题后，第三题就是水到渠成了，第三题的要点见参考答案，此处不再赘述。 项目管理是一个系统工程，没有哪种单一的手段可以有效地改善项目，反之管理中的任何疏忽都可能招致严重的后果，造成项目的失败。而软件项目的复杂性又决定了项目中的工作环环相扣，问题也总是相互关联的。在发现问题后，也需要采取多种手段才能彻底解决问题。这对信息系统的项目经理来说是重大的挑战。
2.1.3 参考答案
【问题1】
(1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。
(2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付时的重大变更。
(3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。
(4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。
(5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。
【问题2】
(1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。
(2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。
(3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。
【问题3】
有效的范围管理包括了从范围定义到范围控制等多方面的工作，每一项工作都是重要的。对于本案例，要结合行业特点进行需求分析，挖掘系统潜在的需求，同时通过原型等方法来辅助需求的定义，避免范围定义不清晰的问题。
在发生需求变更时需要进行有效的需求控制，尽量在满足用户需求的前提下缩小需求范围，坚决避免需求的再次变更。
2．2 案例二：工作要点
阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述，回答问题1至问题2。
2.2.1 案例场景
M 集团是希赛信息技术有限公司(CSAI )多年的客户，CSAI 已经为其开发了多个信息系统。最近，M 又和 CSAI 签订了新的开发合同，以扩充整个企业的信息化应用范围，张工担任该项目的项目经理。张工组织相关人员对该项目的工作进行了分解，并参考了公司同 M 曾经合作的项目，评估得到项目，总工作量 60 人月，计划工期 6 个月。项目刚刚开始不久，张工的高层经理 S 找到张工。
S 表示，由于公司运作的问题，需要在 4 个月内完成项目，考虑到压缩工期的现实，可以为该项目在增派两名开发人员。张工认为，整个项目的工作量是经过仔细分解后评估得到的，评估过程中也参考了历史上与 K 企业合作的项目度量数据，该工作量是客观真实的。
目前项目已经开始，增派的人手还需要一定的时间熟悉项目情况，因此即使增派两人也很难在四个月内完成。如果强行要求项目组成员通过加班等方式追逐 4 个月完成的目标，肯定会降低项目的质量，造成用户不满意。因此，张工提出将整个项目分为两部分实现，第一部分使用三个半月的时间，第二部分使用三个月的时间，分别制定出两部分的验收标准，这样不增派开发人员也可以完成。高层经理认为该方案可以满足公司的运作要求，用户也同意按照这种方案进行实施。
六个月以后，项目在没有增加人员的前提下顺利地完成，虽然比最初计划延长了半个月的工期，但既达到了公司的要求，客户对最终交付的系统也非常满意，项目组的成员也没有感受到很大的压力。
【问题1】请不超过500字，指出张工是如何保证项目成功的？
【问题2】请不超过500字，试结合案例指出项目范围管理的工作要点？
2.2.2 案例分析
这是一个成功的项目管理案例，项目经理张工有效的运用范围管理，在不同的项目干系人中达成一致，使项目的结果同时满足了高层经理、客户和项目组成员的要求。
作为一个项目管理者，必须熟练掌握和应用项目管理九大领域涵盖的知识与技能，对于进行信息系统开发项目而言，范围管理是其中最重要的技能之一。
软件项目的范围主要是由系统需求构成的，而系统需求既是难以把握的，也是容易调整和控制的。软件系统的需求来源于用户需求，在软件项目目标是满足用户需求的情况下，对于相同的用户价值可以定义出不同的系统需求。举一个简单的例子，用户的需求是“解决口渴的问题”，那么最简单的系统需求可以是递上一杯水，复杂一些的可能是递上一杯热水，更复杂的是递上一杯经过多层过滤的纯净水，当然也可以是打一桶虎跑泉的水，然后沏上一杯龙井茶。
用户当然希望用买矿泉水的钱换一杯正宗的龙井茶，但这样的项目范围肯定会导致项目失败。聪明的软件项目经理总是从范围管理开始，先界定系统的边界，然后再在明确的范围内进行时间、成本、风险等的管理。
在项目中，时间、成本和范围构成了一个稳固的三角形，如图2-1 所示。
对于该三角形来说，任何一边都不可能孤立地改变。换句话说，我们不可能固定其中两边而试图缩短第三边。其实这也是很容易理解的问题，如果项目需要做的东西已经确定(项目范围固定)，项目的人员也已经确定(项目成本固定)，那么项目需要的时间就也是固定的。同理，已经固定的项目投入和项目时间也只能做出固定的工作。对于这个三角形而言，非但不可能孤立地改变某一边的长短，就是三边的变化比例不一致也不可能。不成比例的变化与孤立的改变某一边是一样的，都将破坏三角形的结构，违反项目的客观规律，最终招致失败。因此有效的范围管理更像一门艺术，可以帮助项目经理在已经确定的时间和成本下完成项目目标。
在本案例中，高层经理 S 就提出了试图打破这个三角形的要求。他要求，项目组可以增加部分资源，但要提前两个月完成。初一看，并没有在不增加投入的情况下要求项目提前完成，似乎合情合理，比起既要马儿跑又不让马儿吃草的要求好得多，但细一想，增加的资源和提前的时间还是不成比例。项目经理张工深知此中奥妙，因此在听到高层经理的要求后，马上意识到这是一个不可能完成的任务。
那么该如何解决这个矛盾呢？还是要从这个三角形入手。既然时间和资源的变化已经打破了项目规律，那么不妨根据新的时间和资源来重新划定合理的项目范围，保证项目的正常运作。于是，张工将这个项目拆分为两部分，重新定义这两部分的项目范围，使每一部分的范围都可以与已经确定的资源和时间匹配起来，让项目的运作又重新满足了项目的客观规律，最终取得了成功。
在案例中，还有一些细节需要考生注意。张工最初估算整个项目需要花费 60 人月的总工作量，但如果考虑到拆分为两个阶段后会增加设计的复杂度，增加了额外的验收过程等因素，超出原计划半个月是正常的。计划在 6 个月内完成。在把项目拆分后，实际是用了 6 个半月的时间，也就是花费了 65 人月完成了项目。对于上面介绍的时间、成本和范围的关系而言，仅是在理想情况下成立，即项目成员始终能以固定的成本完成固定的工作。而在实际情况下，项目的工期、复杂度等因素都会对项目造成影响。在案例中，虽然看似两部分工作的总和等于没有拆分前的项目，但这仅对于最终目标而言，拆分后的项目增加了若干中间成果，项目的范围实际上还是扩大了。
因为软件项目的范围直接与需求相关，所以，很多人误认为控制项目范围就是控制需求，而控制的方法就是减少需求的内容。这种理解是完全错误的。
范围控制体现在软件开发的各个阶段，很多范围控制并非是针对客户的要求而进行的。例如，本案例中，范围控制就是针对高层经理的要求进行的。再比如，在设计中，我们既可以设计刚刚够用甚至略有欠缺，通过牺牲系统的扩展性、维护性等方面来简化设计，也可以对系统进行充分良好的设计，甚至可能是过度设计。采取哪一种设计策略也是软件项目范围管理的一部分。项目经理可以根据目前的项目的目标与环境出发，综合考虑质量和成本的约束，制定明确的项目范围，保证项目的成功。根据笔者的经验，即时需求已经确定，通过有效的范围管理仍能给项目带来很大的收益，可以在不牺牲软件质量的前提下通过范围管理来降低项目成本，缩短项目工期。
上面主要针对张工在范围控制方面进行了分析，实际在整个案例中，张工还进行了其他的范围管理工作。
首先，在项目刚刚开始，张工就对项目范围进行了定义，进而划分了 WBS 并对项目进行了估算和计划。在 S 提出需要缩短工期的要求后，张工首先进行了项目范围的控制，缩小了第一步需要完成的项目范围。紧接着张工又对两阶段需要完成的项目范围进行了重新定义，制定了验收标准。最后，张工对重新定义的范围进行了确认，与客户和高层经理达成一致。
对于项目而言，仅仅管理范围仍不能保证项目的成功。在这个案例中，张工也运用了其
篇二：项目管理案例分析试题及答案1
谁该为项目失败负主要责任
【案例正文】
小王被任命管理一个重要的软件项目，项目组有 3 个成员。如果该项目不能按照客户的质量要求如期 完成，公司将损失大笔收入，这一损失将影响到公司的未来发展。但结果是项目在小王手上失败了!项目 不但延期了 25%，而且客户还在公司的成员各自开发的模块间发现了明显的集成问题。
情形是这样的：·小王过去是一个很好的程序员，在去年被提拔为经理。
·成员 A 是一个有能力的程序员，在项目的过程中他被小王的经理调去参加公司的培训课程，这造成 了他 30%的工作延期，培训回来以后，公司宣布他在完成该项目后将被提拔到新的岗位，于是他一直忙于 熟悉新的岗位和经理，他的项目后期工作质量受到了严重影响。
·成员 B 是最没经验的程序员，他的开发进度较慢，不幸的是在项目过程当中他生了 5 天病，这更加 减慢了他的进度。尽管他努力追赶但由于没有任何有经验成员的帮助，他还是不能按时完成任务。
·成员 C 是最有经验的程序员，他的绩效是公司的一个标杆。他被分配完成这个项目最困难的任务，
并提前 25%完成了该项工作。他还被分配负责集成所有的软件并进行测试，但他声称由于 A 和 B 的延误、A 的低质量的原因，在你规定的发布时限之前，他没有时间对软件作彻底的测试。小王曾经跟 A
注于眼前的工作问题有过几次谈话，但没能见到任何改进。要求休完病假的 B 加班以赶上进度，他也照办 了。小王要 C 帮助 B，他说他做过努力，但他认为 B 缺乏经验太难交流。
综上所述，究竟谁该为项目的失败负主要责任?
【相关分析】这个项目主要失败在对人力资源的管理上。在其各过程的控制中都存在着问题。
1、制定人力资源计划——识别和记录项目角色、职责、所需技能以及报告关系，并编制人员配备管理计 划的过程。
这个过程应该特别关注稀缺或有限人力资源的可得性，或者各方面对这些资源的竞争。编制人力资源计划 时，必须认真考虑这些因素对成本、进度、风险、质量各方面的影响，并编制人力资源配备的备选方案。 应该拟定人员配备管理计划，说明需要每个团队成员的时间段，特别针对成员 A 和 C 应有资源日历；针对 成员 B 应有培训计划；
2、组建项目团队——确认可用人力资源并组建项目所需团队的过程。
项目经理或项目管理团队应该进行有效谈判，并影响那些能为项目提供所需人力资源的人员。在本例中表 现为小王应该与其职能经理就成员 A 的使用问题进行有效的沟通。如果不得不使用替代资源，项目经理应 该在项目管理相关计划中说明缺少所需人力资源可能造成的影响。
3、建设项目团队——提高工作能力、促进团队互动和改善团队氛围，以提高项目绩效的过程。
团队协作是项目成功的关键因素，而建设高效的项目团队是项目经理的主要职责之一。而在本例中，成员 生产率低下，团队成员之间缺乏认同与合作，团队环境恶化。
建议开展项目团队建设工作（如培训、团队建设、集中办公、基本规则宣导等），在过程中对团队进行正 式或非正式的项目绩效评价，对成员的优良行为给予认可与奖励。项目团队建设会经历几个阶段（形成阶 段--震荡阶段—规范阶段—成熟阶段—解散阶段），这里要凭借项目经理的力量有效带领团队经历所有阶 段。
4、管理项目团队——跟踪团队成员的表现，提供反馈，解决问题并管理变更，以优化项目绩效的过程。 在本例中，针对种种突发状况，小王缺乏积极的应对。事先无预防，事中无监控，事后无评估。从而造成 进度延迟、质量低下。
建议通过以下方式改善局面：
1）预防措施是指在问题发生前所制定的、用来降低问题发生概率和/或影响的措施。这些措施可包括为减 轻成员缺勤所带来的问题而开展的交叉培训，以及为确保所有职责的履行而进一步开展的角色澄清。团队 成员经验水平的高低，将减少或增加项目风险，对此项目经理有必要进行额外的风险规划；
2）在项目执行过程中：
多观察和交谈，随时了解项目团队成员的工作和态度。项目管理团队应该监督项目可交付成果的进展， 了解团队成员引以为荣的成就，以及了解各种人际关系问题。
过程中，应该持续地对项目团队绩效进行正式或非正式评价。
问题日志记录。书面日志能记录并帮助监控谁负责在目标日期之内解决某个特定问题。应该针对妨碍团 队实现目标的各种障碍来解决问题。
3）人员配备的变化，无论是自主选择还是由不可控事件造成的，都会影响项目管理计划的其他部分。如果 人员配备问题干扰了项目管理计划的实施，诸如造成进度拖延或预算超支，就需要通过实施整体变更控制 过程来处理变更请求。
【案例正文】 在项目中有一些关键性的技术工作，且这些工作在行业内部非常保守、国内技术力量薄弱——也就说技
术工作人员难找。在我们团队里有一个这样的关键性技术人员，项目必须经过他这一环。在他这一环时， 时间计划完全被他控制——他说要多少时间就多少时间，而且这个时间非常随意，不给我任何商量的余地， 更不要说去控制。同时，这个工作环节很难找到人代替或外包，这个人对公司好像也没多少留恋可言，纯 粹看钱办事。
目前来说，该如何处理呢？和他沟通、高层出面还是其他方法呢？
【相关分析】从案例中可以看到，项目经理苦恼的是关键资源的进度失控。
进度控制是项目经理的本职工作，除非超出你的能力范围，这个沟通工作当然还得你本人来做。
从做人的角度来说，既然是关键资源当然希望得到足够的尊重，所以在做进度控制的时候项目经理千万不 要抱着一种严格的上下级的心态来行动。
首先在确定关键资源的任务的进度基准的时候，这个很明显是关键资源说了算，如果你有一些跟进度有关 的制约因素的话，我觉得坦诚相告的话最好，让他帮助想办法解决。如果你觉得他说的水分太大，怎么办 呢？就是通过求教的方式让他去对他的任务进行分解，细分到你能理解为止，这样你就可以核实进度基准 的可靠性了。如果细分的结果你还是无法确认，我想你需要考虑一些风险措施了。
进度基准既然是他认可的，那么对进度进行控制时我想你就不必太为难，当然你不必抱怨说，当初你说一 个月搞定，怎么现在还没弄出来。出现这种情况，也应该向他请教出问题的原因，技术上不能解决的问题， 有时是可以通过非技术方法解决的。
外行管理内行，一个是要尊重内行，另外也需要内行能够认识到你是管理方面的内行，是能为他解决技术 问题提供管理方面的帮助的。
一个 IT 经理的无奈 【案例正文】 某家电公司的 IT 经理，为了帮助公司管理几十万台产品，提出了实施条形码管理的计划，得到了常务副总 (后来升任为总裁)的认可，也得到了售后服务部、生产部、财务部和物流中心的赞同。 系统开始试运行后，遇到了不少问题。为了解决这些问题，IT 经理起草了一个流程再造及其配套软件 的申请。但向总裁(即之前的常务副总)申请时，总裁不同意，理由是“没有管理基础，用什么软件都没用”。 IT 经理于是直接和董事长谈。董事长理解了 IT 经理的意图，但表示他已经放权了，具体的实施还是 总裁决定。后来在一次高层会议上，总裁突然发难，认为条码系统成本太高，停止运行。 在 IT 经理和其他部门都无法说服总裁重新启动条码项目后，IT 经理分别向董事长和总裁提交了一份
《成品物流流程优化方案》，其中不再提条形码，改叫成品物流系统，也增加了发货计划管理的内容。但 是方案交上去以后，迟迟没有结果。您认为此项目遭遇挫折的原因有哪些?这位 IT 经理后来采取的措施是 否妥当?您觉得他还可以采取哪些更好的措施?
1、信息化是为管理服务的 作为信息化的负责人，应该始终坚持“信息化最终的目的是为实现公司战略目标服务，为管理服务” 的原则。 2、换位思考，找到关键问题 信息化管理人员最重要的管理技能就是换位思考。我们是一个管理服务机构，那么我们就一定要能从
公司总经理以及其他管理部门负责人的角度来思考问题。只有与他们有共同的思维的时候，我们才能真正 理解他们的管理意图，为他们提供专业的服务。
也只有有了换位思考，我们也才能理解到公司老总真正想要解决的问题是什么，他的问题本质是什么， 这样我们才能提出合理的解决方案。
同一个领导在不同的岗位上他们关心的问题是不一样的。常务副总更关心的是公司的日常运营工作， 如何保证公司顺利地、正常地运作；但公司的总经理更多的是考虑公司总体利润目标，如何提高销售额， 如何降低成本，如何改革公司的治理结构等等；董事长更多的关心公司总体发展战略、未来业务发展方向 等等。在跟不同岗位人员沟通时应该更多地分析和了解他们最关心什么，目前对他们来说什么是最重要而 且紧急的。
3、增强沟通和协调技巧
沟通的技巧是很关键的，特别是与公司最高层经营管理者沟通。他们都非常忙，我们需要快速分析老 总的管理风格特点（指导型，支持型，还是授权型？），找到与他们沟通的方式。
与公司总经理的沟通绝对要避免越级。如果你越过他直接与董事长沟通，自然会让对方觉得你不尊重 他。你想想董事长都害怕给他这种感觉，更何况你呢？
4、成立项目组，业务管理人员和 IT 人员共同参与
在任何一个信息化项目启动时一定要成立一个项目小组，而且必须是业务管理人员和 IT 人员共同参 与，这样才能避免出现软件和业务管理不配合的问题。
5、需求调研一定要充分
做信息化时，需求调研工作一定要做到位。一般来说应该经过多次的交流才能最终确定需求。需求调 研中特别要注意避免需求理解错位，尽量避免做出的软件不能满足需求。我们应提供更多的界面原型、用 户使用场景、业务应用案例等，让不懂信息化的管理人员在软件设计
前期能充分地理解，并参与到系统的 设计审核中来，这样才能保证信息化的成功推行。6、软件上线之前应该要进行内部项目组测试
软件上线前一定要在内部项目小组中进行测试，特别是关键的业务案例，以保证上线后尽量少出现软 件 BUG（缺陷）问题，提高用户使用信心。同时也能保证实施效果，以免出现案例中的集成商现场不断修 改系统的问题。
7、软件上线必须有配套应用模式和相关管理制度配套
软件上线后才发现管理混乱，系统正常的使用效果也无法保证，那么可以肯定地是在系统上线前针对 现有的业务管理流程进行梳理的工作做得不充分。而且项目小组以及业务相关部门在工作流程上没有完全 达成一致，所以导致使用的时候问题才暴露出来，并影响了使用效果。
大型网站建设运营项目的难题 【案例正文】 项目属于服务及运营类，自开始至今已经历时 4 年，而且是两地开发，这中间出现了很多问题，说明 如下： 1. 项目管理沟通问题：因项目过大，本项目中公司领导层过多介入其中。加之项目团队成员 90%都是
一同进入公司的同事，一直是处于各司其职的状态，没有体现出项目经理对团队成员应有的关心和照顾。 但是作为和成员同龄人的我这个项目经理，确实不知道该如何拿捏这个分寸了。有几个项目成员比我还大 几岁，经验比我还要丰富。这个问题很困惑。
2. 项目范围变化：该项目虽说是按项目合同方式来进行，但是实际运行中一般都是客户提什么需求然 后做什么需求，如果客户某段时间无紧急需求，再将合同中的内容完成。(客户在合同签订后提出的新需求 属于应业务及市场的需求，是必须要完成的)这样导致项目验收困难，范围模糊不清，目前采用的方式是互 相抵消，多余部分算做下一期的合同内容
3. 需求变更多：因为是运营型网站，在各个时期都会有很多的活动，而且提出时间晚，因为各类媒体 广告已经推出，项目组必须加班加点敢进度。时间紧，开发流程被缩减，质量不是特别好，上线后接到客 户投诉，必须马上响应解决，给维护和开发人员及整体的项目计划安排都造成严重影响。同时因为加班过 多，项目成员产生抵触情绪。
4. 现场压力大：很多时候需求紧急的情况下，客户和我们的开发、维护部署人员一起办公，出现问题 必须立刻解决。曾经发生过，现场项目成员(2~3 个)因不能忍受这样的高压工作而离职情况
5. 异地沟通效果差：现场主要负责需求调研、项目管理、维护部署的工作，公司总部负责需求设计开 发。后端开发人员对业务了解过少，加之沟通不及时，造成前端和后端脱节。现场承受来自客户的压力， 后端承受着需求频繁变更带来的无休止加班。因后端对需求的管控力度不够，现场需求人员同时需要对需 求质量进行监督，整个过程需全程跟踪。需求人员限于某个需求开发过程过多，无过多精力了解客户更多 的业务需求。
6. 项目框架不健全，团队新人无法很快融入团队。提取的公用部分较少，开发人员人力浪费
篇三：SAP项目失败案例
失败案例
千万元工程的陨落——国企ERP实施亲历记
柳松
九十年代末的一个春天，我当时所在的一家知名的软件开发商在一家大型制造企业获得了一项国家863CIMS项目，ERP被列为其中的一部分，另外还有CAD、CAPP、PDM系统，整个CIMS系统投入近千万。本人作为ERP的实施顾问，参与了该项目的全过程，在长达一年半的实施过程中，对ERP有了更深的认识。特别是对ERP在国企中的实施有深切的认识和切肤之痛，从中发现不少问题，而正是这些问题直接导致了实施的失败。
这几年来，关于ERP实施的文章不少，但有真切感受的文章不多，很多关于实施的文章缺少实施的细节描述，要么是纸上谈兵，要么纯粹是东抄西摘的东西，少有从实践中得来的真切感受。把现实中十分生动具体的实践，变成干巴巴的教条，严格的讲，对ERP的实际应用没有多大借鉴意义。
笔者有ERP的开发经验和长期实施ERP的经历，对ERP有比较深刻的认识。在这里，根据自己的实施过程中的亲身经历，告诉你一个真实的在国有大型制造业实施ERP的故事，把自己在实践中获得的第一手资料贡献出来和大家共享。出于可以理解的原因，本文将隐去有关厂商的真实名称。
一、项目背景
这是一家产值八亿左右的机械制造企业，有职工七千人左右，其中技术人员六百多人。组织结构为五个事业部、十七处、三室、九个分厂、一个科研所，还附属有医院、小学、托儿所、招待所等社会福利机构。九十年代中以来，企业连年亏损，好在树大根深，尚未大伤元气。近来，由于国防订货激增，军品外销形势喜人，企业又恢复了生机，产品一时间供不应求。但由于管理粗放，造成成本节节攀高，产值虽大，效益却很一般。这是企业准备上ERP的动因之一。
开发商则是一家新兴的软件企业，有大约一百二十人的软件开发人员。近年来，仿照一家著名的外国软件开发出了自已的ERP软件，而这个项目则是开发商的第三个大型项目。
该项目经国家立项，列入863CIMS计划（据说列入该计划的将会得到国家一定金额无偿拨款），由此确定了项目资金来源为自筹+上级主管拨+国家拨款。
二、过程中的问题
国外关于ERP实施的阶段划分是有道理的，只有在这每一个阶段的工作都做好了，才能保证ERP的实施成功。现在我就结合这个程序来分析我的亲身经历的ERP实施。
1. 领导培训
ERP系统被视为一把手工程，对企业高层的领导的培训是一项目十分重要的工作。而实际情况是如何做的呢？应该说开发商从一开始就十分重视对企业一把手的工作，但不是进行先进管理理念方面的导入，而是把大量的精力放在了公关上了。这个价值近千万元的项目理所当然地引起了多家软件商的角逐，而且此项目居然不进行招标，这就为各家公司的公关工作留下了宽阔的表演舞台。各家公司各显神通地倾情演出，一时间你方唱罢我登台，种种手段不一而足。而极为重要的ERP理念导入的工作就相当马虎地一带而过。只是请了一位机械制造专家作了CIMS原理的专题讲演，而没有对ERP的理念作任何形式的导入工作，从一开始就为今后的失败种下了祸根。
造成这种情况有双方面的原因：
一方面，开发商实施队伍尚未完善，笔者作为唯一具有开发经验和管理经历的实施顾问，既有从事开发工作，又要主持多个项目的实施，困难是很大的。毕竟，国内的ERP软件是最近几年才出现的事，开发商尢其缺少既懂现代制造业管理又具备较高计算机水平的两栖人才。另外，加之开发商主观上认为自己在公关活动中的工作足以保证后续工作的顺利进行，也不愿意在这方面投入太大的人力、物力，尽可能减少成本开支。除了搞了一次讲座外，就没有搞过管理理论方面的培训了。
另一方面，企业领导上ERP项目的动机复杂。当然也想通过ERP提高管理水平，另外还有攀比跟风以及更深的不为人知的动机。企业的各级管理人员对此也是心知肚明，所以上下都对ERP项目缺乏应有的信心和工作热情。
2. 需求分析
开发商的需求分析工作也极为马虎。仍然是出于确信自己的公关投入可以保
证项目成功（这里开发商理解的成功就是收到项目款），开发商尽可能地减少成本开支，前期的需求分析工作基本是为了应付立项报批而做的，对二次开发基本没有什么意义。
3.BPR
在这个项目的实施过程中，无论是开发商还是用户都没有提出来要进行企业管理流程的重组工作。笔者深知在国企要对企业业务流程作根本性的重组几乎是不可能的，但一点改进都没有而要成功地实施ERP同样几乎不可能，作为实施顾问，笔者曾提出过对企业工作流程进行改进的建议，但却泥牛入海，恨无消息。尤其令人不解的是在我们进驻企业的时候，企业刚完成了对组织机构的调整，似乎这项工作与我们根本无关，企业自己按老一套三下五除二就搞定了。其组织结构仍然是高耸的非人格化的机械结构，我们就是在这样的管理环境下，开展ERP的实施工作的。
4.项目组织
项目组织从形式上看是象那么回事的了。成立了三级项目组织，企业一把手出任领导小组组长，核心小组、各部门项目组也有重量级人物出任组长。但实际工作起来就不是那么一回事了。一把手虽说是组长，但从头到尾只参加过两次会议，而且也是大言炎炎地说些不着边际的官话、套话，说完就走人。而其余负责人对ERP知识极为欠缺，在业务会上，往往不知所云的说些牛头不对马嘴的话，解决不了任何问题。而最可笑的是，该企业的信息中心的主任、项目的具体负责人居然是一个不学无术的人。虽说是计算机大专毕业，但对技术一窍不通。此人很少钻研业务，满脑转的是如何巴结领导、讨好上级的经。
5.实施计划
由于CIMS涉及多个系统，计划的组织工作极为繁重，头绪极多，应该采用PERT技术进行项目管理。但实际上却没有这样做，仍按传统方法管理项目。整个计划极为概略，只有一个粗线条的时间表，各系统分头进行，互不沟通。加之在发包项目时，CAD、CAPP、PDM系统包给另一家驰名的软件开发商，不同的软件开发商所用的开发工具不一、工作方式各异，协调起来十分困难，经常出现混乱，而且开发出来的系统与我们的ERP系统不能有效集成，形成互无联系的信息孤岛。
6.培训工作
前面已经提到了管理理念方面培训工作中的问题，这里只是谈谈操作培训工作的问题。应该说这方面的培训工作较之管理理念方面的培训要好得多。我们组织了对各部门的操作员培训班，从计算机的基本知识开始进行了系统的培训，并进行了较为严格的考试，合格的颁发了上岗证。参加培训的是一些基层的女工，不同领导的麻木与懒惰，她们表现出了较高的学习热情，常常主动加班学到深夜。正是由于她们的帮助才使我们在极为不利的环境下，还能坚持正常地工作。她们所做的一切，常常让我们感叹这才是中国的脊梁。但存在的一个问题是培训面不宽，没有进行持续扩大的培训，另一个问题是没有各级管理人员的参加，直接影响了实施工作。
7.数据准备
数据准备的重要性无庸赘言，作为实施顾问，笔者在各种场合反复强调了基础数据的重要性，并要求企业采取切实的措施来保证这一点。由于我们的坚持，企业方面也对这个问题表现出了极大的关注。布置了全厂的库存盘存，对库存账、物进行了一次较为彻底的清查。应该说，经过这次全厂大盘点，企业的家底是查得较为清楚，但仍不能达到系统上线的要求。其原因是企业多年来实行的是较为粗放的生产管理方式，系统要求的一些基础数据，企业没有完整的记录。比如，各零部件的制造提前期、采购提前期没有一个准确的数据，尤其是采购提前期没有历史记录资料，也没有制造经济批量和采购经济批量的概念。笔者不得不亲自整理浩如烟海的数据，进行分析勉强确定出每次订货成本、库存成本，从而为制定出经济制造批量、经济采购批量打下了基础。
另外，我们在工作中发现，该厂很多零部件的工艺标准、成本标准、损耗标准均制定于七十年代，早已不能适应现在的市场情况。总之，数据准备是认真的，但由于管理的基础工作较差，总体上不能达到系统上线的要求。
8.二次开发
由于没有对企业业务流程进行重组，我们不得不对软件作了较大的修改。在实施初期，我们坚持要求企业的业务流程按ERP的要求进行改造，双方爆发了激烈的争执。经过一段时间的僵持，开发商的老板给发来我们训示：用户是上帝，用户要我们怎么办就怎么办，不要再进行无谓的争执了。于是，我们只有谨遵上
帝的意愿，对软件进行了较大辐度的修改，使ERP软件带上了浓重的国企特色。
三、管理冲突
上面着重谈了在实施ERP各阶段中所存在的一些问题。而这些问题就直接导出了一系列两种管理模式的冲突，下面将就这些问题做一些分析讨论。
1.观念之争
在实施过程中，我们一直处在先进与实用的观念之争的中心。由于无论是管理的理论，还是丰富的职业经历使企业的怀疑派不得不承认笔者的管理思想是先进的。但他们又说他们那一套虽不先进但却是实用的、有效的。支持他们的理由就是按ERP的模式重组生产，将会给已经超负荷的生产运转体制带来混乱。然而，笔者明确地告诉他们，正是由于企业延续三十年不变的管理体制才使得企业不能应付新世纪的挑战。正是由于旧的生产运转体制才使得企业不得不超负荷运转。而且，这种超负荷是低效益的，不可能应付市场日益严峻的挑战，总有一天会不胜重荷则彻底崩溃。如果等到企业完全丧失竞争力，再来进行重组时，可能为时已太晚。为了说服他们，笔者对企业的排产模式给他们做了详细的分析，明确指出其中的问题。
多年来，该企业排产的模式是计划目标或订货合同目标??查半成品库库存数??下达各分厂的月生产计划??各车间生产调度指令??各车间自拟物料需求计划??生产处审批??分厂审批??各车间执行。从这里可以看出，在下达生产计划时，传统的方法使企业生产计划制定者只考虑一个影响因素，即制定计划这个时点上马上可以用于装配成品的半成品库存数。而其下层的物料库存数量则不在企业生产计划制定者考虑之内，而是交给下级分厂或车间自行决定，由于各部门之间信息不能共享，加之出于各种自身利益考虑，下级提出的物料需求计划常常出现多报、漏报的现象，很不准确。且以上库存数据均为静态数据，没有考虑到即将到达的物料数量。计划的环节多，审批烦琐，对市场的变化反应迟缓。另一个大问题是传统的生产管理模式没有进行生产能力计算，只是粗略地凭经验估计，没有制定出详细生产能力需求计划。
以上这些工作虽说对他们有所触动，然而囿于体制，企业难以对业务流程进行根本性的再思考和再设计。
2.利益之争