特别企划
o 本课程全程采用讲练结合的“工作坊”模式，即：各个学员小组各自使用1个实际项目场景，完成5项内容垂直关联的Workshop（工作坊）实战演练。互动式教学、沙盘式演练、海量案例分析，带给学员“身临其境”般临场感觉；丰富的模版、Checklist展示又可以让学员学“即插即用”的“点穴式”项目管理优秀实践。最大限度的避免程式化理论介绍，最大限度的提升学员实际操作能力；
o 以项目的生命周期5大过程组（启动、策划、监控、执行、结项）为明线，以“干系人期望值管理”为暗线，帮助项目经理树立起全面的“商业价值”思维与分析视角，重塑对G端软件项目的范围、风险、进度、沟通、干系人管理……等多项要素的认知，重新审视如何做好G端项目管理；
o 【特别建议】本课程用于企业内训时，可根据贵公司的业务领域特点、过程体系与产品研发生命周期对本课程进行完全的定制化。特别地，我们强烈建议直接采用贵公司实际的产品（已上线的或者正在开发的）作为学员分组演练案例，以提升学员“身临其境”的体验，最大化地实现培训效果向实际工作技能的转化与落地，从而将课堂内容转化成为培训学员“即插即用”式的实际操作能力。
课程背景
G端项目的管理其复杂度远高于C端项目。这主要体现在以下几个方面：
l 一句话需求——“照着XX系统的XX功能做就好了……”，或者一页纸项目——“按照国发第XXXX号文件精神……”——如果在项目的启动和策划阶段没有抓住这其中的主要矛盾，极易造成对项目建设目标的判断失误，并进而造成整个项目生命周期中 “南辕北辙” 的困境；
l 只讲了半句话——只有“我需要一个XXX系统”而没有“我要该系统干什么”——只有What to do，缺失Why to do。——如果项目经理没有做好这其中的“干系人管理”，极易造成对项目核心交付价值的判断失误，并进而导致满意度低下、做了许多无用功客户还不买账；
l “用户期望”与“项目建设范围”的边界不清晰——如果前期的需求调研和范围界定工作没有厘清这其中的界限，极易造成项目范围模糊不定、需求频繁变更；
l 新老系统之间的衔接、渗透与融合，各个项目之间的关联、协同与博弈——如果没有充分考虑这些内容，极易造成对项目工作量和/或进度要求的判断偏差，造成进度延迟；
l ……
本课程以项目生命周期为明线（启动——>策划——>监控——>执行——>结项）、以“干系人期望值管理”为暗线（识别干系人期望值以确认项目的商业价值、管理干系人期望值以控制项目的范围与边界条件、分析为实现干系人期望值所需要的“关键活动项”以策划项目各项参数、管理各个干系人期望值之间的冲突以有效管控项目风险……）深入浅出的阐述To G软件系统的项目管理的特殊点、关键流程、关键要素与关键节点（Key Point）；介绍项目管理过程的常见问题及其解决方案与最佳实践；塑造全局商业思维下的项目管理新方法、新技巧。
本课程讲师荣获中软协颁发“中国软件工程年度人物”、华为技术有限公司颁发的“最有价值专家（MVP）”等多项荣誉，对多种不同行业客户的都有成功的咨询与培训经验（金融、通讯、能源、政务、制造业……），具备丰富的G端项目管理和团队管理实践经验。培训中，讲师将与您分享他在与业界翘楚（华为、IBM、中移动、中国银联 ……等100余家客户）工作/合作/咨询辅导/培训时的切身体会和成功经验，对业界诸多优秀企业关于项目管理方面的大量案例和最佳实践进行深入的分享、论述和剖析，从实战出发探寻解决项目管理问题之道，着重传授给学员“即插即用”的有关G端项目管理实战经验。
目标学员
本课程针对项目经理、项目管理办公室（PMO）负责人以及涉及到项目管理的相关核心成员设置。
最近3年采纳本课程作为内训的部分顶级企业客户名单
（排名不分先后）
l 中国移动旗下政企业务条线
l 中国联通软件研究院、中国联通系统集成有限公司
l 东软（NEUSoft）
l 中电福富（中国电信系统集成公司下属）
l 中电万维（中国电信系统集成公司下属）
l 浙江公众信息产业有限公司（中国电信系统集成公司下属）
l 中电莱斯（中电28所，军用信息化系统）
l 中证信息（证监会联合三大交易所，证券业务监管）
l 深智诚
l 首都机场信息中心、西部机场集团信息中心、重庆机场信息中心
课程大纲
第一天
1. What & Why——软件项目、G端软件项目、以及全局商业思维下的G端项目管理（9:00~10:30）
l 商业视角下的To G软件项目
· 若干政务系统建设案例的展示与深入剖析
· 什么是To G的软件系统？为什么管理这类型的复杂度远高于其他项目（比如：To C的项目）？
· 请注意！
G端软件项目的交付价值，一定是“锦上添花”，而非“雪中送炭”
· 小结：G端软件项目的管理，需要的不仅仅是项目管理能力，更需要对客户方管理策略的理解，对客户方高层管理者管理意志的认知，以及对领域内业务特征的洞察。所以需要项目管理者具备全局商业思维。
l 什么是项目的干系人？项目各个干系人的期望值对于项目会有哪些影响？
l 正确认知G端项目管理的第一要素——我们交付的是项目的价值，而不是项目本身！
· 实例介绍
l 全局商业思维下，G端项目管理全过程其实就是要做好“四件事情——
1) 识别干系人的期望值
2) 识别项目的交付价值
3) 实现并验证关键干系人的期望已然实现
4) 交付项目，让关键干系人真切感受到项目的交付价值
2. 未有项目之前——项目启动过程（10:40~12:00）
l 项目启动的主要工作——识别分析干系人期望值，初步确定项目的交付价值与范围
l 公式：G端项目的交付价值 = 对用户的应用价值 + 对客户的成长价值+对组织自身的商业价值
l 不明觉厉——如何从干系人的期望值中抽象得到项目的目标，从而识别项目的交付价值
l “摆在桌面上讲的目标” Vs.“藏在桌面下讲的价值”——从项目的交付价值到项目的建设目标
· 实例分析方法介绍：BBR模型，也就是各个干系人对于一个To G软件项目交付价值的最高追求——“帮忙不惹事”
· 实例分析：BBR具体应用案例剖析
l 如何有效的引导客户对于项目目标的期望值？为什么说过高的引导干系人的期望值与“挖个坑把自己埋起来”无异？
· 方法介绍：诺兰模型永放光芒——有限引导客户期望值
· 实例剖析：如何从“干系人期望值”抽象得出项目的“建设目标”
l 项目开工会——项目组成员一定要聚餐的”两个会议”之一
分组演练1及其点评（13:30~15:00）： 各分组根据选定的项目场景，分析项目的干系人，明确定义：
1) 项目有哪些干系人；
2) 每一个干系人对本项目的期望、要求和/或约束条件是什么；
3) 在启动阶段的需求调研活动中，针对不同干系人的调研重点分别是什么；
4) 用一句话总结概括项目的“建设目标”或“交付价值”
3. 运筹帷幄——项目策划过程（上, 15:10~16:30）
l 进度、质量、成本、范围——项目的4大目标之间是协调的关系，没有哪个目标天生高人一等
l 什么是一份“好”的项目计划？如何让项目计划更像“项目的”计划（如何避免项目计划千篇一律）
· 案例分析与讨论：象当年写好一篇记叙文一项的写好项目计划——项目计划的“六要素”（时间、地点、任务、起因、经过、结果）
l 以终为始——从项目的“建设目标”入手、分析项目的关键活动项
l 如何应对多个项目之间的“依赖性”问题？
· 范围以及进度关系上的依赖问题及其解决方案
· 人力资源关系上的依赖问题及其解决方案
l 是非曲直话估算：估算不是掐指一算，估算其实就是为了寻找合适的“y=f（x）”表达式
· 常用估算技术介绍——概略估算的扑克牌法、精确估算的功能点分析（FPs）
· 还能更好吗——A公司和B公司的企业级估算模型
l 项目估算Vs.项目计划：估算、目标与承诺之间的区别与联系
· 故所以：估算的真正作用，并不单纯在于“拿出一个数值”，而在于“利用多轮估算的结果调整项目的目标”
· 案例分析与讨论：估算既不是计划，计划也不是估算
l 估算的“不确定性锥”效应
l 重估算与重计划的阈值
分组演练2及其点评（16:40~17:30）：继续上一个演练的结果，各小组根据已经确定的干系人，从干系人的期望值出发，识别各个项目的关键活动项
4. 未雨绸缪——项目策划过程之识别项目的风险（18:30~19:30）
l 风险管理的意义与过程
l 风险识别的“一招鲜”——“干系人期望值冲突矩阵”分析风险
l 风险类型，以及实际案例介绍：
· 项目计划阶段的常见风险
· 需求分析活动时的常见风险
· 设计和构建时的常见风险
· 验证与交付时的常见风险
· 协调管理多个项目时常见的风险
l 描述风险的“三位一体”: 风险的背景、风险发生的必要条件、风险所可能带来的危害
· 案例分析：风险发生的条件、风险的危害以及风险的扩展描述
l 分析风险的“三大禁忌”：不假思索的风险发生的原因归结为1）“项目成员的能力”、2）“客户的原因”、或者3）“沟通不畅“；
l 案例分析：如何通过风险的持续监控而将风险管理有机的融入项目管理中
· 结论：唯有将风险管理融入项目管理中，风险管理才能真正的发挥作用
l 风险的管控措施，以及风险的规避措施和应急计划是否有“针对性”的检验标准：是否可以将管控措施写在WBS里
l 制定规避措施和应急计划的最大禁忌：无限制加班
· 实例介绍：使用“风险跟踪矩阵” 监控风险
l 风险管理的实践与经验
分组演练3及其点评（19:30~20:30）：识别并记录项目Top3的风险，并且制定相应的应急计划和/或规避计划，确定与干系人沟通项目的风险及其管控措施的策略
------------------------------------------------第一天培训结束--------------------------------------------第二天
5. 运筹帷幄——项目策划过程（下，09:00~10:30）
l 策划项目团队管理的利器
· 资源日历——特别适合于同时管理多个项目
· RACI矩阵
l 项目计划如何分层：里程碑/版本——阶段/迭代——活动——任务项
l 规定动作+自选动作——如此让项目的计划更像“项目的”计划
l 制定WBS（WBS，Work Breakdown Structure）的“三大纪律八项注意”
· 案例分析与讨论之1：WBS要至少要包含“名词”和“动词”两个部分；
· 案例分析与讨论之2：WBS要包含“规定动作”与“自选动作”；
· 案例分析与讨论之3：WBS需要细化到何种程度？
l 关键路径分析——项目经理的管理焦点、项目目标的影响因素
· 解耦——细致切分任务项，解耦任务项与任务项之间的依赖关系
· 关键路近分析
· 使用甘特图
· 如果需要“赶工”，那该怎么办？
分组演练4及其点评（10:40~12:00）：综合运用前3个演练的结果，各小组制定本项目的WBS，要求至少包含以下内容：
1) 确定并定义项目的各个里程碑与交付件；
2) 在演练1中确定的与各个外部干系人沟通时的方法方式、频率与内容
3) 在演练2中识别的项目关键活动项
4) 在演练3中识别出的针对项目风险的规避措施和/或以及计划
5) 上述内容文档化为项目的WBS
6. 决胜千里——项目执行与监控（13:30~15:00）
l 举例：项目执行与监控过程中的常见问题
l 如何有效跟踪监控项目的关键活动项？需要追溯到项目的“干系人期望”
· 秉承二八原则实施“有的放矢”的监控
l 项目监控过程——（会议+报告）X用数据说话 = 准确了解项目的状态
l 项目的度量与分析——有效实现“用数字说话”的不二法门
· 度量与分析的目的：1）客观了解项目的进展状况；2）有效沟通项目的紧张状况
· 举例：“内向型”度量项与“外向型”度量项
· 小结：定性做结论，定量做支撑
l 在有效度量和分享的基础上，实现项目的可视化管理
· 项目参数，以及应对多个项目齐头并进时的分层实施与分层控制
l 燃尽图与看板——使用“同行压力”到极致的体现
l 如何召开一次“有用”的项目组例会？
· 首先，甄别一下：开会就是为了解决问题吗？
l “So what”是监控项目状态的最关键内容
· 反面实例介绍与研讨
· 正面实例介绍与研讨
分组演练5及其点评（15:00~16:30）：假定项目组已经达成按照项目计划中定义的第一个里程碑，请各个小组撰写“阶段总结报告”，召开阶段总结会议，向客户（由讲师扮演）及高层管理者（由其他小组组长扮演）当前项目的进展状况，包括：
1) 使用度量与分析手段评估项目的当前进展状况；
2) 运用可视化手段撰写项目的“阶段总结报告”；
7. 余音绕梁——项目收尾过程（16:30~17:30）
l 你的项目应该如何结项：“曲终人散”还是“余音绕梁”？
l Do not punish people, punish process(不要惩罚个人，惩罚流程)——什么是“流程化”的思维方式？
· “系统思考、过程优化”的实际案例剖析::正例——某型仓储物流管理系统从“需求调研”进化为“需求开发”、“需求规划”的过程
· “系统思考、过程优化”的实际案例剖析::反例——某公司系统集成类项目失败后的处置方式
· 他山之石，可以攻玉：某公司关于组织级知识库建设的最佳实践
· 小结：别人吃一堑，我长一智——如何从项目的失败中总结教训，并且使用“流程”这一系统性方式加以推广应用
l 系统思考，过程优化之从项目的成功中总结经验，并且使用“流程”这一系统性方式加以推广应用
l 系统思考、过程优化之“等待100年获得顿悟” Vs. “利用结构化方法用15分钟解决问题”；
l 系统思考、过程优化之 “为特定的问题寻找特定的答案”Vs.“将特定的问题上升为通用的问题域”
l 系统思考、过程优化之 从“发现问题——>解决问题”的应激性思维进化为“发现问题——>分析问题——>解决问题”的系统性思维
· 举例：经验教训总结
l 系统思考、过程优化——高阶项目管理必须具备的基本思维方式
8. 培训总结——To G软件系统的项目管理的真理与谎言
l 串讲：G端软件项目的生命周期——项目管理从干系人期望值的识别到干系人期望值的验证&确认
1) 干系人的期望值构成项目需求的最重要来源
2) 针对干系人期望值的分析和分解形成项目关键目标与关键活动——项目计划的主干要素
3) 计划的协调：：估算、目标和承诺——干系人期望值的平衡
4) 项目的可视化监控——干系人期望值达成情况的过程分析
5) 风险管理 = 干系人期望值的矛盾与冲突的管理
6) 项目总结——如何更好的管理干系人及其期望值
l 总结：何为“全局商业思维”？
1) 从“关注交付成功”到“关注交付成功+关注商业成功”；
2) 从“关注交付质量”到“关注交付质量+关注交付价值”；
3) 从“What to Do”到“What to Do + Why to Do”；
4) 从“产品需求为起点”到“业务需求为起点”
