本套书的定位是填补学者（或称为理论研究者）与实践者之间的空白。 本套书特点： （1）更多的是分析小案例、讲细节、讲实践，实用性强。 （2）着眼实干，注重解决实践中的常见问题。 本套书共3本，其关注点也各不相同。 （1）《技法》主要关注项目的需求、进度、成本、质量、风险以及过程管控方面，这是提升绩效与改进过程的硬功夫。 （2）《管法》主要着眼于项目的团队、沟通以及干系人管理的主题，这是项目思维与实践的软实力。 （3）《心法》主要关注项目管理者的职业生涯和领导力提升，这是迈向顶ding级项目经理的修炼路径。

理并克服拖延 如果让技术人员用10天来写一个技术方案，大部分人*后两天才会开足马力。事实上，工作总是拖到*后一刻！这就是一直困扰着成千上万人的顽疾——拖延症。 研究表明，那些参与一个团队来完成方案写作的人，这种情况会好很多。当然，如果公司规定了写作技术方案的具体步骤、格式和流程，写方案的人也不会拖到*后**或者两天来写。
改掉自己拖延的毛病并非不可能，对于个人来讲，可以借鉴以下这些方法： ? 分清主次，优先做*重要的事情。 ? 消除干扰，终止那些分散精力的行为，例如限制上网、刷微信的时间。 ? 制订计划，计划每天上午和下午的工作。 ? 设定底线，设定自己*后动手的底线时间。 ? 反馈奖励，改进了之后可以给自己一些奖励。 ? 烦事先做，先做自己*不喜欢的事情。 和个人的拖延症一样，项目团队常认为可以*后满足项目的底线。结果在项目的执行过��中，明明已经出现了延迟，整个团队却没有足够警觉或者心存侥幸心理，在前期没有达到预定进度的情况下，过于乐观估计后面的工作，或者对项目的预留资源期望过大。结果在项目*后的底线来临的时候，整个团队处于慌乱状态。为了避免违约或罚款，有的团队通过削减功能或者降低质量来满足项目要求。糟糕的是，项目结束后也不认真总结经验教训，后续项目继续重复错误。时间长了，整个公司的员工都养成这种习惯，或者把这个作为项目的一种规律来看待而不是积极地去管理和克服。 合理利用项目监控，可以保持项目节奏、及时调整项目行为，这对整个团队克服拖延症状十分有效。这方面，里程碑是一个好工具。 7.1.3 激励是比惩罚更有效的措施 18世纪，英国政府为了开发新占领的殖民地——澳大利亚，决定将已经判刑的囚犯运往澳大利亚。 从英国运送犯人到澳大利亚的工作由私人船主承包，政府支付长途运输费用。据《犯人船》记载，1790—1792年，26艘由私人船主运送犯人的船共搭载4 082人，死亡498人，死亡率很高。一艘名为“海神号”的船，运送的424名犯人死了158人。英国政府经济上损失巨大，在道义上更是备受谴责。 对此，英国政府实施一种新制度以解决问题。政府不再按上船的囚犯人数向船主支付费用，而是按实际在澳大利亚下船时的囚犯人数付费。 新制度立竿见影，据《犯人船》记载，1793年新制度下的3艘船到达澳大利亚后，422名罪犯只有1人死于途中。此后，英国政府对这些制度继续改进，如果罪犯健康状况良好还给船主发奖金。这样，运往澳大利亚罪犯的死亡率下降到1%左右。
按照见招拆招的思维方式寻找解决犯人死亡问题的解决方案，一般可以形成两种做法： ? 对船主进行道德说教，寄希望于私人船主良心发现，为囚犯创造更好的生活条件。 ? 政府进行干预，使用行政手段强迫私人船主改进运输方法。 但以上两种做法都有实施难度，同时也会收效甚微。然而，新的激励机制顺应了船主们谋利的需求，使得犯人平安到达目的地。这就是激励机制的重要作用。 动听的道德说教和严厉的惩罚都不如激励机制。如果别人给我们支付佣金，我们会更努力地工作；如果汽油价格上升，我们会减少开车。这就是亚当?斯密在《国富论》中提到的一个思想。
我们期望的晚餐并非来自屠夫、酿酒商或面包师的恩惠，而是来自他们对自身利益的关注。 ——亚当?斯密
人们面对“爱护花木，人人有责”“请君自重，勿折花木”等类似道德说教的警示牌熟视无睹，以至于很多公园里写着“凡偷盗花木者罚款若干”，可是花木被窃的事还是时有发生。 面对顽固的人性，道德说教是软弱无力的，必须有一种保护花木的机制。一个植物园里写着“凡举报偷盗花木者，奖励若干”，结果花木生长得很好，从未发现花草被盗。 “罚款若干”是惩罚机制，“举报者奖励若干”是激励机制。可见，激励比惩罚有效。

实践者的角度 第1章 厘清项目成败的标准 1 1.1 项目成功是有层次的 1 1.1.1 项目成功标准的演进 2 1.1.2 项目交付成果、结果和干系人期望 4 1.1.3 项目成功的层次 7 1.2 项目成功常取决于干系人的感知 8 1.2.1 干系人满意，你就成功了 9 1.2.2 提升感知是核心竞争力 10 1.2.3 项目的成功必须是可以复制的 12 1.3 项目管理的现状和项目失败的原因 14 1.3.1 失败项目分析 15 1.3.2 未正确定义问题 17 1.3.3 治理缺失导致的项目经理责权利不对等 18 1.3.4 项目计划制订过程不佳 19 1.3.5 项目组织和项目团队无效 20 1.3.6 没有按照计划对项目进行跟踪 21 1.3.7 过分关注于技术的项目经理 22
第2章 好结果来自对客户及其业务的理解 24 2.1 深入了解你的干系人 25 2.1.1 一把小椅子 26 2.1.2 找到干系人的痛点 28 2.1.3 给关键干系人建立档案卡 30 2.2 以看戏人的身份澄清业务 31 2.2.1 别人以你看待自己的方式看待你 31 2.2.2 避免选择性知觉 32 2.2.3 警惕反移情效应，看戏不入戏 33 2.2.4 切忌“鸵鸟心态” 34 2.2.5 需求调研的核心是澄清而非说服 35 2.3 硬技巧是需求管理的基础 36 2.3.1 确保理解了业务 37 2.3.2 良好需求的标准 38 2.3.3 书写有效的需求 39 2.4 用好方案赢得干系人支持 40 2.4.1 解决方案的常见问题 40 2.4.2 套用知名公司的文件格式 42 2.4.3 篇幅要足够多但更要突出** 43 2.4.4 脉络清晰以体现结构化 44 2.4.5 用关键词直指痛点 45 2.4.6 定一个打动人心的主题 45 第3章 让计划在不确定的现实条件下取得实效 47 3.1 为什么理论不“实用” 48 3.1.1 计划的常见问题 49 3.1.2 现实工作的条件限制 50 3.1.3 局部偏差对项目整体的影响 50 3.1.4 CPM和PERT在实践中的问题 53 3.2 不确定条件下的项目计划 54 3.2.1 不确定才是项目计划的常态 55 3.2.2 判断项目计划有效性的标准 56 3.3 项目计划应注重实效，估算准确而非** 61 3.3.1 估算是一个逐步求精的过程 61 3.3.2 避免注入水分，警惕估算陷阱 64 3.3.3 面对乐观干系人 64 3.3.4 用里程碑切分项目 65 3.3.5 让估算更容易的实践 66 3.4 避免进度游戏 67 3.4.1 再短一点 67 3.4.2 计划等于承诺 68 3.4.3 行百里路半九十 69 3.4.4 管理并克服拖延 70 3.5 干系人是计划的主人 71 3.5.1 给“牛人”分配任务要“留空间” 72 3.5.2 让团队成员觉得值得 73 3.5.3 让团队成员自己提出来 73 第4章 组织结构对项目管理的挑战 76 4.1 组织结构对项目的影响 77 4.1.1 职能型组织 77 4.1.2 矩阵型组织 80 4.1.3 项目型组织 82 4.2 结构决定行为 83 4.2.1 系统的意志 83 4.2.2 无关人品，系统使然 85 4.3 组织结构对项目管理的挑战 88 4.3.1 职能型组织下的矛盾常表现为对成员个性的攻击 89 4.3.2 矩阵型组织下的项目经理*需要的是领导力 91 4.3.3 项目型组织下的项目经理要树立权威 95 4.4 影响项目的治理与人际因素 96 4.4.1 项目之间的冲突：“牛人”争夺战 96 4.4.2 组织政治因素与人际关系的影响 100 4.4.3 影响项目实施的组织与人际因素 102 第5章 选择合适的项目团队组织方式，让项目**运转 104 5.1 项目团队的组织方式 105 5.1.1 外科手术式项目团队 105 5.1.2 交响乐队式项目团队 106 5.1.3 爵士乐队式项目团队 107 5.1.4 足球队式项目团队 108 5.1.5 *适合的就是*好的 108 5.2 组建项目团队，明确各人责任 111 5.2.1 选择合适的团队成员 111 5.2.2 使用RAM明确每个人的责任 112 5.3 顺利走过团队的生命期 115 5.3.1 塔克曼团队发展模型 115 5.3.2 强烈建议经常搞团队建设 118 5.4 让团队成员发挥各自优势 120 5.4.1 理解团队成员的类型 120 5.4.2 识别项目团队成员的性格 121 5.4.3 面对团队中的“刺头” 125 第6章 项目成功需要称职的职能部门 129 6.1 跨部门项目团队协作存在的问题 129 6.1.1 项目是一个目标集中的组织单元 129 6.1.2 项目团队跨部门协作的常见问题 130 6.1.3 沟通不足以解决跨部门协作的问题 134 6.2 职能部门的有效支撑不可或缺 135 6.2.1 项目驱动型组织中的职能部门为何常挨骂 135 6.2.2 关注项目问题本质，为高层提供真实、全面的信息 135 6.2.3 把握项目问题脉搏，帮助高层提升工作效率 137 6.2.4 在更高层面上帮助项目团队解决项目问题 138 6.3 项目组织是一个复杂的社会技术系统 140 6.3.1 提升效率的关键在于综合优化 141 6.3.2 寻找复杂系统的平衡 142 6.3.3 短期**与体系效率孰重孰轻 146 第7章 把握问题关键，提升研发项目团队绩效 147 7.1 激励技术人员是老总们头痛的事 147 7.1.1 气儿不顺的研发人员让管理者无奈 149 7.1.2 好的研发人员是宝贝 149 7.1.3 激励是比惩罚更有效的措施 150 7.2 让员工获得激励 151 7.2.1 没有钱是万万不能的 152 7.2.2 **不是**的 155 7.2.3 让他感觉到你对他的态度 157 7.2.4 提升研发人员的成就感 158 7.3 培养和保护员工的成就感 158 7.3.1 让员工深信工作的价值 159 7.3.2 及时表扬、真诚激励 160 7.3.3 让员工参与项目管理 161 7.3.4 拓展晋升途径，帮助研发人员成功 162 第8章 切实提高项目的执行力 165 8.1 提高执行力，请从老板开始 165 8.1.1 执行力背后的管理错位 166 8.1.2 执行力不应成为管理水平低下的方便借口 168 8.1.3 执行力的根本保障在于顶层设计 170 8.2 确保和提高执行力 173 8.2.1 下发指令的*小化可执行原则 174 8.2.2 规则是天，是不可碰触的线 175 8.2.3 小心过度理由效应 177 8.2.4 利用好安慰剂效应 178 8.3 警惕影响执行力的陷阱 180 8.3.1 颇具迷惑性的“首问负责制” 180 8.3.2 知识个人化严重伤害项目的执行效率 182 8.3.3 急于量化管理是一剂毒药 183 第9章 领导互联网时代的创新型团队 185 9.1 互联网时代的创新型团队 185 9.1.1 实现创新更应关注团队 186 9.1.2 认识创新型团队 187 9.2 创新型团队成员的素养 189 9.2.1 创新型团队成员的性格特质 189 9.2.2 创新型团队成员的能力素质 191 9.3 建设和倡导创新型团队文化 192 9.3.1 信任—责任矩阵 193 9.3.2 走向活力与创新象限 196 9.4 领导创新型团队 198 9.4.1 如何领导创新型团队 199 9.4.2 创新型团队引入项目管理需要循序渐进 200 9.4.3 让创新型团队弱关联项目临时性 204

第10章 厘清项目组织与人员管理乱象 207 10.1 项目组织与人员管理乱象令人担忧 207 10.1.1 “高素质复合型人才”是难以自拔的陷阱 208 10.1.2 “技术问题”成挡箭神器 209 10.1.3 经验主义愈来愈像“圣牛” 210 10.1.4 “企业文化”是一只无底的桶 211 10.2 科学规律与市场规律孰先孰后 213 10.2.1 研发项目是以客户为导向的 213 10.2.2 建立评价研发项目进展的合理方法 214 10.3 依赖人才还是依靠体系 215 10.3.1 尊重人才不是依赖“牛人” 215 10.3.2 以人为本不是知识个人化的借口 215 10.3.3 研发项目的根本是开发出目标产品 217 10.4 有效项目治理和知识管理是保证 217 10.4.1 实现人力资源的“分类分级”管理 218 10.4.2 人员“来得了、干得好、走得成”是项目治理的责任 219 10.4.3 研发项目成功需要组织体系的保障 219 10.4.4 切实做好着眼于组织长远发展的知识管理 221 第11章 对人的管理*能体现项目管理者的水平 223 11.1 “领导”你的领导 223 11.1.1 做仆人式领导 224 11.1.2 用好你的发起人 225 11.1.3 站在领导角度找到其痛点 226 11.1.4 尝试管理领导的期望和兴趣 228 11.2 远离是非，管好你的客户 228 11.2.1 从结构属性看信息系统项目中的干系人管理 229 11.2.2 客户的签字不是挡箭牌 230 11.2.3 远离是非 232 11.3 让干系人参与项目很重要 233 11.3.1 你麻烦过的领导*有可能帮助你 233 11.3.2 让干系人为项目“付出” 234 11.4 管理干系人的关键还是自我修炼 236 11.4.1 害惨你的可能是你一直自豪的 237 11.4.2 正视自己的弱点 238 第12章 必须在沟通上下功夫 241 12.1 理解沟通模型突破沟通障碍 242 12.1.1 梅拉比安沟通信息模型 242 12.1.2 沟通模型与信息漏斗 243 12.2 使用正确的沟通方式 246 12.2.1 使用结构化方法规划沟通 247 12.2.2 理解沟通方式 250 12.2.3 发挥效用，避**件战争 251 12.2.4 微信这样用让人生厌 254 12.3 提高沟通能力是有方法的 257 12.3.1 实施有效的自我表露 257 12.3.2 积极有效地倾听 259 12.3.3 信息表达要简明规范 262 12.3.4 先处理情绪再处理问题 264 10.3.5 选择合适的语言模式 269 第13章 避免混乱，项目经理是沟通的核心 271 13.1 向上沟通要胆更要得法 271 13.1.1 永远不要让发起人从别人那里得知你该给的信息 273 13.1.2 引用合适的理论和依据来支持自己的观点 275 13.1.3 结论先行，消灭上司的“不耐烦” 276 13.2 与职能部门沟通要互惠 280 13.2.1 流程与制度是框架，人际关系是润滑剂 281 13.2.2 不要把矛盾都集中在自己身上 282 13.2.3 让干系人提起对你和项目的兴趣 283 13.3 与团队成员沟通要用心 285 13.3.1 什么才是团队成员真正想了解的 286 13.3.2 用积极心态与团队沟通 287 13.4 管理干扰，降低工作被打断的高昂代价 289 13.4.1 3种常见的干扰 290 13.4.2 控制好项目会议 291 13.4.3 向陪会说不，拒绝不必要的会议 293 第14章 项目管理实践专题 298 14.1 组织客户对典型客户考察是个关键点 298 14.1.1 做好典型客户管理是现场考察成功的前提 298 14.1.2 客户现场考察应如何组织 300 14.1.3 让典型客户代言，学会讲故事 303 14.1.4 饭桌上“烧一把火” 304 14.2 如何做项目或产品演讲/演示 304 14.2.1 演讲/演示效果为什么不好 305 14.2.2 演讲/演示的策划与准备 306 14.2.3 演讲/演示八段锦 307 14.2.4 演讲/演示的后续工作 313 代后记 成为专家是我认真思考后的选择 314

“项目管理实践三法”系列三本书的第二本，主要着眼于项目的团队、沟通以及干系人管理的主题，这是项目思维与实践的软实力。 本套书的定位是填补学者（或称为理论研究者）与实践者之间的空白。其写作特点如下： （1）以通俗易懂的方式，让读者了解项目思维的基本原理、原则和精髓。 （2）介绍并帮助读者学习、掌握项目管理的基本方法与工具。 （3）通过一些论述和具体的案例分析，使读者了解如何将项目思维应用于项目工作、个人生活甚至社会事务的诸多方面，并希望“抛砖引玉”，引导读者“举一反三”，以便在实际工作和生活中更好地应用。 （4）与读者分享作者二十余年学习与应用项目管理方法和系统思维的心得、实践经验，给予有价值的学习建议和行动指南，帮助读者快速入门和提升。