项目管理核心内容之项目进度管理

3. 风险规划应对，做好应急和变更管理
催活是按照计划收作业，但是计划并不是一定能落地，我们需要拥抱变化（毕竟也没别的办法）。为了保障计划能顺利执行，作业能按时提交，需要项目经理时刻关注风险，尽量去规避一些低级别风险（信息未同步、犯懒没有查资料、干系人管理不深入等），或者降低风险带来的影响。一旦风险发生，根据应急规划做好应对，做好项目变更管理。
还要强调的一点是，如果是关键路径上的关键任务，建议在明确负责人的时候做好back up，这样能大大降低风险，且两个人协同配合，产出和效率会呈倍数增加。
（三）4个策略
以上就是优雅又愉快催活儿的核心组成啦~提升了认知，武装了方法，最后再来分享下具体场景的策略：
①大的节点开会宣贯，小的节点群聊通知，单个节点单点提醒
在上一篇我们聊到进度管理需要分区和授权，不同的节点需要有不同的方式进行宣贯。如果是较大的里程碑节点，我们有必要召开会议通知到相关方，发布工作计划，如项目立项评审会、变更评审会，要有明确的纪要记录结论和待办；
如果是小范围的节点，可以在对应的工作群组中宣贯，一方面大家可以互相看到工作任务，另一方面呢有问题可以及时提出，防止节点卡住；
如果某任务只跟个人有关，那么可以单聊提醒，通过办公软件、微信或者电话提前告知。
②深入了解负责人的工作任务和优先级
获取到这个信息需要下点功夫，可以访谈、调研，或者跟其他相关方了解，以及通过平时的工作交集获取碎片信息。在弱矩阵组织中，项目成员除了做本项目工作外，还额外承担很多工作，这些工作的优先级也会影响你安排的工作任务的交付率。了解到对方的工作优先级，可以更清晰对方的工作情况，及时响应，风险分析和应对，或者解决问题。
③通过专业实力做好配合和支撑
在安排工作和收作业的过程来说，完成一个任务是为了解决一个问题，但为了解决这个问题，往往需要回答很多个问题。比如要完成需求规格说明书的编写，就需要明确项目核心目标，对应的业务部门，具体跟谁沟通，文档的格式，以及需求规格书的质量要求和评审过程。那么这些信息都需要项目经理稳定、精准的给出，帮助对方快速完成任务。虽然在WBS中负责人并不是项目经理，但是项目经理需要提前觉察出这些隐藏的工作。同样，在面对一些决策性的小问题，项目经理也需要凭借专业能力、对项目目标的了解、对干系人和风险的分析，给出专业性的意见建议。这样的协作既能各司其职，也能帮助项目经理赢得好的口碑。
④善于谈判
催活儿的另一个本质是对对方工作时间的争取，对方的时间是有限的，所以这里存在一个必然的博弈。统计好自己的筹码，找到对方的“弱点”，善于谈判，让催活愉快而优雅~
以上就是优雅而愉快的催活儿的主要内容了，当然了，除了上述的策略外，还有很多个性化的窍门，比如撒娇啊、在接口人办公室门口打地铺赖着不走啊（误）、讨价还价啊……一句话，还是得case by case，格局打开，稳住，催就完了~
三、常用计划和工具
关于进度管理内容，上面已经分析了进度管理的本质和拆解，需要包含进度规划、进度计划、进度跟踪以及进度反馈。同时，从协作视角分析了催活儿的要点和本质，以及需要遵守的3个原则，3个机制，以及4个具体执行的策略。下面我们从工具和模板角度出发，给大家展示下不同层级的进度图的形式，如何根据场景和目的选择展现形式和使用不同的工具。
（一） 计划部分
跟进度管理强相关的计划，也是项目经理经常要完成的计划，常见的有上墙计划、通晒计划、WBS计划、里程碑计划。
1. 上墙计划
上墙计划其实是一个相对通俗的说法，指的是需要挂在“墙上”的计划。一般对于项目大项目来说，项目涉及的相关方比较多，为了快速对齐需求，也为了更“醒目”，以便于引起大家的重视，尤其甲方客户会要求乙方提供上墙计划。
上墙计划由于需要打印出来贴在墙上，篇幅也十分巨大，因此计划的不需要过细，但需要拆分出关键节点。制定大致过程如下：
① 识别项目目标，明确交付物，以及具体的价值。对项目交付物进行分类，明确交付物产出的技术路径。
② 基于识别的技术路径，梳理每个路径的关键里程碑。如一个系统集成与软件开发项目，可以拆分为系统集成部分，平台构建部分以及软件开发三条线，针对这三条线再去拆解为关键里程碑。
③ 标记里程碑的关键工作和输出物。每个关键节点，需要标记出关键活动，并明确交付物内容，方便到节点的评审和检查，也有助于加强印象，便于责任到人。
关于上墙计划，不同项目有不同的格式，大家可以脑补一下（实在想象不出可以再跟我联系哈）