请教一个项目管理的初级问题

时间:2023-01-19 16:58:05
现一个老项目,至今已有2年时间,客户有不断更新需求的可能,如何收尾结项阿,初期只定义了3个phase,现根据客户新的要求已增加到4个了,如何降低风险、降低变成烂尾的风险呢,需要哪方面的沟通目标和实施方法呢,请大家给我一些建议,谢谢
!

20 个解决方案

#1


项目内的需求有没有开发完成?客户满意度如何?客户关系如何?等等。这些信息没有,很难有一个建议的。
通常的建议可以是和客户商量,这4个新需求我给你做了,但项目得给我结了。如果对口头协定不放心,就写一个会议纪要双方签字确认,包括双方领导也要签字

#2


这还是初级问题?

呵呵

看销售怎么承诺的了,合同如果没有约束力,就靠关系了,

主要是项目经理怎么跟客户沟通了

先看看目前客户的态度,

不妨与客户吃饭聊一下

之后了解关键的问题,纠结在哪里

项目总要有范围,太大了不好定就阶段交付,*教导我们:零敲碎打牛皮糖

一点点的交付赢得信任,把钱结了再进行下一次合作

打官司是最终迫不得已的步骤,不建议

总之别人说什么都是扯淡,自己要去实践,多花心思和时间,须知此事必躬行

祝你成功~~



#3


引用 1 楼 nightcloud 的回复:
项目内的需求有没有开发完成?客户满意度如何?客户关系如何?等等。这些信息没有,很难有一个建议的。
通常的建议可以是和客户商量,这4个新需求我给你做了,但项目得给我结了。如果对口头协定不放心,就写一个会议纪要双方签字确认,包括双方领导也要签字


项目需求SRS已在设计前完成,由于框架太大了,客户满意度在初期是比较认可的,但已超过原定计划,因为项目面对沟通客户不是最终用户,他们与项目人员沟通是认可的,但一旦三方进行沟通,即马上翻脸,站在对方的立场说话,所以比较复杂,分批交付我们也有想过,但用户如不接受的话,恐怕不好好办阿,谢谢!

#4


引用 2 楼 cmm2cmmi 的回复:
这还是初级问题?

呵呵

看销售怎么承诺的了,合同如果没有约束力,就靠关系了,

主要是项目经理怎么跟客户沟通了

先看看目前客户的态度,

不妨与客户吃饭聊一下

之后了解关键的问题,纠结在哪里

项目总要有范围,太大了不好定就阶段交付,*教导我们:零敲碎打牛皮糖

一点点的交付赢得信任,把钱结了再进行下一次合作

打官司是最终迫不得已的步骤,不建议
……


谢谢!是否可认为关系上的解决是辅助条件呢,合同条款恐怕不会描述的那么细阿,如果对方再增加的话,我们如何说服他们接受需求变更呢,我感觉很难阿,特别对方强势时,这中间是否完全由项目经理去执行呢,有什么技巧方法可以分享一下吗,谢谢!

#5


如果还划算,就接着干;
如果眼看就不划算了,就放弃掉;
把变更分清楚:需求 还是 问题,如果是问题,赶快改,保证用户能用;如果是新增的需求,就成本权衡,小的可以,大的坚决不干

#6


引用 3 楼 michaelmodna 的回复:
引用 1 楼 nightcloud 的回复:
项目内的需求有没有开发完成?客户满意度如何?客户关系如何?等等。这些信息没有,很难有一个建议的。
通常的建议可以是和客户商量,这4个新需求我给你做了,但项目得给我结了。如果对口头协定不放心,就写一个会议纪要双方签字确认,包括双方领导也要签字


项目需求SRS已在设计前完成,由于框架太大了,客户满意度在初期是比较认可的,但已超过原定计划,因……


没有控制好项目范围,让范围蔓延了啊,这样做很危险。

#7


该回复于2011-11-17 09:06:36被版主删除

#8


软件项目中最怕出现与最终用户隔着一层,而这一层缺乏足够的权威和能力控制需求的情况。楼主就是典型的这种情形,因此需要好好考虑下怎么解决这个隔着一层的问题。
在项目初始化阶段就要判断这个风险,如果实在难以避免,宁可放弃掉这个项目。
就你这个项目来说,如果想从实质上解决问题,只有想办法与最终客户直接接触,或者说是以否定掉你现在接触方的哪一方进行接触,确定最终需求和那一方的期望,才能拿出办法来;

#9


软件项目中最怕出现与最终用户隔着一层,而这一层缺乏足够的权威和能力控制需求的情况。楼主就是典型的这种情形,因此需要好好考虑下怎么解决这个隔着一层的问题。
在项目初始化阶段就要判断这个风险,如果实在难以避免,宁可放弃掉这个项目。
就你这个项目来说,如果想从实质上解决问题,只有想办法与最终客户直接接触,或者说是以否定掉你现在接触方的哪一方进行接触,确定最终需求和那一方的期望,才能拿出办法来;

#10


我也有这样的疑问。。。

#11


既然是老得项目,需要尽快完成现有的需求。需要和客户沟通,让客户了解项目在实际环境应用中再去校验功能。
很多凭空的想法是随着客户的思维在不断变化,没有一个最终的目标的。只有在应用过程中才能发现客户更像要什么。

#12


原型法 多迭代 严谨的控制需求变更

#13


这个问题是大多项目不能按时结案的通病,所以是问题,但并不简单,有以下建议:
如果系统不影响正常业务开展的话(如果连正常业务都不能开展,那你什么也别说了,改到能开展为止),那应该要求完成项目验收,并在验收报告中明确遗留问题清单及解决时间。
用户不肯验收解决办法:把需求清单全部列出来,找业务操作人员逐个确认OK或不OK,不OK的全部转到问题清单内,然后把经过确认的需求清单放到客户领导面前,领导也只能签了,最多是跟你纠结问题清单中的问题,大不了你们商量解决掉其中的某几个就签字。
为什么要这样做呢:因为客户的新需求和问题均来源于未验收的项目,项目验收完成,则项目中的新需求就按新需求处理方式来处理了,问题清单中的问题通常不会搞出新的问题来,所以只需要逐个解决就行了,再多也不怕。
下面业务人员不跟你确认需求清单怎么办:中止业务人员应用上的一切支持(包括新需求),并书面通知项目监管人员目前情况(优期是客户方高管),召开会议,并汇报具体情况,同时附上你所收集到的需求清单完成情况;通常情况下,如不重大问题,客户方高管会主动提出来让业务确认掉并完成验收的,因为客户方高管一般也有考核的,他们也想早点结束。

#14


补充一下,不管是直接面对客户,还是通过第三方,都可以这样解决,因为你的验收对象就是需求提供者,应该不可能出现需求来自于终端客户,而验收权有第三方决定,如果不幸真是这样,如果你能解决掉的话,那我向你致敬!

#15


有时候硬性把开发归阶段、看戴成项目都不合理。
就把开发团队看成是售后、维护。老板有手段能挣钱就做唄。

#16


引用 3 楼 michaelmodna 的回复:
项目需求SRS已在设计前完成,由于框架太大了,客户满意度在初期是比较认可的,但已超过原定计划,因为项目面对沟通客户不是最终用户,他们与项目人员沟通是认可的,但一旦三方进行沟通,即马上翻脸,站在对方的立场说话,所以比较复杂,分批交付我们也有想过,但用户如不接受的话,恐怕不好好办阿,谢谢!


那么弄不好就是这个中间商什么都不懂,却要硬要把持。这确实不好办,除了下套否则的不到钱。

其实用户遇到了那种不懂装懂的中间商,也是下套的。用甜言蜜语忽悠他们,可就是故意不相信他们这种人“能找来什么好干活的人?”。所以你们可能其实是被中间商给害了,还说中间商认可你们呢!

#17


引用 15 楼 hiboys 的回复:
有时候硬性把开发归阶段、看戴成项目都不合理。
就把开发团队看成是售后、维护。老板有手段能挣钱就做唄。


那是没有激情做真正的产品、只要给自己发工资就满足了吧?!

#18


其实这类项目根本不需要“结”,就留个小尾巴好了,然后赶紧产品化。等你们产品花了,同一产品有了至少10个其它用户,告诉用户没有时间应付他们了、你们正在研究怎么了解他们的拖欠款问题,你看他们急不急?

其实就是搞项目不搞产品的毛病。

#19


提两点:
1.为客户做系统的时候最好能加一些咨询在里面,需要对客户的商务有些了解,对每一个功能都知道为什么做,如能提出更好的方案给客户(毕竟你是IT专家,从IT的角度可能有其他方案)就是附加价值。
2.做好从第一天就让客户知道,添加功能和改动原有设计都不是免费的,而且时间上可能有延迟。然后每次遇到这样的情况都要强调一次,并给出可能的后果(有的时候偏重时间上,有的时候偏重费用上)。
在IT产品的开发中在和客户多交流,有一点进展就交流一下,最好是能和终端用户交流。剩下的事就都是政治问题了。

#20


面对比较强硬的客户时确实会另大家很头疼。既然已经答应了人家的后续需求,就把这4个功能做好。但是一定要有书面的东西出来请双方领导签字,这是依据。建议后续加需求时与客户沟通放到二期中实现。

#1


项目内的需求有没有开发完成?客户满意度如何?客户关系如何?等等。这些信息没有,很难有一个建议的。
通常的建议可以是和客户商量,这4个新需求我给你做了,但项目得给我结了。如果对口头协定不放心,就写一个会议纪要双方签字确认,包括双方领导也要签字

#2


这还是初级问题?

呵呵

看销售怎么承诺的了,合同如果没有约束力,就靠关系了,

主要是项目经理怎么跟客户沟通了

先看看目前客户的态度,

不妨与客户吃饭聊一下

之后了解关键的问题,纠结在哪里

项目总要有范围,太大了不好定就阶段交付,*教导我们:零敲碎打牛皮糖

一点点的交付赢得信任,把钱结了再进行下一次合作

打官司是最终迫不得已的步骤,不建议

总之别人说什么都是扯淡,自己要去实践,多花心思和时间,须知此事必躬行

祝你成功~~



#3


引用 1 楼 nightcloud 的回复:
项目内的需求有没有开发完成?客户满意度如何?客户关系如何?等等。这些信息没有,很难有一个建议的。
通常的建议可以是和客户商量,这4个新需求我给你做了,但项目得给我结了。如果对口头协定不放心,就写一个会议纪要双方签字确认,包括双方领导也要签字


项目需求SRS已在设计前完成,由于框架太大了,客户满意度在初期是比较认可的,但已超过原定计划,因为项目面对沟通客户不是最终用户,他们与项目人员沟通是认可的,但一旦三方进行沟通,即马上翻脸,站在对方的立场说话,所以比较复杂,分批交付我们也有想过,但用户如不接受的话,恐怕不好好办阿,谢谢!

#4


引用 2 楼 cmm2cmmi 的回复:
这还是初级问题?

呵呵

看销售怎么承诺的了,合同如果没有约束力,就靠关系了,

主要是项目经理怎么跟客户沟通了

先看看目前客户的态度,

不妨与客户吃饭聊一下

之后了解关键的问题,纠结在哪里

项目总要有范围,太大了不好定就阶段交付,*教导我们:零敲碎打牛皮糖

一点点的交付赢得信任,把钱结了再进行下一次合作

打官司是最终迫不得已的步骤,不建议
……


谢谢!是否可认为关系上的解决是辅助条件呢,合同条款恐怕不会描述的那么细阿,如果对方再增加的话,我们如何说服他们接受需求变更呢,我感觉很难阿,特别对方强势时,这中间是否完全由项目经理去执行呢,有什么技巧方法可以分享一下吗,谢谢!

#5


如果还划算,就接着干;
如果眼看就不划算了,就放弃掉;
把变更分清楚:需求 还是 问题,如果是问题,赶快改,保证用户能用;如果是新增的需求,就成本权衡,小的可以,大的坚决不干

#6


引用 3 楼 michaelmodna 的回复:
引用 1 楼 nightcloud 的回复:
项目内的需求有没有开发完成?客户满意度如何?客户关系如何?等等。这些信息没有,很难有一个建议的。
通常的建议可以是和客户商量,这4个新需求我给你做了,但项目得给我结了。如果对口头协定不放心,就写一个会议纪要双方签字确认,包括双方领导也要签字


项目需求SRS已在设计前完成,由于框架太大了,客户满意度在初期是比较认可的,但已超过原定计划,因……


没有控制好项目范围,让范围蔓延了啊,这样做很危险。

#7


该回复于2011-11-17 09:06:36被版主删除

#8


软件项目中最怕出现与最终用户隔着一层,而这一层缺乏足够的权威和能力控制需求的情况。楼主就是典型的这种情形,因此需要好好考虑下怎么解决这个隔着一层的问题。
在项目初始化阶段就要判断这个风险,如果实在难以避免,宁可放弃掉这个项目。
就你这个项目来说,如果想从实质上解决问题,只有想办法与最终客户直接接触,或者说是以否定掉你现在接触方的哪一方进行接触,确定最终需求和那一方的期望,才能拿出办法来;

#9


软件项目中最怕出现与最终用户隔着一层,而这一层缺乏足够的权威和能力控制需求的情况。楼主就是典型的这种情形,因此需要好好考虑下怎么解决这个隔着一层的问题。
在项目初始化阶段就要判断这个风险,如果实在难以避免,宁可放弃掉这个项目。
就你这个项目来说,如果想从实质上解决问题,只有想办法与最终客户直接接触,或者说是以否定掉你现在接触方的哪一方进行接触,确定最终需求和那一方的期望,才能拿出办法来;

#10


我也有这样的疑问。。。

#11


既然是老得项目,需要尽快完成现有的需求。需要和客户沟通,让客户了解项目在实际环境应用中再去校验功能。
很多凭空的想法是随着客户的思维在不断变化,没有一个最终的目标的。只有在应用过程中才能发现客户更像要什么。

#12


原型法 多迭代 严谨的控制需求变更

#13


这个问题是大多项目不能按时结案的通病,所以是问题,但并不简单,有以下建议:
如果系统不影响正常业务开展的话(如果连正常业务都不能开展,那你什么也别说了,改到能开展为止),那应该要求完成项目验收,并在验收报告中明确遗留问题清单及解决时间。
用户不肯验收解决办法:把需求清单全部列出来,找业务操作人员逐个确认OK或不OK,不OK的全部转到问题清单内,然后把经过确认的需求清单放到客户领导面前,领导也只能签了,最多是跟你纠结问题清单中的问题,大不了你们商量解决掉其中的某几个就签字。
为什么要这样做呢:因为客户的新需求和问题均来源于未验收的项目,项目验收完成,则项目中的新需求就按新需求处理方式来处理了,问题清单中的问题通常不会搞出新的问题来,所以只需要逐个解决就行了,再多也不怕。
下面业务人员不跟你确认需求清单怎么办:中止业务人员应用上的一切支持(包括新需求),并书面通知项目监管人员目前情况(优期是客户方高管),召开会议,并汇报具体情况,同时附上你所收集到的需求清单完成情况;通常情况下,如不重大问题,客户方高管会主动提出来让业务确认掉并完成验收的,因为客户方高管一般也有考核的,他们也想早点结束。

#14


补充一下,不管是直接面对客户,还是通过第三方,都可以这样解决,因为你的验收对象就是需求提供者,应该不可能出现需求来自于终端客户,而验收权有第三方决定,如果不幸真是这样,如果你能解决掉的话,那我向你致敬!

#15


有时候硬性把开发归阶段、看戴成项目都不合理。
就把开发团队看成是售后、维护。老板有手段能挣钱就做唄。

#16


引用 3 楼 michaelmodna 的回复:
项目需求SRS已在设计前完成,由于框架太大了,客户满意度在初期是比较认可的,但已超过原定计划,因为项目面对沟通客户不是最终用户,他们与项目人员沟通是认可的,但一旦三方进行沟通,即马上翻脸,站在对方的立场说话,所以比较复杂,分批交付我们也有想过,但用户如不接受的话,恐怕不好好办阿,谢谢!


那么弄不好就是这个中间商什么都不懂,却要硬要把持。这确实不好办,除了下套否则的不到钱。

其实用户遇到了那种不懂装懂的中间商,也是下套的。用甜言蜜语忽悠他们,可就是故意不相信他们这种人“能找来什么好干活的人?”。所以你们可能其实是被中间商给害了,还说中间商认可你们呢!

#17


引用 15 楼 hiboys 的回复:
有时候硬性把开发归阶段、看戴成项目都不合理。
就把开发团队看成是售后、维护。老板有手段能挣钱就做唄。


那是没有激情做真正的产品、只要给自己发工资就满足了吧?!

#18


其实这类项目根本不需要“结”,就留个小尾巴好了,然后赶紧产品化。等你们产品花了,同一产品有了至少10个其它用户,告诉用户没有时间应付他们了、你们正在研究怎么了解他们的拖欠款问题,你看他们急不急?

其实就是搞项目不搞产品的毛病。

#19


提两点:
1.为客户做系统的时候最好能加一些咨询在里面,需要对客户的商务有些了解,对每一个功能都知道为什么做,如能提出更好的方案给客户(毕竟你是IT专家,从IT的角度可能有其他方案)就是附加价值。
2.做好从第一天就让客户知道,添加功能和改动原有设计都不是免费的,而且时间上可能有延迟。然后每次遇到这样的情况都要强调一次,并给出可能的后果(有的时候偏重时间上,有的时候偏重费用上)。
在IT产品的开发中在和客户多交流,有一点进展就交流一下,最好是能和终端用户交流。剩下的事就都是政治问题了。

#20


面对比较强硬的客户时确实会另大家很头疼。既然已经答应了人家的后续需求,就把这4个功能做好。但是一定要有书面的东西出来请双方领导签字,这是依据。建议后续加需求时与客户沟通放到二期中实现。

#21