极简项目管理-读书思维导图
2024-11-21 14:14:29 0 举报AI智能生成
《极简项目管理》是一本为项目管理小白和有经验的项目经理提供指导的工具书。本书通过思维导图的方式，将项目管理的各个环节和步骤进行可视化展示，帮助读者更好地理解和掌握项目管理的知识。思维导图涵盖了项目启动、规划、执行、监控和收尾等五个阶段，以及每个阶段的关键任务和注意事项。此外，书中还提供了一些实用的工具和技巧，如WBS、网络图、风险评估等，帮助读者在实际操作中更好地应用项目管理的方法和原则。通过阅读本书，读者可以快速掌握项目管理的核心内容，提高项目管理的效率和质量。
作者其他创作
大纲/内容
阅读前后的对比
读书前
项目管理概念模糊
没有系统的框架
知道项目管理的大概概念,但是不清楚边界和一些处理方案
读书后
书籍的思维导图
书的概论前言梳理
书籍的定位
极简项目管理是让目标落地、把事办成并使成功可复制的方法论。
本书想解决的问题
VUCA时代
易变性（Volatility）
不确定性（Uncertainty）
复杂性（Complexity)
模糊性（Ambiguity）
通过项目管理的方式去更好的面对VUCA
如何解决中小企业和创业团队当下面临的项目管理问题
本书解决问题的方式
给出关键步骤
给出行动策略
什么是项目管理
项目管理
目的
完成目标
做的事情
调配资源
形成合力
完成目标
国内项目管理的问题
经验主义的问题
市场环境的变化
认识项目管理
极简项目管理基础
组织经营活动分类
重复性劳动
追求
高度一致性-稳定性
非重复性劳动
项目是独特的一次性事务
说不清的成分
需求
客户的需求要进行拆解
区分方案与需求
面对客户的方案分析其合理性,通过专业性给出更合理的解决方案
项目的开始
不确定的部分内容就开始了-导致频繁变更
想要不做频繁变更-要求客户签字确认后再做
签字后仍然会有变更-导致与客户意见不合的后续隐患
项目是一个业务过程,不是一个技术过程
针对业务的解决方案才是客户的真实需求,只盯着技术指标，往往就容易沉浸在细节里面出不来了
不要试图仅仅解决问题本身，还要去解决问题所在环境的问题。
系统工程的一个基本原理就是超越系统本身解决问题，即N维系统产生的问题只有在N+1维系统中才能解决
不要排斥变化
客户每一次提出新的要求，都是在帮我们逐步逼近事实真相。
项目的特点
独特性
1.独特性意味着项目成果的“不重复性”
2.独特性是相对的
存异求同
将过往的经验进行梳理然后进行更好的处理新问题
3.独特性提升竞争力，增加挑战性
项目的目的
项目的目的是给出产品、服务或成果，对于结果强调了其“独特性”；
临时性
1.临时性是指项目有明确的起点与终点
临时性是变化的结果
2.临时性并不意味着项目的持续时间短
3.临时性会造成项目管理者的权限不足
项目经理和团队成员之间是单次博弈
职能经理和团队成员之间是多次博弈，职能经理决定成员的工资、奖金和晋升，而非项目经理
4.临时性的项目不意味着成果的临时性
5.项目可因多种原因结束
渐进明细性
1.项目的许多方面需要渐进明细
目标
范围
计划
2.渐进明细不同于范围蔓延
范围蔓延
渐进明细
项目的渐进明细，一定要在适当的范围定义下进行，也就是要在项目的边界内进行，以避免渐进明细演变成范围蔓延
3.渐进明细的方式
化大为小，逐步推进
剥洋葱式，逐层深入
项目的价值在于驱动变革
组织
日常工作的常见分类
（1）战略规划类工作，主要是给企业定发展方向和长期目标的。
应该包含的内容
现状
我们在哪
愿景
我们要去哪
从现状到愿景的路径规划就是所谓的战略规划
战略规划的意义
达成共识/同步目标
（2）日常运营类工作，帮助企业维持稳定和创造收入。
目的
追求效率
持续获利
运营能够维持组织在一定水平上持续运行
（3）项目类工作，帮助企业建立新的竞争优势或更科学的机制。
目的
开疆扩土
应对变化
项目的本质是改变业务类工作，以非重复性劳动为主要特征。
项目的价值在于驱动变革
项目可以实现组织运营水平的提升。
我理解的三种工作描述
战略告诉我们要做成什么样,运营帮我们保持良好的状态,项目让我们向着目标前进
项目与运营之间的变迁
当项目开始时，资源从运营转移到项目；在项目接近结束时，资源则从项目转移到运营
随着相关工作的完成，可交付成果和知识在项目与运营间转移
示意图
子主题
组织的工作框架
示意图
子主题
愿景
成为什么
使命
需要做什么
战略和目标
战略:如何做
目标:对结果的度量
项目组合管理
战略规划与项目,项目集和运营管理
持续运营管理
产生价值
授权项目集和项目的管理
提升价值创造能力
项目管理工作的分层
项目组合管理
衔接战略规划和项目管理
对于组织来说，做项目是一个投资行为
组织的项目选择和立项过程
解决资源分配问题
投资的角度
项目集管理
多项目共同管理,通过管理动作将共享内容在一起完成,减少重复操作
项目之间的协同问题
资源效率的角度
项目管理
项目的执行
重点
在约束下完成既定工作
用结构化降低项目难度
结构化思维
结构化思维的示例
将信息结构化是提升消息传递效率和质量的一种方法
结构化解决问题的一种思考方式
不同角度的思考
问题本身的属性
问题是怎么产生的?
当前可见的问题点是什么
资源可换么
问题产生的环境因素
地球不行,太空可以么?
空气中不行,纯氧中可以么?真空中可以么?惰性气体中可以么
去解决问题的主体
你不行,换成这方面专家可以么?
示例
200ml水放入100ml的杯子中
问题本身
水-液体
杯子
容积小的杯子,体积大的水
为什么会放不进去?
水多了会流出来
流出来的原因是水是液体
液体变成固体就不会流出来了,200ml水,降温到结冰再放入
水的体积大于杯子的容积
增大压力,将水的体积压缩
杯子可以是变得更大的么?比如气球,类似的可以在一定外力下变大的材质的杯子去提升容积
问题产生的环境
环境中的重力导致多余的水无法在杯子中存在
到一个无重力的环境中
解决问题的主体
我当前不知道该怎么解决这个问题,是否有相关人员可以处理这个问题
专业技能人员
处理过类似问题的人员
要获取游览器中第三方的 cookie 到后台
问题本身
项目管理中一个结构化的方法
按所需开展的管理工作将项目过程分为5个过程组
启动
确立目标
同步信息给参与者明确开始了
规划
该怎做
定义步骤
明确做法
监控
发现问题
改进问题
或者改进方案
执行
按照计划去执行
按照监控去改进
收尾
完成项目中的结果
PDCA循环
P (plan) 计划
D (Do) 执行
C (Check) 检查
A (Action)改进。
按需要解决的问题将项目管理分为10个知识领域
示意图
子主题
范围管理
进度管理
成本管理
质量管理
资源管理
采购管理
沟通管理
风险管理
相关方管理
集成管理类
过程组和知识领域的整合
启动
定目标
识鬼神
组团队
发章程
开好头
规划
拆任务
排计划
算投入
估风险
执行
建团队
带队伍
善协调
监控
采数据
控制量
勤监控
管变更
收尾
过验收
得总结
要归档
极简项目管理地图-示意图
子主题
题目
自己的项目案例
极简项目管理过程
启动-师出有名,名正言顺
项目生命周期
概念
特征
成本与人力投入在开始时较低，在工作执行期间达到最高，在项目快要结束时迅速回落
子主题
利益相关方的影响力、项目的风险与不确定性在项目开始时最大，并在项目的整个生命周期中随时间推移而递减
子主题
项目变更的代价不仅包括成本，还包括时间和质量代价
在不显著影响成本的前提下，改变项目产品最终特性的能力在项目开始时最大，随项目进展而减弱。
变更和纠正错误的成本在项目接近完成时通常会显著增高。
变更和纠正错误的成本在项目接近完成时通常会显著增高。
案例
案例1
案例2
结构
启动项目
组织与准备
执行项目工作
结束项目
项目过程
甲方
逐步移交主动权的过程
乙方
绑架客户上贼船的过程
生命周期模型
瀑布型
使用瀑布模型的条件
完整的预测项目未来情况
优先选择瀑布生命周期的情况
充分了解拟交付的产品
有扎实的行业实践基础
整批一次性交付产品有利于每个人
偏见误解
过多的文档工作
表格繁琐
流程繁重
人被流程管理而不是人管理流程
敏捷性
使用敏捷模型的条件
全新的项目或者了解不多的项目
优先选择敏捷生命周期的情况
需求应对快速变化的环境
需求和范围难以确定
能够有利于相关人员的方式定义较小的增量改进
偏见误解
完全抛弃流程
无序,失控
不适用于复杂项目
不专业
操作
生命周期中的处理原则-乙方
项目早期的变更原则上应倾向于接受（我称之为“让怎么干就怎么干”）。当然必须遵守变更控制程序。
项目中期，要先分析变更的影响，原则上尽可能与相关人员沟通，取消变更（我称之为“要变更，先谈谈”）。
项目后期，变更成本太高，原则上应尽可能不变更。遇到大的变更时可以考虑启动一个新的项目，遇到小的变更也要到售后服务时再做。当务之急是先验收，将项目收尾。（我称之为“生米已成熟饭——吃，是这盘菜；不吃，还是这盘菜！”）
项目需要阶段化管控
通过阶段化去减少不确定性,
阶段化的好处
通过阶段化手段可以更容易的把控项目发展
阶段化后,每个阶段的主要矛盾是固定的,可以更专注的去处理当前阶段的问题
阶段化后,每个阶段的应对方式也会类似,可以更好的去进行整合方案
项目阶段化还有另外一个好处，就是可以减轻痛苦、降低不确定性，从而增强项目经理成功的信心。
通过阶段化,可以明确当前这个问题就是这个阶段的核心,而不会出现完全不了解情况导致更多问题
通过阶段化,可以明确每个阶段的问题,而不会去扩散问题
项目生命周期中的规划控制
确认各个阶段要完成哪些工作
明确每个阶段可交付成功何时产生,如何验证和确认
确认各个阶段需要哪些人参加
确认如何控制风险和验收各个阶段的成果
商业论证-进行可行性评估
能不能赚钱
机会
市场
财务
能不能搞定
技能
产能
专利限制
对大家有没有好处
风险
环境
社会效益
示意图
子主题
总结
项目失败原因
管理优秀的项目败在方向（项目选择）上
管理拙劣的项目败在执行上
项目管理问题-引以为戒
六拍
拍脑袋
拍肩膀
拍胸脯
拍桌子
拍屁股
拍大腿
四没
没问题
没关系
没办法
没资源
三边
边设计
边实施
边修改
只谈
初期-只谈成本
中期-只谈进度
后期-只谈质量
定目标
概念
目标是什么?
一个事情过来了之后不要自己去"我以为",而是要去明确提出目标的人什么样是好的结果
定目标,定的目标不是"我以为",要明确客户的需求背景,真正目标,而不是"我以为的目标"
目标管理也是项目管理者变被动工作为主动工作的有效手段，无法对目标实行管理的项目注定会失败。
操作
如何定义目标
SMART 法则
S-明确的-specific
M-可测量的-measurable
A-可实现的-attainable
R-相关的-Relevant
T-有明确时限的-time-based
目标的设定
基于愿望的的目标必将破产
不要把目标定义的不契合实际情况
目标的范围
设置低目标会导致人的能动性下降
过高的目标无法实现，不切合实际的目标不仅会失去激励作用，还会让人倍感挫折
目标设定示例
示例1-装修
初期-多快好省
一段时间后-尽快完成
在过一段-做完就好
最后-能收场就行
基于愿望的目标产生的负面影响
团队功能失调
“狼来了”和“掩耳盗铃”从此相伴相生
滋生消极组织文化
会干的搞不过会说的
自欺欺人的激励方式
奖励任劳任怨,惩罚灵活应变
洛克定律
跳一跳,够得着
定目标的前提-收集需求
定义项目目标的首要工作是收集需求
描述需求的时候尽量直接
如何判断客户的需求
你想要,拿钱来
客户愿意付钱的是其真正需要的,否则就不是
多关注已知的真实行为
少关注客户说什么，多关注客户的行为。很多时候，客户对自己说的话既没有认真思考，更不用付出代价。
时刻记住项目是一个业务过程
明确客户最终想要解决的问题是什么
总结
切记鸵鸟心态
有问题不能悬而不决,后延问题只会导致更多的延伸问题,并且减少问题的处理时间
问题尽早处理
问题在早期解决成本会比较低
尽早暴露问题，吵完了大家也就可以安心地做事了
目标和需求是需要确认的
国内很多时候客户不肯签字
原因
最可能是客户还没完全思考清楚
项目进行时,拿不到确认/签字,下一阶段就不能开始
签字和确认的目标,并非是逼他们签字,而是希望他们借此机会认真思考项目问题
很多时候你不强势,客户就不会去深入考虑和讨论
不管用什么方法，在项目开始前，主要的项目相关人员必须对项目目标、需求达成一致
目标的示例
反例
客户满意度-怎么算满意
快速响应-多长时间算快速
稳定运行-稳定运行包含哪些指标
有效控制-如何算有效
示例
示例1
识鬼神-项目相关的有哪些人
识别项目相关人
有些人受益于一个成功的项目，而另一些人则会更多地关注项目成功给他们带来的负面影响。
忽视消极人员，会提高项目失败的可能性
当有人反对一个方案的时候
多分析为什么他会反对这个方案
给他带来什么影响
一定不要试图仅从技术层面与客户讨论问题。
分析项目相关人的工具-方法
权利-利益方格
示意图
子主题
编制相关方登记册并制定相关方管理策略
编写步骤
（1）收集相关人员的个人资料（姓名、从属单位和职务）。
（2）评估每个人对项目的期望和态度。
（3）确定每个人的权力和利益分值（在规定范围内的分值，如1~10分）
（4）使用权力–利益方格分析每个人的影响。
（5）基于每个人在权力–利益方格中的位置，制订管理策略。
针对不同区域人员采用不同策略
（1）不间断地管理第一象限的人，尽可能使其成为项目的支持者，促使项目成功。
（2）务必小心地管理第二象限的人，因为他们具有影响力，常在公共机构供职，应注重他们的地位。管理的重点是不要使他们成为项目的反对者。
（3）项目管理者用于沟通的时间很珍贵，应充分利用自己的时间。因此，尽可能花费较少的时间管理第三象限的人，监督其对项目的影响即可。
（4）倾听第四象限的人，他们对项目非常感兴趣，能够提供有用信息。
（5）在任何情况下，应时刻保持对每个人地位和态度的关注，根据实际情况及时调整和更新。
组团队
项目经理
项目管理的本质就是整合
片段式思考损害项目整体绩效
绝大多数组织都是诸多职能部门组成的
人们倾向于先考虑单个部门的需求,利益和目标,而不是优先考虑组织的整体利益
但是对于一个部门的最优方案未必是对一个组织,项目或者客户的最好方案
项目管理者必须要善于化解跨职能、跨部门/团队的矛盾，尝试找到能使各方达成一致的方案，这也是项目管理最重要的工作之一。
项目经理的尴尬-"神"一样的职位
项目经理有责无权的条件下实施项目
他既不给团队成员发钱，也决定不了团队成员的升迁（常见情况），却要安排团队成员干活，自然是不被成员待见的。
他时不时要跟职能部门争资源，给职能部门添麻烦，这些职能部门经理自然也是烦项目经理的。
高管见到项目经理时，听到的总是一堆坏消息：不是进度拖期了，就是成本超支了；不是质量变坏了，就是客户不满了。在高管眼里，项目经理是“从不带来好消息的人”。
项目经理的压力
示意图
子主题
旁观者效应-三落实
旁观者效应的问题
避免责任分散,做好三落实
三落实
任务落实
人员落实
组织落实
RAM-责任分配矩阵-明确每个人的责任
RACI
R-负责
A-批准
C-咨询
I-知悉
RACI 的编写步骤
（1）填写活动的代码和描述。
（2）在其他各栏内，填写项目责任。
（3）对责任分配进行讨论和审批。
RACI-模式分配责任中要注意的事项
讨论和确定好RACI后，必须将RACI传达给项目中（至少是组织内部）的相关人员。
每项活动有且只能有一个R
不能对某项职务划分责任，则该活动需要进一步细分
如果项目管理团队成员在其栏内没有R，那么他不是项目管理团队的真正成员，可能是扩大范围的团队成员（他不具有任何责任，因此他不实施管理，而是执行）。
所有人需达成一致意见，同意责任分配
示意图
示意图1
子主题
示意图2
子主题
发章程
企业是根据什么工作的
章程
项目章程
项目章程是项目团队与组织的契约
前提
契约精神-承诺必须要执行,不打任何折扣的执行
目的
项目章程的编制，表明项目及其团队已经得到了管理层的支持
创建项目章程的另一个目的是向项目团队中的每个人告知项目的存在，明确他们对项目的职责和权利。
项目任务书
项目任务书-项目章程的一个转换
项目任务书作为项目的一个指导性文件，发挥着类似项目章程的作用
项目任务书应该是一个简短的文件（理想情况是一页)
简要说明项目要做什么、如何做，和当项目结束时能给企业提供什么样的商业价值。
项目任务书对项目的发展方向、成果和执行过程中能够进行明智的决策和规划奠定了基础。
项目任务书的目的
达成共识
编制项目任务书的关键是对需求达成早期概念层次的共识，并对需求做出回应
编制项目任务书的过程
由项目经理召集联席会议来起草项目任务书
编制项目任务书的关键是对需求达成早期概念层次的共识，并对需求做出回应
接着应邀请那些没有参加制定项目任务书的相关人员来检查和讨论，直到所有关键人员都表示认可
批准过程的参与者
1）高级管理层。管理层的支持对于项目的成功实施起着至关重要的作用。他们的批准意味着“可以做详细计划，我们授权项目可以使用所需的资源”。
（2）客户。在我们的项目管理概念里，客户起着非常重要的作用。
（3）职能部门经理。项目的可交付成果不可能存在于真空中，总是有一些部门对项目的产品或服务提供输入或从中获得输出。应征求职能部门经理的意见和建议，使他们在最初阶段就了解项目并对项目做出承诺。
（4）项目经理。在理想情况下，项目经理应在最初阶段就确定下来，并参与起草项目任务书。因为他将管理项目，所以他应该在项目定义和项目批准过程中发挥重要作用。
（5）项目团队核心成员。其中主要指团队内的专家们，他们将留在项目团队中，从项目的开始直到最后结束。让他们参与到批准过程中来，往往会加强其对项目的主人翁责任感。
以项目任务书为起点，项目计划团队在开始制订项目计划时应进一步讨论项目任务书的细节，从而更好地理解项目的范围。
将这种理解用正式文件做出公告并归档。
项目任务书主要内容
（1）可测量的项目目标和相关的成功标准。
（2）项目的总体要求。
（3）概括性的项目描述。
（4）项目的主要风险。
（5）总体里程碑进度计划。
（6）总体预算。
（7）项目审批要求。
（8）委派的项目经理及其职责和职权。
（9）发起人或其他批准项目任务书的人员的姓名和职权。
项目任务书的注意事项
（1）项目任务书是非常重要、具有约束力的文件，相当于项目的宪法，项目任务书的发布标志着项目的正式启动。
（2）项目任务书应该由高级管理层编制，或授权项目经理代为编制，但必须由高级管理层签字，以表明高级管理层为项目提供支持的态度。
（3）项目任务书必须指定一位项目经理，并且明确其责任和权力。
（4）项目任务书应该分发给与项目有关的部门和人员，因为该项目任务书将授权项目经理在项目活动中使用组织资源。
（5）为便于阅读和理解，项目任务书中尽量不要出现晦涩的技术术语。
（6）对于超出项目经理权限范围以外的问题，项目任务书必须明确处理问题和升级问题的机制，并让相关人员知悉。
（7）项目任务书要对项目的可交付成果进行概括性描述，以便于团队成员了解所做的工作是什么。
（8）项目目标主要是指项目的绩效目标。
（9）在范围说明中，要特别指出项目不能提供的东西，尤其是可能被误以为已经包括在项目范围内的东西。
（10）项目任务书应清晰定义项目的关键里程碑，通过对关键节点的检查确保项目取得令人满意的进展。
（11）项目任务书不是一成不变的，如果发生重大变更使得原项目任务书不再可行，就应该签发新的任务书。
（12）对于外部项目，应先有合同再有项目任务书。
开好头
目的
在项目过程中，重要的节点必须要举行仪式，要引起领导和相关部门的重视，让项目团队更有凝聚力。
方法
定基调
找节奏
明规则
（1）沟通方式、频率、内容及格式。
（2）项目管理者的权力，即项目奖惩权力、人事调度权力和项目方案的决定权力等。
（3）甲方责任、需求提供、调研配合和业务指导等。
（4）变更处理的流程、文档、权力等。
（5）团队合作模式、风格、出勤、考核标准、争议解决等。
（6）项目开发方的各个部门的义务及责任。
一个需要注意的问题是，在启动阶段确立规则会让人觉得项目管理者比较教条、刻板，常有人以“项目时间紧任务重，先干起来再说”等说法搪塞。对此，你要顶住压力，不必过多解释，因为你解释的理由往往会成为别人反对你的靶子。记住，不在项目开始时订好规则，后面的路只会越来越难
启动会
目的
名正言顺
获得支持
达成共识
明确职责结构/明确分工
结构化方式落实启动会
示意图
子主题
启动会议10问
谁做会议主持人
发起人,组织的搞错管理者代表
启动会为谁开的
为项目而开
谁来讲述项目目标,要求
发起人,组织的搞错管理者代表
谁来讲述组织构成
发起人,组织的搞错管理者代表
哪些人必须参加
发起人
组织的搞错管理者代表
项目经理
职能经理
其他关键人员
历时多久合适
不宜太长
30分钟-1小时
技术方案是否应该讲解
不宜讲解技术方案细节
可以介绍技术架构和概况
重点对谁介绍分工
重点对各职能经理介绍项目分工,获取职能经理对项目的承诺
启动会的结果是什么
得到承诺
职能经理
项目经理
关键人员
形成书面确认
造势,定向,预警,落实,哪个更应该侧重
重要性的顺序
1 落实项目职责
2 预警项目风险
3 确定成功标准
4 营造项目氛围
项目启动会10个重要细节
示意图
子主题
注重面向未来
通过启动会议了解人们对项目的期望
侧重对已确定事项的说明,求同存异
需要组织协调的方面,让发起人讲
讲规则时要重点强调变更程序,协调和问题升级程序
将每个人的责任以及假设,约束等说清楚
需注意的方面以及关键因素是什么
要充满信心的介绍项目团队
越是不支持的人,越要面对,尽力争取他们的承诺
切记落实会后1到2周的工作安排
规划-运筹帷幄,决胜千里
计划不如变化快，还做计划干什么？
计划
计划的总结
计划是花费最少,影响最大的工作
事前想清楚,做好计划,而后按照计划行事
事前想清楚,事后不折腾
现实会有诸多情况导致不能完全按照计划进行,但是计划会为你提供做事的优先顺序,这样会让你事半功倍
（1）计划是用来改的。正因为计划没有变化快，才更需要做计划。
（2）领导不应该直接管人管事，而应该管计划。
（3）项目不应该被领导管着，而应该被计划管着。
（4）员工不应该按领导的指示做事，而应该按计划做事。
布利斯定理
用较多的时间为一次工作做计划,这项工作所用的时间就会减少
项目开始前要回答的问题
必须做什么
花多大成本做
存在什么不确定性
必须做的多好
谁来做
应该如何做
什么时候必须完成
那些工作需要外包
计划的重点
计划一旦制订出来，就应该送交相关人员签字。
有效计划
（1）对计划进行计划
（2）计划执行者应该参与制订计划
（3）计划制订的第一规则是随时准备重新做计划。
（4)指定备用计划
（5）定义问题比解决问题更重要。
（6）重点关注项目的工作分解结构（WBS）。
（7）分阶段编制计划（滚动式计划）。
有效项目计划21问
示意图
1
2
拆任务
拆分任务的必要性
为什么一个项目中大家都很忙，但却看不到完成了什么成果呢？
隐性工作显性化，显性工作结构化，结构工作标准化
结构工作标准化，提高组织效率的必由之路
经验->结构化
WBS-工作分解结构
示例
财税库行横向联网系统项目
子主题
代码设计工作包的工作技术条件
子主题
财税库行横向联网系统的WBS词典
子主题
4种常见的 WBS 类型
按组分解
按功能用途分解
按生命周期分解
按地域/组织分解
示例
按组成分解的自行车项目的WBS
子主题
按功能用途分解的自行车项目的WBS
子主题
按生命周期分解的自行车项目的WBS
子主题
按地域分解的自行车项目的WBS
子主题
WBS的展示方法
树形结构的层次图
阶梯缩进表格
分解方式
WBS 是以可交付成果为向导的分解
不是以活动为向导的分解
WBS 的底层是工作包
工作包,包括为完成该工作细目可交付成功而必须的计划活动
WBS 的编辑方法
自上而下
从 WBS 的顶部开始分解可交付的成果;
从大局开始,持续的分解工作
步骤
①确认项目将要交付的最终产品、服务或成果。它们是第一层级的组件。
②定义为完成每个第一层级组件所需要的主要可交付成果。
③把每一个主要可交付成果分解至恰当的详细程度（遵从WBS分解原则）。
④评估和核实WBS直到被批准。
自下而上
从底层的工作包开始,想 WBS 顶层汇总工作
步骤
①确认WBS中的全部工作包。
②有逻辑地把相关工作包归并到一起。
③把可交付成果汇集到更高一个层级，也就是母层。
④重新分析工作，确保所在分支的所有工作都包含在WBS中。
⑤重复开展汇集和分析工作，直到把所有组件都汇集到第一层级，并且WBS中包含了100%的工作。
⑥评估和核实WBS直到被批准。
如何分解项目工作
两个视角
怎么完成
时间维度
交付什么
空间维度
示意图
子主题
分解标准
目标:分解到满足
易于管理
足够详细
WBS的最底层组件一定是“交付什么”，即都是具体的交付成果。
示意图
子主题
确认分解是否正确的标准
交付了较低层级的所有WBS组件恰好能够交付较高层级的相应可交付成果。
WBS 中每一个工作包都应该有自己的名称
每个名称应该是名词,形容词+名称,名称+动词,而不应该是一个单纯的动词
示意图
子主题
判断 WBS 好坏的标准
MECE 法则--相互独立,完全穷尽
信息透明原则
最底层工作包应该分解到信息透明层次
信息透明
包含完成工作包所需的时间
包含完成工作包所需的成本
包含完成工作包所需的验收标准
80小时原则
为了尽早的了解工作的真实情况
独立责任原则
单个工作包应该只分配给一个责任人，以避免推诿扯皮
滚动式规划原则
示意图
子主题
不同层次原则
不同可交付成果可以分解到不同的层次
一个上级原则
每个下级组件有且只有一个上级组件
WBS 检查表
示意图
子主题
可以交付成果为导向
包含所有的可交付成果,包括项目管理
涵盖了100%的项目工作
每个下层组件都包含了上层组件100%的工作
每个工作包的名字都用的是名词,形容词+名词,名词+动词来命名
以层次结构图或阶梯缩进表展示给各相关人员
负责具体工作的执行者参与了 WBS 的创建
咨询了相关专家的意见
得到了相关人员的认可/批准
建立了 WBS词典
随着项目的工作渐进明细而更新
随着项目工作的变更而更新
WBS解决的问题
从最底层入手可以解决评估工时,成本和资源需求
WBS是项目团队执行工作的基础，同时也为评价变更提供了基准。
WBS常常是向高层展示项目进展状况的工具
任务墙
排计划
进度估算
进度估算方式
史前文明-拍脑门估算
基于经验的类比估算
查找已完工的类似项目,根据上个项目去估算下个项目
应用场景
在项目详细信息不足时使用
不建议以此作为项目进度管理的基础
好处
估算成本低
估算耗时少
存在问题
（1）项目B与项目A类似的程度有多大？毕竟每个项目都是独特的。
（2）项目B真的用时80天吗？我们的资料很多时候都是后补的，经常不是那么可信，这就是现实。
（3）会不会有人为自己或/和项目安全注入水分呢？
基于分解的参数估算
做法
对项目进行分解
创建详细的 WBS
对每个工作包,让最熟悉该工作包的人,基于历史数据进行估算
项目管理团队汇总各工作包的数据得出总进度
应用场景
参数估算的准确性取决于参数模型的成熟度、基础数据的准确性和使用这一方法的人的可靠性。
好处
比类比估算更准确
问题
比类比估算更耗时
WBS 分解正确么
各工作包估算准确么,是否加入了水分?
会不会有人保证为自己/项目安全注入水分
三点估算
做法
正常情况
最好的情况
最坏的情况
项目进度安排
CPM-关键路径法
关联路径的时长意味着项目的最短耗时
CPM中的项目活动属性
活动代号-ID
活动持续时间-DU
最早开始时间-ES
最早完成时间-EF
最迟完成时间-LF
最迟开始时间-LS
浮动时间-TF
三种进度计划形式
项目进度网络图
示意图
子主题
甘特图
示意图
子主题
里程碑图
示意图
子主题
提升项目效率-压缩进度
压缩关键路径
并行
资源增加
加班
项目案例
资料
活动的持续时间与紧前关系
子主题
紧前活动：在进度计划的逻辑路径中，排在非开始活动前面的活动。
操作过程
1 绘制项目的进度网络图
示意图
子主题
2 确定关键路径
示意图
子主题
3 顺推
示意图
子主题
4 逆推
示意图
子主题
5 计算浮动时间
示意图
子主题
在关键路径法中，顺推可以清楚项目的最短周期，逆推（按照活动的最迟开始时间安排工作）可以找到节省成本的方案。
算投入
核心
花多少钱,对应完成多少工作量
预算
概念
对比的内容
计划完成的工作量
实际完成的工作量
实际的花费
对比指标
实际成本与实际完成工作量做比较，表明了项目的成本花费状况
将预算与实际完成工作量做比较，表明了项目的进度状况；
项目成本预算的方法
大中型项目
分级编制
小型项目
集中编制
项目成本预算的步骤
分摊总预算成本
示意图
子主题
制定累计预算
示意图
子主题
子主题
估风险
为什么做风险管理
有备而来好过突发问题
风险管理的悖论
如果风险管理很好，风险就不会发生
可是风险不发生怎么证明是因为风险管理得好呢
风险的定义
未发生但是可能发生的不好的事情
风险三要素
事件
概率
影响
风险分类
已知风险
未知风险
风险分析
分析的数据指标
风险事件发生概率
风险发生后的范围与影响
每个结果的可能性
分析的工具
风险评级表
示意图
子主题
概率影响矩阵
示意图
子主题
项目风险图
示意图
子主题
执行-依计而行,行必结果
系统使然
系统意志
什么是系统意志
系统意志的作用
系统的意志决定了粒子做事情的阻力系数，按系统的意志做事是阻力最小的方式
系统意志的影响
系统内的元素会继承系统的意志
符合系统意志的元素获益最大
结构决定行为
在一个系统中,不同的角色有不同的行为
角色带来的包括责任和作用
同一个系统中,同一个角色更换人员往往看到的情况总是一致的
系统结构是系统中影响最大的一部分
建组织
实施项目的组织结构分类
职能型
典型的职能型组织是一种层级结构
有层级表现
各个组织相互独立
每个层级相互链接
职能型组织分类的运作方式
优缺点
优点
实现技术进步有帮助
工作汇报是唯一的上级
缺点
没有明确负责人,参与者不对项目最终结果负责
难以获得项目资源对项目成果的承诺
部门间出现冲突,处理起来十分复杂,需要逐级向上找到关联结点才能比较好的进行处理
当需要各部门协作面对跨职能部门的复杂项目时，职能型组织的效率十分低下。
跨部门冲突问题
组织里的每个人都在忙，忙着掩盖事实真相。
下属不满领导决策，总是试图证明领导是错的。
只要一跨部门协作就需要开会，协商会议特别多。
使用场景
项目任务清晰划分,稳定划分可以使用职能型模式
项目中不确定因素较多,难以明确责任时,不宜使用职能型团队模式,容易出现相互推诿
问题
管理错位
示意图
子主题
恶性循环
示意图
子主题
示意图
子主题
矩阵型
矩阵型组织是一种既有人对项目负责，又能有效利用组织资源的项目组织方式;
示意图
子主题
优缺点
优点
把职能分工与组织合作结合起来，从专项任务的全局出发，促进组织职能和专业协作有利于任务的完成。
把常设机构和非常设机构结合起来，既发挥了职能机构的作用，保持了常设机构的稳定性，又使行政组织具有适应性和灵活性，与变化的环境相协调。
在执行专项任务时，有利于专业知识与组织职权相结合。
项目团队成员是临时的，这些团队成员可以在同一时间段承担多个项目，使组织资源能够得到充分利用。非常设机构在特定任务完成后立即撤销，可避免临时机构长期化。
缺点
协调困难
工作难以开展
员工缺乏归属感和安全感
矩阵型组织分类
弱矩阵
平衡矩阵
强矩阵
项目型
项目型组织是以项目组作为独立运行的单位，项目组拥有专用的项目资源，团队成员通常集中办公。
示意图
子主题
优缺点
优点
有明确的对项目结果的实现承担这责任的人
可以充分利用项目组专用资源
缺点
对企业的资源利用成都不足
项目资源被各个项目组独占,项目需要时可以及时获得,但是当项目不需要这些资源时却很难从项目释放
使用场景
进度或产品性极为重要,对技术和质量要求较高而项目开发成本相对不重要的,企业资源相对重要的项目
组织结构与组织发展阶段的对应
组织演化过程
子主题
企业诞生
始
牛人出现
什么都能做的人
有自己的追随者
能解决问题
终
企业规模扩大
牛人无法处理所有问题
优势
执行力高
团队敏捷
劣势
单人难以承担越来越大的市场
职能分化
始
团队扩大
多个在自己领域有能力的人去承担自己职能范围内的工作
终
团队更进一步扩大
团队内部职能化不规范
职能经理管理不过来更多的人
规范化
始
团队扩大
职能人通过自己的能力管理不过来自己的团队
开始制定规范,流程,制度去进行团队管理
终
部门协作困难
难以创新和保持竞争力
项目化
始
为了打破职能型团队的部门墙
提升创新能力
带队伍
选队员
组织中人员分类
有能力-同价值观
重用
有能力-不同价值观
慎用
无能力-同价值观
小用
无能力-不同价值观
不用
示意图
子主题
团队组织方式
外科手术式
概念
特点
一个核心成员
其余成员围绕核心成员工作
优劣
优势
关键任务由团队核心负责人亲自动手完成，成功率较高
劣势
团队核心负责人事必躬亲、较为劳累
不利于人才培养和团队成员的迅速成长
适用场景
关键工作必须由资深专业人员亲自操作的项目
一个资深的项目经理带领着一批新手的项目团队
交响乐式
概念
特点
组织有明确的工作任务分工体系，团队成员对整个组织及其他成员了如指掌
·团队领导有大胆用人的气度，敢于授权；
团队成员训练有素、自我指导、勇于承担责任，拥有良好的团队意识，配合默契。
优劣
优势
团队战斗力强
不易出问题
劣势
团队难以组成
爵士乐队式
概念
特点
团队各成员都是专业的，能够熟练演奏自己的乐器，对乐曲了然于胸。
团队各成员熟悉项目情况，不仅能做好自己的工作，还具备总体和系统意识，能够保持与其他成员的协调。
足球队式
概念
特点
有明确目标
成员有分工,但是又可以相互替换调整
在分工明确的前提下,通过积极主动的灵活跑动配合其他成员完成工作
优劣
优势
有基本分工,但是可以相互替换调整
目标明确
共同进退
劣势
出现问题后责任划分
问题抛出到其他人那
团队的生命周期
塔克曼团队发展阶段模型
示意图
子主题
团队发展的五个阶段
形成期
主要工作
明确方向
确定职责
制定规范与标准
进行员工培训
负责人要做的
同步信息
工作目标
工作范围
质量标准
进度计划
进行培训
消除成员的困惑与忧虑
确保团队成员之间建立互信的工作关系
让团队成员之间达成共识
震荡期
主要工作
安抚人心
认识并处理矛盾和冲突
负责人要做的
引导工作
化解矛盾
建立工作规范
规范期
负责人要做的
鼓励提建议
建立关联感
实行参与制
认识到自己是团队的成员
对成员进行工作授权
激发责任心
表扬和奖励
激励
成熟期
负责人要做的
掌舵
集中精力关注进度,成本,质量等事关全局的事情
更新工作方法和流程
推动经验与技术交流
提升管理效率
适当放权
解散期/修整期
结果
解散
组建新团队
勒令整顿
善协调
冲突
项目和部门之间的冲突
项目团队成员在关键时刻会选择出卖团队,但是绝不会出卖组织
铁打的组织流水的项目
同一个时刻,一个人收到两个领导指挥,会使人变得无所适从
资源争夺
矩阵型组织的常见问题
·项目经理如何增强自己的影响力？
·职能部门经理不配合，怎么办？
·项目实施过程中职能经理更换了自己职能部门的人员，如何应对？
·其他职能部门经理推卸责任，怎么办？
·如何制定项目的绩效考核体系？
·项目的奖金要如何发放？
·项目组成员分配过多精力给其自身所在部门工作从而影响了项目，如何应对？
·未经项目经理同意，职能部门经理给自己部门成员放假，如何处理？
·如何跟其他项目经理争夺一个关键核心资源？
处理方案
明确目标,并让每个人熟知
设立一个可以短期实现的里程碑
不要让团队成员闲下来
项目与项目之间的冲突
资源约束
管理总是在可行与合理之间做选择
管理者追求的是可行而不是合理
影响项目因素
资源问题
组织治理结构
人际因素
如何搞好项目
搞好人脉
搞好关系
搞好资源
搞好工作
监控-审时度势,沉着应变
采集数据
用数据而不是用感觉管理项目
90%效应
感觉上只有一点点工作了,实际上还有很多没有完成
如何避免90%效应
给成员定义更细致的工作目标和计划
让团队成员把自己的工作进度用数据展现出来
做好项目管理,要收集的常见数据
技术绩效测量结果
进度活动的起止日期
已完成的任务数量
可交付的成果状态
进度进展情况
变更需求的数量
缺陷的数量
实际发生的成本
实际持续的时间
分析工具
直方图
直方图的常见作用
某个特性波动的状态
直观的传递有关特性的状态信息
在研究波动状况之后，可以掌握过程状态，从而确定应在什么地方集中力量进行工作改进
如何制作直方图
确定数组和组宽
数组
组宽
绘制步骤
（1）选择要分析的对象，典型的有时间、成本、质量、变更、故障、重量、速度、尺寸等。
（2）收集数据。
（3）确定组数和组宽。
（4）绘制直方图。
直方图的分布状态
正常型分布状态
山峰状
异常型分布状态
偏峰型
双峰型
平峰型
孤岛型
锯齿型
示意图 
散点图/相关图
作用
识别两个变量之间可能存在的关系
制作方法
定义理论关系
收集样本数据
在直角坐标系中绘制散点图
分析数据
分析方式
在散点图中，所有数据点的分布越靠近某条斜线，两个变量之间的关系就越密切；
所有数据点的分布越分散，两个变量之间的关系就越弱。
帕累托图
重要信息
数据由左至右按降序排列的条形
各要素按百分比比例累计的曲线
占比80%的水平线
在帕累托图中，80%水平线与累计曲线交叉点的左侧要素就是需要重点解决的问题
帕累托图的绘制过程
收集数据
子主题
按降序排列数据，计算占比和累计百分比
子主题
绘制帕累托图
分析方式
排在最左边的条形显示出最大的改进机会，它代表了导致最多缺陷或错误的原因
帕累托图识别出了“关键的少数原因”，也就是那些导致大多数缺陷或错误的少数原因——80%水平线与累计曲线交叉点的左侧要素
控制图
概念
受控状态
当一过程仅受随机因素影响，而关键指标的平均值和偏差都基本保持稳定时，称为受控制状态。
特殊因偏差
作用
控制图可以揭示过程中偏差的本质，指出什么情况是正常的，什么情况是不正常的
·希望对过程输出的变化范围进行预测时。
·判断一个过程是否稳定（处于受控状态）。
·分析过程变异来源是随机的还是非随机的。
·完成一个过程改进项目时想要防止特殊问题的出现，或对过程进行基础性的改变。
·希望控制当前过程，问题出现能觉察并对其采取补救措施时
分析方式
判断过程是否失控的标准
单点规则
7点规则
控制量
项目质量管理的尴尬
质量管理部门成了质量检验部门
质量管理人员常成为众矢之的
出不出质量问题是个问题
质量认证越来越像形式主义
需要什么样的质量管理
QA 部门:质量管理部门的定义
开展有效的质量控制活动
建立健全质量保证体系
树立优秀的质量文化
确保企业的产品质量和过程质量。
QA 部门的职责
QA部门的三中角色
警察
教师
医生
决心比技巧更重要
责任
出了问题你负得了责吗
把原则坚持到底
勤监控
项目监控
一些监控基础项
·对过去绩效的分析
·当前的风险和问题状态
在本报告期完成的工作
·在下一个报告期将要完成的工作
·本期批准的变更的汇总
·偏差分析的结果
·预测的项目完成情况（包括时间和成本）
·必须审查和讨论的其他相关信息
PDCA 循环
示意图
子主题
子主题
P-计划
D-实施
C-检查
A-改善
项目监控的实践
里程碑
将里程碑完成率作为项目绩效考核的标准
合理的规划里程碑
围绕里程碑安排工作
将里程碑的重要性和压力传递给所有人
项目管理监控的工具
短会-5分钟站会
必要回答的问题
（1）昨天我做了什么？
（2）现在我遇到了什么困难？
（3）今天我计划做什么？
任务墙
行动跟踪计划
示例
子主题
管理和沟通
面对不同方的沟通
向上
面平
向下
管变更
目标
让变更可控
让变更可管理
降低变更带来对于成功的影响
项目的过程
站在实施方（乙方）的角度，项目过程就是“绑架客户上咱们贼船的过程"
站在委托方（甲方）的角度，项目过程就是“逐步移交主动权的过程”。
发生变更不是问题，问题是许多变更处于“非管理状态”
变更发生后需要界定的问题
·说明批准或者不批准变更所需的时间、费用。
·规定一个大家都同意的办法，以便提出变更并评估其对项目基准的影响。
·规定一个大家都同意的办法，以便提出变更并评估其对项目基准的影响。
·变更发生时要确定你能做些什么以及不能做些什么。
要确认明确的事
评审变更会引起哪些连锁的变更
如何对这些变更进行管理；
变更效果达到后要不要更改管理标准
变更管理的步骤
示意图
子主题
第一步，当有人提出变更时，首先要评估信息的准确性，确认项目变更事实。
第二步，提供变更申请的书面记录
第三步，分析变更对范围、进度、成本、质量等诸方面的影响。
第四步，沟通变更影响，确认是否取消变更。
第五步，针对变更请求，提出相应解决方案。
第六步，查阅审批权限，选择合适人员对变更进行审批。
第七步，召开变更控制会议，批准或否决变更
第八步，根据对变更请求的审批状态，与相关人员进行沟通。
第九步，指导与执行变更相关工作，跟踪变更执行状态。
变更中要注意的问题
1.认识变更中的矛盾
2.警惕范围蔓延
3.“烦琐”的“九阴真经”
4.给客户提供多个选项
谨慎对待第一次
利用框架效应
忠告不如警告，以损失为导向的沟通将更加有效。
收尾-慎终如始,好戏杀青
做好项目收尾,不留后遗症
过验收:项目不能做成烂尾楼
得总结:最大的浪费是经验教训的浪费
去归档:让经验教训真发挥作用
成为卓有成就的项目管理者
好的项目管理者为何如此稀缺
打造面向业务的系统化思维
极简项目管理,说起来容易做起来难
名词解释
运营
长期
重复性
运营以追求效率为目的，赚钱的事要好好干，这对组织很重要
项目
独特的
临时性的
渐进明细
项目的本质是改变业务类工作
项目的价值在于驱动变革
铁三角
三个定点
范围
时间
成本
内部
质量
项目经理
十大领域
规划
沟通
整合
干系人
成本
采购
风险
资源
进度
质量
五大阶段
启动
规划
执行
监控
收尾
方案
需求
迭代
增量
紧前活动
预算
风险
未发生但是可能发生的不好的事情
系统意志
陈述性知识与程序性知识
知识金字塔
示意图
子主题
子主题
收集的经典话语
用户根本不知道自己需要什么，直到你把它摆在他面前。
“我确实说不清我想要的东西是什么样子的，但我能说清的是你给我的东西不是我想要的。”
如果你从不犯错，这意味着你从来没有尝试过任何新事物。
人类总会犯一个错误：人总是用之前见过的东西，来描述一个未曾出现过的东西
针对业务的解决方案才是客户的真实需求,只盯着技术指标，往往就容易沉浸在细节里面出不来了
不要试图仅仅解决问题本身，还要去解决问题所在环境的问题。
系统工程的一个基本原理就是超越系统本身解决问题，即N维系统产生的问题只有在N+1维系统中才能解决
如果你给孩子一把锤子，那么整个世界在他眼里都是钉子
项目的价值在于驱动变革，运营能够维持组织在一定水平上持续运行，而项目可以实现组织运营水平的提升。
在过程中打败自己，在结果上打败对手。
项目不是在结束时失败，而是在开始时失败。
如果你不知道要到哪里去，给你张地图也没有用！
自我欣赏的是艺术，他人接受的才是商品
对事要硬、对人要软！
毫无规划的唯一好处是，失败于你而言纯粹是个意外，而此前你全然不会为此感到惴惴不安。
定义问题比解决问题更重要。无论做什么，都要定义目的。从目的定义入手，制定问题陈述。如果跳过这一步，你就可能为一个错误的问题浪费时间。
现实会有诸多情况导致不能完全按照计划进行,但是计划会为你提供做事的优先顺序,这样会让你事半功倍
做正确的事,并正确的做事
看见即降伏
项目中可能出错的事通常要比可能变好的事更多，这就是无情的事实。
优秀的管理者不是善于冒险，而是善于控制风险
没有完美的个人，只有完美的团队。人无完人，但团队却可以是完美的团队！
管理总是在“可行”与“合理”之间做选择;管理者追求的是“可行”而不是“合理”，管理者说的话应该是以有效与否来区分，而不是以真假来区分
当你要对你所说的话进行测量并将它们以数据的形式表达出来时，说明你清楚了一些事情；但是如果你不能以数据的形式将其表达出来，说明你对它的了解还很少
无法评估就无法管理
工具
项目任务书
简要说明项目要做什么、如何做，和当项目结束时能给企业提供什么样的商业价值。
RAM-责任分配矩阵
明确团队中的职责任务责任工具
权利-利益方格
分析项目相关人的工具-方法
商业论证-进行可行性评估
验证任务是否要做
结构化思维
用于进行问题问题
SMART 法则
用于设定明确的合理目标
项目生命周期
阶段化管控提升项目的成功率
WBS-工作分解结构
将工作拆分,然后显性化,结构化,标准化
CPM-关键路径法
直方图
跟踪计划表
智商情商矩阵
我读书前预留的问题
为什么读这本书
达成读书目标
提升自己的项目管理能力
在日常工作生活中去使用项目管理
想要解决什么问题
知道项目管理理论脉络体系
知道学习方法
知道微吼工作中的应用场景
项目工具
项目生命周期
结构化思维方式
SMART 原则
如何做
这本书主要想表达什么?
我从书中收获了什么
书中我觉得最有价值的话
读书的目标
想要更多的去理解项目管理
学会在日常工作中使用项目管理的方法去进行项目管理和把控
书籍中的问题
0 条评论
下一页
