项目经理第一个多月的失败总结：
软件功能需求文档没有完整的完成，也没有经过上级确认。导致后期系统边界还不明确，软件需求规格书模糊，不好下笔。
组员的管理不好，没有合理有效明确的安排他们任务，任务没有有效的量化，导致项目分析停滞不前，基本无产出物。定不好任务一个很重要的原因是不明确文档的作用，不想编写文档。
吸取经验，争取改进如下：
功能需求文档一定要尽早的让上级或客户确定，一旦确定，后期便有了系统边界，再在里面做详细软件分析就好办了。
功能需求规格书可以不具体，但一定要表达清楚边界。以后的软件要实现什么功能。若有需要还需要把不实现什么功能也加上。一些模糊的边界也尽早的确定固化。
文档结构可以以功能、角色、部门、任务等为菜单进行组织。功能需求文档是基于商业业务来的。
在功能需求的基础上，分析软件需求规格书，采用后期程序菜单的形式，组织文档结构。文档内容尽量具体化，增加前期文档时间，减少后期代码思考。除了说明要实现的功能及实现的步骤，还需要添加一些不可见的程序处理逻辑，如对哪些数据产生的影响。若可能，最好增加详细字段说明，外加demo图解。
组员管理上，制定项目长期计划(制定多个里程碑点)，制定月计划(向里程碑前进)，分解周计划(将月计划按当前实际情况进行人员的分配)，实施日计划(由组员自己提出日计划安排，并于每天完成任务汇总，累计)。
每周五进行当周的任务总结，分析本周的完成任务，完成进度，遇到的困难问题，与预期任务比较，关键里程陴任务未完成适当安排周未加班。若进度严重不合格，调整下面的计划安排。制定下周的任务，由组员根据任务目标，自己提出下周任务安排计划(日计划)，一致通过。将日计划纳入周计划，将周计划纳入月计划，再将月计划纳入项目计划。
将每周五的会议内容存档，方便后期查看总结学习。学习计划的合理安排和人员的分配。