| 【相关分析】（27个分析） |
|
|
时间：2011-01-28
题目：加强沟通
分析：１. 分析原因，仔细检查配置系统，查看客户提出的原先系统上没有的要求是否在ＰＭＩＳ中或者以前的变更中曾经提出过？是否是客户对你这个信任的项目经理缺乏信心？是否是原项目经理口头承诺的变更没有进入项目管理信息系统？检查一下和同上是否有明确的变更控制流程和后期维护条款？
２. 采取补救措施，如向客户说明后期维护的策略，补充合同相关条款。
３. 如果是新增加的变更，则向客户说明项目后期进行变更的影响，如果是比较大的范围变更，可以建议这些变更在系统二期或者作为一个新的项目实现; 如果是小的变更，则看是否有响应的替换方案实现，或者协商延续项目期限等方式来实现。
４. 加强沟通，必要时可以让原先的项目经理或者高层带着你去拜访客户，查明项目后期变更的深层原因。
|
|
|
时间：2010-03-23
题目：需求梳理和交流
分析：可能原因：
1、项目交接不全面，接收人并不完全了解项目情况；
2、项目范围本身就不是很明确；
采取的措施：
1、梳理出客户提出的新需求，进行分类整理，一定要明确项目需求和客户需求；
2、整理出来后同客户进行交流，确定哪些需要修改，是否在本合同内修改，哪些可以使用当前的配置； 另外，在这个时候要注意同项目中厉害干系人的交流，避免双方出现不必要的麻烦，必要时，需要商务人员多配合；
|
|
|
时间：2009-05-12
题目：加强沟通
分析：１. 分析原因，仔细检查配置系统，查看客户提出的原先系统上没有的要求是否在ＰＭＩＳ中或者以前的变更中曾经提出过？是否是客户对你这个信任的项目经理缺乏信心？是否是原项目经理口头承诺的变更没有进入项目管理信息系统？检查一下和同上是否有明确的变更控制流程和后期维护条款？
２. 采取补救措施，如向客户说明后期维护的策略，补充合同相关条款。
３. 如果是新增加的变更，则向客户说明项目后期进行变更的影响，如果是比较大的范围变更，可以建议这些变更在系统二期或者作为一个新的项目实现; 如果是小的变更，则看是否有响应的替换方案实现，或者协商延续项目期限等方式来实现。
４. 加强沟通，必要时可以让原先的项目经理或者高层带着你去拜访客户，查明项目后期变更的深层原因。
|
|
|
时间：2009-05-12
题目：项目范围变动是导致项目失败的主要因素
分析：在项目管理中，最忌讳的是客户提出没完没了的范围变更。从客户角度出发，范围变更是很正常的事：我现在有新的要求了吗！但从项目管理角度出发，范围变更意味者时间拖长及成本增高。如果范围变更过大，正在实施的项目有可能推倒重来。因此，项目经理与客户要建立良好的沟通渠道，促使双方互相了解。如果客户提出的变更要求是合理的，双方需要签署范围变动合同。
|
|
|
时间：2009-04-27
题目：没有做好交接工作，范围定义不明确
分析：1.项目经理要改变观念，虽然本项目是小项目，但也要按项目管理的规范来管理。
2.有可能客户与前项目经理的关系，双方有合作的基础，对范围没有明确的定义，也没有形成范围说明书。
3.现在换了项目经理，客户开始担心项目不能按时完成，或完成的项目不能使用。加强沟通，提高彼此之间的合作，与客户一起对目前的问题理清并分类，可以分为新需求，细化需求，完善需求，新需求与客户沟通是否要实现，要实现就追加到范围说明书，完善需求与客户沟通是否可以培训与修改同步进行。
4.让客户知道，后期范围频繁的变更会让项目的成本增加并影响项目实施的进度。
5.提高项目交付物的质量，减少返工
|
|
|
时间：2009-03-16
题目：需求不明确
分析：整体感觉出现这样的问题是由两个方面造成的：
1、需求本身并不明确，在系统设计初期，一般情况下与客户确认界面原型的工作往往会被忽视，实际上这就是典型的需求不明确。
2、工作交接不清楚，具体作了哪些，做到什么程度，是否与客户沟通并达成一致，看来没有交接清楚
解决问题，大体上分为几个角度：
1、首先将客户提出的问题也好，需求也好进行分类整理，大致可以分为如下三类：项目范围外的新需求、项目范围内的需求且对客户工作营销较大，必须进行修改的、项目范围内的需求但并不关键。
2、针对这三类，分别与客户进行沟通：对于需求范围外的，与客户明确，并确认是否必须要做，如果做的话需要追加合同；对于项目范围内且必须进行修改的，由于是前期工作出现失误，只能自认倒霉，列出问题列表进行修改吧；对于不关键的需求，尝试与客户沟通，寻找其他替代方式解决或让说服客户认可当前配置。
3、在项目过程中，本身双方就需要进行磨合，因此在功能并不是严重影响客户使用的情况下，说服客户培训与问题修改同步进行。
|
|
|
时间：2009-03-05
题目：交接问题
分析：工作交接不够，不能是前任说什么就是什么，要有自己的理解和判断，同时也要把对项目了解的情况和公司负责人说清楚（责任问题啊，免得背黑锅）；
同用户也要做一个交接，让用户知道实施方的项目负责人正在交接工作，同时了解项目的真实情况。
总之，工作交接重要的是要全面的了解项目的情况，也要让公司和客户的相关领导都知道这些情况，争取领导的支持，为接任后的工作做好准备。
|
|
|
时间：2009-02-18
题目：重点在沟通
分析：对于半路接收的项目是比较头疼的，首先在接手的时候要和前任项目经理尽可能的详细的了解项目范围，同时查看合同明确规定出的项目的范围情况，一些外围的事情也是需要和你的前任进行了解清楚的，比如客户领导方的脾气秉性为人处事、好恶等等，对于出现的一些后期的需求，如果确属系统完善方面的同时在进度范围内的，如果可以实现就尽量的实现。如果通过评审准确定位为范围之外的，我们要明确的和双方的负责人员说明，并出具文字性的建议，也就是该追加多少费用就追加多少费用呗~~
|
|
|
时间：2009-02-04
题目：交接要有记录有见证
分析：虽然是内部的工作交接，对于项目进度的交接完成的部分，应该要求提供由甲方签字认可的（过程）检查记录，如果对于尚未检查验收的部分条件许可的情况下，最好在交接时前任和后任同时和业主代表当面说清楚。这样对己对人都好交代。
|
|
|
时间：2009-01-31
题目：工作交接！
分析：个人观点：工作交接并不是把所有的文件或东西留下就算交接了，我最近也是新交接了一些工作，但是老大只是把我新接的内容告诉了我，其他的事情交给人事了，人事处理的更简单，把你所有的东西放在哪，还有什么文件，更简单的是留下了几把钥匙就结束了。
这根本就不是工作交接，对吧~？
虽然不清楚你的交接是怎样的过程，但我想一旦你接手了这项新的任务，就要从头开始，一点一点地旅顺头绪，真正把问题找出来，才能够找到解决问题的办法。
项目范围不能轻易改变，这样将导致很多矛盾的产生，不利于整个项目的成功顺利进行。
|
|
