项目管理论文哪里有？本文既是对项目进度管理理论的丰富，又是对规模化敏捷应用的开拓。虽然取得了一些研究成果，但在如下几个方面仍有研究空间： （1）对于 S 保险公司契约中台项目的进度管理困境，是否还有其他可行的解决方案？ （2）由于案例中项目经理只有项目组内管理权限，只能对组内的结构、角色、进度管理进行了调整，并实施规模化敏捷，但没有引入业务层价值流敏捷，即 SAFe规模敏捷实践。对如何在传统企业矩形组织结构里，有效推行客户层面和企业价值流层面的敏捷，仍需进一步研究。
第一章 绪论
1.2 研究内容与方法
1.2.1 研究内容
本文阐述了 S 保险公司的契约业务中台项目的进度管理现状，基于业务中台软件研发项目的特点，分析了契约业务中台项目进度计划估算偏差大、进度管理难、进度压缩效果差等进度管理问题产生的原因。本文结合项目管理和敏捷开发理论，对契约业务中台项目中使用到的 Scrum、Sprint、KanBan 和规模化敏捷实践情况，以及基于格拉布斯准则的估算方法的应用进行了充分的分析，旨在运用科学有效的项目管理方法和实践经验，找到适合传统保险行业的业务中台项目进度管理方法，并为相关传统行业的业务中台项目进度管理提供参考。
在研究中，本文将大量运用到 S 保险公司的契约业务中台项目管理数据和软件研发行业最佳的项目管理理论和实践经验，就契约业务中台项目产生进度问题和改进进度管理前后的项目信息和相关数据，进行分析和比较，论证进度管理改进措施的效果。
1.2.2 研究方法
文献研究法。根据论文研究对象、课题和方向，通过期刊、互联网、书籍等多种渠道，查询业务中台软件研发项目的特点、类似项目进度管理经验、进度估算方法、软件敏捷开发理论和规模化敏捷实践的文献资料，获得本论文需要的项目进度管理的前沿的、深入的研究和实践知识，从而指导问题的分析和研究。
案例研究法。将 S 保险公司契约业务中台项目，作为研究对象。基于搜集和整理的该项目进度管理过程中的文档和数据，分析项目进度管理的问题，探寻根本原因；同时剖析项目组实施的解决方案，尝试分析和评估该方案的效果。
第三章 S 保险公司契约业务中台项目进度管理现状
3.1 契约业务中台项目基本情况
3.1.1 S 保险公司情况
S 保险公司是一家成立于 2007 年底的全国性人寿保险公司。据公开资料显示，S 保险公司近年来原保费收入不到 500 亿，行业占比 1.62%左右，位于原保费收入百亿级别第 7 名。纵观保险全行业数据，2019 年原保费收入千亿级别的 7 家保险公司，原保费收入占比为 62.92%左右。产业集中度较高。
良好的业绩和稳定增长的盈利能力对谋求上市的 S 保险公司来说格外重要。近年来互联网中介发展迅猛，而保险监管日趋严厉，国家层面一直倡导深化金融改革，放开了金融行业的外资限制。想要在当前红海中持续发展，S 保险公司只有通过科技赋能业务创新，在瞬息万变的市场中捕捉商机，灵敏的先人一步抢占市场份额和发展制高点，从而获取最大利润。这就要求作为支撑部门的 IT 科技团队，能更加灵敏的响应业务市场变化，通过业务软件更快的、更稳的迭代支持公司的业务创新。S 保险公司组织架构如图 3-1，可以发现公司各部门是典型的职能结构模式来划分。整个保险行业里，信息技术一直属于后台服务部门[46]。
第五章 S 保险公司契约业务中台项目进度管理改进
5.1 敏捷开发的应用
针对 S 保险契约业务中台项目研发过程中，采取按部就班的瀑布模型进行研发，带来项目进度上的失控问题。需要采用更加合理的开发方法、更加灵活的组织、更加高效的协作、更加积极的拥抱变更，来应对项目进度管理上的挑战。以Scrum 为基础的敏捷开发方法是解决需求不确定性的有效方法之一[52]。在经过项目发起人等关键利害干系人批准后，项目组调整为敏捷开发模式来改善项目进度管理。整体上采用持续迭代的方法来制定、管理和实现长期路线图，通过短周期来开展工作、审查可以工作的交付物，从而确保能及时对变化作出调整。
5.1.1 Scrum 的应用
人与人之间的交互是复杂的，并且其效果从来都是难以预测，但却是工作中最为重要的方面[53]。不论是 Scrum 还是 LeS S 都暗示着：组织和个体的行为受组织结构的深刻影响，因此先期的组织结构调整是在为建立敏捷文化铺平道路[39]。
敏捷开发的实施之前，项目经理利用业余时间对各小组组长、需求人员进行了项目管理知识和敏捷开发知识的培训。然后项目经理才对现有团队组织结构进行适当调整。
首先组建 Scrum Team。将现有开发团队和测试团队界限淡化处理。组建成有开发、测试混合的开发 Scrum 小组。契约业务中台项目团队划分为 3 个 Scrum 开发小组。由于部分人员流动，每个 Scrum 开发小组的人数一直没超过 8 人。
其次，无论是原核心契约系统的业务功能重新设计需求，还是新的需求特性，由 Product Owner（PO）以用户场景式的方式编写成用户故事。以便 Scrum 小组各成员快速理解，并能直接促使各角色主动思考：需要做什么来帮助该需求的实现。避免形成一个需求从需求人员、开发人员、测试人员和运维人员层层加工传递的低效的被动的沟通场景。让团队成员从完成各自工作任务的维度，调整到关注项目交付物在真实场景的应用维度上来。在契约业务中台项目中，原核心契约系统功能用户故事的 PO 由开发人员兼任，需求人员辅助。而新的业务需求特性，则完全由需求人员来整理用户故事，需求人员的 PO 角色是全职的。
5.2 基于格拉布斯准则的估算方法的应用
项目管理人员在项目执行过程中很难得出正确的预期，因而也就不能对项目进度进行有效的控制[54]。
S 保险公司契约业务中台项目，由于中台项目属性，即使采取了敏捷开发，仍不能消除项目活动的不确定性和风险。为了合理评估这些不确定性和风险引入了三点估算方法。研发成员因进入团队的时间长短不一样，对项目需求的认识、理解层度不一致，同时团队成员软件研发技能水平也参差不齐。这些不一致因素，是导致团队成员在对活动持续时间估算出现粗大偏差的主因。
项目组通过统计学中经典的格拉布斯准则来识别异常值，能有效提高项目进度估算的基础数据质量，然后结合三点估算的方法，力求项目进度估算准确，以减少项目执行过程中的进度变更。操作过程可概括为：首先针对活动持续时间，团队成员各自评估出乐观时间To 、最可能时间Tp 和悲观时间Tm ，然后再根据格拉布斯的临界值，将估算出来的异常数据识别出来，排除后再重新计算三个时间值，代入贝塔分布公式后求解出期望时间。
第六章 结论与展望
6.1 论文主要工作和结论
本文首先文献调查了项目进度管理、敏捷开发 Scrum、KanBan、规模化敏捷等理论，以及基于格拉布斯准则的项目进度估算方法。 然后，以 S 保险公司在保险契约业务中台项目研发过程为例，分析了项目团队采用瀑布开发模式后，复杂多变的业务需求给项目进度带来了诸多问题，总结出以下进度管理的问题：
（1）进度计划时间过长，进度计划维护成本高企、面对不断的范围潜变进度计划尾大难掉、估算依据和假设产生的误差放大，以及无法形成有效的开发节拍；
（2）项目活动持续时间估算方法不能科学的消除偏差，估算过程不利于进度管理；
（3）赶工和快速跟进，长期来看，工期压缩效果不佳。
最后，本文阐述了项目组采取的因地制宜的敏捷开发改进措施，以及建立起富有保险契约业务中台特色的基于格拉布斯准则的估算方法。本文的主要研究结论如下：
（1）传统的瀑布开发模型并不适用于需求多变的业务中台项目，特别是充满不确定性的保险契约业务中台项目。
（2）运用 Scrum 及规模化敏捷思路重新定义团队协作，通过 Sprint 制定合理开发团队冲刺时长，并使用合理的开发节拍，能确保契约业务中台项目组及时响应变化，持续提升团队的能力，保障项目进度管理。
（3）团队采用的规模化敏捷包含了 SoS 会议机制、唯一全职的 PO 和看板精益思想，糅合了 Scrum@scale 和 LeS S 思想。并不窠臼于某一学派。灵活采用合理的方法，有效解决了实际问题。
（4）团队务实的引入基于格拉布斯的优化评估方法，对拥有不确定性的任务活动和用户故事进行估算，确保了 Sprint 计划和时间跨度较长的发布计划更加准确，有效解决中台项目进度估算中粗大偏差的实际问题。
参考文献（略）
