项目管理之路（2）：第一次项目例会

转眼间人力系统项目已经开始实施，虽然项目到现在为止也还是有很多问题，但是踉踉跄跄还是走到现在，召开了第一次项目例会。

有了之前项目启动会的教训，这一次项目例会放在心上多了，不过好在问了同事后得知项目例会因为没有领导在所以没有这么正式，也不需要做ppt，前期的话要准备会议要讨论的议题，心里要有项目例会的计划和节奏把控。

一、准备工作

项目例会的目的是为了总结研讨项目当前的进度，讨论当前遇到的问题及解决方案，以及接下来项目的计划。准备工作也是要围绕着着三点来进行：首先要看下最近的项目周报（乙方项目经理已经提供了两周的周报），看一下项目进度中的进度、风险以及问题，然后组织一下语言和节奏进行总结，在项目中进行讨论；然后要列举一下项目当前以及接下来遇到的或者可能遇到的问题，形成简要的word文档以备例会使用；最后讨论一下乙方的接下来的计划（这个项目我们是甲方，主要的活都是乙方来干，我们主要是推动跟进协调）。

二、例会召开

（1）项目进度讨论

首先，讨论一下当前项目进度。目前项目已经完成了蓝图初稿，乙方内部提交研发的需求已经完成一半，部分组织、人事模块已经开始开发。进度方面需求和开发进度基本正常，但是项目蓝图已经提供了将近一周，但是由于人力部至今还没给出反馈，这里面既有人力部比较忙的原因，而且需要确认组织、人事、薪酬等模块需要人力部不同的二级部门来确认，但是人力部门接口同事兼顾协调众多方面需求由一定的难度；也有我的原因，我没有对连续两周周报出现的这个问题予以足够的重视（惭愧！我的工作失误！）；还有，乙方是一家创业公司，人手比较紧张，乙方的项目经理也是乙方实施部门老大，需要兼顾几个项目，也没有完全投入。这个问题是我们三方共同的问题，由于三方都不是专职这个项目都有另外的事要办，这个事情可能会长期存在，但是我作为PMO人员职责所在应该紧密跟进。同时，人力提供业务资料也存在这个问题（人力提供过资料，但是不齐全，只是一部分）。

经过讨论：

1.项目蓝图确认问题采取功能模块验收时确认的方式，同时一些基本的标准功能确认应该人力部应该加紧确认（后期乙方驻场人员进场后也会加紧跟进）；

2.人力提供业务资料问题，人力同事表示昨天又提供了一次，已经齐全。请乙方项目经理会后检查确认是否已经齐全。

（2）项目问题及风险讨论

1.目前人力系统的审批流程涉及到和OA系统的对接改造，但是双方有一个衔接问题，人力部门希望项目一期能够上线，但是目前离一期上线只剩一个半月了，但是己方OA改造项目尚未立项，还要经过立项申请、审批通过、商务、合同阶段。时间比较紧张，必须要分工组织开始启动。

会议讨论结果：人力部门推动项目立项，我负责协调沟通OA开发商工程师和乙方尽快开始接洽。

2.人力系统薪酬部分涉及到和财务系统对接，涉及到一个复杂的情况就是，原本我司的人力系统和财务系统都是用友的，所以之前对接不存在问题，但是现在换掉他的人力系统，却还要和他的财务系统对接肯定是得不到协助的（用友得知后，在我们和乙方商务走完后还特意分别联系过财务、我和人力，希望我们能够继续使用升级用友人力系统，被我方说明情况拒绝）。项目采用的方案是乙方聘用用友自由顾问的方式来解决对接问题，个人觉得这样其实风险很大， 这个事情能否做成全部集中在聘用的自由顾问上，出了问题其实我们甲乙双方其实并没有太好的办法，风险高度集中而且还是集中在甲乙双方外的第三方。

会议讨论结果：事不宜迟，乙方尽快（下周一）开始和聘用的自由顾问开始商讨实施方案并尽快反馈项目组情况。

3.数据初始化问题

目前乙方制定的计划是在系统配置开发完毕后，再进行数据导入，但是我方认为这样会不利于后期开发测试的迭代调整。

会议讨论结果：尽早开始导入数据到测试环境系统（目前已经搭建好），方便后续效果检验来调整开发。

4.考勤问题

目前我司考勤方式比较原始，除了总部以外，各个分支点均有考勤机，考勤机之间互相不连通，相当于单机版，形成的数据会各自存储，然后每月由各地人力专员导出形成表格，最后提交人力部。项目初期计划能够让人力系统连接各个考勤机，形成的数据直接送入人力系统。但是经过咨询目前考勤的情况，大家讨论后觉得初期计划的改造都不现实。

会议讨论结果：一期采用各个人力专员按照格式导入到人力系统（人力专员工作量没变，但是会减少人力部工作量），人力部目前有考勤机改造计划，但是一期应该是赶不上了，后期由考勤机改造后再行实施。

（3）近期计划

在保证会议结果：下周驻场人员进场、用友顾问接洽、业务资料确认、蓝图确认的情况下，按照计划推进需求文件、研发配置等事宜。

同时，建议项目验收时要分模块分功能提供验收，以免等到整体再验收出现问题难以解决。

三、会议总结

会议在最后总结很重要，要落实会议讨论的事项的最后责任人。第一、这个意味着本次会议讨论的各个事项由谁去落实。第二、总结可以再次确认会议成果，避免因双方理解分歧而造成的误解。

四、会议纪要

虽然本次会议不像商务会议一样正式，也没有领导参与，但是也还是要撰写会议纪要，会议纪要内容以会议最后的总结为基础，组织整理一下语言形成文档是对会议结果各方的确认。

一般以邮件的形式（邮件可以留痕所以代表比较正式的方式）发给各方，并且抄送给各个项目干系人以及领导。虽然项目例会列席的只有人力部、乙方、信息部，但是还由很多人也有一定的项目相关度，比如说财务同事（涉及到财务系统对接）、运维同事（运行维护人力系统）等；其次、乙方的一些领导也可以抄送，包括乙方的商务以及一些领导（让对方领导知晓，可以在项目进度滞后或者出现问题可以施加一定压力）；最后，还有我方的领导，领导虽然不一定会看，但是领导万一想看就可以随时查阅，或者事后领导如果问起为什么没有汇报情况也有邮件留痕。

五、总结

这是本项目的第一次项目例会，也是我召开的第一次项目例会。虽然在其他人看起来稀松平常，但是无论对于我还是对于项目本身都是小小的里程碑，也有一些总结感悟。

（1）请教同事。召开例会之前还是要多请教有经验的同事，尤其是对于我这样没有经验的菜鸟，请教之后就会对例会有个大致的认识和准备，如果可以的话可以邀请一起参加。

（2）提前准备。要在提前计划一下议程（要做到心中有谱），准备一下例会要讨论的问题，可以用文档列举一下，还要提前打开近期的项目周报、项目计划之类的资料。

（3）注意记录。会议过程中要记录一些讨论的问题及结果，可以简单的记载一下，能记住核心信息就可以，也有利于会后形成会议纪要。对于我这样记性不好的人来说尤其必要。

（4）各方确认。会议的最后一定要把所有事项以及责任人回顾一遍，得到各方确认，理由前文有提不再赘述。

（5）会议纪要。虽然会议最后确认过，但是会议纪要发出去之前要给各参会人都确认一下，以免出现问题。

心态要好，明白当下自己能力欠缺还是太多，多历练，现在就是交学费的时候。只有能力经验起来后，机会来的时候才有可能抓住。加油！

转载于:https://www.cnblogs.com/s2390304938/p/9309260.html