①弄清楚调研的目的。对用户：让用户认为调研者已经非常了解或者有足够能力了解企业现有业务流程;对自己：调研获得信息足够让团队成员能够很好的开展工作。

　　②整理出的需求一定要得到用户确认，这样在变更的时候会占有一定的主动。

　　③把握好项目范围的“度”，将如何定义才“合适”呢?这个问题在项目实施双方衡量的标准是不一致的，或许我们暂且用“多”和“少”这两个相反的字眼来反映业主方和实施方对项目范围的衡量标准。当然了，在实际的项目管理当中，我们并不能那么简单就把这个因素用这两个简单而相反的字眼来概括，因为项目范围本身涉及到不同利益双方之间的关系，而且还涉及到业主本身复杂的业务逻辑，在项目开始时描述项目的需求范围时对项目范围边界的定义上就存在着一定的模糊性和不确定性。很多时候都是一些定性的要求、而不是定量的，例如“界面友好，可操作性强，提高用户满意度”等。类似这些模糊的需求就是导致后续项目扯皮的根源，这些都将成为隐藏的风险，值得小李高度重视。项目范围的明确定义，有经验的项目经理及系统分析员将起到至关重要的作用。

　　④保证项目一开始就有很明确地项目范围界定，有一套完善的变更控制管理流程，不能任由用户怎么说，就怎么做，也就是说一开始游戏规则一定要定好，才能保证整个项目不会成了一个烂摊子。

　　分析1：流程有问题　(zhengshenghua)

　　1、合同中的项目范围(我们项目一般叫需求规格说明书)没定义完整、清晰及可管理，可能是一句话包含了一大块功能，如果这样显然会在实施过程中处于被动。

　　2、工作流程有问题，客户必须有项目经理，所有变更需求均得由甲方的项目经理提交给我们，而不是谁都直接提过来，导致根本无法执行需求变更流程。

　　分析2：需要清晰的范围界定　

　　1.范围的确定不够清晰明确。建议在借鉴成熟的范围定义条件下同项目关系人增加沟通以得到完整，清晰的范围定义。同时分析了解项目关系人，任何可以影响到项目的人、该项目会影响的人都应事先做出分析，比如考虑到系统与销售部相关，可以在项目开始前通过客户的项目经理了解销售部意见。

　　2.对于工作流程，对于客户中其他部门提出的意见要统一与客户的项目经理讨论解决，或者请其将多方召集起来一起解决，这样大家自然会对有冲突的要求做出判断。毕竟是客户要求，只是未通过项目经理提出，那么我们就将其纠正回去就是。 项目管理者联盟文章，深入探讨。

　　分析3：职权问题

　　项目到底对谁负责最初都没有明确，导致后面执行中被多人指挥，造成项目执行没有统一，引起困惑。现在最重要的是找到最先提出与之合作的经理，交换双方意见，对他们所提的意见和改进变更进行整理，找出其共同点和差异处。

　　分析4：重视沟通

　　首先，在项目的开始，项目的发起人和项目的干系人没有搞清楚，使之在项目开始之前，没有充分考虑到涉及到的重要人员。导致现在的情况。

　　另外，我个人认为在项目的进程中，要在规定的时间，比如一周或半个月同客户一起研究讨论项目的进度，双方的领导一定要参加，并就项目进行中的问题一一说明，并做好记录。

　　分析5：项目范围界定不清晰(许四胜) 本文转自项目管理者联盟

　　项目范围界定没有明确具体，造成不同人员有不同理解(当然也可说沟通不充分)。

　　然而现实环境经常是不能一次界定出明确的项目范围，所以项目前期的沟通很重要，需要项目干系人一起磋商项目的具体需求、范围。

　　分析6：请让项目经理参与到售前中来(cgq1022 )

　　此案例内容存在于目前国内绝大部门IT项目中，个人认为： 项目管理者联盟文章，深入探讨。

　　1、项目经理在项目启动前需要参与到售前的谈判中，把握项目需求和项目范围。

　　2、项目经理制定完项目范围说明书后，在公司销售、市场都参与的情况下，组织甲方召开会议，确定项目最终的、详细的项目范围说明书，并要求甲方指定甲方唯一接口人。

　　分析7：细化需求,走程序变更

　　1.最终用户能用合同的相应条款作为依据提出变更，说明用户的要求有合理的方面。用户的要求没有包含在范围说明书中，是范围说明书编写时没有与最终用户沟通细化。

上一页  [1] [2] [3] 下一页