项目进度管理的好坏与很多因素有关，项目管理过程中，最容易出问题也是最常见的问题就是进度的滞后。作为项目管理者，进度管理在某种程度上决定了项目的成败。
我在8年的项目管理生涯中，带领了大大小小的项目，不一而足。进度是最容易出现问题的一个环节。在进度管理中，也应为某些项目进度没有控制好，获得了一些经验教训，并深受启发。个人总结下来，影响进度的原因可以分为不可预见因素和可预见因素两部分：
不可预见因素：
1、来自于客户、市场等外部因素不合实际的进度要求；
2、项目在执行过程中，外部依赖条件没有按照计划来执行，比如客户没有在计划在适当的时间节点给出必要的资源支持（包括提供必要的表单、提供必要的UI素材、提供必要的办公环境、必要的服务器资源、必要的人力资源、必要的业务支持等），影响项目的正常执行；
3、其他不可抗力的外部因素（如自然灾害、项目外部环境、客户方临时计划的调整等）
4、项目执行过程中，团队关键成员因临时缺席需请假，或者因为中途离职；
5、公共资源（一个人同时可承担多个项目），临时有其他项目中途插进来，需要团队里面的某个成员参与；
6、来自客户方的临时变更；
可预见因素：
1、来自于前期对需求的把握不够明确，需求不够细化，对项目的外部依赖没有做充分的预估等，导致对项目进度的预估过于乐观，从而制定了过于乐观的进度计划；
2、制定计划时，没有考虑一些不可控或不可抗力的外部影响因素，所以没有为进度预留适当的buffer，导致一些没有预见的影响因素在发生时，没有足够的时间去处理；
3、项目经通常没有过多的耐性来对进度作出一个合理的评估，通常都只是拍脑袋；
4、编码阶段，没有统一规范的开发规范作为指导，导致不同的开发人员各行其是，最后在集成整合测试时出现各种各样的问题，花费大量的时间用来解决bug；
5、项目经理对风险项目风险预估不足，往往在项目上线阶段暴露了各种各样的问题；
以上是我在项目管理中所遇到过的一些问题，其实每个问题都有对应的解决办法，关键是，作为PM，要时时刻刻思考，方方面面思考。尽早规避影响项目进度所有可能风险因素。这样才能做到临危不惧，随机应变。
对于不可预见因素的处理办法：
怎样应对客户的不合理工期要求？我的做法通常是，你说1个月的时间完成全部开发和上线，那好，我要首先告诉你，我们项目管理的流程是什么样的，我会告诉他项目有哪几个阶段，需要做哪些方面的工作，每个阶段大概需要多久时间，说白了，咱就是拿数据说话，信不信咱看数据。好，经过这一气的说教，客户说那再给你半个月时间，然后作为项目经理，觉得这个时间有点realistic了，于是，好，这样我们也先别在这拍脑袋了，就这项工作，我们觉得这个时间还是基本合理的，不过，按照我们的项目管理过程，我们还是要做一个相对比较靠谱的进度计划出来，如果大家对计划有什么疑问，我们再调整也不迟，然后按照最后的计划来知行。客户同意，搞定。但这里要补充一点，客户的要求时间，往往存在两种情况，一种是刚性时间要求（配合某个特定时点的市场活动等，必须在活动的前一天或两天 上线），一种是弹性时间要求，这个时间也是客户拍脑袋的时间，至于基于什么理由，往往也说不出一个123，所以，客户在给我们时间要求时，我们一定要问个deadline的理由，并分析这是不是真实的deadline。
怎样应对，在项目执行过程中，客户没能按照计划时间给出必要的资源支持，作为乙方，影响到我们项目的交付。往往这样的资源可能也不是甲方对接人单方面就嫩给出的，不然，他也没有必要在这上面去拖延我们的时间，要知道，我们的共同利益是绑在一起的。所以，资源迟迟没能到位，很可能这样的资源他们也需要其他内外部的协助才能给出（可能是要走一个内部繁复的流程；可能是要依赖另一方，另一方又依赖另一方，层层依赖的情况；可能是到等到某个时点才能输出完整的数据；可能是。。。），所以，我们作为乙方在做计划时，要帮助甲方考虑这些依赖因素，并在计划中给予体现。那么我们回过头来说说，一旦这种情况发生了，我们怎么办，没办法只有邮件崔（必须，并抄送相关干系人，对方和己方的领导），并附带分析所产生的影响，最直接的影响就是项目进度，所以，对此，我们提出项目进度变更申请，获得甲方同意后，我们重新发布变更后的项目进度计划并抄送相关各方。当然，这种情况我们还是不愿意看到的，所以我们尽量能在赶早告知客户，并给予周期性的提醒，同时，帮助对方考虑替代方案（如果上线时点不能调整），比如是不是可以消减相应的功能，但保证上线的时点。
自然灾害这种情况几乎不太可能，极小极小概率事件。基本可以忽略，一旦发生，大家认命吧。
面对团队成员变动，项目开始时，项目启动会，就要问清楚，我们这个项目大概要持续到什么时候，这个时间段有没有人员请假离职（离职这事要私下了解），以便提前做好应急准备。如储备资源等；不过作为项目经理，平时要注重团队建设，尽量减少离职率吧。
面对中间插进来的项目，要把项目资源的一部分时间抽出去做其他项目，两个项目经理坐下来聊一聊，当然开始大家都会向着自己说话，都会说自己有多多困难，但最后都会有一方妥协袭来，但作为理性的自然人，妥协的前提是，在不影响自己项目的前提下。所以，双方可就公共资源所要做的工作进行细化，然后我们让开发来评估，并给出个交付时间承诺，如果评估下来一个人在指定的时间不能完成这两件事，那么，作为项目经理，就需要将问题上升，寻找更高级别管理人员的资源支持了。
来自客户方的临时变更，首先乙方项目来对变更进行分析和论证（分析变更的合理性，基于的背景和所要达到的目的），项目经理评估变更可能带来的影响并告知客户及相关干系人，如用户放弃变更则结束变更申请，如用户坚持，请客户给出变更申请邮件（抄送客户方相关干系人并得到客户方批准人同意），项目经理提交变更走内部变更流程，或直接邮件变更事项及影响，如内部相关干系人无异议则接受变更，同时更新项目进度计划。
对于可预见因素的处理办法：
项目经理在制作进度计划时：
第一，要明确项目范围，并在此基础上制作WBS，这是合理的范围保证项目不镀金，项目只做它该做的事情；
第二，要充分预估项目的外部依赖，并给这些外部依赖预留相应的时间；
第三，对于不可预见的因素，要留有适当的buffer，合理的buffer以应对不时之需。给团队留有缓冲的时间；
第四，项目经理在评估工时时要基于多种方法和工具，如有历史经验，可依据历史经验，如无，则可采用三点估算法或专家估算法；
第五，避免返工，这就要求项目经理在项目执行过程中做好质量预防和质量控制，从需求到设计到编码到最后的测试都要层层把关。每个关卡可指定不同的责任人来监管，并向项目经理汇报；
第六，对项目风险做充分预估，并定期评估（通常是每周）项目可能存在的风险，并提前做好风险预防和准备。关键路径上存在的风险更需要注意（比如服务器环境，域名，账号等资源）；
第七：建立项目看板制度，有条件的，可以在白班上每天写下每个人的工作任务，以及当天完成的任务，没有条件的，可以建立每日汇报机制，每个开发人员依据计划汇报自己当天工作完成情况，项目经理依据看板来跟踪项目进度，并适时发起控制策略；
原文地址：https://www.cnblogs.com/jack2018/p/8971858.html