在18年第一季度末尾,接手PMO工作。目标是建立PMO,支持项目运作。其实这是一个较空泛的目标,具体要做哪些工作,是一项不断摸索的过程。幸而有项目总监直接指导,同时部门拥有多位十几年经验的老司机-项目经理,在18年支持型PMO算是大体成型。工作总结记录如下。
首先是现状分析,定位了目前所处的位置,才能找到差距所在,确定接下来的工作。
最先应维护的文档,就是项目清单。PMO作为一个运营组织,面向的对象是项目,若有多少项目、项目基本信息都无法掌握,自然也起不到管理的作用。之前所有项目的监督指导,由部门总监(项目总监)一人操盘,18年新增了十几项项目,同时还有已上线系统的运维督导、部门管理工作,难免分身乏术,精力被迫投入到项目的救火当中,无法抽身从全貌、顶层架构、流程设计上,施加影响。同时,各项目之间,缺少关联性统筹兼顾,彼此相对独立,无法发挥项目组合的威力。更严重者,系统是成功上线了,可又是一个信息孤岛,加重了业务人员手工作业量,给后期信息流打通增加了更大的困难。
项目清单结构如下,注意区分项目与任务。项目的定义:“项目是为创造独特的产品,服务或成果而进行的临时性工作”,而一个需协调多方组织配合的任务,也可当做一项目来驱动,这里没法给出统一的判断标准,需做具体分析。但对于任务和项目如何管理的区分是清晰的。任务,只需能保障闭环即可,无论是记录在系统工具或Excel中,定期更新状态,记录结果。
- Project name
- Project manager
- Business area
- Project level
- Status
- Issue/Risk
- Timeline
18年大大小小项目,共33个,并行运作最多时有二十多个。可分为
公司级大型项目,拥有专职的项目团队、独立办公室,非本部门主导,如PLM一期、CRM一期,都是公司最核心系统。针对此类大型项目,PMO不涵盖项目内部管理,但要求适当的项目分享,及协调与其他项目交叉的资源;
本部门主导、作用于业务部门的项目,有的项目影响同样巨大,如IM替换、邮箱替换项目,皆为公司级作用域。有的是针对特定部门、或领域需求的项目,如非生产类物料采购平台;
本部门主导、不直接满足业务部门需求的项目,信息安全、运维服务相关项目,大多属于此类。运维项目,如容灾,只要满足业务用户要求的RPO、RTO即可,干系人没有任何其他要求,遵循传统的瀑布式方法运作。又如ITIL项目,其实没有这个系统,业务用户不会有意见,一通电话不比系统提单来的过瘾。但为了化被动服务为主动、同时提升SLA,线上处理是必要的转变。系统上线后,所有人都会受到影响,但并没有直接满足业务部门的需求,因为没有解决业务用户的痛点(会提升服务效率,但用户很难觉察到,处理慢催促几次就行了,起码还拥有掌控感)
所以这么多项目,若无法把控全貌,很容易顾此失彼。把所有项目纳入项目清单中,持续维护。
深入了解各项目的具体状态及运作模式。大型项目,因存在专项组,状态是可控的。且存在实施方,顾问会提供成熟的项目管理方法论,体系是完备的。而本部门主导的项目,项目管理现状差异巨大,与项目经理个人能力强相关。需着重了解:
项目计划,是否有目标日期、里程碑
与干系人有无成熟的沟通机制,站会、周例会、月例会
变更如何管理,是否有做记录,是否有审批环节。同时也包括,前期需求如何受理、排序,原始需求如何转为开发需求
文档管理,是否把控需输出的文档资料,版本管控情况
问题、风险项如何管理,是否在做跟进
如何组织测试,测试用例如何编写,如何确保测试充分
部门作为支撑项目管理的后台,要了解是否具备了足够的条件,能够为项目经理提供必要的专业支持。包括:
流程支持。最要紧的流程,是需求变更管理、立项管理流程。这里的需求变更管理流程,指的是系统上线1到2月后,进入产品运维阶段,如何受理业务提出的需求,如何排序、处理。这是保证了源头的管控,若该流程缺失或存在问题,会持续引发下游的问题。最典型的例子,每个小部门都能直接找开发人员提需求,来一个做一个,做的很累,效率又低、做的又不好看,系统并没有任何改善。犹如项目管理中没有了变更管理,边界蔓延,看起来做了许多,业务并不领情。立项管理,同样属于源头上的把控。业务痛点没精准定位,病因是什么都弄错了,由此立的项目就算成功了又能给业务带来什么价值。同样,产品选型不当、POC不全面、技术评估不彻底,会给项目增添巨大的困难度。即使成功上线,后期运维也是个大问题。如有的产品,数据集成能力极差,标准接口都不支持,导致后续与其他系统打通时极其困难,而这就是因为产品选型时缺少技术人员的充分参与;其次,其他IT类流程,虽不是项目管理相关流程,但也存在着间接作用。外包人员管理,事件、问题管理,自研系统开发实施管理,版本发布管理,系统权限管理,物理环境、服务器管理等。
资产管理。硬件、软件如何管理。硬件类因与运维本身工作强相关,自然会做维护。但软件资产,就很难有人说的清了。
项目预算、核算管理。从财务角度,项目要有四算。但基于现状,能在立项时做好预算,把项目总共花了多少钱统计清楚,便已达到要求。
因存在海外子公司,项目涉及海外部署时,与海外的沟通、协作机制。 PMO-海外沟通
从现状出发,可分解出PMO要做的工作,包括:
项目周例会。这是最迫切的动作,作为项目管控的抓手,一方面可掌握项目状态全貌,供领导者决策,另一方面可把控项目问题、风险,在过程中规范、提升项目管理方法论
项目交叉项资源的协调与决策项跟进。涉及多个项目团队的沟通,或资源分配,以PMO名义组织,并作为PMO的跟进项。
项目管理工具的落地与运维
流程梳理及优化,以主导者或参与者身份介入
资产梳理与维护
项目费用管理
项目文档管理,重要文档、流程、资料的归档,形成过程组织资产库
提供项目管理过程模板,及关键交付物check list,监督关键交付物的提供情况
组织关键里程碑评审,包括立项评审, Kick-off Meeting, Go/No-go Meeting, 项目结案报告
根据项目的不同类型、级别,提供相适的项目管理方法论
架构梳理,主要是数据架构、业务架构
项目周例会的意义十分重大,需优先建立并维护。周例会的关键点,在于取得领导的支持,否则项目经理个个都是大忙人,别说提供周报告,就是要求参加例会也不会搭理的。原因一是以前没有这个习惯;二是短期内项目经理看不到收益,不理解PMO的作用;三是透明化的管理转变,人自然会有所抗拒。因此事先一定要与领导进行充分沟通。一是另其理解重要性,其实每周能汇总项目状态,输出项目周报,对于领导把控全局具有极大的帮助,自然会支持;二是配合领导的时间,犹如项目的开工会需领导务必参与,周例会也要优先配合领导的时间。此外,可将周报的提交次数,作为项目经理KPI的考核指标,强制约束直到形成习惯。周例会主要做的事情,包括
有无问题点
有无风险项
有无跨团队事项需要沟通
决策事项的记录、发布与跟进
设计周报告模板发给项目经理,要求每次例会前提供。模板不可复杂,最好一页纸,包括
项目目标
项目里程碑:序号,里程碑,开始日期,结束日期,状态(未启动;红色-存在重大问题,延期;黄色-存在问题或风险,需关注;绿色-进展正常)
交付物
资源总结与计划(本周总结,下周计划)
也可再加一页,增加重要问题、风险及待决策事项内容框
交叉项可从两个维度理解。一个是项目维度,主要涉及数据集成开发。例如对于大型商用系统,一个只支持JDBC,另一个不允许直联,都是强势团队,需PMO介入协调。又如引进了ODS/MDM后,又不希望两个系统直接打通了,数据该如何集成,需要三方达成一致。从业务层面考虑,采购类合同评审,是放到合同平台,还是放到SRM?要协调业务方与两个项目组共同讨论;另一个维度,是不同子部门职能上的协作。既有存在部门墙的现象,也存在一个问题如何权衡决策。最典型的例子是项目即将上线,但信息安全从他的角度认为尚不符合安全要求,存在风险。但这不是项目经理的考量因素,在他看来系统已具备上线条件。部门职能上的冲突项,主要在于
信息安全。策略、合规性
项目管理。架构,流程,解决方案
运维。网络、服务器、数据库
开发。接口集成,移动化开发
商业软件。新功能导入,安全性
项目管理&产品管理&TFS 实践Tips
PMO-外包管理
PMO-立项流程
PMO-需求管理
PMO-资产管理
PMO-费用管理
项目文档,其实查看任一大型项目的文档库,都能提取一箩筐的项目模板。但作为支持型PMO,面对目前项目管理水平总体不成熟的环境,提供的模板宜简不宜多,取所有不同类型、级别项目最大公约数。确定了关键节点交付物check list,并提供相应文档模板即可。后续需监控每个项目交付文件在关键里程碑节点的完整性。
项目管理交付物Check List
方案评审
项目立项阶段不止内部团队,还要组织关联项目、部门一起开会讨论。评审:
关键业务需求+痛点
目标+范围
项目周期+预算
产品选型、POC,若涉及新系统采购
Kick-Off Meeting
开工会的意义,无论对于项目经理或项目团队,都意义重大。会议步骤:
交代开工会目标
介绍参与者
项目背景、目标、范围
关键成功因素,前提条件、假设因素
解决方案概述
项目计划
项目风险
组织结构、决策体系
项目章程,办公地点、责任分工、会议机制、相关流程
下一步计划
具体需做裁剪,保证总会议时长小于1h,还要预留给甲方、乙方领导的讲话时间。
Go/No-Go Meeting
主要检查以下完成情况:
UAT
问题是否已解决
遗留问题计划
数据准备
配置迁移
服务器环境
用户培训
上线总结报告
项目结案报告
重点是经验教训的总结,保证归档资料的统一化
成果汇报,如系统使用人数或阐述给用户带来的益处
成本效益分析。企业信息化项目成本是巨大的,效益却很难统计,甚至是无法看到的,有节流没有开源。正因为如此,反而更要重视效益的总结。也许是很简单的数据统计,如系统使用人数、次数,减少的人工操作时数,甚至线上有多少数据、业务量,以数据来说明效益。
系统运营状态
业务运作是否正常
问题处理情况,改善意见或方案。上线后1-2月内,解决影响系统正常运作的Bug,但记录的大大小小问题、需求可能已是满满一清单。是否有做分级,不同级别采用相应的处理策略。一般分三级,L3由运维人员解决,L2交由项目组开发人员,L1由原厂或实施顾问负责。对于L1的问题处理情况,未处理项是否提供承诺解决日期。
交付物是否已全部提供
As-is, To-be,需各整理一份。关注业务架构及数据架构,目的在于找到数据断点。
从PMO层面,assign任务或要求,需考虑对于assignee,带来什么帮助?有什么提升?多与assignee沟通,看其意愿、理解和看法,根据反馈调整PMO管理策略
半年总结,存在的问题:
欠缺项目规划,投入多少资源、达到什么目标、推广到什么程度不清晰。在现状、目标、可行性评估不足的情况下,就启动项目
成本投入,费用回顾及总结
需求管理机制仍存在问题 ,团队与业务及IT沟通过程不顺畅
商用系统,对产品理解不够,没有合适的SA