关闭
您尚未登录,请登录后提交案例分析!
用户名 密码 联盟服务 关于我们 联系方式 收藏本站
返回网站首页 6月 北京上海 PgMP开课,针对2022年9月PgMP认证考试


网站登录:会员 企业 专家 服务商
企业服务:PMP培训  内训课 公开课
工 具 箱:发表文章 提问题 发案例
首页动态 | 文库 | 下载 | 书架 | 访谈 | 专栏 | 专题 | 人才 | 培训 | 软件 | PMC 互动:活动 | 案例 | 问答 | 论坛 | 博客 | 圈子 
应用:基础工程软件制造活动研发  认证:PMPACPPgMPIPMPP2ISPMPIMCP建造师MPM  特色:热点奖项

PMI-ACP®认证

适合敏捷开发项目
敏捷项目管理最佳实践

网络课程

PMI-PBA®认证

重视项目商业分析
商业价值与需求分析能力

网络课程

NPDP®认证

产品管理国际认证
全球产品管理最佳实践

网络课

PMP®认证

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

PgMP®认证

大型复杂项目全球标准
定位高级项目管理层

网络班

PfMP®认证

链接战略与项目
实现组织资源投资回报

全球直播

软考项目管理

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

栏目说明
    项目管理者联盟《案例》栏目,是为项目经理排忧解难的互动平台。当您的项目碰到难题时,您只需要将您所在项目的情况描述清楚并提交到本网站,众多项目管理高手将对您的问题提出最佳解决方案。您的项目背景信息必须清楚;项目的进展现状必须详细说明;项目难题中所涉及的项目成员关系要阐述清楚。
专家点评
缪燕  目管理者联盟 缪燕
【案例正文】
   小李从一个著名的IT企业辞职了,为了创业的梦想,自己开了个公司,想运用十多年软件.....[详细]
·如何与有争议项目的客户沟通
·项目收尾面对突如其来的变更
· 如何改善不注重工期的项目文化?
·一个外行项目经理如何管理项目
· 项目目标为何失控?
·从公司战略角度认识项目目标
more>>最新案例
04-10·需要职能部门的配合的时候.
04-10·需求合理但得亏成狗了,进.
10-18·项目领导无法正确判断项目.
10-09·多项目总是面临冲突无法协.
10-09·国有企业项目集群管理推行.
09-28·项目领导无法正确判断项目.
08-16·对开发流程不了解的项目经.
06-15·如何评价产品经理拿数据说.
05-12·需求分析所需达到的详细程.
04-28·技术出身的管理者,求教如.
more>>热点案例
·如何处理项目中的尴尬局面.[4109]
·多项目组合作的项目如何明.[2877]
·项目团队人气底下态度散漫[2252]
·项目人员管理上的一个困惑[2171]
·高温煤气净化项目收尾阶段.[1728]
·PMO应该如何更好的分配资源[1453]
·项目中人员成本所占权重该.[1425]
·IT项目经理应该如何与技术.[1380]
·怎么样建立一个比较实用的.[1267]
·如何确保项目能在有限时间.[893]
·采用什么的组织结构[851]
·如果你是项目经理,怎么去.[819]
·工期拖了怎么办?[778]
·软件项目预期延期如何应对[769]
·某个工程项目的索赔问题[743]
·客户方领导同意方案但是拒.[743]
·如何做好项目的质量成本分.[738]
·《越狱》主角迈克尔算不算.[729]
·新入职项目经理如何介入项.[691]
·不是技术出身的人如何做好.[647]
最新分析
·需求合理但得亏成狗了,进.[4]
·多项目总是面临冲突无法协.[3]
·项目经理该不该参与开发的.[15]
·项目领导无法正确判断项目.[3]
·需要职能部门的配合的时候.[17]
·项目领导无法正确判断项目.[4]
·如何做好项目的质量成本分.[738]
·对开发流程不了解的项目经.[5]
·用人抓大放小,要学会放权[11]
·关于PMO工作内容的思考[11]
·项目经理如何提高自己的情.[18]
·新任产品经理,如何才能更.[6]
·如何评价产品经理拿数据说.[12]
·技术出身的管理者,求教如.[14]
·如何确保项目能在有限时间.[893]
·IT项目经理应该如何与技术.[1380]
版权说明
本网站案例栏目中,案例及案例分析为项目管理者联盟网站版权所有,如需转载或引用,请务必注明:案例摘自项目管理者联盟[www.mypm.net]。如需用于商业用途,必须得到项目管理者联盟授权,可发邮件至管理员 申请或电话咨询:010-82273401/11
敏捷项目管理ACP认证培训
国际产品经理NPDP认证
对日本软件外包项目失败原因分析
[姓    名]  项目管理者联盟 [单    位]  真实案例,单位保密 [发布时间]  2008/12/22
[所属行业]  IT软件 [所属主题]  项目综合管理 [项目阶段]  项目全过程

案例正文

这是一个针对日本的软件外包项目。客户是日本的一家著名的大企业,全球500强之一。

客户要求的内容很多,也很严格,不仅要求使用指定的技术和工具,而且还自主开发了一个平台,要求在该平台上进行开发、测试;还有各种文档格式要求和技术要求;最重要的是要保证工期,一定要在2个半月内提供高质量的、完整的产品。

中国数家企业参与了该外包项目。D企业是其中之一,主要负责该项目40本程序(本是实现一个完整功能的程序单位。一本程序也就是一个程序。这与我们国产软件的设定不一样。)的详细设计、编码以及单体测试工作。

成立项目组

项目立项后,D公司成立了项目小组。项目经理是一名在对日软件项目方面有多年开发经验的开发人员,但是,他是第一次带项目。项目经理下设三个小组:负责详细设计的DS小组(6名成员),负责编程的PG小组(5名成员)以及负责测试的PT小组(5名成员)。每一小组设置一名小组长,配备若干组员。

同时,D公司在日方派驻了一名SE(高级分析设计人员),主要负责分析、设计以及中日两方的协调工作。DS人员具有丰富编程经验,提前1周进入了项目组工作。

之后,PG和PT小组成员开始进入项目。项目经理安排PG和PT小组1周内熟悉这个复杂的平台。

项目正式开始了。经过分析,项目组决定将40本程序分为A、B、C三类,分别包括10本,12本,18本程序。其中,A类的难度看起来似乎不高,是一些数据库表的维护工作,和业务没有太大关系,工作量也很少。B类和C类难度预计差不多,但是,分别属于不同的业务领域。

一个星期后,部分程序的详细设计出来了。为了保证工期,项目小组决定三个小组同时进行,并行工作。详细设计人员继续做详细设计,编码人员投入编码,而测试组成员同时编制测试设计书,并设计测试数据。

初试成功

项目经理决定PG小组首先从难度最小的A类程序入手,这样不仅可以看到成功的曙光,而且可以鼓舞大家的士气。于是,5名PG小组成员开始分别着手A类程序。一切都很顺利。1本程序差不多在2天内完成了。

一周后,A类程序全部编码完成,PT组开始测试,完成了一半的测试工作。随后,测试修改完毕后的5本程序交给日方确认,顺利通过,客户评价也极高。

于是,项目经理信心百倍,项目组成员也信心十足。经过仔细分析,剩下的B类和C类程序,可以根据处理侧重点的不同划分为入力系、Batch系、账票系三类,比例大致相当。项目经理也更新了进度计划。新的进度计划中,每名PG成员分别负责2本入力系、2本Batch系、2本账票程序。DS小组的工作也进展顺利。

遭遇难题

正当大家怀着胜利的喜悦继续前进的时候,PG小组遇到了很大的难题。日方提供的开发平台太复杂了。此时,项目小组才发现,已经开发完成的A类程序其实只是一种2层结构的程序,而B类、C类程序是复杂的3层结构,要搞清楚如何开发这些程序不只需要时间,更需要充足的经验和高超的技能。PG小组成员纷纷卡壳,不知道该在哪儿赋值,不知道该在哪儿取值,与以前接触的编程截然不同,似乎每本程序都有一个无穷的长链,只有龙头,没有龙尾,无法理清。

一周过去了,原定很顺利就编写完的程序的实际进度却是5%,或者10%,这并不是说,已经开发了5%或者10%,而是为了表明这些程序的开发工作已经开始,而向客户展现一种开发中的姿态(因为每日都要给客户发送进度报告)。于是,项目经理开始要求大家加班。

两周过去了,技术最好、经验最丰富的一名PG人员—小G的进度率达到了40%,而其他成员仍然在原地踏步。大家纷纷去请教小G,小G不耐烦地回答:“去看日方发过来的资料吧”。

烦躁,焦虑,疲劳,一名PG成员病倒了,打了个电话要请假。过了几天,又一名PG成员也来电话请假,说是感冒。三周后,也就是1个月后,除了10本C类程序全部开发完成,通过验证外,只有一本程序的进度率达到了80%。5名PG成员中的2名病倒了。大家都忙着从数百页的日文开发手册中寻找答案。

于是,项目经理开始要求PT组有经验的成员加入PG组以填补空白。

小G的程序完成了,可是运行后什么也没有。又经过一周,小G的程序基本可以运行了,但是还有很多的技术问题,测试结果极不理想。

紧急救“火”

工期已经非常逼近,不能再等了,于是项目小组开始向公司反映情况。公司立即从其他项目组中抽调了2名经验丰富的“技术高手”来协助。鉴于绝大部分程序的详细设计已经完成,召回了在日本的窗口SE—“业务高手”,同时安排大家都加班。

为了很好地运用小组中的知识财富,D公司安排小G不再继续开发工作,而是做技术总把关,做专职的问题解决能手。后来,集中大家的智慧,解决了入力系的入力难题,解决了Batch系的没有界面而有极多数据复杂处理问题,以及账票系的账票出力问题。

快到截止日期时,原有的PG成员中有2名开始长期请病假。

经过大家的齐心协力,加班加点,在预定截止日期的当天,所有程序都开发完毕,测试完毕,只是还有很多问题和错误需要修正。

为了保证工期,项目经理决定暂时将问题和错误隐蔽,将所有的测试报告中的“再确认”一栏填写上“OK”。项目经理提交所有预定提交的成果物。同时,PG和PT人员仍在继续奋战。

一周后,日方发过来大量问题,绝大部分是单本程序的问题。项目小组继续修正。一个月后,项目终于结束了,项目小组才得以解散。

项目虽然在规定的日期内完成,但从管理的角度来讲,这是一个失败的项目管理,在管理过程中仍存在着许多隐患,请大家分析一下:

1、该项目在项目计划上是否存在问题?
2、项目经理在任务分配上是否合理,有哪些需要改进的地方?
3、项目经理在项目后期的团队成员管理上,是否存在问题?

项目管理者联盟PMP培训
相关分析14个分析)

须一
省份:上海市
单位:该信息保密
行业:IT软件
 
时间:2011-06-27
题目:针对开发中的问题

分析:我做了多年的对日开发,我觉得在开发过程中有不少问题。
1 程序难度分类后,开发顺序制定的不好。B、C类程序难度大,和基盘的关联也密切,应该优先进入开发,最好分出几个优秀且有经验的PG分别针对入力、batch、帐票做出程序sample。对日开发时,同类程序的结构基本是一致的,有sample再推广比较容易几十个人同时开发。
2 B、C类程序大规模推进时,PG的任务分配方针完全错误。入力、batch、帐票的基盘是不同的,batch、帐票还相近点,帐票是种特殊batch。在工期紧、大家都对基盘不熟悉的情况下,最好的分配方式是指定PG专门开发某一类程序,第一本会慢点,但第二本开始速度就会加快。要把这3种类型全都搞懂弄熟,没有相当的时间及开发量是不可能的。
3 项目经理、小组骨干在情绪控制上没有做好。大家都不懂,项目组更应该保有一个互助互利的气氛,而不是将经验私藏,只知道逃避。定期开经验交流会,把不好的情绪发泄出来,也是件很重要的事。

九品彼岸
省份:北京市
单位:该信息保密
行业:工程设计安装
 
时间:2009-03-31
题目:管理层(PMO)着重总结经验

分析:1、项目拿到手后才成立项目组,说明投标环节有隐患。项目组应该尽早成立,参与投标管理,比如技术要求不清楚,工期紧等等因素。
2、对外方提供的开发平台没有提前做好技术准备,说明本项目计划存在瑕疵。
3、出现“救火”情况,项目经理固然有责任,但也说明公司项目管理体系存在一定问题。作为高级项目经理,或企业PMO,计划工作没有做好。
4、大概看看,人力资源管理也没有计划好。我想项目经理的资源是有限的,搞好沟通管理,调动人力资源支持要有上层的授权。
总之,个人感觉从管理层层面(PMO)着重总结经验。

左红英
省份:上海
单位:该信息保密
行业:IT软件
 
时间:2009-03-14
题目:风险意识很重要

分析:1 项目计划
项目计划的做成欠缺准确性
项目计划在作成前需要正确地估算每个模块的难度及所需工时。这里对难度的估计作的不够准确。项目经理应在计划作成前与技术专家分析个模块的难度,做好初步的WBS,这样可以将计划作的更准确,也可以更合理的分配任务。
根据简单功能的进度调整进度计划,暴露了此项目经理对风险估计的不足。
2 任务分配
任务量的分配多少是由量和难度决定的,不好说每个人的工作量问题。但是开发流程上存在着大的漏洞。B类C类的问题在详细设计阶段就应该被发现,并及时记入课题。而不应再编码时才暴露出来。就算有些棘手的问题计划过程中没有意识到,也应该及时的由DS等技术人员加入解决,而不是让经验不足的PG浪费宝贵的开发时间。
应在计划中就设定项目风险等级,提高风险反应速度。项目进度在大规模滞后才意识到开始救火,即让自己的工期紧张,也可能给公司的管理安排等方面带来困扰。

3 团队管理
管理上的混乱造成了大量加班的发生。有些成员有可能是真的累倒了,也有可能是在逃避这样的工作方式。长时间加班不只是降低效率,还会使团队的人心涣散。要及时了解成员的想法,收集大家意见。
这个时候,可以有这几种选择:1利用各种工具提高开发效率,2适当的向公司提出加入人手,3试着与客户协商调整工期。

另外,将问题和错误隐蔽的做法有砸自己和公司饭碗之嫌^^。


王瑶
省份:上海
单位:该信息保密
行业:IT软件
 
时间:2009-02-14
题目:前期的pilot选错对象了

分析:从难度最小的A类程序开始固然可以鼓舞士气,但是应该按照每种技术类型,一般就是入力系、Batch系、账票系三类,各选较典型的一本,派最强的人员作出样板来。之后大队人马才开始行动,由于都有了参考的样板,效率会高很多。一下子铺开,出了问题代价非常高。尤其对新接触的flamework,只有2个半月的开发时间,个人经验根本就是个风险很高的项目,对最早作为pilot的程序,一定要确保包括所有类型。

王新星
省份:上海
单位:该信息保密
行业:IT软件
 
时间:2009-02-07
题目:项目经理应变不够及时

分析:当项目遇到困难时没有及时安排攻关人员,或与日方交流。等项目4/10的时间浪费了后,才在公司的帮助下,集中大家的智慧,任命技术攻关人员,反应也太慢了。
整个团队的协作不够。当大家纷纷去请教小G时,小G给与的不是帮助,而是拒绝,显然浪费了大家不少时间。项目经理应该在此时组织大家学习,由小G分享经验及心得,同时肯定小G的能力及贡献。
在对开发平台不熟悉,程序怎么运行的都不了解的情况下开发出来的程序没有bug基本是不可能的。作为国内的软件外包公司,有一个比较共性的毛病,就是太注重语言,而相对的轻视技术。在文中提到“DS人员具有丰富编程经验”,但是在项目的攻关时却没有看到DS的身影。很显然,本项目的详细设计是不到位的。该在哪儿赋值,该在哪儿取值,详细设计都不写,详细设计都写了啥?代码编写不下去就是DS的问题。

jxy
省份:广东
单位:该信息保密
行业:IT软件
 
时间:2009-02-04
题目:分析

分析:1、项目计划问题
1)需要制定项目进度计划,采用WBS技术对项目任务进行合理的分解,并进行工作责任分配,然后对分解的工作任务进行合理的排序。从项目后续期间产生的问题看,在制定项目进度计划方面,项目经理在任务分解和工作任务排序上不够合理。比如,在工作安排上,先完成最简单的A类程序,没有首先解决项目的技术难点和关键点,把比较难的B类和C类程序安排在后续完成,导致项目严重延期。
2)需要制定项目风险计划。项目经理需要站在全局的角度,对整个项目存在的技术风险、业务风险和管理风险等进行全面的分析,并制定相应的风险控制计划。从案例看,项目经理没有对技术风险进行分析,导致由于平台技术问题,影响了项目的进度和质量。
3)需要制定项目人力资源计划。从项目产生的问题看,项目经理在人员安排上出现了问题。比如没有先安排DS或者SE进行技术难点公关,没有对编程人员进行技术培训等。

2、任务分配问题
项目经理在任务分配上不够科学。
1)首先应对项目的业务和平台进行熟悉,这方面做得工作不够深入和全面,到项目后期才发现问题,直接影响了项目的进度。
2)应先确定项目的关键路径,保障项目关键任务的完成,才能保障项目能按期完成。项目经理先从最容易的程序开始做,低估了B和C类程序的难度,结果由于关键任务安排在后续做,再加上技术难点没有解决,导致了后续项目的混乱局面。
3)SE和DS在项目中应发挥重要作用,需安排技术水平高的人员对B类和C类程序进行技术难点攻关,由于A类程序比较简单,人员安排可以少些。

3、项目后期团队成员管理
1)制定团队激励和惩罚措施。
2)加强项目组人员的沟通,增强团队的凝聚力


梁桢
省份:上海
单位:该信息保密
行业:综合应用
 
时间:2009-02-02
题目:小小看法仅供参考

分析:1.在文章中没有看到PG和PT在了解日方系统及DS在分析设计时没有看到SE发挥了什么作用,而SE在整个项目中出现“工期已经非常逼近,不能再等了”的时候才出现,所以SE在这个项目中是伐真正发挥了作用需要笔者分析,如果真实情况真是如此则是沟通出了致命问题。

2.在发现BC勒是3层结构的而非2层结构时,明显是系统分析不彻底导致,从事软件开发工作的都知道需求分析尤为重要,而项目经理为了追求一时的“首战告捷”缩短了项目需求分析时间或ABC类内在联系的分析,风险意识不够。

3.PG成员G认真分析日方的资料,而其他成员均无所适从,明显是需求分析不透彻和内部成员沟通不畅导致。

4.在“工期已经非常逼近,不能再等了”的时候项目经理才向公司求援,明显是项目经理风险意识不够。

5.对于隐藏BUG问题可以理解,但不提倡。
最后,没有看到项目经理在此过程中发挥了多大的作用。


黄小东
省份:上海
单位:该信息保密
行业:IT软件
 
时间:2009-01-31
题目:前期分析!

分析:感觉主要是前期的技术分析不到位。
其他方面还是做的不错的。

zhangpy
省份:山东
单位:该信息保密
行业:IT软件
 
时间:2009-01-21
题目:问题不少

分析:1、项目经理的第一个项目,公司应当予以经验方面的协助和管理
2、前期任务分解分析不到位,根本原因不可得知,可能是出在技术上,或许别的方面不畅通。
3、项目内部沟通不好
4、危机处理能力差,遇到特殊情况就一触即溃
此项目并没有太多的不可控因素存在,项目经理的各方面能力需要加强

杨永新
省份:广西
单位:该信息保密
行业:IT软件
 
时间:2009-01-10
题目:个人看法

分析:1、缺少风险分析。
1、技术人员间缺乏沟通合作。
关于联盟 | VIP会员 | 培训服务 | PMP认证 | PgMP认证 | 刊物出版 | 沙龙会议 | 人才服务 | 广告投放 | 联系我们 | 友情链接

项目管理者联盟 版权所有 | 京ICP备10055250号-11 | 京公网安备 11010202009440号

如转载本站文章,必须于文章开头处注明转自“项目管理者联盟”,并注明原作者
PMI,Project Management Professional, OPM3, PMBOK, PMP,PgMP,PfMP,PMI-ACP,PMI-PBA
and the PMI Registered Education Provider logo are registered trademarks of the Project Management Institute, Inc.