3. 風險規劃應對，做好應急和變更管理
催活是按照計劃收作業，但是計劃并不是一定能落地，我們需要擁抱變化（畢竟也沒別的辦法）。為了保障計劃能順利執行，作業能按時提交，需要項目經理時刻關注風險，盡量去規避一些低級別風險（信息未同步、犯懶沒有查資料、干系人管理不深入等），或者降低風險帶來的影響。一旦風險發生，根據應急規劃做好應對，做好項目變更管理。
還要強調的一點是，如果是關鍵路徑上的關鍵任務，建議在明確負責人的時候做好back up，這樣能大大降低風險，且兩個人協同配合，產出和效率會呈倍數增加。
（三）4個策略
以上就是優雅又愉快催活兒的核心組成啦~提升了認知，武裝了方法，最后再來分享下具體場景的策略：
①大的節點開會宣貫，小的節點群聊通知，單個節點單點提醒
在上一篇我們聊到進度管理需要分區和授權，不同的節點需要有不同的方式進行宣貫。如果是較大的里程碑節點，我們有必要召開會議通知到相關方，發布工作計劃，如項目立項評審會、變更評審會，要有明確的紀要記錄結論和待辦；
如果是小范圍的節點，可以在對應的工作群組中宣貫，一方面大家可以互相看到工作任務，另一方面呢有問題可以及時提出，防止節點卡住；
如果某任務只跟個人有關，那么可以單聊提醒，通過辦公軟件、微信或者電話提前告知。
②深入了解負責人的工作任務和優先級
獲取到這個信息需要下點功夫，可以訪談、調研，或者跟其他相關方了解，以及通過平時的工作交集獲取碎片信息。在弱矩陣組織中，項目成員除了做本項目工作外，還額外承擔很多工作，這些工作的優先級也會影響你安排的工作任務的交付率。了解到對方的工作優先級，可以更清晰對方的工作情況，及時響應，風險分析和應對，或者解決問題。
③通過專業實力做好配合和支撐
在安排工作和收作業的過程來說，完成一個任務是為了解決一個問題，但為了解決這個問題，往往需要回答很多個問題。比如要完成需求規格說明書的編寫，就需要明確項目核心目標，對應的業務部門，具體跟誰溝通，文檔的格式，以及需求規格書的質量要求和評審過程。那么這些信息都需要項目經理穩定、精準的給出，幫助對方快速完成任務。雖然在WBS中負責人并不是項目經理，但是項目經理需要提前覺察出這些隱藏的工作。同樣，在面對一些決策性的小問題，項目經理也需要憑借專業能力、對項目目標的了解、對干系人和風險的分析，給出專業性的意見建議。這樣的協作既能各司其職，也能幫助項目經理贏得好的口碑。
④善于談判
催活兒的另一個本質是對對方工作時間的爭取，對方的時間是有限的，所以這里存在一個必然的博弈。統計好自己的籌碼，找到對方的“弱點”，善于談判，讓催活愉快而優雅~
以上就是優雅而愉快的催活兒的主要內容了，當然了，除了上述的策略外，還有很多個性化的竅門，比如撒嬌啊、在接口人辦公室門口打地鋪賴著不走啊（誤）、討價還價啊……一句話，還是得case by case，格局打開，穩住，催就完了~
三、常用計劃和工具
關于進度管理內容，上面已經分析了進度管理的本質和拆解，需要包含進度規劃、進度計劃、進度跟蹤以及進度反饋。同時，從協作視角分析了催活兒的要點和本質，以及需要遵守的3個原則，3個機制，以及4個具體執行的策略。下面我們從工具和模板角度出發，給大家展示下不同層級的進度圖的形式，如何根據場景和目的選擇展現形式和使用不同的工具。
（一） 計劃部分
跟進度管理強相關的計劃，也是項目經理經常要完成的計劃，常見的有上墻計劃、通曬計劃、WBS計劃、里程碑計劃。
1. 上墻計劃
上墻計劃其實是一個相對通俗的說法，指的是需要掛在“墻上”的計劃。一般對于項目大項目來說，項目涉及的相關方比較多，為了快速對齊需求，也為了更“醒目”，以便于引起大家的重視，尤其甲方客戶會要求乙方提供上墻計劃。
上墻計劃由于需要打印出來貼在墻上，篇幅也十分巨大，因此計劃的不需要過細，但需要拆分出關鍵節點。制定大致過程如下：
① 識別項目目標，明確交付物，以及具體的價值。對項目交付物進行分類，明確交付物產出的技術路徑。
② 基于識別的技術路徑，梳理每個路徑的關鍵里程碑。如一個系統集成與軟件開發項目，可以拆分為系統集成部分，平臺構建部分以及軟件開發三條線，針對這三條線再去拆解為關鍵里程碑。
③ 標記里程碑的關鍵工作和輸出物。每個關鍵節點，需要標記出關鍵活動，并明確交付物內容，方便到節點的評審和檢查，也有助于加強印象，便于責任到人。
關于上墻計劃，不同項目有不同的格式，大家可以腦補一下（實在想象不出可以再跟我聯系哈）