优质文档举例说明之前工作中最失败的案例或者项目失败原因是什么精选word文档 17页Word格式文档下载.docx
《优质文档举例说明之前工作中最失败的案例或者项目失败原因是什么精选word文档 17页Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《优质文档举例说明之前工作中最失败的案例或者项目失败原因是什么精选word文档 17页Word格式文档下载.docx（15页珍藏版）》请在冰豆网上搜索。
因此采用了严格瀑布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。
在项目交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。
由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70％的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写的部分代码才通过验收。
由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也超出原计划的100％。
【问题1】请不超过300字，对张工的行为进行点评？
【问题2】请从项目范围管理的角度找出该项目实施过程中的主要管理问题？
不超过200字回答。
【问题3】请结合你本人实际项目经验，指出应如何避免类似问题？
2.1.2案例分析
这是一个失败的项目，张工在项目管理中既有闪光点，也有失败的地方。
但项目管理中的任何差错都会影响项目的结果，而范围管理的失误对项目的影响更为明显。
模糊的项目范围定义、错误的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。
张工对项目范围有一定的把握。
在范围定义中，张工发现了不同行业间具有不同的特点，电子政务行业对系统运行环境有着特殊的要求。
根据国家对电子政务的要求，政务内网与政务外网是该行业一致的标准，这与企业信息化是完全不同的。
张工捕获到该需求，并对这个
需求进行了清晰的定义，根据瀑布模型的要求，对设计和实现都进行了严格的控制，因此在系统交付时完全满足了用户对保密性的要求。
在这一点上，张工是成功的。
如果在范围定义时忽略了行业标准，项目肯定会招致更大的失败。
但用户界面的风格和操作的便捷性也属于系统范围的一部分。
与系统运行环境一样，我们通常称这类需求为隐性需求。
这类需求往往不是由用户直接提出，而且受行业特点决定的范围所约束。
对于电子政务来说，系统保持一致的风格非常重要。
作为政府对公众开放的窗口而言，并不需要很强的个性化，但一致的界面风格可以体现出政务的严肃性。
考虑到全体民众层次差异较大，大多数访问系统的用户一般都没有接受过系统使用的培训，操作的便捷性也是政务系统必须实现的功能之一。
很明显，对于这些系统的隐性需求张工没有充分考虑，从而导致一而再，再而三的变更。
对于软件项目，所有的需求都必须经过清晰的定义，这些需求都是项目范围的一部分。
张工仅仅注意了其中的一部分，而忽略了用户界面，最终导致项目的失败。
对于电子政务信息系统，尤其是面向公众开放的信息系统，范围定义更加困难。
这些系统的最终用户几乎不会参加需求开发的工作，他们的需求都是间接的，通过政府部门的负责人传递到项目组。
但最终用户的意见对项目的结果会有巨大的影响，这是就对范围管理提出了更高的要求。
除了在范围定义方面的问题外，张工在范围确认和范围控制方面也存在不小的失误。
当系统第一次更改时，就应该意识到系统界面风格和操作便捷性的重要性。
这时应该清晰地定义系统的界面风格和操作风格，并设法进行确认。
如果采取了恰当的措施，第二次的变更是完全可以避免的。
在刚刚进入一个陌生领域的时候，其中充满了各种各样的风险。
隐性的行规和行业特点都是项目范围的风险。
面对这些风险，即使再细致的调研也无法完全避免，也不能完整定义系统的范围。
因此可以考虑采取原型法等方式来提前暴露风险，减少风险带来的损失。
因此在案例中，张工也没有进行充分的风险管理，采用严格的瀑布模型增加了风险发生后带来的损失。
对于这个案例，缺乏良好的设计也是很明显的缺陷。
用户界面中耦合了大量的业务逻辑，这必然增加变更的代价，从而导致大部分代码重写。
若在项目初期意识到界面变更的风险，随之采用良好的设计，将表现层和业务逻辑彻底分开，系统变更的代价也会小得多。
综上所述，项目经理张工在整个案例中，针对范围管理做了一些工作，但不全面，在风险管理和质量管理上也都存在缺陷。
有了上面的分析，这道题就很容易作答。
项目的闪光点在于对系统运行环境进行了清晰的定义，并最终满足了用户的要求；
但不充分的范围定义和范围确认招致了项目的失败，而采用了抗风险能力较弱的瀑布模型和低质量的设计又雪上加霜，最终导致项目延期100%.
因此第一题答案的要点就很明确了：
（1）张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。
（2）张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付的重大变更。
（3）张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。
（4）张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。
（5）张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。
对于第二题，是在第一题的基础上考察对范围管理的理解，因此可以忽略在其他领域的问题。
在范围管理中主要包括如下内容：
（1）范围管理计划。
（2）范围定义。
（3）工作分解。
（4）范围确认。
（5）范围控制。
在本案例中，没有专门设计到范围管理计划和工作分解的内容。
从表面上看，范围定义存在明显的缺陷。
但案例中提到系统又发生了第二次变更，由此可见，张工在范围确认和范围控制上也存在不足。
若在问题第一次出现时就进行有效的范围确认和范围控制，则完全可以避免第二次的变更。
因此，第二题的答案要点如下：
（1）张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。
（2）在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。
（3）重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。
在完成第二题后，第三题就是水到渠成了，第三题的要点见参考答案，此处不再赘述。
项目管理是一个系统工程，没有哪种单一的手段可以有效地改善项目，反之管理中的任何疏忽都可能招致严重的后果，造成项目的失败。
而软件项目的复杂性又决定了项目中的工作环环相扣，问题也总是相互关联的。
在发现问题后，也需要采取多种手段才能彻底解决问题。
这对信息系统的项目经理来说是重大的挑战。
2.1.3参考答案
【问题1】
（2）张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付时的重大变更。
【问题2】
【问题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、换位思考，找到关键问题信息化管理人员最重要的管理技能就是换位思考。
我们是一个管理服务机构，那么我们就一定要能从
公司总经理以及其他管理部门负责人的角度来思考问题。
只有与他们有共同的思维的时候，我们才能真正理解他们的管理意图，为他们提供专业的服务。
也只有有了换位思
升级会员 