课程简介
一般地，我们定义“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)阶段总结报告（模板） |
近期公开课推荐