比较完善的项目建议书，这里面包含了一个巨大的项目工作范围，你的SOW和WBS可能也写得很详尽。但此刻，你的团队里只有2个后端开发人员，没有前端工程师和数据库开发工程师，也没有测试人员来保证项目的质量。这是一个多么悲伤的话题啊，就像你选定了要演奏的曲目，确定了音乐会的时间和场地，但仅有2个音乐师能够出席。所以，那个音乐指挥家挥舞着指挥棒在想，可不可以把这场音乐演奏会变成音乐独奏会?
这样的情况下，你依然需要淡定地把项目方案建议书和需求规格说明书重新审视一遍。结合用户需求思考和权衡，哪些功能是目前比较关注的，而哪些功能是未来系统需要关注的。这个其实并不难，如果你和用户开放地沟通过，项目功能的轻重缓急，你应该心里有数。所以，你很有必要在此基础之上，整理出项目当前阶段的需求规格说明书来。不要一味地喊叫资源不足，这样的方式只会引起领导对你做事能力的怀疑，而不能解决根本问题。
5、确定核心功能的优先级
关于个人工作效率的经典之作《高效能人士的七个习惯》一书里依据纵坐标(重要性)和横坐标(紧急性)来划分任务，有如下四种组合：
(1)重要且紧急，迅猛龙式出击。
(2)重要但不紧急, 准备好未来的方案、策略和计划。
(3)不重要但紧急，学会说不，拒绝任何承诺。
(4)不重要也不紧急，可以研究下隔壁的妹纸为何每次遇见你都会笑得很好看。
一个大型的项目，利益相关方会很多。常常会有很多年轻而对项目管理知识无知的利益相关方从方便个人利益的角度出发，突然过来很莫名地给你讲，XX报表要放在你的系统里实现而且某大领导非常重视。这时，你需要做的就是果断拒绝，不要给任何承诺。很明显，这是不重要也不紧急的事情。因为凡是重要且紧急的任务，领导都会在需求讨论会上明确地强调多次。项目经理心里要有一杆秤，哪些人的需求是需要理会的，哪些人的需求是不用过多关注的。
整理完核心功能和关键任务的优先级列表后，你会发现项目一半的范围进行了裁剪。这是一个好的趋势和结果，因为缩减和明确项目范围永远对项目的如期交付是有利的。而一个项目的实施，10个人有10个人的计划和结果，2个人也有2个人的计划和结果。当你无法争取标配的资源获得对这个项目的足够支持时，只能关注核心功能并在核心功能范围内进行任务的优先级排序。
6、制定可行的迭代计划
迭代这个词现在很泛滥，但很多人都不明白需要迭代什么。项目经理首先要明确，在这些核心功能清单中，哪些是需要放在持续的迭代计划当中的。不是项目所有的功能都需要迭代，成熟的功能基本都是一次开发就落地实现，如果你说要迭代设计登陆和退出功能就显得非常逗比和无知。通常需要迭代的任务都是那些比较复杂的，业界技术不是很明确或者用户未来期望也不是很明确的功能。
迭代周期不要过短(团队Hold不住，时间都会浪费在代码分支合并冲突检测、各种测试、Bug修复、上线发布中)，也不要太长(否则失去了敏捷开发的意义)，为了给不成熟的团队留出充分的容错时间，所以需要具体情况具体分析。这时作为项目经理的你，需要和开发人员探讨每个里程碑的实现程度。
7、设计前瞻的系统架构
如果你有幸遇到一个有全局观、有前瞻性的系统架构师，项目会顺利很多。系统的架构就像交通工具的骨骼，你需要和架构师进行密切的沟通。开发未动、架构先行的准则是保证系统未来不会宕机和崩溃的重要准则。所以你不要期望“老牛破车”的架