从0-1搭建交付型项目管理体系流程（上）【宝芝林2】
从0-1搭建交付型项目管理体系流程--商业论证篇【宝芝林3】
非常受大家的欢迎，给大家带来了不少启发，很多小伙伴催更了，作者在繁忙的工作之余抽时间把后面的写出来了，分阶段的非常透彻说明了如何搭建项目管理体系-招投标篇，今天就分享给大家，供大家参考。
从0-1搭建交付型项目管理体系流程--招投标篇：
招投标篇
大家好，我是宝芝林，今天跟大家分享的主题是项目管理流程中的招投标阶段的内容。
一. 目标及作用
本阶段主要的目标就是编写详细的、切实可行的项目方案，并最终形成投标书进行投标，争取投标成功。
二、公司现状及行业特点
2.1. 公司现状及团队特点：
公司目前的组织架构是项目经理责任制，在商业论证阶段项目经理已经介入相关工作。在招投标阶段：
主要执行者：项目经理及其核心团队成员,负主责；监督及指导：事业部经理，负总责；相关配合者：商务人员进行必要的配合；投标阶段审批者：总经理、事业部经理、业务及技术顾问、商务、财务；2.2. 行业特点
银行、保险行业目前整体行业正处于数字化战略转型阶段。目前实施的项目多为其数字化转型整体战略规划方案下的某个具体落地项目，大致可以分为2种大的类型：
一类是甲方已经有了比较清晰的想法和方案，已经形成了比较详细的业务需求规格说明书。另外一类是甲方虽然建设方向比较明确，但是具体落地的方案和想法还不成熟，需要乙方提供落地解决方案。项目经理及其团队需要针对这两种情况进行调研和分析，从而制定有针对性、能够落地的解决方案和项目整体计划。
三、工作内容拆解
我们来分解一下这个阶段常见的工作内容及步骤：
主要可以分为一个主要投标流程和两项大的工作
1. 投标流程相关工作
① 了解、收集项目投标要求及相关文件（譬如：项目邀请函、采购要求文件、业务需求说明书等）；
② 明确细化投标相关要求，包括时间、地点、方式、提供投标文件要求等信息；
③ 按要求递交、上传投标标书及其他相关文件；
④ 现场或远程线上投标；
2. 投标文件制作
① 商务投标内容编写；
② 详细阅读、分析项目招标文件，找出有歧义或模糊的问题点，与甲方进行沟通确认；
③ 深入了解、分析项目业务需求，分析业务功能及业务流程，形成比较详细的需求功能清单，形成业务解决方案；
④ 如有可能对甲方的IT信息系统架构进行了解，形成技术解决方案；
⑤ 依照招标要求，及WBS工作分解，形成项目管理方案，最终整合所有内容，形成项目投标书。
⑥ 编写投标讲解PPT；
3. 公司内部项目计划及评审（一般在投标一周前完成）
① 对形成的业务解决方案及技术解决方案进行评审、确认；
② 依据业务解决方案及技术解决方案，进行WBS工作分解，形成项目计划（包括项目工作范围、项目成本计划、项目进度计划、项目人员计划以及资金使用计划等），并进行评审、确认；
③ 形成投标报价策略，一般制定3次报价，并报公司审批、确认；
④ 对投标讲解PPT进行评审和确认；
四、工作流程及支撑工具
01
工作流程
02
投标流程工作支撑工具及交付物
这里的投标工作，指的是投标的相关流程性事务工作；
主要用到的工具为检查清单列表和常见的5W2H模型；
1.获取、确认投标信息检查清单：
2.投标文件检查清单
流程名称
投标工作
参与角色
项目经理（主责）、产品经理及技术组长（参与）
商务（协助）
思考工具/过程产物
投标工作计划、检查清单，5W2H模型
里程碑
及交付物
投标文件合成及打印
投标完成
03
投标文件-商务标及项目管理内容支撑工具及交付物
投标文件的内容从结构上大致可以分为①商务标内容②业务解决方案③技术解决方案④项目管理计划这四块内容。这一节简要介绍商务标及项目管理计划相关内容。
3.1. 商务标内容：
商务标内容相对比较程式化和固定，一般公司都有相对应的模板供项目经理使用。主要内容包括：
公司的基本情况：营业执照、资质证明、一般纳税人证明、公司资质及证书、实施案例；服务说明及技术规格偏离表：服务说明一览表、技术规格偏离表；投标书：甲方提供的投标书模板；法人代表授权书、承诺及声明：法人代表授权、承诺及声明；主要参照甲方投标书要求提供相关资料及证书即可。
3.2.项目管理计划内容
投标书里面的项目管理计划内容相对也比较固定，主要体现公司项目管理的水平和能力，可以参照PMP里面的五大过程组和十大领域进行编写和裁剪。通用部分可以参考以往项目的模板，主要需要改动的地方为项目整体计划、计划团队核心人员简历，已识别的项目风险等。主要内容包括：
项目整体计划及里程碑节点；项目团队组织架构及核心人员简介；项目需求管理计划；项目质量管理计划；项目沟通管理计划；项目风险管理计划；项目变更管理计划；项目实施监控计划；流程名称
商务标及项目管理内容
参与角色
项目经理（主责）、事业部经理（总责）
商务（协助）
思考工具/过程产物
商务模板、项目管理内容模板、检查核对清单
里程碑
及交付物
商务标及项目管理相关内容
04
投标文件-业务解决方案支撑工具及交付物
业务解决方案内容是根据甲方的业务需求及用户修去需求和业务目标，最终提供较为详细的可落地的整体功能框架及功能列表。
业务解决方案内容格式相对固定，但是如何推导出甲方认可、可落地的解决方案是比较考验项目经理及其核心成员的。
业务解决方案内容格式（可根据实际情况进行裁剪）
下面着重介绍业务解决方案及项目范围是如何形成和确认的,主要可以分为2个大的部分：
①项目调研及资料获取；
②业务解决方案形成；
1. 项目调研和资料获取；
一般有两种方式：
① 从招标相关文件获取，譬如邀请函、业务需求规格说明书、采购需求文件等，如能获取该项目所在的整体数字化转型规划相关文件或背景，将对整个项目的理解有非常大的好处。
② 项目高层及业务需求人员访谈：
目前银行、保险等行业目前正处于数字化转型阶段，存在很多不确定性，甲方向乙方发出招标函的时候，也有很多咨询和讨论的目的。项目经理在对项目背景和招标文件深入了解的情况下，心中已经有了大概的方案，但还存在很多需要进一步确定的内容，这时候如有可能就可以与甲方的高层或者业务发起方进行沟通和确认，往往更能了解甲方真正遇到的问题和需求。
2. 项目范围确定及解决方案编制；
项目范围和解决方案的确定主要采用由大到小，颗粒度逐步缩小的方式。
首先在大的项目范围上进行明确：
这些内容一定要尽量明确清楚，往往很多项目进入开发阶段，比较大的工作内容和范围还会发生争议和分歧，会对项目的顺利实施带来非常大的隐患。
其次就是形成具体的业务解决方案
在确定、设计需求功能和范围的时候要同时关注业务广度和深度，特别是业务深度问题。这是确定项目范围和需求功能时，项目经理和需求人员比较容易犯的错误。
一个需求功能实现的比较浅可能需要1个人月，如果做的比较深，工作量可能会成倍的增加。
以保险行业常见的在线理赔申请业务举例：
较浅解决方案：仅支持18岁以上的成年人作为被保险人为本人进行医疗责任的理赔申请较深解决方案：①支持为本人进行理赔 ②支持为未成年人子女进行理赔③支持医疗、重疾、身故、伤残、津贴等各种责任的理赔申请这两个方案的和业务复杂度和工作量至少相差2-3倍以上。
在行业特点中分析了目前银行、保险行业的软件项目的特点，主要存在两种情况：
一类是甲方已经有了比较清晰的想法和方案，已经形成了比较详细的业务需求规格说明书另外一类是甲方虽然建设方向比较明确，但是具体落地的方案和想法还不成熟，需要乙方提供落地解决方案在这里提供了2个比较常用的方法和工具供项目经理及其团队使用。
加法模型
加法模型的思路主要是在限定了成本预算、时间限定和质量标准的情况下，不断的增加工作内容。就像搭积木一样，一点点把需要的实现的功能和范围搭建起来。适合场景：
甲方落地方案比较宽泛和需求不太清晰；乙方有相关成熟标杆案例、业务场景非常熟悉；减法模型
减法模型的思路和步骤：
梳理甲方招标文件中要求完成的工作和业务功能，形成清单列表；理解项目背景和目标，明确项目预算、时间要求及质量要求三个约束条件；由粗到细，厘清模糊的部分，不断将超出边界的工作逐步裁掉；可综合使用需求优先级评估模型：KANO模型、MoSCoW模型、RICE模型。
至此项目整体范围及解决方案基本编制完成，主要交付物为业务解决方案内容及需求功能清单列表（基本需要细化到二级目录颗粒度）。
流程名称
业务解决方案
参与角色
产品经理（执行）、项目经理（主责）
事业部经理（总责）、业务及技术顾问（指导）、商务（协助）
思考工具/过程产物
客户调研、标杆案例、加法模型、减法模型
需求功能列表、业务框架图、业务主流程图、业务用例图
里程碑
及交付物
业务解决方案
05
投标文件-技术解决方案支撑工具及交付物
系统技术解决方案是根据业务解决方案及非功能需求，对技术选型、系统模块规划、数据库、安全等多方便进行设计，最终形成较为详细的可落地的整体技术方案。
银行、保险行业企业，一般均为大型及超大型企业，其整个公司的信息系统相对一般企业更复杂，一般都有比较完善的企业级信息技术架构和规范，在设计技术解决方案时，一般都需要在其整体技术框架约束下进行设计。
若该企业为已有客户，项目经理可以在公司内部寻求以往项目过程形成的技术文档及相关信息若该企业为新的客户，则项目经理需要协调事业部经理及商务，尽量现场对客户系统技术架构进行调研和沟通，了解一手的情况通过调研甲方企业信息系统整体架构，一般会获得如下信息：
甲方企业级系统架构及技术规范约束；待建项目所在系统（有可能为完全新建系统）及技术框架；待建项目涉及的外部上下游系统及基本的服务交互机制；数据库及相关中间件规格；网络及硬件相关信息（网络拓扑图、私有化或云服务器等）；技术解决方案主要内容及结构如下（可根据实际情况裁剪）：
系统整体设计思想：实用性和先进性、安全可靠性、高可用性、灵活性、开放性、易用性、可管理及易维护性;系统整体架构图：技术架构图、系统架构图、应用架构图、数据架构图、部署架构图等;前后端架构设计：前后端技术选型、分布式微服务设计、批处理设计、分布式缓存设计、消息队列设计、数据流转设计、日志监控设计;数据库设计：数据库选型及用途、数据库表名及ER图;系统非功能设计：可扩展、网络性能、稳定性、可维护性、安全保密设计等;系统软硬件规格及清单：软件规格及清单、硬件服务器规格及清单、网络带宽要求等;流程名称
技术解决方案
参与角色
技术组长（执行）、项目经理（主责）
事业部经理（总责）、业务及技术顾问（指导）、商务（协助）
思考工具/过程产物
技术调研、甲方企业信息技术架构及规范
系统架构图、应用架构图、数据架构图、物理部署网络图
里程碑
及交付物
技术解决方案
06
投标方案及项目计划及成本公司内部评审
投标前各种评审工作主要为项目经理负责及主导，基本上分为①业务及技术方案评审②项目整体计划及成本评审；
1. 业务及技术方案评审
业务方案及技术方案形成后，项目经理组织人员进行评审，主要参与人员为团队核心成员、事业部经理及公司技术、业务顾问。
业务方案和技术方案根据项目的实际情况既可以单独评审，也可以统一评审。
统一评审：中小项目、已有类似业务案例项目、已有客户项目
单独评审：大型项目、新业务类型项目、新拓展客户项目
流程名称
业务/技术方案评审
参与角色
项目经理（主责）
事业部经理、业务及技术顾问（评审、指导）
思考工具/过程产物
业务及技术解决方案
里程碑
及交付物
业务及技术解决方案评审会
2.项目整体计划及成本评审
在业务及技术方案评审完毕及确定后，项目经理开始根据项目范围、需求功能清单列表及技术方案的内容，对项目整体计划更新及项目成本进行估算（注意：这里是项目经理第二次进行项目计划及成本评估，第一次在商业论证阶段）。
(1)需求功能列表：
(2)项目成本估算:
项目经理根据需求列表清单，通过功能点估算法对每个功能工时进行评估，同时技术组长也对每个功能点进行工时评估，最终确定每个功能的工时，从而得出完成需求功能所需总工时。
项目经理综合项目整体范围中的其他工作，最终评估出整个项目的公司内部成本和对外报价。此时评估出的项目成本已经比较精准，基本可以作为实际的项目成本评审的最终数据基准，无特殊情况不再调整。
功能点估算法具体介绍参见咱们分享过的文章：不懂技术如何准确评估项目开发工作量？
（3）项目进度计划及其他
此时项目进度计划及人员安排仍旧相对为粗颗粒度，一般精确到里程碑节点计划即可。
此外还包括项目干系人登记册、项目人员资源日历等
流程名称
投标前项目计划评审
参与角色
项目经理（主责）、事业部经理（总责）
总经理、业务及技术顾问（评审），商务、财务（参与）
思考工具/过程产物
项目整体范围、需求功能清单、WBS分解、功能点估算法
甘特图、关键路径法
里程碑
及交付物
投标前项目计划评审会
项目整体计划（范围、成本、进度、人员规划）
投标报价策略
思考题
你们公司投标工作由谁负责？
你们公司项目范围、业务及技术解决方案形成的方法论有哪些？
你们公司有哪些评估项目成本的方法和工具？
你们公司由谁最后对项目成本负最终责任？
作者介绍：PMO前沿特约分享嘉宾宝芝林：
18年 保险、银行、政府企业级IT信息化建设经验；从事项目管理、业务解决方案咨询相关工作领域；擅长0-1搭建软件项目管理体系、团队搭建及管理；某保险行业软件公司担任软件项目交付部经理；
