002 第1章 极简项目管理基础
站在实施方(乙方)的角度,项目过程就是“绑架客户上贼船的过程”。当然,如果站在委托方(甲方)的角度,项目过程则是“逐步移交主动权的过程”。
如果把培养孩子当成一个生命周期来看
项目在被分成多个阶段后,能更清楚地展现其规律性,人们也更容易把控项目的发展,提高项目成功的可能性。
通过划分阶段对工作按照时间进行分类,也更容易搞清楚每个时期的主要矛盾是什么。
可以减轻痛苦、降低不确定性,从而增强项目经理成功的信心
缺图
042 2.1.3 延伸:疯狂的项目之六拍、四没、三边、只谈 六拍:拍脑袋、拍肩膀、拍胸脯、拍桌子、拍屁股、拍大腿
四没:没问题、没关系、没办法、没资源
三边:边设计、边实施、边修改
只谈:项目初期只谈成本、项目中期只谈进度、项目后期只谈质量
【金句】如果你不知道要去哪里,给你张地图也没有用
046 2.2.1 自我欣赏的是艺术,他人接受的才是商品 这三个工作到底需要多长时间才能完成呢?哪种组合方式更好呢?
SMART法则
050 2.2.3 跳一跳、够得着:基于愿望的目标必将破产 目标建立在愿望大大超过能力的基础上,团队成员只能被迫接受。但是,他们不是发自内心地认可这个目标,于是在后续工作中他们不会努力去实现这个目标,而是用行动来证明你们定的目标是错的。
人们对项目团队的目标或交付能力失去信心,于是人们不再把精力投入项目实施中去,转而去设置下一轮的基于愿望的目标
(1)“狼来了”和“掩耳盗铃”从此相伴相生。
(2)会干的往往搞不过会说的。
(3)自欺欺人的激励方法。
(4)奖励任劳任怨却惩罚灵活应变。
就以福特如果得到的两个目标(“培养出能够跑得更快的马” 和“造出汽车”),后者显然在现有认知下是够不着的,但是如果没有这个目标,就很难产生颠覆性的创新
理论基础就是行动学习的理论
(1)你想要,拿钱来。客户的期望总是比能交付的要多。区分需要与想要的一个方法是:客户愿意付钱的是其真正需要的,否则就不是。
(2)多关注已知的真实行为。少关注客户说什么,多关注客户的行为。很多时候,客户对自己说的话既没有认真思考,更不用付出代价。
(3)时刻记住项目是一个业务过程。遇到问题以后不要仅仅解决问题的本身,还要去解决问题所在环境。 客户要买一个电钻,是因为他缺一个电钻吗?不是,是因为他想在家里的墙上打一个洞。那客户真的想要一个洞吗?不是,是因为他想在墙上钉一个钉子。那客户真的是想要在墙上钉一个钉子吗?不是,他只是想挂一幅画。而想要挂一幅画,客户只需要一个粘钩就可以了。
切忌“鸵鸟心态”:答应与否都不能算错,但明知道客户有这种需要,却不加以明确,让这个问题“悬”着就是一个严重的问题
如确实有问题存在而且躲不掉,假如争吵不可避免,那么早吵也会比晚吵好。一方面,问题在早期解决成本会比较低,另一方面,尽早暴露问题,吵完了大家也就可以安心地做事了。
目标和需求是需要确认的
真正想要的并非他们的签字,而是希望他们借此机会认真考虑项目问题
058 2.3.1 关键是要管理与平衡相关方的期望和利益 项目管理者的两个重要职责:管理人的期望;平衡人们的不同利益,并确保项目团队以专业和友好的态度与他们打交道。
061 2.3.2 用权力–利益方格分析和管理相关方 (1)收集相关人员的个人资料(姓名、从属单位和职务)。
(2)评估每个人对项目的期望和态度。
(3)确定每个人的权力和利益分值(在规定范围内的分值,如1~10分)。
(4)使用权力–利益方格(见图2-14)分析每个人的影响。
(5)基于每个人在权力–利益方格中的位置,制订管理策略。
如果你喜欢一个人,就让他去当项目经理,因为这使他有机会驱动组织变革;如果你恨一个人,也让他去当项目经理,因为十有八九他会被失败的项目“毁”了
为确保每个人都能承担起自己对组织的责任,必须做好三落实: 任务落实:每个任务都必须有明确的负责人
人员落实:任何一个人,不能让其只享有权利而不承担义务
组织落实:确保组织中的制度、流程、工具、技术协调一致,并有统一的激励措施
责任分配矩阵图(缺图)#方法
068 2.5.1 项目章程是项目团队与组织的契约
069 2.5.2 编制项目任务书的重点在于达成共识 项目启动阶段最重要的成果并不是项目任务书本身,而是在编写项目任务书的过程中所获得的洞察力和达成的共识。#观点
(1)可测量的项目目标和相关的成功标准。
(2)项目的总体要求。
(3)概括性的项目描述。
(4)项目的主要风险。
(5)总体里程碑进度计划。
(6)总体预算。
(7)项目审批要求。
(8)委派的项目经理及其职责和职权。
(9)发起人或其他批准项目任务书的人员的姓名和职权。
重要的节点必须要举行仪式,要引起领导和相关部门的重视,让项目团队更有凝聚力#观点
074 2.6.1 项目不是在结束时失败,而是在开始时失败、 尽量营造项目的工作氛围,例如张贴项目总体进度图,制作项目的标志图,或者有意识地更换一下项目成员的工位,让他们坐得更近一些。#方法
可以让每个人想一句话,表达一下自己要如何努力来保证整个团队的绩效。#方法
当事情真实发生的时候,也就是固定的“程序”触发条件产生时,对方的固有“程序”便会失去原有效用。这在心理学中被称为“免疫效应”。(示范:你可以这样和你的家人沟通:“我知道你听了我的想法之后会感到生气,但是我真的很想要那部越野车!”)#观点
(1)沟通方式、频率、内容及格式。(2)项目管理者的权力,即项目奖惩权力、人事调度权力和项目方案的决定权力等。(3)甲方责任、需求提供、调研配合和业务指导等。(4)变更处理的流程、文档、权力等。(5)团队合作模式、风格、出勤、考核标准、争议解决等。(6)项目开发方的各个部门的义务及责任。
以上信息不一定都以项目制度的形式公布出来,如果映射到制度上,应该包括#方法: (1)项目例会制度。(2)绩效考核制度。(3)汇报制度。(4)文档流程。(5)变更管理制度等。
#观点省略了项目启动会的项目,其过程往往很混乱,很多人对项目的配合不够,协同性很差,项目目标也就无法按计划实现。
#观点如果可能,要大张旗鼓,千万不要像鬼子进村——“悄悄地来,悄悄地走”。
#方法为了完美地启动项目,建议用结构化方法实施项目启动会。 缺图:表2-5 启动会议10问;表2-6 启动会议10个需要注意的细节
阿蒙森团队率先到达南极点之后,又顺利地返回了原来的基地。而斯科特团队没有获得荣誉,更糟糕的是,他们返回的路上天气非常恶劣,不断地有人掉队,最后没有一个人生还。斯科特团队不但没有完成首先到达南极点的目标,而且全军覆没,这已经是生与死的区别了。
一个是有计划的(物资准备充足、风险预估等),另一个是随心所欲的
#观点布利斯定理:用较多的时间为一次工作做计划,做这项工作所用的总时间就会减少(不可能完全按照计划进行,但是计划会为你提供做事的优先顺序,这样会事半功倍)
#案例南极探险案例补充:阿蒙森团队对午餐的特别安排(省去了生火做饭的时间和能源浪费)
#观点管理项目是个复杂的过程,计划充当着这个过程的地图。该地图必须足够详细,使项目经理能据此决定下一步做什么,进而保证工作在规定时间、预算、范围内能保质保量地完成。
087 3.1.3 “如来十掌”为制订计划提供了抓手 #案例张斌带领团队为客户进行无线通信基站的建设,他们的项目需要于三天后在野外施工。天气预报显示,三天后暴风雨将至,而张斌的团队并没有防雨设备。现在该怎么办?
(1)“如来十掌”的第一个问题:做什么(范围、需求)
(2)“如来十掌”的第二个问题:什么时候做(时间、进度)
(3)“如来十掌”的第三个问题:花多大的代价做(成本、费用)。
(4)“如来十掌”的第四个问题:做到什么程度(质量)可以接受。
(5)“如来十掌”的第五个问题:需要什么资源(团队、采购或外包)。
091 3.2.1 隐性工作显性化,显性工作结构化,结构工作标准化 #观点WBS及其词典是组织的重要无形资产。在同一企业中,尽管所有项目各不相同,但有许多项目在较高层次上是相似的。如果能够花费些精力去编制涵盖这些同类型项目的标准WBS,那么这样的WBS就成了企业的一种无形资产。
#方法4种常见的WBS类型(没有最佳方法,合适的就是最好的。建议在项目启动时每种方法都要考虑一下,从中选择一个可以清晰定义项目工作的方法来分解项目。) (1)按组成分解
(2)按功能用途分解
(3)按生命周期分解
(4)按地域/组织分解
树形层次结构更适用于向高层管理者汇报工作或沟通
而表格形式更适合项目团队成员自己使用,因为可以在表格右侧增加更多细节备注,这有利于团队协作,但看起来更复杂。
拿到一个项目后,对于一个具体的目标可以从两个视角考量:“怎么完成”和“交付什么”
当选择了一个视角后,下一步又可以分别从这两个视角进一步分解,直到满足“易于管理”和“足够详细”两条标准为止(WBS的最底层组件一定是“交付什么”,即都是具体的交付成果。)
(1)MECE法则:相互独立,完全穷尽
(2)信息透明原则:指可以估算工作包的工作量以及完成工作包所需的时间、成本和验收标准。
(3)80小时原则:单个工作包的完成时间不应超过80个小时
(4)独立责任原则:单个工作包只分配给一个单独的人
(5)滚动式规划原则:近细远粗,近多远少
(6)不同层次原则。不同可交付成果可以分解到不同的层次
(7)一个上级原则。每个下一级组件有且只有一个上级组件
缺图:判断WBS好坏的检查表
#观点WBS被认为是现代项目管理的重要基石: WBS首先解决的就是项目中“做正确的事”的问题,只有明确了“做正确的事”,“正确地做事”才有基础
#方法看见即降服:看见即降伏的原理对项目管理极有价值,利用这个原理,通过可视化、透明化工具对项目过程进行管控。在项目过程中,让项目所有相关人员一起来创建WBS,并在WBS中使用不同色块标明每个工作包的状态,还可以把各项工作的责任人标明,同时给出各项工作包的时间计划。
缺图
#点评和思考团队内部的WBS配合表
109 3.3.1 让进度估算走向科学
114 3.3.2 关键路径法:进度计划与网络技术
121 3.3.3 案例:路易十四的地牢
125 3.4.1 核心在于花多少钱对应完成多少工作量 #观点将预算与实际完成工作量做比较,表明了项目的进度状况;将实际成本与实际完成工作量做比较,表明了项目的成本花费状况。将实际花费与预算比较,只能得出花钱速度的快慢,对项目并无实际价值。
#案例T公司为某项目A制订了4个月的实施计划,第二个月月底的财务数据如表3-10所示。T公司财务部经理黄兴拿到该项目的数据,向公司总经理高静汇报:该项目运行得不错——费用节约了! 分析缺图 图3-36 第一个月工作情况的三种可能情景
129 3.4.2 抓住项目预算的关键
132 3.5.1 优秀的管理者不是善于冒险,而是善于控制风险 #观点优秀的管理者不是善于冒险,而是善于控制风险
#观点风险管理的悖论:如果风险管理很好,风险就不会发生,可是风险不发生怎么证明是因为风险管理得好呢?
#方法做好对已知风险的管理,在识别后,我们需要以下数据进行风险分析。 (1)风险事件发生的概率。(2)风险真的发生后,可能产生的后果的范围与影响。(3)每个结果的可能性。
#方法通常首先查询风险的影响评级(见表3-13),然后查询概率影响矩阵(见表3-14)来评估每个风险的重要性和所需的关注优先级。 缺图:表3-13 风险影响评级[插图] 表3-14 概率影响矩阵
#观点系统的意志决定了粒子做事情的阻力系数,按系统的意志做事是阻力最小的方式
#观点元素会继承系统的意志 2.符合系统意志的元素获益最大
#案例狱警实验是心理学史上最著名、最有争议性的实验之一,曾经多次被改编成电影。狱警实验告诉我们:角色变了,人也跟着改变。
#观点被误解的蝴蝶效应。人们心目中蝴蝶效应的一个形象写照:从小到大的一堆柱子排在一起,推倒最小的一根柱子就会产生连锁反应,最终把右侧的花瓶砸碎。谁谁砸碎了花瓶?是整个系统和结构
#观点总之,如果把一堆炸药放在一起,只要一个火星就能引起爆炸,那如果真的爆炸了,也不应该埋怨那个火星,而应该反思为什么炸药这么危险的东西不好好管理。火星总会来的,小骨牌总要倒下,蝴蝶总要振动翅膀。应该怪罪的是设计系统结构的人,而不是系统中的元素。
#观点把系统结构搞好了,我们就可以安心专注于正常的工作。
·高层感觉中层能力不行、素质不够,就替中层思考。
·中层感觉基层能力不行、素质不够,就替基层思考。
·基层没事干,也感觉高层领导能力不行,就替高层思考。
152 4.2.2 矩阵型组织
它对企业的资源利用程度不够。项目资源被各项目组独占,当项目需要这些资源的时候固然能及时获得,但当项目不需要这些资源时却很难从项目组释放。
当项目遇到技术难题需要调用组织更多力量时,这种形式也颇为不便。
155 4.2.4 组织结构应与组织发展阶段相适应 #观点无数实践证明,成功的企业从诞生、职能化、规范化到逐步引入项目化,有着类似的历程和发展阶段,这个过程没有捷径。
158 4.3.1 选择合适的团队成员
#观点项目团队的组织方式有很多种,但基本上可以归为外科手术式、交响乐队式、爵士乐队式和足球队式四种。最适合的就是最好的 1.外科手术式项目团队(所有人都围绕着主刀医生,主刀医生就是整个团队的核心。)
2.交响乐队式项目团队(在演奏过程中,指挥其实是一个精神领袖,团队成员都全情投入,陶醉在美妙的乐曲中。)
3.爵士乐队式项目团队(有一个灵魂人物,但是不脱产,所有人都参与演奏)
4.足球队式项目团队(有明确的分工,但是不规定在何时、由谁、在何位置、做什么,一切要随时进行调整)
164 4.3.3 顺利走过团队的生命期
168 4.4 善协调:项目管理是一个极具挑战性的工作 169 4.4.1 项目与部门间的冲突
174 4.4.2 项目间的冲突:“牛人”争夺战
178 4.4.3 影响项目的治理与人际因素
184 5.1 采数据:用数据而不是用感觉管理项目 186 5.1.1 用直方图展示和理解数据
190 5.1.2 用散点图寻找数据之间的关系
192 5.1.3 用帕累托图定位需要关注的重点
195 5.1.4 用控制图实现过程管控
靠客户逼
靠检查控
靠过程保
靠设计防
靠文化治
#观点QA 和 测试的区别:QA的重点在于流程度量和过程改进,而不仅仅是问题测试
#观点名副其实的QA小组或QA经理具备以下特质。(QA工作对人的要求非常高,熟悉质量体系仅仅是基本条件,更需要很高的综合素质、业务能力和项目经验) (1)有权有钱,能够对团队成员提供必要的培训。
(2)有权处理客户的投诉,推动客户投诉的处理。
(3)有能力制订过程改进计划,并根据过程改进计划进行组织结构调整、人员配置以实施过程改进。
(4)有能力、有权力通过多个项目来度量过程改进是否有效。
警察:及时发现和报告项目中的问题
教师:对项目成员进行过程和规范的培训以及在过程中进行指导等
医生:QA人员可以承担收集、统计、分析度量数据的工作,对项目过程进行诊断,帮助分析原因,开处方
#观点项目复盘中常常看到“加强过程管控,要求团队成员自检、互检,严格按程序要求实施,加强培训”等,1次、2次、5次、10次……有时连自己都麻木了,不是吗?——能做什么呢?就是坚持一贯的原则了。
#方法解决问题的万能公式(行动之前要计划,计划之前要分析,分析之前要信息) 缺图
#观点很多的加班现象都是项目管理不当造成的
#方法5分钟站立会议(5 minutes stand-up meeting) 是实践中项目管控的好办法。会议时,项目团队成员在固定时间(如每天上午8:30—8:35)、固定地点,每天站着围在一起,轮流主持、相互通报,每人回答以下3个问题。(1)昨天我做了什么?(2)现在我遇到了什么困难?(3)今天我计划做什么?5分钟站立会议既可以推动项目进展、跟踪项目问题,往往也可以提升团队对项目的责任感,起到团队建设的作用。
224 5.3.3 要想避免混乱,必须在沟通上下功夫
225 5.4.1 唯一不变的就是变化
#方法管理变更的九阴真经 (“九阴真经”人为地增加了变更的摩擦系数,让变更变得困难,客观上降低了变更的频率) 第一步,当有人提出变更时,首先要评估信息的准确性,确认项目变更事实。
第二步,提供变更申请的书面记录。
第三步,分析变更对范围、进度、成本、质量等诸方面的影响。
第四步,沟通变更影响,确认是否取消变更。
第五步,针对变更请求,提出相应解决方案。
第六步,查阅审批权限,选择合适人员对变更进行审批。
第七步,召开变更控制会议,批准或否决变更。
第八步,根据对变更请求的审批状态,与相关人员进行沟通。
第九步,指导与执行变更相关工作,跟踪变更执行状态。
233 5.4.3 对变更的管控是项目管理水平的体现 如你顶不住压力同意了变更,这在事实上会给客户一个信号:变更是可以被接受的,只要对项目团队施压就行。
#方法利用框架效应(面临收益时人们会小心翼翼,选择风险规避;面临损失时人们甘愿冒风险,选择倾向风险偏好,以损失为导向进行沟通往往更有效。总之,忠告不如警告!) #案例有点玄乎不太好理解总体就是说,要把不变更的收益、变更的损失清晰的对比出来
243 第6章 收尾:慎终如始,好戏杀青
272 第7章 好的项目管理者为何如此稀缺
293 第8章 打造面向业务的系统化思维
314 第9章 极简项目管理,说起来容易做起来难
325 附录A 赋予逻辑意义的数字
326 附录B 一个大型学术会议的WBS
327 附录C 一个办公室装修的WBS