产品经理
互联网
项目管理
推荐课程
average > 0 ? $model->average . '分' : '10.0分' ?>

To B软件系统的项目管理实战工作坊

David Wang

前华为 项目经理、内部教练

【职称及荣誉】
产品研发管理与项目管理专家,团队管理和过程改进专家,业界知名讲师和咨询师
NPDP、PMP、CSM、CSL等项认证资质,6 sigma黑带
中国软件协会(CSPIN)专家委员会委员
中软协2014年度“中国软件工程年度人物”7位获奖者之一
中国软件行业峰会(TID)第1届大会出品人,第3届、第4届大会执行主席
“柔性软件流程体系(DPD)”创始人
《软技能——代码之外的生存指南》译者(人民邮电出版社,2016年曾经连续占据京东“计算机与网络类”图书热销榜5个月)、《软件开发者职业发展终极指南》译者(人民邮电出版社,2019年出版)

【工作经历及专业背景】
王老师拥有18年的软件研发、项目管理与质量管理经验,曾先后供职于华为技术有限公司、国际商用机器技术有限公司(IBM Solution and Services Co.)、中国移动无线数据研发中心和QAI(外资全资咨询顾问公司)等多个企业,担任过项目经理、质量总监、咨询顾问等多个职务。他深厚的理论知识、丰富的咨询经验以及犀利而又不失亲和力的咨询风格使得他近年来在业界屡获殊荣

【擅长领域】
王老师善于规划和建设覆盖市场、研发、部署、维护支持等覆盖全价值链和全业务的管理体系,对各种方法论和模型了解清楚,运用自如;善于将多种模型、标准或方法论之间进行系统的整合,以“因地制宜注重落地”的方式协同运用来解决企业实际存在的问题,而并不拘泥于某一个特定的模型/标准。另一方面,凭借长期的研发管理实践工作中积累的丰富经验,他尤其善长于在工程与技术管理、项目管理方面的培训、引导和咨询工作,对一线的员工(项目经理、需求分析人员、架构设计人员、设计开发工程师及测试工程师)有很强的亲和力,使他们能够很快的体会到管理所带来的乐趣和益处。

【职称及荣誉】 产品研发管理与项目管理专家,团队管理和过程改进专家,业界知名讲师和咨询师 NPDP、PMP、CSM、CSL等项认证资质,6 sigma黑带 中国软件协会(CSPIN)专家委员会委员 中软协2014年度“中国软件工程年度人物”7位获奖者之一 中国软件行业峰会(TID)第1届大会出品人,第3届、第4届大会执行主席 “柔性软件流程体系(DPD)”创始人 《软技能——代码之外的生存指南》译者(人民邮电出版社,2016年曾经连续占据京东“计算机与网络类”图书热销榜5个月)、《软件开发者职业发展终极指南》译者(人民邮电出版社,2019年出版) 【工作经历及专业背景】 王老师拥有18年的软件研发、项目管理与质量管理经验,曾先后供职于华为技术有限公司、国际商用机器技术有限公司(IBM Solution and Services Co.)、中国移动无线数据研发中心和QAI(外资全资咨询顾问公司)等多个企业,担任过项目经理、质量总监、咨询顾问等多个职务。他深厚的理论知识、丰富的咨询经验以及犀利而又不失亲和力的咨询风格使得他近年来在业界屡获殊荣 【擅长领域】 王老师善于规划和建设覆盖市场、研发、部署、维护支持等覆盖全价值链和全业务的管理体系,对各种方法论和模型了解清楚,运用自如;善于将多种模型、标准或方法论之间进行系统的整合,以“因地制宜注重落地”的方式协同运用来解决企业实际存在的问题,而并不拘泥于某一个特定的模型/标准。另一方面,凭借长期的研发管理实践工作中积累的丰富经验,他尤其善长于在工程与技术管理、项目管理方面的培训、引导和咨询工作,对一线的员工(项目经理、需求分析人员、架构设计人员、设计开发工程师及测试工程师)有很强的亲和力,使他们能够很快的体会到管理所带来的乐趣和益处。

课程费用

5800.00 /人

课程时长

3

成为教练

课程简介

一般地,我们定义“B端系统”为:客户(付钱购买项目产出的产品/服务的人士)与用户(项目产出的产品/服务的最终使用者)不是同一批人的系统/产品。典型的B端软件系统包括:企业信息化/数字化系统、政务信息化/数字化系统。
根据我们的经验,B端系统的项目管理其复杂度远高于C端系统(客户和用户是同一批人士)。高复杂度主要体现在以下几个方面:
一句话需求——“照着XX系统的XX功能做就好了……”;
一页纸项目——“按照国发第XXXX号文件精神……”;
只讲了半句话——只有“我需要一个XXX系统”而没有“我要该系统干什么”——只有What to do,缺失Why to do;
“业务流程”与“系统流程”的边界不清晰;
“用户期望”与“项目建设范围”的边界不清晰;
新老系统之间的衔接、渗透与融合,各个项目之间的关联、协同与博弈
本课程以项目生命周期为明线(启动——>策划——>监控/执行——>结项)、以“相关方期望值管理”为暗线(识别相关方期望值以确认项目的交付价值、管理相关方期望值以确定项目的范围与需求、分析为实现相关方期望值所需要的“关键活动项”以策划项目、与相关方有效沟通项目的进展状况……)深入浅出的阐述To B软件系统的项目管理的特殊点、关键流程、关键要素与关键节点(Key Point);介绍项目管理过程的常见问题及其解决方案与最佳实践。

目标收益

1、以项目的生命周期5大过程组(启动、策划、监控、执行、结项)为明线,以“相关方期望值管理”为暗线串联起软件项目的范围管理、进度管理、沟通管理、相关方管理、风险管理……等多项主题;
2、本课程全程采用讲练结合的“工作坊”模式,即:各个学员小组各自使用1个实际项目场景,完成6项内容垂直关联的Workshop(工作坊)实战演练。互动式教学、沙盘式演练、海量案例分析,带给学员“身临其境”般临场感觉;丰富的模版、Checklist展示又可以让学员学“即插即用”的“点穴式”项目管理优秀实践。最大限度的避免程式化理论介绍,最大限度的提升学员实际操作能力;
3、【特别建议】本课程用于企业内训时,可根据贵公司的业务领域特点、过程体系与产品研发生命周期对本课程进行完全的定制化。特别地,我们强烈建议直接采用贵公司实际的产品(已上线的或者正在开发的)作为学员分组演练案例,以提升学员“身临其境”的体验,最大化地实现培训效果向实际工作技能的转化与落地,从而将课堂内容转化成为培训学员“即插即用”式的实际操作能力。

如何围绕相关方期望值分析并识别项目的目标、确定项目的交付价值(而不是一句简单的“按时保质的完成任务”来做搪塞);
如何围绕项目的目标,有效挖掘与分析项目需求,有效识别与控制项目的范围;
如何使用“因果关系图”进行项目可行性分析、确认项目的建设目标,从而准确地识别出项目的“独特性”,实现对项目管理活动的“点穴式”管理;
如何识别项目与项目之间的依赖关系,从而有效解决跨项目间“耦合度”的问题
如何实现项目“可视化”的监控方法;
如何与各个相关方展开有效沟通项目的进展状况,以及项目的风险与问题;
项目结束了就曲终人散了,经验、教训散落一地无人整理——然而对于组织来说,这些经验和教训都是珍珠和钻石。如何让项目经理们做到“慧眼识珍”?

培训对象

本课程针对项目经理、项目管理办公室(PMO)负责人、研发部门经理、测试部门经理、测试项目经理、研发/测试骨干等涉及项目管理的所有相关人员设置。

课程大纲

1.What & Why——软件项目和软件项目管理的概念 ●热身练习:角色扮演游戏
1)过程:3人一组完成一个Mini项目的实施过程
2)讲评:通过演练来认识“项目的成功从哪里来”的命题,认识软件项目管理的常见误区——需求不清晰、缺少可视化监控手段以及缺乏可操作的交付质量保障手段 ……
●什么是To B的软件系统?什么是To C的软件系统?为什么关于前者的项目管理复杂度远高于后者?
●什么是项目的相关方?项目各个相关方的期望值对于项目会有哪些影响?
正确认知软件项目管理的第一要素——我们交付的是项目的价值,而不是项目本身!
1)BBR模型,也就是各个相关方对于一个To B软件项目交付价值的最高要求——“帮忙不惹事”
2)BBR具体应用案例剖析
●项目管理全过程其实就是要做好“四件事情——
1)识别相关方的期望值
2)识别项目的交付价值
3)实现并验证关键相关方的期望已然实现
4)交付项目,以便于让关键相关方真切感受到项目的交付价值
●项目管理面临的重大挑战——高层管理的问题、项目经理的问题、项目组成员的问题
●你准备好了吗——作为项目经理,在项目的整个生命周期中你将承担怎样的角色与职责?
1)你愿意做怎样的项目经理,“包工头”还是“工段长”,“二极管”还是“三极管”?
2)你能讲的清楚吗?你自己项目的“独特性”特征是什么?
3)你能讲的清楚自己项目的“目标”是什么?注意:不要仅仅只以一句“按时保质的完成任务”作为搪塞,但是并不清楚或者没有关注到自己的项目会给各个相关方(客户、用户、高层管理者、项目团队成员……)所带来的价值……
●我们是一个怎样的项目?
1)各个学员分组选定自己小组的演练项目场景;
2)各个学员分组确定自己小组的演练项目的生命周期;
3)如何判断本小组的项目“成功”? 判定“成功”的条件是什么——注意我们说的是“项目成功”,而非“项目交付”
2.未有项目之前——项目启动过程 ●项目启动的主要工作——分析项目的需求,确定项目的范围
●现实总不如看起来那么美好之一——划定项目范围时的两大常态(“客户讲不清楚需求”、“需求总是处于变更当中”)
●现实总不如看起来那么美好之二——你所接收到的从业务维度发过来的需求通常存在哪些问题:
1)“业务流程”与“系统流程”的边界不清晰
2)“用户期望”与“系统功能”“的边界不清晰
3)只有“系统能做什么”,没有“系统做的有多好”
4)最容易被忽略的一类用户——Administrator
●三种不同详细程度的“需求”:白云级需求、风筝级需求和场景级需求
●不明觉厉——如何从项目的需求中抽象得到项目的目标,从而识别项目给客户/相关方带来的价值
●讲得出“价值”是极好极好的——如何通过分析和分解相关方的期望值来识别并确认项目的目标?
●如何有效的引导客户对于项目目标的期望值?为什么说过高的引导相关方相关方的期望值与“挖个坑把自己埋起来”无异?
【实例剖析】如何从“相关方期望值”抽象得出项目的“建设目标”
●以终为始——从项目的“建设目标”入手、分析项目的关键活动项
●如何应对多个项目之间的“依赖性”问题?
1)范围以及进度关系上的依赖问题及其解决方案
2)人力资源关系上的依赖问题及其解决方案
●项目开工会——项目组成员一定要聚餐的”两个会议”之一
【分组演练1】各分组根据选定的项目场景,分析项目的相关方,明确定义:
1)项目有哪些相关方;
2)每一个相关方对本项目的期望、要求和/或约束条件是什么;
3)在启动阶段的需求调研活动中,针对不同相关方的调研重点分别是什么;
4)用一句话总结概括项目的“建设目标”或“交付价值”
3.运筹帷幄——项目策划过程(上) ●进度、质量、成本、范围——项目的4大目标之间是协调的关系,没有哪个目标天生高人一等
●什么是一份“好”的项目计划?如何让项目计划更像“项目的”计划(如何避免项目计划千篇一律)
【案例分析与讨论】象当年写好一篇记叙文一项的写好项目计划——项目计划的“六要素”(时间、地点、任务、起因、经过、结果)
●是非曲直话估算:估算不是掐指一算,估算其实就是为了寻找合适的“y=f(x)”表达式
1)常用估算技术介绍——概略估算的扑克牌法、精确估算的功能点分析(FPs)
2)还能更好吗——A公司和B公司的企业级估算模型
●项目估算Vs.项目计划:估算、目标与承诺之间的区别与联系
1)故所以:估算的真正作用,并不单纯在于“拿出一个数值”,而在于“利用多轮估算的结果调整项目的目标”
2)案例分析与讨论:估算既不是计划,计划也不是估算
●估算的“不确定性锥”作用、重估算与重计划的阈值
【分组演练】继续上一个演练的结果,各小组根据已经确定的相关方,从相关方的期望值出发,识别各个项目的关键目标与关键成功要素。
4.运筹帷幄(中)——项目策划过程之识别项目的风险 ●风险管理的意义与过程
●风险识别的“一招鲜”——“相关方期望值冲突矩阵”分析风险
●风险类型,以及实际案例介绍:
1)项目计划阶段的常见风险
2)需求分析活动时的常见风险
3)设计和构建时的常见风险
4)验证与交付时的常见风险
5)协调管理多个项目时常见的风险x
●描述风险的“三位一体”: 风险的背景、风险发生的必要条件、风险所可能带来的危害
【案例分析】风险发生的条件、风险的危害以及风险的扩展描述
●描述风险的“三位一体”: 风险的背景、风险发生的必要条件、风险所可能带来的危害
【案例分析】风险发生的条件、风险的危害以及风险的扩展描述
●分析风险的“三大禁忌”:不假思索的风险发生的原因归结为1)“项目成员的能力”、2)“客户的原因”、或者3)“沟通不畅“;
【案例分析】如何通过风险的持续监控而将风险管理有机的融入项目管理中
【结论】唯有将风险管理融入项目管理中,风险管理才能真正的发挥作用
●风险的管控措施,以及风险的规避措施和应急计划是否有“针对性”的检验标准:是否可以将管控措施写在WBS里
●制定规避措施和应急计划的最大禁忌:无限制加班
【实例介绍】使用“风险跟踪矩阵” 监控风险
●风险管理的实践与经验
【分组演练3】识别并记录项目Top5的风险,并且制定相应的应急计划和/或规避计划,并且与相关方沟通项目的风险及其管控措施
5.运筹帷幄——项目策划过程(下) ●策划项目团队管理的利器
1)资源日历——特别适合于同时管理多个项目
2)RACI矩阵
●项目计划如何分层:里程碑/版本——阶段/迭代——活动——任务项
●规定动作+自选动作——如此让项目的计划更像“项目的”计划
●制定WBS(WBS,Work Breakdown Structure)的“三大纪律八项注意”
案例分析与讨论之1:WBS要至少要包含“名词”和“动词”两个部分;
案例分析与讨论之2:WBS要包含“规定动作”与“自选动作”;
案例分析与讨论之3:WBS需要细化到何种程度?
●关键路径分析——项目经理的管理焦点、项目目标的影响因素
1)解耦——细致切分任务项,解耦任务项与任务项之间的依赖关系
2)关键路近分析
3)使用甘特图
4)如果需要“赶工”,那该怎么办?
●分组演练4:综合运用前3个演练的结果,各小组制定本项目的WBS,包括:
1)确定并定义项目的各个里程碑与交付件;
2)确定并定义项目的WBS,并且在WBS的内容中体现出前两个演练的成果
3)确定并定义与各个外部相关方沟通时的方法方式、频率与内容
4)识别项目的风险,并制定相应的规避措施和/或以及计划
5)上述内容的文档化
6)项目计划的评审,由讲师扮演客户、其他小组组长扮演高层管理者
6.决胜千里——控制过程 ●举例:项目执行与监控过程中的常见问题,特别是同时协调管理多个项目的时候
●如何有效跟踪监控项目的关键活动项?需要追溯到项目的“相关方期望”
秉承二八原则实施“有的放矢”的监控
●项目监控过程——(会议+报告)X用数据说话 = 准确了解项目的状态
●项目的度量与分析——有效实现“用数字说话”的不二法门
○度量与分析的目的:1)客观了解项目的进展状况;2)有效沟通项目的紧张状况
○举例:“内向型”度量项与“外向型”度量项
○小结:定性做结论,定量做支撑
●在有效度量和分享的基础上,实现项目的可视化管理
项目参数,以及应对多个项目齐头并进时的分层实施与分层控制
●燃尽图与看板——使用“同行压力”到极致的体现
●如何召开一次“有用”的项目组例会?
○首先,甄别一下:开会就是为了解决问题吗?
●“So what”是监控项目状态的最关键内容
○反面实例介绍与研讨
○正面实例介绍与研讨
●变更控制:偏差申请、变更评估、变更实施与跟踪
【分组演练5】假定项目组已经达成按照项目计划中定义的第一个里程碑,已经按照项目计划完成中各项工作。这时,讲师将根据实际情况给各个小组设定不同的“突发事件”情景——
1)“突发事件”可能包括但不限于:领导视察,客户参观,多项目之间协作不畅……等,由讲师临机设置;
2)各学员小组需使用度量与分析手段评估项目的当前进展状况,运用可视化手段撰写相关报告,然后派出代表发布演练成果
7.余音绕梁——项目收尾过程 ●你的项目应该如何结项:“曲终人散”还是“余音绕梁”?
●Do not punish people, punish process(不要惩罚个人,惩罚流程)——什么是“流程化”的思维方式?
1)“系统思考、过程优化”的实际案例剖析::正例——某型仓储物流管理系统从“需求调研”进化为“需求开发”、“需求规划”的过程
2)“系统思考、过程优化”的实际案例剖析::反例——某公司系统集成类项目失败后的处置方式
3)他山之石,可以攻玉:某公司关于组织级知识库建设的最佳实践
4)小结:别人吃一堑,我长一智——如何从项目的失败中总结教训,并且使用“流程”这一系统性方式加以推广应用
●系统思考,过程优化之从项目的成功中总结经验,并且使用“流程”这一系统性方式加以推广应用
●系统思考、过程优化之“等待100年获得顿悟” Vs. “利用结构化方法用15分钟解决问题”;
●系统思考、过程优化之 “为特定的问题寻找特定的答案”Vs.“将特定的问题上升为通用的问题域”
●系统思考、过程优化之 从“发现问题——>解决问题”的应激性思维进化为“发现问题——>分析问题——>解决问题”的系统性思维
○举例:经验教训总结
●系统思考、过程优化——项目管理必须具备的基本思维方式
【分组演练6】假定项目可以正常结项,请各个小组撰写“项目总结报告”,召开项目总结会议,向客户(由讲师扮演)及高层管理者(由其他小组组长扮演)项目的当前状况,包括:项目的经验与教训总结,以及这些经验与教训哪些可以作为改进组织级管理流程的输入?
8.培训总结——To B软件系统的项目管理的真理与谎言 ●本次实战演练活动讲评
●总结与串讲::软件项目管理的生命周期——项目管理从相关方期望值的识别到相关方期望值的验证&确认
1)相关方的期望值构成项目需求的最重要来源
2)针对相关方期望值的分析和分解形成项目关键目标与关键活动——项目计划的主干要素
3)计划的协调::估算、目标和承诺——相关方期望值的平衡
4)项目的可视化监控——相关方期望值达成情况的过程分析
5)风险管理 = 相关方期望值的矛盾与冲突的管理
6)项目总结——如何更好的管理相关方及其期望值
●To B软件系统项目管理的2项真理
●To B软件系统项目管理的7个谎言
培训过程中将共享的模板/工具 1)“相关方期望值”登记表
2)项目启动计划模板
3)项目立项申请表
4)规模估算表格(基于Function Point方法)
5)规模估算表格(基于Web Page估算技术)
6)工作量估算表格(基于COCOMO II模型)
7)项目“一页纸”计划模板
8)相关方冲突矩阵(用于识别项目的风险)
9)项目风险与状态记录
10)项目需求跟踪矩阵(含横向跟踪)
11)接口关系跟踪矩阵
12)阶段总结报告(模板)
1.What & Why——软件项目和软件项目管理的概念
●热身练习:角色扮演游戏
1)过程:3人一组完成一个Mini项目的实施过程
2)讲评:通过演练来认识“项目的成功从哪里来”的命题,认识软件项目管理的常见误区——需求不清晰、缺少可视化监控手段以及缺乏可操作的交付质量保障手段 ……
●什么是To B的软件系统?什么是To C的软件系统?为什么关于前者的项目管理复杂度远高于后者?
●什么是项目的相关方?项目各个相关方的期望值对于项目会有哪些影响?
正确认知软件项目管理的第一要素——我们交付的是项目的价值,而不是项目本身!
1)BBR模型,也就是各个相关方对于一个To B软件项目交付价值的最高要求——“帮忙不惹事”
2)BBR具体应用案例剖析
●项目管理全过程其实就是要做好“四件事情——
1)识别相关方的期望值
2)识别项目的交付价值
3)实现并验证关键相关方的期望已然实现
4)交付项目,以便于让关键相关方真切感受到项目的交付价值
●项目管理面临的重大挑战——高层管理的问题、项目经理的问题、项目组成员的问题
●你准备好了吗——作为项目经理,在项目的整个生命周期中你将承担怎样的角色与职责?
1)你愿意做怎样的项目经理,“包工头”还是“工段长”,“二极管”还是“三极管”?
2)你能讲的清楚吗?你自己项目的“独特性”特征是什么?
3)你能讲的清楚自己项目的“目标”是什么?注意:不要仅仅只以一句“按时保质的完成任务”作为搪塞,但是并不清楚或者没有关注到自己的项目会给各个相关方(客户、用户、高层管理者、项目团队成员……)所带来的价值……
●我们是一个怎样的项目?
1)各个学员分组选定自己小组的演练项目场景;
2)各个学员分组确定自己小组的演练项目的生命周期;
3)如何判断本小组的项目“成功”? 判定“成功”的条件是什么——注意我们说的是“项目成功”,而非“项目交付”
2.未有项目之前——项目启动过程
●项目启动的主要工作——分析项目的需求,确定项目的范围
●现实总不如看起来那么美好之一——划定项目范围时的两大常态(“客户讲不清楚需求”、“需求总是处于变更当中”)
●现实总不如看起来那么美好之二——你所接收到的从业务维度发过来的需求通常存在哪些问题:
1)“业务流程”与“系统流程”的边界不清晰
2)“用户期望”与“系统功能”“的边界不清晰
3)只有“系统能做什么”,没有“系统做的有多好”
4)最容易被忽略的一类用户——Administrator
●三种不同详细程度的“需求”:白云级需求、风筝级需求和场景级需求
●不明觉厉——如何从项目的需求中抽象得到项目的目标,从而识别项目给客户/相关方带来的价值
●讲得出“价值”是极好极好的——如何通过分析和分解相关方的期望值来识别并确认项目的目标?
●如何有效的引导客户对于项目目标的期望值?为什么说过高的引导相关方相关方的期望值与“挖个坑把自己埋起来”无异?
【实例剖析】如何从“相关方期望值”抽象得出项目的“建设目标”
●以终为始——从项目的“建设目标”入手、分析项目的关键活动项
●如何应对多个项目之间的“依赖性”问题?
1)范围以及进度关系上的依赖问题及其解决方案
2)人力资源关系上的依赖问题及其解决方案
●项目开工会——项目组成员一定要聚餐的”两个会议”之一
【分组演练1】各分组根据选定的项目场景,分析项目的相关方,明确定义:
1)项目有哪些相关方;
2)每一个相关方对本项目的期望、要求和/或约束条件是什么;
3)在启动阶段的需求调研活动中,针对不同相关方的调研重点分别是什么;
4)用一句话总结概括项目的“建设目标”或“交付价值”
3.运筹帷幄——项目策划过程(上)
●进度、质量、成本、范围——项目的4大目标之间是协调的关系,没有哪个目标天生高人一等
●什么是一份“好”的项目计划?如何让项目计划更像“项目的”计划(如何避免项目计划千篇一律)
【案例分析与讨论】象当年写好一篇记叙文一项的写好项目计划——项目计划的“六要素”(时间、地点、任务、起因、经过、结果)
●是非曲直话估算:估算不是掐指一算,估算其实就是为了寻找合适的“y=f(x)”表达式
1)常用估算技术介绍——概略估算的扑克牌法、精确估算的功能点分析(FPs)
2)还能更好吗——A公司和B公司的企业级估算模型
●项目估算Vs.项目计划:估算、目标与承诺之间的区别与联系
1)故所以:估算的真正作用,并不单纯在于“拿出一个数值”,而在于“利用多轮估算的结果调整项目的目标”
2)案例分析与讨论:估算既不是计划,计划也不是估算
●估算的“不确定性锥”作用、重估算与重计划的阈值
【分组演练】继续上一个演练的结果,各小组根据已经确定的相关方,从相关方的期望值出发,识别各个项目的关键目标与关键成功要素。
4.运筹帷幄(中)——项目策划过程之识别项目的风险
●风险管理的意义与过程
●风险识别的“一招鲜”——“相关方期望值冲突矩阵”分析风险
●风险类型,以及实际案例介绍:
1)项目计划阶段的常见风险
2)需求分析活动时的常见风险
3)设计和构建时的常见风险
4)验证与交付时的常见风险
5)协调管理多个项目时常见的风险x
●描述风险的“三位一体”: 风险的背景、风险发生的必要条件、风险所可能带来的危害
【案例分析】风险发生的条件、风险的危害以及风险的扩展描述
●描述风险的“三位一体”: 风险的背景、风险发生的必要条件、风险所可能带来的危害
【案例分析】风险发生的条件、风险的危害以及风险的扩展描述
●分析风险的“三大禁忌”:不假思索的风险发生的原因归结为1)“项目成员的能力”、2)“客户的原因”、或者3)“沟通不畅“;
【案例分析】如何通过风险的持续监控而将风险管理有机的融入项目管理中
【结论】唯有将风险管理融入项目管理中,风险管理才能真正的发挥作用
●风险的管控措施,以及风险的规避措施和应急计划是否有“针对性”的检验标准:是否可以将管控措施写在WBS里
●制定规避措施和应急计划的最大禁忌:无限制加班
【实例介绍】使用“风险跟踪矩阵” 监控风险
●风险管理的实践与经验
【分组演练3】识别并记录项目Top5的风险,并且制定相应的应急计划和/或规避计划,并且与相关方沟通项目的风险及其管控措施
5.运筹帷幄——项目策划过程(下)
●策划项目团队管理的利器
1)资源日历——特别适合于同时管理多个项目
2)RACI矩阵
●项目计划如何分层:里程碑/版本——阶段/迭代——活动——任务项
●规定动作+自选动作——如此让项目的计划更像“项目的”计划
●制定WBS(WBS,Work Breakdown Structure)的“三大纪律八项注意”
案例分析与讨论之1:WBS要至少要包含“名词”和“动词”两个部分;
案例分析与讨论之2:WBS要包含“规定动作”与“自选动作”;
案例分析与讨论之3:WBS需要细化到何种程度?
●关键路径分析——项目经理的管理焦点、项目目标的影响因素
1)解耦——细致切分任务项,解耦任务项与任务项之间的依赖关系
2)关键路近分析
3)使用甘特图
4)如果需要“赶工”,那该怎么办?
●分组演练4:综合运用前3个演练的结果,各小组制定本项目的WBS,包括:
1)确定并定义项目的各个里程碑与交付件;
2)确定并定义项目的WBS,并且在WBS的内容中体现出前两个演练的成果
3)确定并定义与各个外部相关方沟通时的方法方式、频率与内容
4)识别项目的风险,并制定相应的规避措施和/或以及计划
5)上述内容的文档化
6)项目计划的评审,由讲师扮演客户、其他小组组长扮演高层管理者
6.决胜千里——控制过程
●举例:项目执行与监控过程中的常见问题,特别是同时协调管理多个项目的时候
●如何有效跟踪监控项目的关键活动项?需要追溯到项目的“相关方期望”
秉承二八原则实施“有的放矢”的监控
●项目监控过程——(会议+报告)X用数据说话 = 准确了解项目的状态
●项目的度量与分析——有效实现“用数字说话”的不二法门
○度量与分析的目的:1)客观了解项目的进展状况;2)有效沟通项目的紧张状况
○举例:“内向型”度量项与“外向型”度量项
○小结:定性做结论,定量做支撑
●在有效度量和分享的基础上,实现项目的可视化管理
项目参数,以及应对多个项目齐头并进时的分层实施与分层控制
●燃尽图与看板——使用“同行压力”到极致的体现
●如何召开一次“有用”的项目组例会?
○首先,甄别一下:开会就是为了解决问题吗?
●“So what”是监控项目状态的最关键内容
○反面实例介绍与研讨
○正面实例介绍与研讨
●变更控制:偏差申请、变更评估、变更实施与跟踪
【分组演练5】假定项目组已经达成按照项目计划中定义的第一个里程碑,已经按照项目计划完成中各项工作。这时,讲师将根据实际情况给各个小组设定不同的“突发事件”情景——
1)“突发事件”可能包括但不限于:领导视察,客户参观,多项目之间协作不畅……等,由讲师临机设置;
2)各学员小组需使用度量与分析手段评估项目的当前进展状况,运用可视化手段撰写相关报告,然后派出代表发布演练成果
7.余音绕梁——项目收尾过程
●你的项目应该如何结项:“曲终人散”还是“余音绕梁”?
●Do not punish people, punish process(不要惩罚个人,惩罚流程)——什么是“流程化”的思维方式?
1)“系统思考、过程优化”的实际案例剖析::正例——某型仓储物流管理系统从“需求调研”进化为“需求开发”、“需求规划”的过程
2)“系统思考、过程优化”的实际案例剖析::反例——某公司系统集成类项目失败后的处置方式
3)他山之石,可以攻玉:某公司关于组织级知识库建设的最佳实践
4)小结:别人吃一堑,我长一智——如何从项目的失败中总结教训,并且使用“流程”这一系统性方式加以推广应用
●系统思考,过程优化之从项目的成功中总结经验,并且使用“流程”这一系统性方式加以推广应用
●系统思考、过程优化之“等待100年获得顿悟” Vs. “利用结构化方法用15分钟解决问题”;
●系统思考、过程优化之 “为特定的问题寻找特定的答案”Vs.“将特定的问题上升为通用的问题域”
●系统思考、过程优化之 从“发现问题——>解决问题”的应激性思维进化为“发现问题——>分析问题——>解决问题”的系统性思维
○举例:经验教训总结
●系统思考、过程优化——项目管理必须具备的基本思维方式
【分组演练6】假定项目可以正常结项,请各个小组撰写“项目总结报告”,召开项目总结会议,向客户(由讲师扮演)及高层管理者(由其他小组组长扮演)项目的当前状况,包括:项目的经验与教训总结,以及这些经验与教训哪些可以作为改进组织级管理流程的输入?
8.培训总结——To B软件系统的项目管理的真理与谎言
●本次实战演练活动讲评
●总结与串讲::软件项目管理的生命周期——项目管理从相关方期望值的识别到相关方期望值的验证&确认
1)相关方的期望值构成项目需求的最重要来源
2)针对相关方期望值的分析和分解形成项目关键目标与关键活动——项目计划的主干要素
3)计划的协调::估算、目标和承诺——相关方期望值的平衡
4)项目的可视化监控——相关方期望值达成情况的过程分析
5)风险管理 = 相关方期望值的矛盾与冲突的管理
6)项目总结——如何更好的管理相关方及其期望值
●To B软件系统项目管理的2项真理
●To B软件系统项目管理的7个谎言
培训过程中将共享的模板/工具
1)“相关方期望值”登记表
2)项目启动计划模板
3)项目立项申请表
4)规模估算表格(基于Function Point方法)
5)规模估算表格(基于Web Page估算技术)
6)工作量估算表格(基于COCOMO II模型)
7)项目“一页纸”计划模板
8)相关方冲突矩阵(用于识别项目的风险)
9)项目风险与状态记录
10)项目需求跟踪矩阵(含横向跟踪)
11)接口关系跟踪矩阵
12)阶段总结报告(模板)

课程费用

5800.00 /人

课程时长

3

预约体验票 我要分享

近期公开课推荐

近期公开课推荐

提交需求