五、让开发工程师“走出去”,充分理解调研，面对客户沟通
千万不要认为，调研是浪费时间，调研如果方便的话，带上女同事(嘿....嘿....别小看女同事哦)和开发工程师。我不赞成，调研人员中只有项目经理和需求分析人员两种角色。调研中的问题，要生成分析报告。并能根据调研内容，迅速提出重点和难点,及关键性的问题。这样开发工程师是会将大部分精力放在重点模块上，会更好地细化关键性的模块。
我们每个人的理解不一样,开发工程师更关注的编码的技巧和功能的实现。开发工程师代表，参与调研可以很好地保证调研是指导开发，更好地的避免出现业务需求和开发脱节。再者让他们切实感觉用户的所说，所想。让他们也了解下原来有时客户需求表达的不清晰和多变性。平时并不是需求分析人员和调研员故意为难开发工程师。这样比你天天喊提高产品质量，站在用户角度换位思考强多了。
六、作好实施准备，先“跑”为“赢”
系统开发好了，功能完善了，你能说成功了?是否会出现系统开发好了，挂在那里,却无人问津，无相关数据采集制度等等。让客户方项目阻碍者落下话柄?
系统好了，要人用呀，相信只有用了，才能体现系统的价值和公司的信誉度。也只有系统用了，才能体现你作为项目经理的价值。因此要想法设法，尽一切可能让客户先把数据采集上来。数据上来了， 主动权就掌握在咱手里了。之后的种种修改，不再是系统的功能不完善了。更重要的是公司里，老板会认为你之前所作的各种变更和修改是有意义的。切莫要把所有功能都细化，抱着等先完善好了，再上线采集数据的心态。这样成功的可能性很小， 甚至有可能直到你离开之日，系统功能还在作差不多的修改，里面却因没有客户的业务数据作支撑而变得毫无意义。
很多不大不小的项目，缺少实施方法论。我见过很多软件公司。就只有业务员和软件工程师两中角色，没有专门的实施工程师。可能项目小不觉得，项目稍上一点规模，问题就暴露了。俗话说“三分开发，七分实施”呀。
建议当系统大部分功能经过测试就可以了，先跑起来吧。一些小修改，非关键性目标的，在"跑后"再作为升级处理。这样即使某些功能不够细化,你能可以放心的对客户和老板说项目达到预期目标了，甚至可以说成功了。
七、关于在开发过程中的用户征求意见会议
项目经理或开发公司方负责人一定要掌握会议进展的主动权。但凡有客户方参加的项目会议，介绍完系统之后，客户方领导往往会发表意见，有的是与系统功能有关，有的可能是涉及客户方各职能部门的管理机制，工作流程，甚至是工作上的繁琐。连春晚都众口难调呀。记住,跑题了，及时把话题拉回来, 在这些发表意见中不排除有阻碍项目者的高论。
会议不能太长,凡是与信息系统有关的会议,主题切莫离开中心思想"你们开发的系统是什么,能为他们干什么，是怎么体现和优化他们实际的业务流程"勿需太多地用演示帐户，操作开发的信息系统。他们讨论的时间不能太长(控制在四十分钟左右)。会议结束后，要第一时间内整理出会议报告，最好是开会时，有专人现场作Word文档。现场签完名后，才让他们拍屁股走人。
会议记录之后，回到公司召集项目组所有成员及客户方的支持者，对会议记录中相关问题作出评估和控制，最后生产客户需求变更评估和控制文档。
存档(三份,一份交于客户确认，一份交于公司商务部，当然自己得留份底。到时候老板过问进度，也好有个交代呀。