一、做好计划
项目计划是指导项目执行的依据，也是衡量项目组绩效的基准，做好计划至关重要。 项目计划是由项目总体计划和子计划组成的。通常，进度计划、质量计划、风险计划、测试计划、配置管理计划以及沟通计划是项目计划中比较重要、对实际工作也比较有指导意义的几个子计划。其中，进度计划是所有计划的基础，它确定了项目的时间范围，它让你知道在哪个时间应该完成哪项工作；质量计划则告诉你这项工作是否已经完成，是否满足要求；风险计划将会告诉你完成这项工作可能出现的障碍，应如何解决，比如对于维护型的项目要考虑到人员常被借调，突发任务对计划的影响等；测试计划将会告诉你如何循序渐进的发现工作中存在的漏洞，是否可以交工；配置管理计划将会为你列举一下这项工作将由哪些部分组成，哪些是关键的，哪些是可变的；沟通计划将告诉你在做这项工作的过程中你要跟哪些对象共事，应如何跟他们协调一致。 另外要注意项目计划是项目组全员参与的，目的是项目组团队对计划取得一致，另一个原因是获得双向的一个承诺。
1、针对确认的需求评估工作量，评估要基于功能细节来做，经过估计计划才有意义，与实际偏差才会少一些
2、项目计划的缓冲时间
按常规的项目计划，一般预留10-20%的缓冲时间，以应对中间可能出现的风险，比如人员变动带来的影响或接口部门的节奏不一致对项目计划造成的影响。
3、接口沟通的重要性
一般项目中最难掌控的就是接口系统的开发进度，不同部门的工作习惯和人员能力不同，加强沟通和引导。通俗地讲，是项目组在沟通过程中，要预先把这部分的工作分析好。对涉及双方沟通 的结果需要有文档记录，比如会议纪要。确定责任人、完成时间等。出了问题后可追述到人。追究毕竟不是项目组要的结果。为确保项目能顺利进行，接口的沟通是很重要的，比如研发组在沟通过程中能否处于权威的地位？能不能领导其它接口系统的工作？可视情况适当借助上级或对方上级的力量，对相关接口人进行督促。保障项目的进度。
4、项目计划是渐进明细的过程：计划也不是一蹴而就的，任何人也没有料事如神的本事，它是一个由宏观到微观、由粗到细逐渐分解逐渐细化的过程。 如果不考虑外部因素的影响，计划变更的频率和幅度，可直接反映出制定计划时存在的问题，比如可操作性。总结经验，避免下次再犯同样的问题。
5、项目计划的粒度
按PMI的提倡工作任务的分配是规则是80小时的单位，软件行业属于高新产业，对进度的控制相对要比建筑行业更紧凑一些。所以软件研发类的项目更应该控制在2-3内比较合适，即16-24小时。
二、需求变更控制
首先需求分析应该有两层的含义：
1、理解用户的需求，2：辨别用户需求。做到这俩点的基础是需要理解用户的业务需求，即业务模式和操作习惯（通过信息系统或人工处理事务的方式）。
理解用户需求：指的是在做调研的时候，要理解用户表达的意思，不要漏掉用户提供的细节。比如文档或口头的描述。为辨别用户需求做基础
辨别用户需求：一般系统常见的问题是，业务专家有很多，很多时候，专家意见不一致。甚至天马行空，不符合逻辑，不切实际的需求很多，需要在了解用户的业务模式后，才能辨别出来。注意在调研的时候要做好文字记录，不要漏掉细节。回头仔细琢磨。这一点是很多项目经理或需求分析人员忽略的地方，为后期变更埋下隐患。
避免这种问题的情况是，找理由到客户现场，想办法收集基层操作员的需求。
2、预估需求
对于用户未提到的需求，但可能以后会扩展的需求的应对方法。对于内部系统来说，可以早期引导用户。对于外部项目要在设计时考虑到，保留必要的
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
