* 帖子主题 *  真实案例:非常失败的项目    你是第 3269 位浏览者          钟鼓楼     军衔: PMU初级二星  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 311篇  注册: 2001-12-28                         --------------------------------------------------------------------------------        一个中型的MIS项目,期间客户不停的更改需求, 公司负责人考虑到与客户的关系,要求PM服从客户的要求。PM对项目中其他方面的控制并没有问题。最后项目被延期了3个月,质量也不尽如人意。  问:如果你是项目经理,你怎么办?     --------------------------------------------------------------------------------  在空旷的星河下想你,那个在风里游弋的光影    --------------------------------------------------------------------------------    [ 本文发表于 2001年12月29日 22:33:31 ]            bill      军衔: PMU初级一星  财产:   经验:   魅力:   来自: 北京市  鉴定: 本功能已经被关闭   发帖: 148篇  注册: 2001-12-17                         --------------------------------------------------------------------------------        该问题在SI公司中普遍存在,也始终困扰着SI公司的项目经理。首先我想先从项目经理以外的环境来分析此问题。  针对这个问题实际上原因主要是项目实施的大环境不好,主要是:客户的成熟度、公司的项目管理制度的问题。  1.客户成熟度方面,由于客户对自己项目的理解不是很深入或者是由于“客户至上”的观念在作孽,他们始终认为我出钱做事,你们就应该听我的,导致客户认为需求的变更非常普遍,变更是天经地义的事情。针对这方面的原因,解决的方法只有提高客户的能力和水平,减少同业的恶性竞争,相信随着发展,客户的观念也在逐渐的改变。而且这种改变已经在某些地方有所体现了!  2.公司的管理制度的问题。公司对于项目管理没有真正实现以项目的实施为中心的发展结构,而始终强调客户至上,这样出现了这个问题。实际上这是一种误区,如果单纯的强调客户至上,围着客户转,不论客户的要求是否合理都照单全收,就会使得项目实际上是按照客户的不成熟的想法去实施的,项目质量肯定不会好,最终受损的还是客户。所以这就需要公司适当的改变自己的做事方法,更多的去从实施的角度去考虑一些问题,特别是尊重项目经理的意见,这样才能真正做到有利于客户,有利于公司的发展和形象。另外针对变更,公司建立比较严格和可操作的流程,减少变更的随意性。     --------------------------------------------------------------------------------     --------------------------------------------------------------------------------     [ 该贴在 2001年12月30日 8:51:48 被 bill 修改过 ]              bill      军衔: PMU初级一星  财产:   经验:   魅力:   来自: 北京市  鉴定: 本功能已经被关闭   发帖: 148篇  注册: 2001-12-17                         --------------------------------------------------------------------------------        从项目经理的角度讲,他不能从根本上来解决此问题,但是确有办法避免和降低此问题的影响。我觉得可以有以下几种方法:  1.需求分析阶段。与客户充分的交流,及时发现客户的隐含的需求,同时多从客户的角度去着想,将功能尽可能的完善。在需求分析没有完全彻底时,不要盲目开工,千万不要抱着先做,有问题再说的想法!  2.制定项目需求变更的流程。成立需求变更控制小组,由客户方的负责人加入此小组,对于需求变更的出现,必须通过此小组,评审通过后方能认可。增加了需求变更的复杂性和可行性,会降低需求变更的次数,减少不必要的需求变更。  3.明确告诉公司的管理层,需求变更需要经过项目经理的评估,并且将每次需求变更会造成的各方面的不利影响明确的记录,并向管理层汇报。  4.向项目的实施过程中,学会引导客户,以减少不必要的变更!  如果出现了此问题之后,在项目后评价阶段项目经理应该做什么呢?我觉得:  1.将过程中出现的变更记录,向管理层提交,以体现项目出现此结果的原因。  2.提交较详细的项目总结,反映由于变更对项目的影响,建议公司采取改进措施。  3.在项目组内部进行总结,发现哪些变更是由于我们自身的原因造成的,进行经验的总结,找出解决的方法!     --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2001年12月30日 9:16:29 ]            钟鼓楼      军衔: PMU初级二星  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 311篇  注册: 2001-12-28                         --------------------------------------------------------------------------------        bill,你的回答很精彩。。。佩服,佩服。    --------------------------------------------------------------------------------  在空旷的星河下想你,那个在风里游弋的光影    --------------------------------------------------------------------------------    [ 本文发表于 2001年12月30日 21:32:46 ]            juliett      头衔:   军衔: 二等兵  财产:   经验:   魅力:   来自: 上海市  鉴定: 本功能已经被关闭   发帖: 82篇  注册: 2001-12-24                           --------------------------------------------------------------------------------        我觉得主要责任在公司的管理层,现在很多项目都存在这个问题,项目经理只能在他的职权范围尽可能减小后果的严重程度,但是我认为这种不良的大环境因素项目经理已开始就应该预估他的风险。  个人看法,不成熟的地方请版朱和其他同志们指出,共同切磋。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2001年12月31日 11:30:00 ]            daiqiang      军衔: 三等兵  财产:   经验:   魅力:   来自: 四川成都市  鉴定: 本功能已经被关闭   发帖: 127篇  注册: 2001-11-26                           --------------------------------------------------------------------------------        如果能成立变更控制委员会,要求有公司高层和客户的高层参加,如果遇到需求改变,要求大家一起来评审,该变更造成的进度和预算改变必须要当官的签子认可,才开始具体的开发。我也认同前面同志哥意见,谢谢。    --------------------------------------------------------------------------------  骆驼飞鸟和鱼:  你就象冬天的雪花,我不该接近你,你融化了,悄悄的,消失在我温暖的眼里     --------------------------------------------------------------------------------    [ 本文发表于 2001年12月31日 14:18:02 ]            bill      军衔: PMU初级一星  财产:   经验:   魅力:   来自: 北京市  鉴定: 本功能已经被关闭   发帖: 148篇  注册: 2001-12-17                         --------------------------------------------------------------------------------        juliett 和daiqiang讲的非常有道理,实际上项目失败的主要责任应该由公司的管理层承担!  但是在目前的情况下(大环境),项目经理如何做呢?  我觉得大家的提议很好,成立变更控制委员会,进行风险的预评估,都是很好的选择!而且对工作的开展确实有利!     --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年1月4日 9:31:44 ]            juliett      头衔:   军衔: 二等兵  财产:   经验:   魅力:   来自: 上海市  鉴定: 本功能已经被关闭   发帖: 82篇  注册: 2001-12-24                           --------------------------------------------------------------------------------        我觉得bill提出的第一点非常重要,就是充分的了解客户的隐含需求,不过最多发生的事就是,即使项目需求变化以后,老板和客户也不会把它当成项目变更来处理,不会给你更多的时间和资源,ibm的做法就是截止到一个时间以后就再不能提新的需求了,如果提的话就当时项目变更了,在合同里写得很清楚。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年1月4日 17:23:00 ]            daiqiang      军衔: 三等兵  财产:   经验:   魅力:   来自: 四川成都市  鉴定: 本功能已经被关闭   发帖: 127篇  注册: 2001-11-26                           --------------------------------------------------------------------------------        可是在实际的SI类的项目中,如果按照IBM的方法,我估计项目100%的失败。可分2点来看  1:如果是涉及基本的需求变更,那必须变,得叫双方老板同意。除非老板对发生的任何结果都对你满意,则可以按原计划进行。  2:非基本需求可以不变,告诉客户不接受对方的变更。    --------------------------------------------------------------------------------  骆驼飞鸟和鱼:  你就象冬天的雪花,我不该接近你,你融化了,悄悄的,消失在我温暖的眼里     --------------------------------------------------------------------------------    [ 本文发表于 2002年1月4日 18:50:22 ]          rabing      军衔: PMU初级一星  财产:   经验:   魅力:   来自: 山东济南市  鉴定: 本功能已经被关闭   发帖: 152篇  注册: 2001-11-29                           --------------------------------------------------------------------------------        客户成熟度方面,由于客户对自己项目的理解不是很深入或者是由于“客户至上”的观念在作孽,他们始终认为我出钱做事,你们就应该听我的,导致客户认为需求的变更非常普遍,变更是天经地义的事情。  太经典了    --------------------------------------------------------------------------------  求之不得,不求或与  http://www.jn-cyberport.com    
  --------------------------------------------------------------------------------    [ 本文发表于 2002年1月9日 10:10:51 ]            ljk99      军衔: 无军衔   财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 1篇  注册: 2002-1-18                       --------------------------------------------------------------------------------        我的办法是:  1 确定版本,客户要求改变的需求,如果变化不是很大,可以留到下一个版本解决  2 可维护性可塑性对一个项目很重要,不要死盯着之前的东西不放    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年1月18日 22:01:46 ]            Endeavor      头衔: 论坛版主  军衔: 三等兵  财产:   经验:   魅力:   来自: 上海市  鉴定: 本功能已经被关闭   发帖: 156篇  注册: 2001-12-10                           --------------------------------------------------------------------------------        是不是问题的根源在于项目组和客户没有合同平等关系?  永远不能解决的问题阿.这种情况下项目经理只能竭尽所能,以求心安.     --------------------------------------------------------------------------------  所有的一切都将成为项目...    --------------------------------------------------------------------------------    [ 本文发表于 2002年1月22日 18:36:47 ]            zhangjm      军衔: 一等兵  财产:   经验:   魅力:   来自: 江苏南京市  鉴定: 本功能已经被关闭   发帖: 68篇  注册: 2002-1-20                         --------------------------------------------------------------------------------        我认为既然是客户提出的变动,则应按照客户的意识改动,毕竟项目是为客户服务的。但同时客户必须承担改动造成的各种损失:包括时间和money。做法如下:  a)由客户提出更改的要求,必须是书面的,以作备案  b)根据客户要求制定相应的变动后的进度及相应的资金变化,如对已完成工作的变动,客户需承担损失  c)和客户进行更改后的项目商议,客户同意后双方签字。  此时,也不会存在说的问题了    --------------------------------------------------------------------------------  明天会更好    --------------------------------------------------------------------------------    [ 本文发表于 2002年1月25日 9:59:27 ]            eastsoft      军衔: 二等兵  财产:   经验:   魅力:   来自: 北京市  鉴定: 本功能已经被关闭   发帖: 32篇  注册: 2002-1-23                           --------------------------------------------------------------------------------        ljk99 在 2002-1-18 22:01:46 发表的内容   我的办法是:  1 确定版本,客户要求改变的需求,如果变化不是很大,可以留到下一个版本解决  2 可维护性可塑性对一个项目很重要,不要死盯着之前的东西不放          我同意这位大哥的意见,我听说一些大的软件公司他们做软件的时候就是先按照需求分析开发(当然这个需求是很详细的),然后如果有什么需求变更的话就留在当前项目开发完毕了再完成。  如果需求变更比较小,应该是以补丁的形式发布,  如果需求变更比较大,应该就是一个新版本喽  good luck      --------------------------------------------------------------------------------  飘在北京……~~    --------------------------------------------------------------------------------    [ 本文发表于 2002年1月25日 15:53:51 ]            zhg321      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 60篇  注册: 2001-11-26                         --------------------------------------------------------------------------------        在工程项目管理中,甲方提出变更,增加工作量,要向乙方付钱,这是惯例,也是工程索赔的重要内容。在软件工程中,同样也存在这个问题,不能因为变更导致的工作量增加是脑力劳动,就不支付增加费用。要彻底解决这个问题,关键还是形成这样的制度,比如合同中规定,乙方严格按照甲方认可的需求的提供服务。  当然,这需要一个过程,乙方应当主动维护自己的利益。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年3月20日 12:17:42 ]            ralph      军衔: 三等兵  财产:   经验:   魅力:   来自: 深圳  鉴定: 本功能已经被关闭   发帖: 305篇  注册: 2002-3-5                         --------------------------------------------------------------------------------        同意,在合同中应该明确的提出变更的控制和相应附加费用条款,我们就是这样做的。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年3月20日 13:18:05 ]            mikeliu      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 620篇  注册: 2002-1-16                         --------------------------------------------------------------------------------        合同的谈判很重要。    --------------------------------------------------------------------------------  多想!多讨论!多实践!    --------------------------------------------------------------------------------    [ 本文发表于 2002年3月20日 21:24:32 ]          mikeliu      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 620篇  注册: 2002-1-16                         --------------------------------------------------------------------------------        MIS是最容易“镀金”的项目。客户多数情况下都不清楚自己需要什么。项目组和客户的关系常常是不平等的。应该改变“客户是上帝”的观念,建立“双赢”的Partnership.    --------------------------------------------------------------------------------  多想!多讨论!多实践!    --------------------------------------------------------------------------------    [ 本文发表于 2002年3月20日 21:30:52 ]            jim0124      军衔: 下士  财产:   经验:   魅力:   来自: 北京  鉴定: 本功能已经被关闭   发帖: 98篇  注册: 2002-2-25                           --------------------------------------------------------------------------------        以中国目前的现状来看,MIS开发是一个没有终点的项目,所以要彻底从一个MIS开发项目中脱身,我建议在开发的过程中要注重培养用户自己的技术人才队伍。一旦达到了这个目标(事实上也是一个比较容易实现的目标),用户就会很容易接受将新需求放在后续版本中实现的要求。  这也是一个方法论的问题。    --------------------------------------------------------------------------------  你是如何面对现实的    --------------------------------------------------------------------------------    [ 本文发表于 2002年3月22日 9:27:50 ]            claymore      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 6篇  注册: 2002-3-25                       --------------------------------------------------------------------------------        对于这个案例,不知道合同是怎样签的。根据小弟的经验对于目前中国Mis软件业的行情,在处理客户关系这个问题上PM投入的精力应该是他拿的工资的一半水平。呵呵  1. 搞好与客户上上下下的关系,做到出了问题客户主动帮你顶。(具体怎么做那要看PM的水平了,吃饭,喝酒,泡妞都是可选项。哈哈)  2. 一定要公司把合同签得好,该硬的时候要硬。有时候翻脸是必要的(不用担心,副总出面翻脸,你出来赔罪,老总请客.................ok?)  3. 加上你对项目的优秀控制,相信项目可以做到60分,不要要求太高,Mis项目不失败就是最大的成功了。  祝所有PM好运!AMon.      --------------------------------------------------------------------------------  PMP    --------------------------------------------------------------------------------    [ 本文发表于 2002年3月25日 16:02:55 ]            claymore      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 6篇  注册: 2002-3-25                       --------------------------------------------------------------------------------        还有就是关于CCB的,把客户的一把手搞进CCB是非常有必要的,这样做可以让PM把一些不必要的修改挡在门外(让客户的Boss去管客户,毒辣吧!)    --------------------------------------------------------------------------------  PMP    --------------------------------------------------------------------------------    [ 本文发表于 2002年3月25日 16:08:35 ]            weapon      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 11篇  注册: 2002-3-20                         --------------------------------------------------------------------------------        bill的回答有一定的道理,可是我经历过一个Mis项目,项目需求变更控制具有以下条件:  1、所有需求变更必须经过变更委员会的签字确认。  2、变更委员会成员包括客户方领导、信息中心成员和最终使用用户核心成员。  3、所有变更记录必须得到公司质量部门批准、客户方信息中心领导批准和最终使用用户领导批准。  但是这些控制条件还是不能减少客户提出需求变更。客户甚至经常提出带有反复性的变更要求,而公司为了维护与客户的关系,不能不做,时间拖长了还会引起客户的责难,像这种情况该如何处理呢?    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年3月25日 16:57:32 ]            Tiggler      军衔: 一等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 46篇  注册: 2002-3-18                         --------------------------------------------------------------------------------        曾做过些MIS项目,感触颇深:  1. 客户需求不断变化,随着时间的延长,他们对系统越来越了解,所以要求也越来越多;  2.手下人的意见越来越大,加班没有出头的日子;  3.bug不断,越修补越多  后来我采用了一些以前在建设工程中用的方法抑制这些现象的出现:  1. 对于目标不断变化,首先订下尽可能详细的合同,对质量有明确的定义,以后的目标变动,客户必须是书面的,而且要双方估价确认,当场支付费用才修改,否则以合同为搪塞;  2.对于加班太多,充分做好下属的家属思想工作,希望她们能理解、支持,适当时强制下属停止工作,放假一天;  3.只采用非常成熟的技术,绝不采用任何没有完全掌握的或不能完全控制的技术。  在项目管理中,文档是非常重要的,而国内软件工程师特别反感写工程文档,所以这个工作基本上是我自己来做的,但请工程师过目,不要出什么技术上的纰漏就可以了。      --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年3月28日 19:14:18 ]            gemmy      军衔: 一等兵  财产:   经验:   魅力:   来自: 宁波  鉴定: 本功能已经被关闭   发帖: 45篇  注册: 2002-3-25                         --------------------------------------------------------------------------------        我现在就在执行一个项目,因为厂长和顾问没有足够经验,我没有权力处理,经常变更,土建工期delay30天,预算超支200万RMB左右。只能在安装期间赶回来。  我想交一些做工业技改项目的朋友,投资在1000万RMB以上的。精通STEP7优佳。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年4月1日 19:06:08 ]            conan      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 4篇  注册: 2002-4-10                         --------------------------------------------------------------------------------        我觉得应在如下几方面考虑:-  1。变更控制程序是要的,但是程序要考虑到最终使用用户不一定有变更请求的权限,他们必须通过变更控制程序规定好的人员来进行  2。项目的需求,我们不能只考虑到通常所指的系统功能需求(即是产品范围),而也应该从项目范围考虑  3。在项目实施之前(即我们通常说的详细设计、编码等),一定要到用户对系统需求的签名,这样即使用户需要改动,我们还可将该签名的需求为依据来商谈人力、成本、进度的改动  4。用户任何的变更改动,最好采用正式的表格来填写,而不要采用email,口头方式,采用这些方式用户常常可以反悔;采用正式表格使用户不厌其烦填写变更请求,这也是给用户一个重新思考的机会,我们发现采用这方式可以有效降低用户随口提的变更请求  5.我们并不反对需求变更,但是不能在系统任何时候多允许变更,我们至少应在系统集成测试时要停止用户的功能增加的请求(当然,用户接收测试时发现的功能缺陷要改的)    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年4月10日 17:38:25 ]          buffers      军衔: 无军衔   财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 4篇  注册: 2002-4-16                       --------------------------------------------------------------------------------        这中变更,让我三月内三次,大手术,为什么?公司经营结构变动,软件必须得该,够苦了。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年4月16日 11:08:38 ]            一刀      头衔: 中士  军衔: PMU初级三星  财产:   经验:   魅力:   来自: 上海  鉴定: 本功能已经被关闭   发帖: 467篇  注册: 2002-4-13                         --------------------------------------------------------------------------------        加需求还是另做一个版本这是可以商量的嘛。  我发现大家都没有将系统工程师归入讨论的范围,令我非常意外。项目经理和老板都是是管理上的负责人,系统工程师才是技术上的主角,框架是他搭的,是否能加东西,风险如何都是他说了算的,项目经理的判断主要是基于他的结论。当然文档化的过程是必须的。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年4月16日 17:03:16 ]            coolpenny      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 6篇  注册: 2002-4-19                         --------------------------------------------------------------------------------        客户需求变更也让我吃尽苦头。我觉得presale有很大的责任,他们总是将信息系统吹得无所不能,让客户的初始期望过高,总希望能够做到完美,这就是客户不断变更需求的主要原因。所以presale在给客户灌输mis思想的时候,是不是能够更结合实际,确定一个比较可行的scope和goal。  另外,由于客户需求变更的主要来源于客户项目组或者最终使用者,并由客户项目经理决定。如果能够将客户项目经理的个人利益与项目实施的成败挂钩,相信客户项目经理不会轻易做出较大的变动,而是争取在他们老板的时间、成本、质量控制下完成项目实施工作。    --------------------------------------------------------------------------------  项目是有生命的    --------------------------------------------------------------------------------    [ 本文发表于 2002年4月19日 15:12:32 ]            coolpenny      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 6篇  注册: 2002-4-19                         --------------------------------------------------------------------------------        客户需求变更也让我吃尽苦头。我觉得presale有很大的责任,他们总是将信息系统吹得无所不能,让客户的初始期望过高,总希望能够做到完美,这就是客户不断变更需求的主要原因。所以presale在给客户灌输mis思想的时候,是不是能够更结合实际,确定一个比较可行的scope和goal。  另外,由于客户需求变更的主要来源于客户项目组或者最终使用者,并由客户项目经理决定。如果能够将客户项目经理的个人利益与项目实施的成败挂钩,相信客户项目经理不会轻易做出较大的变动,而是争取在他们老板的时间、成本、质量控制下完成项目实施工作。    --------------------------------------------------------------------------------  项目是有生命的    --------------------------------------------------------------------------------    [ 本文发表于 2002年4月19日 15:12:42 ]            SlowBull      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 9篇  注册: 2002-4-25                         --------------------------------------------------------------------------------        Well, 这确实是一个涉及很多方面的问题;而且在很多关键性的大问题上,已经超出了项目经理的基本职能范围。但在项目实施过程中,出现变化是很正常的事。项目经理应该有基本的常规能力来处理。  对于环境问题,我想这是项目经理在项目管理之外需要付出努力与自己的周围环境共同努力建设的问题。  另外,从技术上来说,为了能尽可能快地对用户的变化做出响应,还是有些办法的,虽然不能彻底解决问题。比如:极限编程 (XP, eXtreme Programming)。      --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年4月25日 20:36:09 ]            wli      军衔: 无军衔   财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 4篇  注册: 2002-5-14                       --------------------------------------------------------------------------------        但是,后果由谁承担呢?目前,软件公司的PM可能没有这个资格。: )    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年5月14日 18:10:41 ]            xuwa      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 6篇  注册: 2002-5-15                       --------------------------------------------------------------------------------        大家的意见都是正确的,其实项目本身就是管理变更的过程,解决的方法有数不清的种类,只要达到目的就是好方法。建议根据具体的工作环境使用各种变更控制手段和有效的沟通手段。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年5月16日 23:24:09 ]            acai      军衔: 无军衔   财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 10篇  注册: 2002-5-24                       --------------------------------------------------------------------------------        RUP has a concept which name is "Change Request", guess it will help you.    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年5月24日 12:58:00 ]          arthurzhen      军衔: 三等兵  财产:   经验:   魅力:   来自: 上海  鉴定: 本功能已经被关闭   发帖: 17篇  注册: 2002-5-7                         --------------------------------------------------------------------------------        对于一个新的项目来说,在项目的进行过程中本来就会有需求的变更和一些不可预见的因素夹在其中。  对于一个对目标经常变更的项目,首先项目经理就应当能够对项目的总体目标有一个更为细致的认识。至于细分到具体的目标时,可以给出更为详细的分析。当关键的需求未被更改时,那么这个客户的要求就不会对整个项目产生太大的影响。一旦是项目的关键目标被更改,我想这时的项目经理就应该考虑是否向公司提出要求,或增加成本的投入及廷长项目的周期。  以上是新手的个人关点,请多多指教。      --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年5月28日 11:54:59 ]            lionel      军衔: 无军衔   财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 2篇  注册: 2002-5-29                       --------------------------------------------------------------------------------        有个笑话,巴依老爷给阿凡提一块布,让阿凡提做帽子,巴依老爷问做一个帽子可以哇,阿凡提说“可以”,可是贪心的巴依老爷问阿凡提说“那两顶”呢?阿凡提仍说可以,最后巴依老爷将帽子的数量提升到十顶,可布还是只有这一小块,阿凡提还是说“可以”。结果帽子做好了,巴依老爷去取的时候发现,阿凡提做了十顶特小的帽子,只能套在10个手指上。hoho。  这是现代卓越给我们做PM培训的时候举的一个例子。他的意思是,必须要让客户明白,项目变更是要有很大代价的。要么是让双方的老板交涉,延长工期,增加投入,或者就是和客户商量,为了控制成本,为了能够按时保质的完成该项目,建议将该项目中某些原不重要的功能去除(这点很重要,如果客户觉得要删除原有功能的,就会心痛肉痛,就不大敢再提新的需求)    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年6月3日 7:47:47 ]            bluestone      军衔: 三等兵  财产:   经验:   魅力:   来自: 上海  鉴定: 本功能已经被关闭   发帖: 61篇  注册: 2002-6-5                         --------------------------------------------------------------------------------        在开发中,这个问题已经太普通了。我的理解,一个是开发的时候,最好有这方面的经验。中国的软件公司,不论什么,它能不能做,都拼命去抢,没有自己的强项,抢下来的项目完不成。  本着公司长期发展的原则,公司应该注重某一些方面的开发,而不要是项目就做,这个在上海现在很严重。     --------------------------------------------------------------------------------  我爱阳光,它温暖我的身体,  我爱雨水,它洗涤我的灵魂,  我爱光明,它指明道路,  我爱黑夜,他让我看到星辰。    --------------------------------------------------------------------------------    [ 本文发表于 2002年6月5日 13:09:50 ]            cncaigs      军衔: 少尉  财产:   经验:   魅力:   来自: 广州  鉴定: 本功能已经被关闭   发帖: 371篇  注册: 2002-4-15                         --------------------------------------------------------------------------------        钟鼓楼 在 2001-12-29 22:33:31 发表的内容   一个中型的MIS项目,期间客户不停的更改需求, 公司负责人考虑到与客户的关系,要求PM服从客户的要求。PM对项目中其他方面的控制并没有问题。最后项目被延期了3个月,质量也不尽如人意。  问:如果你是项目经理,你怎么办?          在很多中小型的项目中,PM通常是集PM、系统分析员、系统工程师、高级程序员于一身。所以大多数人都会忽略。在我们公司的IT部门系统分析员就是这么干的。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年6月5日 15:46:41 ]            cncaigs      军衔: 少尉  财产:   经验:   魅力:   来自: 广州  鉴定: 本功能已经被关闭   发帖: 371篇  注册: 2002-4-15                         --------------------------------------------------------------------------------        奇怪!我想引用一刀老兄的文章怎么变成了钟鼓楼的文章了?    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年6月5日 15:49:14 ]            zhangmy_2000      军衔: 三等兵  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 19篇  注册: 2002-6-25                         --------------------------------------------------------------------------------        bill 在 2001-12-30 9:16:29 发表的内容   从项目经理的角度讲,他不能从根本上来解决此问题,但是确有办法避免和降低此问题的影响。我觉得可以有以下几种方法:  1.需求分析阶段。与客户充分的交流,及时发现客户的隐含的需求,同时多从客户的角度去着想,将功能尽可能的完善。在需求分析没有完全彻底时,不要盲目开工,千万不要抱着先做,有问题再说的想法!  2.制定项目需求变更的流程。成立需求变更控制小组,由客户方的负责人加入此小组,对于需求变更的出现,必须通过此小组,评审通过后方能认可。增加了需求变更的复杂性和可行性,会降低需求变更的次数,减少不必要的需求变更。  3.明确告诉公司的管理层,需求变更需要经过项目经理的评估,并且将每次需求变更会造成的各方面的不利影响明确的记录,并向管理层汇报。  4.向项目的实施过程中,学会引导客户,以减少不必要的变更!  如果出现了此问题之后,在项目后评价阶段项目经理应该做什么呢?我觉得:  1.将过程中出现的变更记录,向管理层提交,以体现项目出现此结果的原因。  2.提交较详细的项目总结,反映由于变更对项目的影响,建议公司采取改进措施。  3.在项目组内部进行总结,发现哪些变更是由于我们自身的原因造成的,进行经验的总结,找出解决的方法!          从项目管理的目的来看,项目延期并不能说明项目失败(可能项目经理会有失败感)."项目管理就是为了满足甚至超越项目涉及人员对项目的需求和期望而将理论知识、技能、工具和技巧应用到项目的活动中去。"最终只要用户方和项目承包方满意(需求得到满足),只要双方对项目延期没有异议(老板没有扣奖金),就应该说是圆满地完成了项目.BILL的意见只能是澄清了项目经理和用户方谁会最终承担项目延期的责任,但是并不能防止问题发生,如果没有人认为需要有人需要承担责任那么还有什么问题呢?      --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年6月25日 16:16:12 ]            xiaobugbug      军衔: 无军衔   财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 3篇  注册: 2002-7-11                       --------------------------------------------------------------------------------        欢迎大家去下述网址查看一个真实案例
  http://www.21cmm.com/bbs/view.asp?id={44C0C0DF-3FC6-4195-AAAE-895C19C9B3A5}&Title=项目管理的难题请大家帮忙解决    --------------------------------------------------------------------------------  Everything is project if you think it be. Everything isn''t project if you think it not.    --------------------------------------------------------------------------------    [ 本文发表于 2002年7月11日 23:41:39 ]            fxuefei      军衔: 无军衔   财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 2篇  注册: 2002-12-18                       --------------------------------------------------------------------------------        PM应该和客户建立良好的沟通,使他们知道什么样的要求是必要的,和可以2次开发的,降低他们的期望值,提高我们在他们心目中的成本值.很多问题可以放在2次开发上.    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年12月18日 17:43:49 ]          newchinaboy      军衔: PMU初级二星  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 141篇  注册: 2002-10-14                       --------------------------------------------------------------------------------        我经常遇到这种情况,客户的需求变化太快,看了诸位得高见,学习ibm挺不错的!    --------------------------------------------------------------------------------  共同进步,共同发展!    --------------------------------------------------------------------------------    [ 本文发表于 2002年12月19日 12:58:32 ]            schion      军衔: PMU初级二星  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 64篇  注册: 2002-10-22                       --------------------------------------------------------------------------------        我谈一点,公司内部的项目管理制度的建立和完善,有赖于各个从事项目管理的个人去推动,促进这一进程的加快。上层领导,不了解项目管理,他们没有时间,也能力来作这个事,唱主角的是项目管理人员。这是我的体会。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年12月20日 2:10:06 ]            dannyliu      军衔: PMU初级三星  财产:   经验:   魅力:   来自: 北京市  鉴定: 本功能已经被关闭   发帖: 114篇  注册: 2002-11-4                       --------------------------------------------------------------------------------        好文章    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年12月20日 11:12:43 ]            galber      军衔: 无军衔   财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 2篇  注册: 2002-12-31                       --------------------------------------------------------------------------------        juliett的提法很好,但在我国现状下不太可行。  我认为反而是引导客户更重要,也更可行。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2002年12月31日 16:00:18 ]            rewen      军衔: PMU初级二星  财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 25篇  注册: 2003-1-3                       --------------------------------------------------------------------------------        首先要从客户的角度帮客户理清楚需求。有些客户的需求根本不明确,或者客户自己也不知道做一个什么样的系统。这个时候需要我们从客户角度提出一个完善的系统。  其次,在客户作出不必要的功能追加的时候可向他们说明这需要额外的时间和金钱。你必须等待并且要另外支付费用,使客户就会重新考虑是否值得追加某些看起来很花哨但不实用的功能。    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2003年2月11日 16:19:38 ]            jie_rui      军衔: 无军衔   财产:   经验:   魅力:   来自: 不告诉你 :)  鉴定: 本功能已经被关闭   发帖: 5篇  注册: 2003-2-12                       --------------------------------------------------------------------------------        bill的回答的确精彩,主题思想就是尽量不要改动原需求    --------------------------------------------------------------------------------     --------------------------------------------------------------------------------    [ 本文发表于 2003年2月12日 17:06:16 ]            horsewmh      军衔: 无军衔   财产:   经验:   魅力:   来自: 上海市  鉴定: 本功能已经被关闭   发帖: 2篇  注册: 2001-11-29                       --------------------------------------------------------------------------------        按理说客户不断的变更需求是一件好事情,因为你可以得到更多的Money,当然前提条件是大家都遵守一定的游戏规则,比如说变更控制管理。否则的话,此项目必然出现进度无法控制的局面,质量的保证也就难说了。但是,如果通过这个项目的一定损失能够与客户建立非常到位的关系,那么你就还会有二期、三期或者别的什么项目来做,你的老板还是会赚的。    --------------------------------------------------------------------------------  广交业界朋友,让我们共同致力于项目管理。    --------------------------------------------------------------------------------    [ 本文发表于 2003年2月13日 18:27:37 ]          
				  |