聊聊IT项目建设中甲方项目经理的重要性

引子

信息化建设的好处和需求日益凸显，越来越多的企业选择南京学思，在此，南京学思向广大用户致以诚挚的感谢!

当下，信息化系统的复杂度和精细化程度越来越高，对项目多方配合提出了更高的要求。项目是否能够成功达到各方预期并落地运行，依靠乙方单方面的工作是不够的。甲方的项目经理的把控和协调工作十分关键。

信息化建设是甲乙双方共同合作的项目。甲乙双方之间可能存在对项目理解角度不同，知程度不同等情况。用户作为甲方采购软件产品和软件服务。项目在甲乙双方处理中侧重点不同：站在甲方立场看，是一个软件应用项目;而站在乙方立场，则是一个服务项目。双方的项目的目标和范围是不同的，尽管都由启动、计划、执行、控制和收尾几个过程组成，却不一一对应。甲方在软件应用项目中的采购管理过程，将甲方软件应用项目与乙方软件服务项目联系在一起，其中的合同管理对应甲方项目的执行和控制过程，对应乙方的计划、执行、控制和收尾过程。认同这个道理后，甲方在项目中是要承担很多责任的，准备工作和配合工作做到位，才可保证项目成功，实现双赢，尤其在复杂的大型信息化建设项目管理中更应该如此。
实际操作中，项目结果往往不能尽如人意。

甲方项目经理张三的故事

立项后，甲方领导层指定张三为甲方项目经理。被委以重任后，张三热泪盈眶，马不停蹄查阅资料，协调人员，召开项目启动会。各部门主管领导积极参与，一个迟到的都没有，领导从一百个方面表达了项目建设的重要性和必要性，各主管部门胸口拍的咚咚响，承诺实施过程中有求必应，任劳任怨。

实施后，张三发现，协调和安排在执行层出现阻力。执行层抗拒工作模式的变更，不满于眼下工作量的增加，便反馈相关负责人。负责人迫于客观上的生产压力，向张三提出质疑。滚雪球一般，一个部门接一个部门或者所有部门一起，找张三甚至越级反馈问题。

面对冲击， “硬派”张三申请管理手段，压制各层的反弹，强制推进项目。项目成功了，张三的人际的关系没了。“软脚”的张三，向建设方施压，通过改变流程，或者增加功能来缓解推行阻力。殊不知这些调整，已经背离项目的立意，长此以往项目实施偏离正轨，项目成功上线遥遥无期，张三日不能食夜不能寐。更有张三“先硬后软”或者“先软后硬”。系统达到一定的“平衡”后，便是仓促上线，数据跑通，便匆忙组织验收，汇报成果。久之，信息化系统或无人问津或者碎片化使用留有一点门面数据展示。张三最终感叹：信息化项目经理能自保、交差不错了，不奢求干出什么成就了。

张三的复盘

1、领导强调重要性和必要性，张三作为项目经理很擅长重申这两点。除此以外，张三没有什么其他有效措施。事后张三总结了信息化项目的本质，即实现从人性化管理到信息化流程管理的转变。而信息化管理某种程度上达不到人性化管理的柔性和变通性。信息化管理建设上，哪里是去人性的，哪里是多样性的，这种颗粒度需要提前了解。

2、项目初，张三缺乏对项目的风险评估及预备方案。遇事基本靠卖人情处理，不行则请“尚方宝剑”，即斩向内部也施压外部，没有缓冲余地。

3、懂得召开项目启动会，张三的组织能力已经强过不少项目经理了。但启动会议仅用来表决心、表忠心就把一个关键节点给浪费了。没有整个项目的推进计划，工作安排，难点重点，节点日期在会议上就立刻公布，启动会就只能流于形式，在项目推进中起不到作用。

4、“把项目做好”不是一个有效的项目目标。有效的项目目标需要在初期规划分解好。信息化项目不是一蹴而就的，是个循序渐进从无到有的过程。这就需要给每个涉及到的职能部门规划目标，时间节点事务以及目标效果。

5、执行层对信息化工作有误解，觉得这件事就是给他们增加工作量，把原先的成果推倒重头再来。只有张三的宣贯工作做到位，才能引起执行层的重视，使其认清形式权衡利弊，做出积极调整。信息化项目必然会有阵痛，但完成后会大量减少重复劳动以及人工错误。宣贯工作不能继续强调重要性和必要性了，而是及时向执行层公布他们工作的意义、成果和汇报。

6、张三在遇到信息化功能及流程问题时，不应一味的施压应用方或实施方，要听取双方的意见，某主任可能说的功能或者流程，能够加快系统的数据流或者降低应用难度，但张三要站在整个信息化管理的角度，保障数据流及功能全面安全的情况下，进行相应的意见采纳，给出合理的变更方案。

7、张三要把控好项目方向，信息化建设项目是企业的信息化建设项目，不是某个部门某个人的项目。不能因某部门说数据录入难度大就简化数据颗粒度要求，更不能因某关键流程缺失而放弃在系统里添加。该坚持的时候不能退缩。

8、张三在此项目上线阶段已没有节奏可言，是为了上线而上线，并非真正落地投产，有数据便草草结项。殊不知系统要真正投产，上线阶段必须有节奏地稳扎稳打，让系统上下游职能部门相互依赖，最终相互督促，才是系统落地自运行的最好办法。

9、结束项目后，张三没有做好运维的工作。一是没有指定系统维护人员，二是没有指定系统使用的监督人员，致使系统上线后渐渐没落，成为面子工程。

张三缺位的后果

上述故事中，至少还有个甲方项目经理张三。在其他的故事里，甲方连张三都没有。由于甲方没有一个具备专业知识，能够统筹管理项目的人。乙方不得不逐一判断甲方的项目干系人，致使双方的沟通成本大幅提升。且由于甲方没有一个可以决策的人物，项目推进容易进入各部门“踢皮球”的状态。项目推进难度由于没有项目经理的剧中协调，更是指数级提升。且有大量未经论证的需求被追加到项目中来，导致项目原先目标的偏移，甲方无人掌控项目进度，最终导致项目拖期或项目流产。

综上所述，信息化项目建设中，甲方项目经理至关重要。甲方项目经理应如何开展工作，才能有力保障信息化项目的成功落地呢？

本文项目经理化名张三，是一部分项目经理的缩影，不代表全部。文章宗旨是剖析问题，改进工作，降本增效，如有失当之处还请海涵。真理越辩越明，有不同看法的读者，欢迎评论。

甲方项目经理工作的关键节点

话接上文，一个信息化建设项目大致划分为以下几个阶段：项目启动、调研设计、开发部署培训、上线运行及验收。甲方项目经理习惯将重点放在开发部署培训以及上线运行阶段，殊不知项目启动及调研设计阶段才是项目迈向成功的关键。

项目启动

项目启动会是项目启动的最后阶段。开项目启动会的目的是对项目启动阶段的成果进行盘点和确定。双方项目经理应围绕项目启动会议，做好项目风险评估，分解好项目阶段任务，明确好各方责任。

甲方项目经理要在启动阶段完成如下工作：

阐明项目的投入产出分析及关键风险说明，明确项目管理制度章程；

搭建甲方项目组，明确相关各部门单位的关键干系人，发布《项目组人员名册》；

 

明确甲方人员同乙方人员的沟通工作流程。明确重点事项的决策人、负责人、联络人；

制定一个完整的项目计划，明确项目组各部门单位的工作，公示相关工作时间进度表。这里要强调，软件的项目计划重在“准确”而非“快速”。最终签署并发布《项目实施计划》。

 

调研设计

项目调研设计阶段，对于控制项目走向非常重要。在这一阶段，往往出现乙方信息化人员认为甲方业务的需求不清晰，而甲方业务人员认为自己的需求已经十分清晰。为此，甲方项目经理需要充分参与甲乙双方各业务层次人员访谈、会议、调研问卷等工作，协助乙方将甲方的业务需求，对应到信息化功能层面，具体包括业务流程，流程所涉及的岗位、单据、报表，以及各种单据和报表之间的计算关系等等。如有必要，可制定需求分析报告的框架，针对关键点形成文档。

 

需求调研报告完成之后，乙方人员会同甲方人员进行需求分析，之后编制需求规格说明书，即我们常讲的概要设计。同样，甲方项目经理对需求规格说明书也要有一个评审确认的过程,确认的过程同调研报告的确认过程大致相同。

 

此阶段最重要的成果是两个文档，即《调研报告》及《设计方案》，甲方项目经理的工作重点是将这两个文档中描述的内容细化，不要怕影响进度。因为通过对历史项目的复盘，我们得到一个结论：项目时间最多浪费在不对称信息的沟通交流及反复。因此，前期通过《调研报告》及《设计方案》将信息内容明确与细化，甲乙双方达成共识，项目的推行会方便、快捷和顺利。

开发部署培训

在开发部署阶段，乙方根据双方确认的需求规格说明书进行开发实现。甲方项目经理要跟踪开发工作中的风险：对开发完成后部署的系统与各应用单位关键人一同进行功能测试及确认；对不满足需求的，要及时提出整改或变更；对满足需求，要求乙方召开培训会议‍对系统进行针对培训；同时编制操作说明书，并组织甲方项目组，根据操作说明书制定甲方自己的使用规范。

 

上线阶段

上线阶段是决定项目能否成功落地的关键阶段。在此阶段乙方项目组成员发挥的作用相对次要，主要由甲方的项目组承担推动工作。甲方项目经理应充分调动甲方项目组，根据计划严格保证上线的各个节点。推进步骤可分为:

发布系统操作说明书及使用规范；

制定上线计划，按计划节点严格推行系统上线；

组织收集上线问题及意见，与乙方沟通进行调整或变更；

稳定上线成果，上线不成功的，及时组织各方会议，明确整改内容。上线成功的，持续推行上线使用，如有必要，可将上线工作任务作为常态化工作进行考核。

验收阶段

 

验收阶段是对项目成果的汇总及总结。经验不足的甲方项目经理对验收有误解，认为只要系统能“跑起来”，就能组织验收。其实不然，验收会议目标是对项目建设的成果进行沟通确认，甲方项目经理要在验收会议之前，组织类似“预验收”的会议，将各部门使用情况进行沟通汇总，提前处理好矛盾问题。并对项目的《技术协议》及《设计方案》进行梳理，提前查漏补缺，避免将验收会议开成“申诉会议”。

最后，甲方项目经理在此阶段要严格按照相关项目章程文档，对项目内容进行逐条验证验收。（文章来源：南京学思 CSD-30）