(13.1.1)PMBOK之一(附):组织系统及其影响,过程资产环境因素与项目经理
PMI的PMP考试有一个重要条件,假设考生已经了解一些初步的管理学知识,因此了解组织治理、组织结构和组织文化也很重要。
任何一个项目都必须在一定的组织环境中开展,项目管理工作要受组织环境的影响。
项目成功的必要条件:
- 如何定义项目成功——商业文件
- 给谁做——相关方(见<(13.1.3.10)PMBOK之三:十大知识领域之相关方管理>)
-
项目运行环境
- 事业环境因素
- 组织过程资产
- 组织系统
- 组织治理
- 管理要素
- 组织结构
- 如何进行过程控制——生命周期法(上章中描述)
- 什么流程做——项目管理过程(下章中描述)
- 谁领导做——项目经理
项目工作说明书
项目工作说明书包括业务需要、产品范围描述、战略计划。
商业文件
- | 商业论证 | 效益管理计划 |
---|---|---|
描述 | 从商业角度提供必要的信息,决定项目是否值得投资 | 对项目执行过程中的效益进行管理,使得效益能够最大化 |
实例 | 可以从经济角度确定是否项目会给组织带来收益 | 规定测量和度量项目效益的时间,和使项目效益最大化的方法 |
- 项目发起人通常负责项目商业论证文件的制定和维护。项目经理负责提供建议和见解,使项目商业论证、项目管理计划、项目章程和项目效益管理计划中的成功标准相一致,并与组织的目的和目标保持一致
- 在项目启动前完成编写
- 商业文件的修改,不应该由项目经理或者变更委员会控制。它作为超脱项目范围的文件,不属于项目文件,应该由发起人负责修改和再次审核批准
A.1 商业论证
需求评估通常是在商业论证之前进行,包括了解业务目的和目标、问题及机会,并提出处理建议。在需求评估后完成撰写, 需求评估结果可能会在商业论证文件中进行总结
项目商业论证指文档化的经济可行性研究报告,用来对尚缺乏充分定义的所选方案的收益进行有效性论证,是启动后续项目管理活动的依据
- 商业论证列出了项目启动的目标和理由。它有助于在项目结束时根据项目目标衡量项目是否成功。
- 商业论证是一种项目商业文件,可在整个项目生命周期中使用。
- 在项目启动之前通过商业论证,可能会做出继续/终止项目的决策
- 发起人负责制定和维护,PM可参与提供建议,但不可以修改
商业论证可能包括(但不限于)记录以下内容:
- 业务需要
- 形势分析
- 推荐方案
- 评估标准
根据 PMP 考试大纲,项目经理在启动过程组的第一项工作就是开展项目评估( Project assessment),来确认商业论证报告中的结论仍然是合理的(没有过时的)
A.2 项目效益管理计划
如果说商业论说明的是项目可以为组织带来效益,那么效益管理计划会说明达成这些效益的时间点,并且度量其是否达成
项目效益管理计划描述了项目实现效益的方式和时间,以及应制定的效益衡量机制
- 制定效益管理计划需要使用商业论证和需求评估中的数据和信息
- 项目效益管理计划的制定和维护是一项迭代活动。它是商业论证、项目章程和项目管理计划补
充性文件。 - 项目经理与发起人共同确保项目章程、项目管理计划和效益管理计划在整个项目生周期内始终保持一致。
它描述了效益的关键要素,可能包括(但不限于)记录以下内容:
- 目标效益(例如预计通过项目实施可以创造的有形价值和无形价值;财务价值体现为净现值);
- 战略一致性(例如项目效益与组织业务战略的一致程度);
- 实现效益的时限(例如阶段效益、短期效益、长期效益和持续效益);
- 效益责任人(例如在计划确定的整个时限内负责监督、记录和报告已实现效益的负责人);
- 测量指标(例如用于显示已实现效益的直接测量值和间接测量值);
- 假设( 例如预计存在或显而易见的因素);
- 风险(例如实现效益的风险)。
A.3 项目成功的标准
确定项目是否成功是项目管理中最常见的挑战之一。
时间、成本、范围和质量等项目管理测量指标历来被视为确定项目是否成功的最重要的因素。最近,从业者和学者提出,确定项目是否成功还应考虑 项目目标的实现情况
有可能一个项目从范围/进度/预算来看是成功的,但从商业角度来看并不成功。这是因为业务需要和市场环境在项目完成之前发生了变化
项目成功可能涉及与组织战略和业务成果交付有关的其他标准。这些项目目标可能包括(但
不限于):
- 完成项目效益管理计划;
-
达到商业论证中记录的已商定的财务测量指标。这些财务测量指标可能包括(但不限于):
- 净现值 (NPV);
- 投资回报率 (ROI):年平均利润/投资本金;
- 内部报酬率 (IRR):大于行业收益率则项目可接受;
- 效益成本比率 (BCR):越大越好,1.0时表示不赔不赚;
- 达到商业论证的非财务目标;
- 完成组织从“当前状态”转到“将来状态”;
- 履行合同条款和条件;
- 达到组织战略、目的和目标;
- 使相关方满意;
- 可接受的客户/最终用户的采纳度;
- 将可交付成果整合到组织的运营环境中;
- 满足商定的交付质量;
- 遵循治理规则;
- 满足商定的其他成功标准或准则(例如过程产出率)
A.4 效益评估方法
A.4.1 现值PV与净现值NPV
- 将来时点上的现金折现后的资金金额为现值
- 净现值PV:按一定的折现率,将每年的收入折现到同一时点上累加
- FatureValue = PresentValue*(1+R)^n 其中R为年利率
- 净现值>=0.项目可接受;否则,不可接受
A.4.2 投资回报率 (ROI)和回收期 (PBP)
- 回收期 (PBP):现金流累积后为0的时间,也就是回本的时间;
- 投资回报率 (ROI): 年平均利润/投资本金;
需要注意的是,上述计算都不考虑资金的时间价值和回收期后的情况
A.4.3 内部报酬率 (IRR)
使得NPV=0时的利率;
大于行业收益率则项目可接受;
A.4.4 机会成本与沉没成本
机会成本是指为了得到某种东西而所要放弃另外一些东西的最大价值
沉没成本是指由于过去的决策已经发生了的,而不能由现在或将来的任何决策改变的成本
一、组织系统对项目的影响
组织是为实现短期经营目标和长期战略目标而协同工作的一群人的组合。
系统是各种组件(人员、部门等)的集合,可以实现单个组件无法实现的成果
- 系统通常有组织管理成负责建设和优化
- 系统和组件都能优化,但是不能同时优化
- 系统呈现非线性响应(人月神话)
1.1 组织治理与项目治理
组织治理属于事业环境因素,项目治理属于组织过程资产。
1.1.1 组织治理
组织治理是有一系列的规则所组成的框架, 在组织治理的指导与支持下,运用组织结构和组织文化来协调员工的行为。
其中,组织结构是有型的硬规则,而组织文化是无形的软规则。
- 组织治理由董事会执行
- 确保相关方的责任得以落实
1.1.2 项目治理
项目治理是组织为项目建立的高级别的指导、支持、监督与控制框架:
- 由项目指导委员会执行。项目指导委员会相当于项目中的董事会,由各主要干系人代表和独立成员构成。
- 项目治理是组织治理与项目管理的桥梁,项目经理及开发团队必须在项目治理框架下开展项目管理。
【图#1.1.1】
项目治理的层次高于项目管理,是高层次的项目决策机制,用来规定应该由什么人在什么时候遵循什么程序作出与项目有关的重大决策,譬如确定与执行项目成功标注,协调干系人的重大利益矛盾
在有效的项目治理框架的支持下,项目就能获得组织高管的指导和支持、外部干系人的支持以及宏观层面的监控,增大成功的概率。
项目治理的内容 见PMBOK指南
- 项目治理框架提供管理项目的结构、过程、角色、职责、终责和决策模型
- 明确角色、职责和职权
- 识别、升级和解决项目期间问题的流程
- 阶段关口或审查流程、以及项目决策流程
- 超出项目经理职权的决策制定
- 超出项目经理权限的变更的审批流程
- -开展项目知识管理并吸取项目经验教训的过程
1.2 组织结构形式
在不同的组织结构中,项目经理的权限不同
考题可能是关于项目经理与职能经理的权限划分,也可能是关于各种组织形式的优缺点;
考题涉及项目未点名在什么组织下运行,默认就是在矩阵式下运行
考题没点明与那种类型比较,默认就是与职能型的比较
比较 | 职能式组织 | 弱矩阵组织 | 平衡矩阵组织 | 强矩阵组织 | 项目式组织 | 备注 |
---|---|---|---|---|---|---|
适用条件 | 规模小、技术简单、专业单一 | 规模中等、跨专业 | 同上 | 同上 | 规模大、技术复杂、多专业,需要最大限度控制资源的(譬如工期很紧,全部成员全职为项目工作) | |
权力划分 | 完全在职能经理 | 主要在职能经理 | 项目、职能经理平等 | 主要在项目经理 | 完全在项目经理 | |
项目预算的控制 | 职能经理 | 职能经理 | 项目、职能经理平等 | 项目经理 | 项目经理 | |
PM角色 | 兼职 | 兼职 | 全职 | 全职 | 全职 | |
员工占比 | 全部为职能员工 | 不超过1/3的全职为项目工作 | 1/2全职为项目工作 | 超过2/3全职为项目工作 | 全部全职为项目工作 | 以上描述非硬性指标 |
最大优点 | 成员兼顾职能和项目工作 | 允许兼职,资源利用率高 | 同上 | 同上 | 项目经理权利充足,对资源有管理权 | 备注 |
最大缺点 | 无全职员工,容易忽视项目工作 | 沟通与管理复杂,需要大量规章制度 | 同上 | 同上 | 资源重复配置,资源利用效率低 | 备注 |
ps:紧密式矩阵并不属于矩阵式模式,实际上它也不属于我们常规的 3项分组,它只是把项目团队成员集中办公。 注意不要与“弱矩阵组织|平衡矩阵组织|强矩阵组织”混淆
I 职能式组织(直线式组织)
【图#1.1.2】
最传统的部门模式,依据职能、或者专业来划分部门。
没有单独的项目部,项目只有放在各职能部门中进行。项目经理及所有项目成员都是兼职做项目,项目经理基本没啥权利,甚至不能称为“项目经理”;
也叫直线式组织,主要通过上级对下级的直线领导来完成工作。这也导致了不适合复杂、跨专业的项目,因为一个职能部门完成工作后必须交给上级领导, 上级领导再转给下个部门,以此类推。不仅消耗时间,同时各个职能部门之间无法整合。
举个例子吧,就像国家的管理,分为警察部,军队部,如果协同为一个缉毒项目工作,那么警察部只能内部协同并完成任务后汇报给警察部长,然后警察部长交由军队部长去继续处理,一般警察部和军队部的成员之间不能相互交叉
比较项 | 优点 | 缺点 |
---|---|---|
同一职能部门内的沟通、协调和决策比较容易 | 与其他职能部门没有沟通,容易忽视其他职能部门的利益 | |
项目成员兼顾职能工作和项目工作 | 职能工作容易优先于项目工作 | |
同专业的人在一起工作,容易提升技术 | 不利于跨专业、跨部门的合作 | |
职能部门为员工提供职业发展平台,发展路径清晰 | 没有全职的项目经理、项目经理无权利,无法建立项目管理职业路径 |
II 矩阵式组织
【图#1.1.3】
矩阵式组织同时利用职能式组织和项目式组织的优点,并尽量避免他们的缺点。
主要特点,项目经理没有管理项目的全权,项目经理控制项目,但不控制资源:
- “借资源”,即许多项目成员从职能部门借来的
- “两个老板”,即项目团队成员同时接受项目经理和智能经理的领导
举个例子吧,就像小说里看的TVB公司,其实按照职能划分部门形成了 灯光部门、服装部门、化妆部门、编剧部门、导演部门等,然而开拍一部电影的时候,制片人作为项目经理,从各个职能部门“借人”组成一个项目团队,从而开始拍摄。
- 弱矩阵组织
- 平衡矩阵组织
- 强矩阵组织
比较项 | 优点 | 缺点 |
---|---|---|
有专职的项目经理 | 项目经理的正式权利不足 | |
各职能部门参与项目,项目得到支持 | 职能部门之间为了争夺项目利益而开展权利斗争 | |
双线领导有利于方案优化 | 双领导间的权利斗争 | |
允许项目成员兼职,提高人力资源利用率 | 项目成员有两个老板,导致分心和报告工作质量增加 | |
有利于横向沟通 | 结构复杂,需要大量规章制度 | |
项目完工后,成员有家可归 | 有退路的项目成员可能对项目不够忠诚 |
III 项目式组织
【图#1.1.4】
整个组织按照项目划分为一个个项目部门。
现实生活中很难有完全的项目式组织,毕竟任何组织都或多或少都需要职能部门(财务部、行政部等)的支持,但是从单个项目角度来看,可以采用项目式的组织,即一个自成体系的、拥有全部所需成员的团队。
举个例子吧,腾讯的各个项目部:XX游戏部,腾讯管家部,等等;sxf本身应该也算是项目式组织,ad\at等都是根据项目进行了划分
xx | 优点 | 缺点 |
---|---|---|
项目组织结构简单,边界明确,权责清晰 | 因无法共享资源,而出现项目之间的重复配置资源 | |
项目经理具有全部权利 | 职能部门不参与项目,甚至对项目方案排斥 | |
全部项目成员全职工作,忠诚度高,决策速度快 | 项目结束后后员工无家可归,导致收尾阶段人心涣散 | |
有利于建立项目管理的职业路径 | 成员因完全关注项目工作,而失去与外界同行交流的机会,影响专业技术的发展 |
IV 复合型组织与项目联络员、协调员
- 项目联络员与项目协调员是对职能式组织(或者弱矩阵)环境下对项目经理的描述。
-
项目联络员基本没啥权利,不能做决定也不能强迫决定的执行,只是充当项目成员的助手。
- 譬如如果在职能式组织下完成跨专业的项目,那么项目必须被拆分为“依据各部门职能的,在各部门之职能范围内”的子项目,由各个职能部门独立去完成,如果需要沟通,就需要“项目联络员”。
- 项目协调员有一定的权利,可向高层汇报
-
项目联络员基本没啥权利,不能做决定也不能强迫决定的执行,只是充当项目成员的助手。
实际上,现实中往往不会单单采用以上讨论的某一个组织形式,而往往是混合使用。
【图#1.1.5】
- 混合型
- 转型期时
- 执行需要不同技术知识的多个小项目最有效的组织类型
- 简单系统型
- 个系统的的或简单的组织结构意味着组织内的工作小组是灵活的。无论在组织中扮演什么角色,人们都在一起工作,而项目经理对项目资源可能没有什么权威
- 多部门结构
- 一个组织有多个部门,每个部门内部都是一个只支持该部门的IT组织。IT项目是在一个部门内启动的,而不是整个组织中的所有部门
1.3 管理要素
管理要素是指组织根据组织治理框架和组织结构类型所确定的关键管理职能
关键职能部门或一般管理原则包括(但不限于)以下部分,组织将这些管理要素的绩效分派到选定的员工身上。这些员工可能在不同的组织层级上执行这些职能。
- 基于专业技能和可用性开展工作的部门;
- 组织授予的工作职权;
- 工作职责,开展组织根据技能和经验等属性合理分派的工作任务;
- 具有纪律性的行为(例如尊重职权、人员和规定);
- 统一领导原则(例如针对一组活动只能有一个计划或一个领导人,以及相同的目标);
- 组织的总体目标优先于个人目标;
- 支付合理的薪酬;
- 资源的优化使用;
- 畅通的沟通渠道;
- 在正确的时间让正确的人使用正确的材料做正确的事情;
- 公正、平等地对待所有员工;
- 明确工作岗位的安全职责;
- 确保员工安全;
- 允许任何员工参与计划和实施;
- 保持员工士气
1.4 项目管理办公室PMO
- PMO不同于为了专个项目而组建的临时项目部或项目组织
- 项目审计:检查项目过程中的相关活动是否符合规定要求,一般是全局审计,包含风险、质量、采购
- 考试中,要假设PMO已经存在于组织中,除非题干中明确说明不存在
PMO负责制定和贯彻标准化的项目管理工作流程与规章制度,协调所辖各项目对资源、工具、技术和方法的分享。
作用可以多样化,譬如制定制度,对项目管理知识的指导培训,选派项目经理等,尤其是建立、维护和管理“项目管理系统”。
项目管理系统是项目管理成熟的标志之一,包含了管理项目的一系列工具、技术、方法、资源与程序。
一般而言,如果设立了PMO,那么PMO经理就是项目经理的直接上级。
从PMO对项目施加的控制程度来看,可以分为从小到大的三种:
- 支持型。 PMO仅为项目提供行政支持服务,如提供模板方法、过去项目经验等。对项目没有控制权力,如PMO无权要求项目使用某个模板,或者必须符合PMO设定的相关规定;
- 控制型。 PMO在提供支持的基础上,有权对项目施加一定的控制,有权要求项目服从PMO的相关规定;
- 指令型。 PMO直接管理项目,对项目目标的实现负责
PMO地位可以是从最低级的行政级办公室到最高的战略级PMO的任意级别。大型集团中往往存在不同级别的PMO。
PMO可以授权“非从属战略”的例外项目
二、事业环境因素
事业环境因素是指能够影响项目的但项目团队成员无法控制的任何内外部因素,可能来自组织执行团队内部,也可能是外部。
项目管理中的任何过程都受事业环境因素的影响,虽然PMBOK没把环境因素列入某些过程的输入
项目管理一般不会对事业环境因素进行更新,只有“获取资源”、“建设团队”和“管理团队”三个过程会导致更新(涉及资源可用性、员工能力)
2.1 执行组织的内部因素:
- 组织治理
- 组织结构与组织文化
- 地理位置分布:组织是集中在一起还是分散在各地,对于“人力资源管理”和“沟通管理”有影响
- 基础设施,包括硬件和软件
- 人力资源库。 组织成员的名单、岗位、技能水平、培训记录等
- 人事管理制度。 对于“人力资源管理”有影响,譬如如果制度规定了只能内部请人,不许外包
- 工作授权系统
- 已有的沟通渠道
- 组织的风险态度和风险承受能力
- 项目管理信息系统
- 项目工作条件:对项目质量有重大影响
- 项目产品运行条件:对项目质量有重大影响
- 资源可用性(获取资源)
- 员工能力(建设团队\管理团队)
2.2 执行组织的外部因素:
- 地方、国家甚至国际的政治文化氛围
- 政府的法律规定
- 行业指南或标准
- 行业或学术研究资料
- 市场情况
- 潜在供应商情况
- 相关组织发布的合同范本
- 财务影响因素
- 当地对采购的特别要求
- 商业数据库
- 除执行组织以外的干系人的风险态度和风险承受能力
- 相关行业或领域的项目管理知识体系
- 来自组织外部的项目工作条件和项目产品运行条件
三、 组织过程资产
- 资产是指能够未来带来收益的任何事物。
- 组织过程资产会影响项目的每个过程,即便PMBOK没把环境因素列入某些过程的输入
- 在实际中,组织过程资产 与 事业环境因素相互交叉。 譬如组织的人力资源政策既可以是组织过程资产 也可以是 事业环境因素;再譬如一项政策或规定,如果你利用它,它就是资产;如果没利用它,就是环境。
组织过程资产是来自“项目执行组织”的,正式或者非正式的 政策、过程、程序、模板或者知识库(数据库)等。
- 组织过程资产是用于帮助项目成功,也是组织中最重要的无形资产
- 在项目实施中,团队成员有责任对组织过程资产进行必要的更新
*1.3.1 “过程与程序类”————组织过程资产的第一类别:政策、过程、程序、模板
该部分的更新通常不是项目工作的一部分,由PMO或其他职能部门完成。
- 具体的政策或工作标准。
- 例如人力资源政策,健康与安全政策,安保与保密政策、质量政策、采购政策和环境政策(可以是事业环境因素,也可以是组织过程资产)
- 工作指南。
- 例如标准化流程指南,沟通指南等
- 各种流程。 例如变更控制程序,工作授权程序,风险控制程序
- 各种模板。
- 例如员工奖励证书模板
- 项目管理计划模板、项目文件、项目登记册、报告格式、合同模板、风险分类、风险描述模板、概率与影响的定义、概率和影响矩阵,以及相关方登记册模板等
- 预先批准的供应商清单和各种合同协议类型
- (如总价合同、成本补偿合同和工料合同)
这里的程序并不是指软件开发行业中的软件程序,而是指处理某件业务的流程顺序。
*1.3.2 “共享知识库”————组织过程资产的第二类别
在项目的生命周期中,要经常地更新组织过程资产;在项目阶段的结束,必须更新组织过程资产
- 各个项目的项目文档
- 项目经验教训文档
- 配置管理知识库
- 财务数据库
- 问题与缺陷数据库
- 过程测量数据库
- 供应商数据库
一般而言,XX程序都是属于组织过程资产,XX系统一般属于事业环境因素
四、项目经理
项目经理是受项目执行组织委派,领导团队实现项目目标的个人,是项目的唯一责任点
项目团队负责执行项目计划并且创造可交付成果,项目领导并不是唯一负责执行项目计划的角色,项目经理可能不会直接创造可交付成果
项目执行组织:任何员工直接参与的某项目
工作的组织都是项目执行组织。一个项目可能有多个项目执行组织,某个项目执行组织都有一个项目经理。类似但不限于业主、承包商等名称。
项目经理为项目执行组织实现项目目标,在组织结构中起着承上启下的作用,是联系组织高管(战略制定者)和项目团队(战术执行者)的桥梁。
为了有效的管理项目,项目经理需要了解技术,具有一定的技术能力,但不需要是技术专家。应该能把握全局,掌控项目整体。
- 项目经理的角色职责
- 制定项目管理计划及相关子计划
- 使项目使用符合进度和预算要求
- 识别、检测和应对风险
- 准确及时的报告项目指标
4.1 项目经理作为整合者
项目经理最重要的角色就是 整合者, 项目整合管理由项目经理负责, 且只能由项目经理负责整合所有其他知识领域的成果,并掌握项目总体情况,项目经理必须对整个项目承担最终责任。虽然其他知识领域可以由相关专家(如成本分析专家、进度规划专家、风险管理专家)管理,但是项目整合管理的责任不能被授权或转移。
项目经理在项目管理中的角色是多方面的,其中最重要的角色是“整合者”。
-
作为整合者,项目经理必须看到项目的“大局图”,确保项目全局的利益。项目经理必须:
- 通过与项目干系人主动、全面的沟通,来了解他们对项目的需求
- 在相互竞争的众多于系人之间寻找平衡点
- 通过认真、细致的协调工作,来达到各种需求之间的平衡,实现整合
-
项目经理在项目整合上的双重角色
- 对上:与项目发起人携手合作,既要了解战略目标并确保项目目标和成果与项目组合、项目集以及业务领域保持一致
- 对下:指导团队关注真正重要的事务并协同工作
-
项目经理整合的三个层面
- 过程层面:每个项目管理过程都不是独立的,整合相关作用的项目管理过程
- 认知层面:人际关系技能和其他管理项目的方式整合,以及项目管理知识各领域的整合
- 背景层面:项目背景和所处企业环境的整合
-
整合复杂想的来源
- 系统行为:组成部分与系统之间的依赖关系
- 人类行为:不同个体和群体之间的相互作用,动态变化
- 不明确性:出现问题、缺乏理解或造成困惑引发的不确定性
4.2 项目经理的能力
-
项目管理技术:核心
- 与项目、项目集和项目组合管理特定领域相关的知识、技能和行为,即角色履行的技术方面。
- 领导力。
- 指导、激励和带领团队所需的知识、技能和行为,可帮助组织达成业务目标
- 战略和商务管理。
- 关于行业和组织的知识和专业技能,有助于提高绩效并取得更好的业务成果,同时确保项目能始终与组织战略、商业目标一致
4.2.1 技术项目管理技能
- 重点关注所管理的各个项目的关键技术项目管理要素。简单来说就是随时准备好合适的资料。最主要的是:
- 项目成功的关键因素;
- 进度;
- 指定的财务报告;
- 问题日志
- 针对每个项目裁剪传统和敏捷工具、技术和方法。
- 花时间制定完整的计划并谨慎排定优先顺序。
- 管理项目要素,包括(但不限于)进度、成本、资源和风险
4.2.2 战略和商务管理技能
- 项目和战略的关系
- 目标和目的的关系
- 项目的优先级
- 与项目发起人、团队、主题专家制定合适的项目交付策略
- 商业环境变化对项目影响和评估的能力
4.2.3 领导力技能
- 谈判
- 抗压
-
沟通
- (研究显示,顶尖的项目经理投入有 90% 左右的时间是花在沟通上
- 解决问题
- 批判性思维
- 人际关系技能
上图中错误的点:领导在于“做正确的事”,管理在于“正确的做事”
领导是指创建愿景,使员工看到愿景,并带领员工朝愿景前进。管理是指把困难的事情做成功
4.2.3.1 人际关系技能
- 领导力。确定和传达目标,带领下属朝目标努力的能力。
- 团队建设。使一群人为共同目标而协同工作的能力。
- 激励。基于别人的需求,采取措施,使别人去做你希望他做的事的能力。
- 沟通。让别人了解自己的想法以及让自己了解别人的想法的能力。
- 影响力。在没有正式权力的情况下,让他人服从自己的能力。
- 决策。在两个或更多的备选方案中做出合理选择的能力。
- 政治和文化意识。了解项目所在地的政治氛围和文化氛围的能力。
- 谈判。与他人谈判并达成协议的能力。
- 建立信任。使自己与他人之间相互信任的能力。
- 冲突管理。识别和解决冲突的能力。
- 教练技术。指导他人,帮助他人提高工作能力的能力,使他人从“没有能力做某事”到“有能力有某事”
4.2.3.2 领导力风格分类
- 放任型
- 例如,允许团队自主决策和设定目标,又被称为“无为而治”
- 交易型
- 关注目标、反馈和成就以确定奖励,例外管理
- 强调奖励和惩罚
-
服务型
- 强调关注他人的成长、学习、发展、自主性和福祉,为团队成员提升上述服务为主要内容
- 是敏捷方法的重要一环,在研发设计类醒目中表现良好
- 变革型
- 通过理想化特质和行为、鼓舞性激励、促进创新和创造,以及个人关怀提高追随者的能力*
- 魅力型
- 强调个人魅力
- 例如,能够激励他人;精神饱满、热情洋溢、充满自信;说服力强
- 交互型
- 例如,结合了交易型、变革型和魅力型领导的特点
- 例如,结合了交易型、变革型和魅力型领导的特点
领导风格可以粗略地划分为
- 命令型。简单地告诉别人做什么、怎样做与什么时候做,适用于能力差、愿意听话(有热情)的人
- 参与型。上下级共同参与决策过程,其中上级可以起支持、协调、教练、指导和决策等作用
最后做决定的可以是
上级——咨询型(邀请别人出主意,但决定由自己做)
下级参与者——支持型(给下级提供支持,由下级做出决定)
上下级共同——合意型(通过讨论,集体决策) -
授权型。只告诉下属所要求的结果,授权下属很大的工作自主权
- 可以根据给予工作指导的多少及考虑下属感受的程度,把领导风格划分成:
- 命令式。指导多,不考虑下属感受。
- 推销式。指导多,考虑下属感受。
- 参与式。指导少,考虑下属感受。
- 授权式。指导少,不考虑下属感受
管理风格可以粗略地分为:
- 独裁式。由老板(领导)严格控制、独自决断,比较容易出错。适用于规模小、风险低的项目。
- 民主式。是一种参与式管理,是项目上用得最多的一种管理风格。团队成员参与决策,能较好地调动成员的积极性,提高他们的责任心。
- 放任式。对员工放任自流,进行松散式管理。适用于高度创新的工作以及高度自觉并能力很强的人
团队生命周期中: 形成-命令指导型,震荡-教练型,规范-参与型,成熟-授权型,解散-命令指导型
xx | 优点 | 缺点 | 适用项目 | 适用人员 |
---|---|---|---|---|
独裁式 | 决策快 | 容易出错 | 低风险、范围清楚 | 能力差、愿意服从 |
民主式 | 集体参与 | 决策慢 | 大多数项目 | 能力强、有参与愿望 |
放任式 | 充分发挥员工创造力 | 易失去控制 | 高度创造性的项目,如科研 | 能力强、自觉性高 |
4.3 项目经理的权利
- 职位权(有时称为正式的、权威的、合法的,例如组织或团队授予的正式职位);
- 专家权(例如拥有的技能和信息、经验、培训、教育、证书);
- 参考权(例如因为他人的尊重和赞赏,类似的项目经验,获得的信任);
- 包含朋友等熟人关系
- 信息权(例如收集或分发的控制)
- 情景权: 在某种情境下,具备的权力。 譬如架构师请假,然后又有重要任务,pm作为架构师参与项目。
- 奖励权(例如能够给予表扬、金钱或其他奖励);
- 惩罚权(例如给予纪律处分或施加负面后果的能力);
- 施加压力的权利(例如限制选择或活动自由,以符合预期的行动);
- 个性魅力(例如参与人际交往、联系和结盟);
- 关系权(例如参与人际交往、联系和结盟);
- 迎合权(例如运用顺从或其他常用手段赢得青睐或合作)
- 愧疚权(例如强加的义务或责任感)
- 说服权(例如能够提供论据,使他人执行预期的行动方案);
回避权(例如强加的义务或责任感)
-
来自职位的权力有:
- 正式权力。也叫合法权力或职位权力,直接来自项目经理的职位。项目经理的正式权力往往不足,除非在项目式组织中。
- 奖励权力。是奖励下属的权力,与正式权力相连。
- 惩罚权力。也叫强制权力,如果下属不按要求行事,就要受处罚,与正式权力相连。
弱矩阵或者职能结构中的项目经理,没有正式的权利,最好是通过专家权利来管理和约束成员
-
与项目经理的人身依附在一起的权力有:
- 专家权力。作为项目管理方面的专家而产生的权力。别人愿意服从你,是因为你有项目管理方面的专业知识与专业技能。
- 参照权力。来自项目经理的性格魅力和沟通能力,以至于别人愿意以你为榜样,愿意向你看齐,愿意以你为参照物。
- 包含朋友等熟人关系
-
信息权利
- 既与职位有关,也与人身有关的一种权力,是信息权力。你掌握了某种信息,而具有的权力
权力种类 | 权力来源 | 最易导致 | 好坏顺序 | 对谁有效 |
---|---|---|---|---|
正式权力 | 项目经理职位 | 下属的服从 | 一般 | 下属 |
奖励权力 | 项目经理职位 | 下属的忠诚或服从 | 较好 | 下属 |
惩罚权力 | 项目经理职位 | 下属的抵抗 | 最坏 | 下属 |
专家权力 | 项目经理个人 | 他人的忠诚 | 最好 | 与本专业相关者 |
参照权力 | 项目经理个人 | 他人的忠诚 | 较好 | 任何人 |
信息权力 | 职位和个人 | 他人的服从 | 一般 | 信息需求者 |
4.4 冲突
新观念 | 旧观念 |
---|---|
合理的冲突是有益的 | 冲突都是不好的,必须避免发生冲突 |
只要有界面,冲突就是不可避免的 | 冲突是由人的个性或者领导者的无能引起的 |
要通过找到问题的根源,依靠冲突的当事人自己解决(领导可以协调) | 必须要把冲突的当事人分开 |
冲突可以依靠冲突双方的直接领导来解决 | 冲突必须依靠高层领导的介入才能解决 |
冲突管理的策略和流程写在,《规划资源管理》过程的“团队章程”中
4.4.1 冲突的原因
-
冲突的原因
- 项目有许多干系人,他们对项目的要求和利益总是或多或少地存在矛盾
- 项目的时间、成本等限制条件造成的项目资源不足
- 项目经理的权力不足,对项目成员没有足够的控制力
- 项目经理需要从职能经理那里借资源
-
按常见程度排序,最常见原因排在第一位
- 资源稀缺。导致人们对资源的争夺
- 进度优先级排序。对各项活动的重要性有不同看法
- 个人的工作风格差异。各人所喜欢的工作风格不同
- 个人的性格差异。人与人之间的个性不同
4.4.2 冲突的解决
-
如果冲突太多、太严重,就是不良冲突了。可以通过以下几种办法来减少不良冲突:
- 充分的沟通
- 为项目分配合理的时间和预算,提出合理的范围和质量要求
- 工作的权责清楚、不相互交叉
- 使工作任务充满趣味性和挑战性
-
解决冲突的原则
- 开诚布公
冲突双方开诚布公地讨论冲突事项 - 对事不对人
用对事不对人的态度对待冲突 - 着眼于团队和项目
以最有利于团队和项目的方式解决冲突 - 着眼于现在和未来
从过去的阴影中摆脱出来,寻找有利于现在和未来的解决方法 - 当事人自己解决
冲突最好由当事人自己尽早解决,他们的直接上级可以协助
- 开诚布公
-
解决冲突的常见方法
- 合作或解决问题。
冲突当事人用合作的态度,把问题摆到桌面上来,直面问题,寻求把不同的观点或方案综合起来,得到双方都乐意接受的观点或方案。
这是“双赢”的方法 -
妥协或调解
冲突双方都做出一些让步,强调双方,这也是一种有效的办法。由于重点放在双方都做出让步上
所以可以理解为“双输”的解决方法 -
缓和、缓解或包容
强调双方的共同点而不是差异点(求同存异),以便解决问题,冲突某方做出一些让步,强调单方,
是“双赢”的方法(但只是部分解决冲突) -
撤退或回避。
冲突中的一方或双方从冲突中撤退出来(往往是暂时的),如把问题留到以后去解决;
是“双输”的方法 - 强制或命令。
一方强制另一方,这是最坏的解决方法
是“赢一输”的方法
- 合作或解决问题。