交付项目管理全流程总结

项目管理最最基本的就是对范围、时间、成本、质量(STCQ:Scope、Time、Cost、Quality)的把握,这四点其实就是项目的目标。不管项目复杂还是简单,计划还是执行,一定不能忽略这四点,必须烙印在项目经理的大脑里,就象写入电脑固件的BIOS,一启动就要加载,形成项目经理的一种下意识行为。

在项目的实施过程中,则分为启动、规划、执行、监控和收尾,在这些过程中也会有一些关键点要注意。这里不说太多理论层面的东西,而是结合我司交付项目实际情况,对整个流程进行整理和总结,易于操作,开箱即用。

项目目标

范围

为了明确项目范围,以下三个文件必须要有。

首先是项目合同。这个可以跟销售要,当然如果有一些敏感信息可以脱敏后再拿过来。项目经理主要关注合同里关于产品交付的描述以及回款的阶段,比如到货、安装或者初验后分别有多少比例的回款。

然后是招标文件。招标文件有详细的关于交付的产品组件、规格,比如ECS多少CPU,OSS存储容量等等。还有交付工期是如何计算的,是否从中标后开始算。工期不仅仅是是软件交付时间,中间还包括到货,上架,布线时间。

最后就是交付产品清单。这个可以跟售前同学要,该文件包含了本次项目需要交付的所有产品信息,包含云平台组件规格,硬件清单,软件清单等。关于硬件,要注意其中的网卡和flash卡,是否非标,是否满足交付条件。

时间

时间其实就是进度把控,在项目正式实施前,进度计划表要明确,并且要提交给客户和监理审核,客户和监理确认后要严格按照计划表执行。项目经理要考虑是否会有延期的可能,合同中客户是否对项目延期有处罚条款。

质量

任何东西都可以损失,唯独质量不能有损失。即使遇到影响进度的问题,可以通过市场关系,和客户沟通,比如延期个几天,但是质量不能妥协。项目经理要关注,交付的东西是不是全面,所有组件是否都可以使用,是否都经过了测试。如果东西少,要加入到风险控制列表。如果交付质量有问题,后期可能会影响验收。

成本

目前的实际情况,虽然项目经理对成本的管控较少,但是也要关注自己项目里面的人员投入情况。

过程管理

启动、规划、执行、监控、收尾,实际中会把执行和监控放到一起。

启动

在项目中标后,要和市场沟通时间点,召开对内和对外的项目启动会。

对内启动会参会人员有:销售、产品和服务。目的是沟通项目的整体情况,明确交付的范围,初定实施计划和人员安排等,内部形成一个统一的方案。

对外启动会参会人员有:我司、用户、集成商、ISV和监理等。我们要提出我们的诉求,这个会议主要对外,会议目的要明确,明确各方的边界和工作范围。我们做什么,什么时候做,不是只有自己知道,而是让别人知道和认可。这些依赖于合同和招标文件,要避免让客户认为什么事情都应该是我们干的。

比如硬件集成商,就要负责上架,硬件检测,BIOS配置等。比如布线问题,什么时候布线,线材什么时候进场,谁来负责。比如数据项目,前期调研工作,应该是用户某领导来牵头。启动会结束后,会整理一个联系人清单,把各个相关方的责任人都明确出来。这些都是我们后面工作的前置条件,如果不讲清楚谁是负责人,不把问题提出来,可能会压缩后面软件交付工期。

关于启动会的输出件:主要有工作范围边界、联系人清单、沟通计划(清楚每个人的作用与角色,有什么事找什么人)、初步项目实施计划(分哪几个阶段,谁来负责,谁来配合,工期多长时间)。

项目计划在项目实施阶段中可能会临时变更,比如时间或者是实施方案,这个变更一定要让客户知晓。如果后续影响到了工期,一定要明确相关责任,规避风险。

规划

首先是内部的人力规划,要整理一个明确的人员管理图,每个人要有明确的分工,不要扎堆的往项目里面投。然后是ISV/集成商合作规划,要在工作界面内合作,定期碰头核对实施计划,产品到货时间等。

项目实施计划不是虚的东西,而是根据过往的经验实际沉淀下来直接拿来可行的东西,包含工作阶段细分,风险识别和判断。实施方案,需要跟客户汇报,得到客户认可,包括实施计划,人员安排。

另外,不要光关注项目,还要关注人的问题,比如驻场人员,什么时候进场,谁负责招聘,需要什么样的技能要求。在项目招标时就应该由项目经理提出需求。

执行

在执行前,一定要跟产品同学进行可行性交付确认,比如平台版本号,硬件是型号是否适配。

如果有多产品交付时,产品间可能会有依赖性。在交付完一个组件后,要完成相关的测试工作。测试过程要有记录和截图,最后整理输出测试报告。

执行过程中最重要的就是风险的管理,这也是对项目的监控。在做的过程发现有问题,一定要及时记录,每周在周报中的风险列表中注明。用好总部的技术资源,处理不了的风险,可能影响进度并且自己把控不了的,及时拉电话会议。项目经理作为第一责任人,需要拉通资源把问题处理掉,通过邮件要让领导,市场人员知晓相关事情。这也是规避责任的方法。

对于客户临时提出来的新需求,不要在现场直接把事情说死,需要回来讨论商量一下,然后再给客户一个答复。比如客户的需求,在当前版本无法实现,但是可以后期通过升级的方式解决。

在项目正式转运维前,有一个试运行阶段。在这个阶段,要按照测试用例,把整个过程完整的跑一遍。要把测试过程遇到的问题,如资源开通的过程,测试环境使用,网络性能不佳等,都要做记录。比如用了两天,网络不通了等类似情况。对于要求高的客户,可能会要求试运行报告有截图。

收尾

项目交付转运维要按照标准进行。交付同学和运维同学之间的责任交接,所有转运维资料必须齐备,运维同学也要主动核对验证,可以通过邮件的形式进行确认。

项目经理一定要关心项目的验收和回款。时间点和销售确认,合同里面也会有,提前准备初验、终验相关资料,比如开工报告、测试报告等。验收过程中如果遇到问题,要知道找谁来推进,什么时间点能够完成。

项目验收完以后,进行项目总结。输出的项目经验可以给其他项目参考,或者是项目问题总结。项目完结后,要感谢项目的支持人员。

其他经验

邮件

要有侧重点,比如通知高风险问题,除了表格里的风险列表,在邮件的正文也要强调出来,标题用请重点关注。发送人员也要关注,特别是对外邮件。

非标交付

一定要进行可行性交付确认,在项目下单之前就应该有,应该要让交付的人和产品的人一起确认本次交付件可行,发邮件确认,谁评估的。如果没人确认,直接发邮件说,此时无人回复,也没有人补充确认,只能遇到问题再解决问题,但是对工期是有影响的,影响工期大概是多少天。事情要做,更要形成文字记录。

平台升级

一定要拉着上游厂商项目经理,所有人拉到一起,这个项目今天一定要升到某个版本,还是什么,谁确认的,部分升级还是全部升级,原因是什么,整个升级的里程碑是什么,比如这个月升级什么,下个月升级什么,分别解决哪些问题。一定要记录,并且以群公告的形式发出来。

服务进入时间

一个项目在中标以后才参与有点晚,服务在中标时就要参与进来,比如项目要交付哪些东西,用户大概什么时候会购买设备,下单。跟销售和售前提前确认这些东西。

服务人员能力

不仅要对需要交付的产品功能熟悉,还要对服务产品也要很熟悉。要有足够的敏感性,有没有给阿里下服务订单,驻场订单有没有下,借货有没有,服务全不全。

最后,需要在实际项目中多积累经验,具体问题具体分析,多交流,多沟通。

0%