课程费用

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)阶段总结报告(模板)

活动详情

提交需求