IT项目经理成长手记

很多人觉得开会只是一个形式，没什么必要，但是，接下来，从制定项目沟通计划的步骤、项目与外部的沟通、非正式沟通的利与弊等方面来说明，开会是不是必要的，没有开会会失去沟通的机会，会让项目安排不明朗，无沟通会使项目降低效率！所以，开会也是任务。

开会也是任务-有计划地沟通

• 案例背景
  • 提前上线问题反思换位思考
    • 非常明确的一点：部分提前上线的起因正是沟通不畅造成的
    • 高层无奈
      • 客户高层推动项目也有很大的阻力
      • 对项目进展情况又弄不清楚
      • 从侧面听到的都是一些不利信息
      • 希望从项目组得到直接信息时却没有被认真对待
    • 结果
      • 误解逐步加深、信息不断失真
      • 最后采用部分上线的方案也是无奈之举
      • 强推新方案也有不同意见，只能通过政治任务的方式
  • 问题根源
    • 根源还是在沟通上！
    • 之前
      • PM特别反感会议和报告，怕多了之后影响项目进度
      • PM总是尽力阻挡各种会议，重要的会议也是派人应付
    • 现在
      • PM认识到会议、报告不但非常重要，而且是确保项目成功的一个重要因素
      • 必须把开会当成一项任务，而且要被有效的管理
  • 做为一名新的项目经理能及时反思就打补丁也是值得我们学习的
• 制定项目沟通计划的步骤
  • 沟通计划主要是为了解决沟通的规范化和制度化，在项目组内可以有效执行
  • 第一
    • 列出主要角色和关系，以及项目中的主要报告和会议的框架
    • 由项目组的PMO负责落实沟通计划的执行
  • 第二
    • 制定沟通矩阵来理清项目干系人之间的沟通关系
    • 沟通矩阵第一列代表信息的提供方，第一行代表信息的接收方，相关的交叉点上，就是两方的信息交互关系
  • 第三
    • 根据沟通矩阵确定沟通的方式、时间、频度、对象，制定详细的沟通计划。固定的沟通任务包括书面沟通和会议沟通两类
  • 第四
    • 将沟通制度化，重新梳理项目，制定会议沟通计划
• 项目与外部的沟通
  • 为了有效管理与外部的沟通，项目组采用了客户建议的-《业务联系书》
  • 业务联系书使用场景
    • 一
      • 需要正式地向客户提交文档，相当于签收的过程
      • 比如完成了需求分析，正式提交《需求分析报告》，同时提出评审申请
    • 二
      • 需要从客户索取资料，或者需要必要的信息和正式答复
      • 收到对方承诺之后，则记录在案并按时间要求进行跟踪
    • 三
      • 跨部门布置项目工作时，相当于任务书
      • 比如，需要网点资料的调查信息，则可以通过业务联系书的方式提出申请，并提供调查的文档模板
  • 例子
    • 最近一次测试中，发现合作厂商的“系统接口异常”
    • PM通过正式的业务联系书发出了请求，落到文字+时间限制，接收方会重视起来。即使不能按期解决，也会按期回复将如何处理
• 非正式沟通的利与弊
  • 利
    • 客户反映远程监控系统“根本不能用”，结果原因是用户界面不友好，而工程师态度比较生硬，客户不满，从而作出上述结论
    • 会前的非正式沟通可以了解各方要反映的问题，提前解决
  • 弊
    • 一名骨干调到其他项目组，在PM还没跟客户沟通之前，这名员工就到客户那里告别了，并表示是因为关系好“私下先透露一下”
  • 人事变动沟通遵循的原则
    • 当事人不得事前直接与客户沟通自己变动的情况
    • 原则上必须由其上一级负责人与客户进行沟通
    • 必须同时说明替代的解决方案，并征得客户的同意
    • 不得在人事变动沟通完成前，擅自进行人事变动
• 经验与教训
  • 沟通是确保项目成功的一个重要因素，项目经理可能80%的时间都花在沟通上，沟通也需要好好计划，识别沟通对象和信息要求，并确定正确的沟通方式