很多项目经理在这个阶段,由于经验不足及整个项目管理体系涉及的环节和内容比较庞杂,往往无法有效思考,无从下手。
笔者有幸在最近几年的工作实践中,实际搭建并迭代了2-3次项目管理体系流程框架,期间也经历过很多迷茫,也踩过一些坑,当然更多的是收获和经验,有了一些个人的实践方法和感悟。
本着输出和总结个人的经验沉淀,以及受PMO前沿梦想老师分享精神的影响,笔者将在后续的章节,通过一个完整的软件交付项目,跟大家分享自己在构建项目管理体系过程中,一步步思考、一步步分析的步骤和思路,从而搭建出符合公司特点、能够落地的项目管理的体系。
在分享具体的交付型软件项目管理体系流程之前,先介绍一下常用的一些思考方法和模型,这样大家可以有一个比较整体的概念。
01行业标杆和经典理论
人类社会经过几千年的发展,特别是进入现代商业社会后,各行各业都形成了很多经典、实用的理论和模型。我们大多数人都是普通人,需要站在巨人的肩膀上,借鉴已有的经典理论和模型,并根据我们的实际需要来快速提高我们的能力。
譬如项目管理流程体系的搭建,就可以参照PMP、Prince2、CMMI这些经典的项目管理体系和方法,或者参考软件行业先进企业的管理流程。
02分层、分步骤拆分思路
当我们遇到一个比较大的、复杂的工作或事物时,是非常难于理解和把握的。一般的解决方式是把大的问题按照各种维度拆解成小的问题和结构,从而降低复杂度和理解难度。
笔者常用的模型是金字塔模型。其理论认为所有的事务都可以按照三种维度进行分解:时间顺序、结构顺序和重要性顺序。譬如:
Ø我们常说的软件项目管理流程分为:项目启动-需求分析及设计-概要/详细设计-代码实现-测试-项目上线-项目收尾就是按照时间顺序去分解。
Ø需求分析和设计工作中,常用的业务de架构-应用架构-数据架构-技术架构 就是按照结构顺序进行分类。
Ø我们常用的WBS工作分解结构其实也是以上运用几种逻辑顺序进行分解。
03目标-现状-问题差距-解决方案
这个模型大家应该也不陌生,也是笔者常用的模型和思考方法。
Ø我们做任何事情,只有有了目标才能更加聚焦和有明确性,防止走偏。
Ø只有了解了现状,才能发现差距和具体的问题所在,问题差距=目标-现状。
Ø而分析出问题和差距,我们才能够有针对性地制定相应的解决方案。
通过这个方法与经典理论相结合,才有可能能找到符合本企业、本团队可落地的各种方案。
04二维矩阵模型
二维矩阵在这里就不多介绍,其在很多领域都被广泛使用,譬如项目管理5大过程组+10大知识领域、项目决策矩阵模型、在软件项目开发过程中项目经理、技术组长、需求分析人员、开发人员、测试人员等各个阶段的岗位职责等。
05二维矩阵模型
四象限模型也是大家耳熟能详的模型,很多模型其实都是四象限模型的具体应用。
譬如常见的干系人权力影响模型、时间管理模型、波士顿矩阵。
05表单化模板和问题检查清单
公司各种管理流程的建立,有两个大的目的:
Ø一是为了统一标准,提升效率
Ø另外一个目的就是降低对人员能力的要求,从而使工作门槛降低
表单是承载公司战略意图与管理意图的工具,同时也是让制度、流程、标准、编码等落地可执行的重要工具。现在企业运行,无论是传统的线下运转,还是全线上无纸化办公,其本质都是通过一个个表单在各个环节进行流转,从而完成相关的业务。
问题检查清单在企业实践中,可以通过组织过程资产沉淀或者有经验的人员总结出来后,让能力水平经验相对弱的人员也能有完成相应的工作,相对轻松上手,并起到培养团队成员的目的。
譬如项目启动大会工作内容清单,项目风险识别清单等等。
现在随着腾讯文档、飞书等在线协作文档和表格出现,已经越来越方便搭建公司线上管理表格和清单,从而有效提高工作和业务协同。
项目管理体系流程整体框架及目标
我们开展任何相对复杂的活动,都需要制定明确的目标,从而为后续的工作提供指引。
这里我们用到的是看现状-查问题-定目标-提供解决方案的常用方法和思路。
1、看现状
搭建能够落地的项目管理体系流程和纯理论研究的最大不同,笔者认为一定要贴合企业的发展现状和实际业务运营的特点来开展,因此分析企业的现状就是第一步要开展的工作。接下来我们从公司所处阶段、公司的组织架构、公司开展的业务等几个方面去分析。
1.1. 公司所处阶段
公司目前处于1-10的阶段。
目前从正式开始业务运营以来,已经进入第三个年,已经从最初的10多人,通过自主团队建设和引入外部团队,已经突破100人左右,正处于业务快速发展期。
1.2. 公司的组织架构
公司的组织架构在期间也进.行过调整,根据业务开展特的实际运行和参照行业先进标杆,由原来的产品部、技术部、测试部、项目部的职能矩阵式调整为目前的事业部下的项目经理责任制。具体结构如下:
公司采取扁平化管理,最高层级为总经理并直接管理商务部,和支撑保障部门。
目前设立了三个软件交付事业部,每个事业部根据各自部门的发展情况,拥有3-5个软件开发项目组。并由三位事业部部长+外部业务、技术专家顾问组成虚拟的决策委员会,开展日常的管理及决策工作。其中软件开发项目组为最小单位组织,以项目经理牵头,并与产品经理和技术组长形成团队核心骨干。
可能有眼尖的小伙伴会发现,咦你们公司怎么没有CTO、产品总监等岗位。这其实就是每个公司根据自己发展的阶段和业务特点的独特性。
首先:是根据公司开展业务的特点决定的,在后面的公司业务会分析到
其次:是根据公司现有团队人员特点来决定的。公司的三个软件事业部部长或在业务领域,或在技术开发领域都有自己各自的特长,独当一面,各自互相补充支持。通过决策委员会及外部聘请的业务和技术顾问这种机制已经可以满足目前阶段的实际业务开展。
说到这里,我们要向中国人民解放军学习,穷则老三样:56冲锋枪、RPG火箭筒和107毫米火箭炮,富则歼20、东风导弹、航母战斗群。总之要贴近实战和现有条件,只要能把美帝干翻的,那都是好方法好手段。
对我们项目经理来说,有条件要上,没有条件创造条件也要上。
通过组织架构的分析,对我们最终搭建的项目管理流程的工作步骤及各个管控点提供了依据和指导,使我们的管理流程更能顺利的、高效的开展,更加落地。
1.3.公司开展的业务
公司定位于保险、银行等大型金融行业数字化建设软件供应商,目前主要开展的的业务有数字化转型咨询、软件项目实施、人力资源外包服务及软件产品开发四个大的领域。目前以软件项目实施占公司营业比重最多,本次项目管理体系流程的搭建就是针对这个业务模块展开的。
目前大型保险、银行企业通常都会进行数字化转型业务战略规划,然后根据规划的内容进行相应的信息化建设,其中部分核心IT建设内容为保险、银行企业自己创建的金融科技公司进行实施,其余部分均为保险、银行软件开发供应商以项目制度的形式进行开发实施。
目前大部分保险、银行企业对定制化的外包项目绝大部分仍旧采用瀑布式软件开发方式和流程,极少部分项目开始试点敏捷开发。
而目前公司服务的3-5家保险、银行甲方均采用瀑布式软件开发流程。
这基本上就为我们的将要构建的的交付型软件项目管理体系流程定下了基调:
即采用跟甲方相匹配的瀑布式软件项目管理开发流程。当然我们在实际过程的细节和节点,也引入了敏捷项目管理中一些比较实用的工具,譬如每日站会、看板、需求优先级评估、分阶段快速迭代上线等。这一点现在看来和PMBOK第七版不谋而合。
在这里再唠叨一句,瀑布式和敏捷式真的有必要分的那么清楚吗,笔者个人认为在真正的项目实践中,瀑布+敏捷的混合式将越来越多的成为主流模式。还是那句话,只要是符合公司现阶段实际的、有利于软件项目开发效率和管控的,都可以大胆拿过来使用。
到了这里,现状和基本背景都分析完毕了,这样我们就了解了企业内部和企业外部的各种情况,为我们最终制定可以落地的项目管理体系流程提供了有力的保障。
思考题:
你们公司目前处于什么阶段呢?
你们公司的组织架构你能画出来吗,每个部门大概的职责你了解吗?
你们公司的开展的主要的业务是哪些,行业特点是什么,是定制化项目为主,还
是产品自研为主?
2、查问题
只有发现目前项目管理体系流程中具体存在的问题,把问题收集并汇总归纳具象化后,我们才能有针对性的调整、迭代我们新的项目管理体系流程。
那么如何全面的、深入的去探查问题呢,我们这边采用分别针对公司高层(总经理)、中层(各事业部部长及支撑部门经理)以及一线项目组成员三个层次,采用先发散后收敛归纳的方式进行调研和分析。这样从高到低,从整体到局部基本上可以做到不遗漏,各个方面都能照顾和了解到。
2.1 公司高层(总经理)
总经理并没有指出特别具体的问题,只是重申了一些公司后续发展的规划和本年度的重要事项。
公司预计会成功开拓新的2-3家中等规模的保险、银行客户,其中一家公司的IT信息研发中心在另外的一线城市。业务量会逐步增加,需要更多的有战斗力,可以大概率保证项目顺利交付的软件项目交付团队。
公司当年准备进行CMMI3及质量管理体系认证,从而增加公司相关资质,更有利于公司招投标和相关高科技企业认证。
虽然没有特别明确的问题,但是已经为我们搭建项目管理体系提供了比较宏观的背景和要求。
2.2 公司中层(事业部部长和支撑部门经理)
笔者与另外2位软件事业部部长工作经验、能力特长各自不同,特别是其中一个事业部及其下属团队为公司整体引入,与公司现有各种制度流程处于磨合状态。笔者与他们进行了深入的沟通和畅谈,各自分享了自己的经验和教训,以及目前项目实施过程中经常遇到的困难,并总结归纳了普遍的问题,和迫切需要解决的方向。
这其中既有管理层面遇到的问题,也有具体执行层面项目经理常见的问题。大家在实际分析中要通过头脑风暴等发散收集后,至少要按照这两种维度去归纳整理,方便后面有针对性的制定对策,而这些问题就是我们项目管理体系架构中的各个环节的管控要点。
并与商务部和支撑部门经理进行了沟通和访谈,听取了他们遇到的问题,以及意见和想法,主要可以归纳2个维度:
1.其他部门希望我们能为他们做什么
2.我们可以为其他部门做什么,及遇到的哪些问题。
不知大家有没有注意到,在做调研问题中,是以我们三位交付事业部部长的思考和讨论为主,其他部门为辅。
这其实是与公司组织架构和经营模式有关,在公司软件交付事业部是战斗和收入主体,其他部门均为辅助保障部门。如果是矩阵式组织架构,在流程制定上要均衡所有部门的意见。所以大家一定要找到最关键的部门和要素,要根据自身公司的实际情况进行调研和分析。
2.3 一线项目组成员
笔者同时也调研了自己负责以及外部引入事业部团队的项目经理和技术、业务骨干,获取了他们目前遇到的问题,以及希望从公司得到的帮助。
当然有些问题不是完全项目管理制度和流程可以解决的,需要排除干扰。
思考题
你们公司项目管理目前遇到哪些问题呢?
3、定目标
通过现状分析和问题分析,最终归纳汇总及优先级排序,最终定下来了整体的原则和要着重解决的几个问题和目标:
目前各个项目团队项目管理流程不完全一致的问题
降低一线项目经理及业务骨干使用难度并能够给与必要指南(解决方案:在每项具体工作节点形成模板表格,有定量指标和形成检查清单)
明确支撑部门工作界面和介入重要节点指标
满足CMMI3认证要求
在定目标和方案的过程中,一定要找到目前最重要的2-3点问题来制定目标和重点解决,不能太多。因为资源和人们的精力是有限的,如果问题太多需要分阶段一步一步来解决。
到了项目总监或者部长这个企业中层及以上的级别,一定要有取舍的思维和能力,不能既要、还要、全都要。
思考题:
如果是你的话制定的公司项目管理体系搭建的目标和原则是什么呢?
4、确定方案
根据前面几个步骤的分析和目标,最终确定要搭建的项目管理体系流程整体框架仍旧采用瀑布式软件开发流程和内容,在具体每个环节上根据公司具体内容进行调整和建设落地。
各位读者看到这里,意不意外。这不是满大街都差不多的流程吗?
笔者想说的是,软件行业已经发展几十年的时间,大的框架和流派已经基本成熟和固定下来,目前以瀑布式和敏捷式开发2个大的流派为主。
笔者包括其他大多数人都没有能力进行特别大的创新和变革,我们都是站在前人的肩膀上,逐步改进和发展。重要的是思考和分析的过程,此外整套框架体系也引入了大量的敏捷工具和思想,具体的落地和裁剪内容在后面的每个具体工作节点里面进行介绍和体现。
思考题
如果是你,最终确定的项目管理流程节点是哪些呢?
在整个分析过程中,你会运用哪些分析工具和思考方法呢?