软件项目管理中10大知识领域中（整合、范围、时间、成本、质量、人力资源、沟通、风险、采购、干系人）项目资源不足的情况，或许是最常见，但却最棘手。但其实，广义上讲还有如下资源不足的情形：
1、权力不足以掌控项目全局？
因为很多公司，项目经理没有实权。项目立项的时候没有任命和宣布。项目启动的时候没有授权和介绍。就这样你在无形之中成为了PM，和产品经理一起做需求分析、系统规划设计。而且很多时候，连产品经理都没有，你既是PM又是产品经理。没有权利，而这个项目又有太多的项目干系人需要你去协调和驱动：需要将那些未建立健全的项目流程制度落地规范起来，需要将那些模棱两可的系统逻辑、规则明确统一起来，需要将那些用户并不是很清楚的需求引导梳理出来......不一而足。这样的过程中，很多小白一样的干系人，总会抬起无辜的眼神，愤愤不平地问：这件事情分配给我做的理由？如果真要分配请邮件抄送我的直属上级。这是一个无正解的话题。干系人不属于项目团队成员，你没有权利要求他做任何一件与你现在负责的系统产品有关的任务，即便这样的工作任务明明是在他的职责范围之内。如果有这样的情况，那是你的方式错了。在职场上事不关己高高挂起是一种普遍现象，你不能期望所有的人都想你一样热心地忠诚于自己的职责。所以，项目经理不是万能的英雄，该需要请BOSS来分配的工作任务，就不要怕麻烦他。因为你权利不够啊。
2、时间不足以制定周密的计划？
凡事预则立，不预则废。项目计划的重要性不言而喻。但需求在变，计划总是赶不上变化。如果你之前做过开发，根据项目任务评估出的计划还基本靠谱；如果没有，那只能和开发人员沟通交流，通常没有人愿意把真实的评估时间汇报出来，开发设置冗余时间，一方面是为了防止意外，另一方面是为了避免加班成灾。所以你的计划永远都有拍脑袋的成分在里面，无法周密，也无法严谨。“计划赶不上变化”，恩，这意味着项目经理的大部分工作应该是培养团队处理不可预料的变化的能力，而不是参与日常编码和架构决策。那么当系统上线的时间定了，你还能做些什么来调整项目的计划呢？
3、人力资源不足以支持项目的难度和强度？
任何一个公司都会存在资源不足的问题，但不是领导不重视。一个新规划的项目立项和启动的时候快到年底了，招聘会相对变的艰难很多，而且应聘者的技能和综合素质都需要严格把关。在做软件项目时，我们也不想一次就弄得自己精疲力竭。我们需要保持一个稳定的工作进度。可持续发展的团队就像是在跑马拉松而不仅仅是在冲刺。
如何应对？
很多项目经理习惯性地认为会哭的孩子有奶吃，一方面可以得到领导的重视，另一方面资源充足的团队就相对轻松一些。就会说，要明确现状，获得理解和支持。但这是一句废话，没有任何的驱动意义，也没法以结果为导向实现项目的交付。而且，你的潜台词还在说，领导眼瞎。拜托好不好，一个项目的规划和实施，你的上司比你心里更清楚。他不是看不到这样的现状，而是人力资源缺乏的现状并不是他一时半会就能立马解决的问题。所以，你的预防针变成温馨提醒和进度汇报就足够了。重要的是，基于这样的现状，作为项目经理能做点什么，或者应该做点什么让这眼前的浓雾散开，可以窥得见一缕美好的阳光呢。这样的情况下，项目经理需要站在企业的角度去思考问题，要学会为企业分担问题不足的资源可以通过培训、外部推荐寻求资源等等。但核心的思路是在于，使用灵活而变通的思想简化项目管理。包括但不局限于：
1、简化项目的解决方案，对项目功能块和功能点进行裁剪，关注系统核心的和关键的功能；
也许你从一开始就设计了比较完善或者完美的项目建议书。这里面包含了一个巨大的项目工作范围，你的SOW和WBS可能也写的很详尽。但此刻，你的团队里只有2个后端开发人员，没有前端工程师、没有数据库开发工程师，也没有测试人员来保证项目的质量。这是一个多么悲伤的话题啊，就像你选定好了要演奏的曲目，确定了音乐会的时间和场地，但仅有2个音乐师能够出席。所以，那个音乐指挥家在心里挥舞着指挥棒想，可不可以把这场音乐演奏会变成音乐独奏会。
这样的时候，你依然需要淡定地把你的项目方案建议书和需求规格说明书重新审视一遍。结合用户需求思考和权衡，哪一些功能是目前比较关注的，而哪一些功能是未来系统需要关注的。这个其实并不难，如果你有和用户开放地沟通过，项目功能的轻重缓急，你都心里有数。所以，很有必要在他们基础之上，整理出项目一阶段的需求规格说明书来。不要一味的喊叫资源不足，这样的方式只会加重领导对你做事能力的看法，而不能解决根本问题。
2、对核心功能和关键任务进行优先等级排序
关于个人工作效率的经典之作《高效能人士的七个习惯》那本书里依据纵坐标（重要性）和横坐标（紧急性）来划分任务，有如下四种组合：
1、重要且紧急，迅猛龙式的出击；
2、重要但不紧急, 准备好未来的方案、策略和计划；
3、不重要但紧急，学会说不，拒绝任何承诺；
4、不重要也不紧急，可以研究下隔壁的妹纸为何每次遇见你都会笑的很好看；
一个大型的项目，干系人会很多。常常会有很多年轻而对项目管理知识无知的干系人会从方便个人利益的角度出发，突然过来很莫名地给你讲，XX报表要放在你的系统里实现而且某大BOSS非常重视。这样的时候，你需要做的就是果断拒绝，不要给任何承诺。很明显，这是不重要也不紧急的事情。因为凡是重要且紧急的任务，大BOSS都会在需求讨论会上明确地强调多次。项目经理心里要有一杆秤，那些人的需求是需要理会的，那些人的需求是不用多关注的。
整理完核心功能和关键任务的优先级列表后，你会发现项目一半的范围进行了裁剪。这是一个好的趋势和结果。因为项目管理，缩减和明确项目范围，永远对项目的如期交付是有利的。而一个项目的实施，10个人有10个人的计划和结果，2个人也有2个人的计划和结果。当你无法争取标配的资源获得对这个项目的足够支持时，关注核心功能、在核心功能范围内进行任务优先排序。之后，通常困难都是一时的，规划良好的迭代实施计划，讲缩减至一半的项目范围，持续地补充完善起来。通过持续渐进、裁剪和分解的方式最终实现项目的成功。
3、制定持续可行的迭代计划和周期
迭代这个单词很泛滥，但很多人都不明白需要迭代什么。首先要明确，在那些核心的和关键的功能清单中，有哪些是需要放在持续的迭代计划当中的。不是项目所有的功能都需要迭代。成熟的功能基本都是一次开发就落地实现，如果你说要迭代设计登陆和退出功能就显得非常逗比和无知。通常需要迭代的任务都是那些比较复杂的，业界技术不是很明确或者用户未来期望也不是很明确的功能，比如权限体系、报表体系等等。
迭代周期不要过短（团队HOLD不住，时间都会浪费在代码分支合并冲突检测、各种测试、bug修复、上线发布中），也不要太长（否则失去了敏捷开发的意义），为了给不成熟的团队留出充分的容错时间，所以需要具体情况具体分析。这时作为项目经理的你，需要和开发探讨每个里程碑实现程度。
4、设计前瞻而灵活性高的系统架构和开发框架
如果你有幸遇到一个有全局观、有前瞻性的系统架构师项目会顺利很多。系统的架构就像交通工具的骨骼。你需要和架构师进行密切的沟通。开发未动，架构先行的准则是保证系统未来不会宕机和崩溃的重要准则。所以你不要期望“老牛破车”的架构和框架之上，能继续朝里面添加或者迭代什么功能，也无需指望它能够跑的有多快，有多远。甚至，更多的可能是，你在项目功能进行迭代的时候，它已经无法兼容和承受这么多的“负荷”，变得支离破碎，牵一发而动全身，瞬间就宕机挂起。系统架构和框架的前瞻性、灵活性、兼容性是分布式开发、多用户并发环境里必须要考虑的重点和难点问题之一。
5、快速高效驱动业务方明确系统关键逻辑和规则
前面已经很明确了，留给开发团队仅有的2个人员的开发时间没剩下多少啦。如果你还不主动出击，驱动关键业务方，明确系统逻辑和规则。就会导致后续再多的开发人员都需要无休止地熬夜加班。尽早地确定系统逻辑和规则，本质上是为了给开发、测试人员节省更多的时间，来保证系统的质量和性能。系统逻辑和规则的确认，最好的方式是最终都能够用正式的邮件确认和统一过。业务方不会明确地告诉你，业务规则和逻辑是什么样子的。所以需要你主动牵引，按照需求会议的讨论内容、结合你对业务的理解、对用户的研究整理出符合当前的系统逻辑和规则，并最终请业务关键人员进行确认回复。因为只有明确统一了逻辑和规则，你才正真地为开发人员扫除了顾虑和障碍，才能在有限的时间内，聚焦在业务逻辑和规则的实现当中，而不是写一行代码出现一个的疑问，然后朝你问十万个为什么。然后仅有的时间又会浪费的解释和思考当中。所以一个合格的项目经理，对项目的思考和规划需要是最全面的，并且都能够是前瞻性的，至少比团队单中任何一个人都需要有超前思考。
最后，项目经理需要调整心态，控制好自己的情绪。无论是什么原因造成的资源不足，作为项目经理你一旦接受了项目，无论出于什么原因、目的，你都必须想办法把事情做好，把项目做成功；另一方面，项目经理不需要委屈求全，项目经理必须学会最大限度保障自己的利益。你不可能令所有的干系人都满意，但你能做到的是，让自己的努力让自己满意，用心平衡内心就好。
