小唐刚刚完成了一个软件开发项目的实施，这是他第一次担任项目经理，项目的完成虽然有惊无险，但实施过程中出现的各种风险却让他想起来就害怕。他认真地对这个项目实施的全过程进行总结，以减少实施下一个项目时的风险，因为他已经得到总经理的通知，休息 2 周后，他将赴往某市，去负责一个更复杂的信息集成项目。
在管理当前项目的时候，重要的是实用以前的项目教训来改进公司的项目管理过程。因此，在项目结束过程中，重要的是评审风险识别清单。
项目特别容易招致风险，是因为每个项目在某些方面都是独特的，所以他不可能以这个项目为例列出将来要实施项目所面临的风险，他必须制订出权变措施，用来应对风险。管理储备也是必须的，什么事都要留有余地，包括时间和成本。

问以下经验是否正确？
对于如何规避风险，他总结出 4 条经验：关注能排除产生风险的因素；不去投标认为风险过大的项目；接受风险事件带来的后果；如果用户能更好地减轻风险的话，则将风险留给用户。
关于风险对资金的影响，他认为：在概念阶段（计划、启动阶段），风险最大，而对资金的影响最小；在执行和收尾阶段，风险会逐步降低，对资金影响也随之减少。所以，在概念阶段，要注意防范极高风险的发生。

黄经理担任了公司一个大型软件项目的项目经理，项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。项目组天天加班，保持了项目的正常进度，客户相当满意。但需求变更却越来越多。为了节省时间，客户的业务人员不再向黄经理申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快黄经理就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在的系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。

而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整一周的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。

随后发生的事情让黄经理更加为难：客户的两个负责人对界面风格的看法不一致， 并为此发生了激烈争执。黄经理知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决定调整所有界面，黄经理只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问黄经理，“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”

赵某是某系统集成公司的项目经理，负责某省科技厅情报研究所 863 项目的管理， 该项目由多家单位共同完成，赵某所在的公司为总承包商，另有某理工大学计算机网络实验室负责网络方面的设计和开发，科技厅下属子公司负责 UI 方面的设计和开发， 另有一家单位负责文档的整理。

在项目中，赵某发现项目干系人太多，沟通交流不方便，进度难以协调。虽然项目最终成功，但赵某觉得项目完成得不是很理想。

【问题1】分析下项目中沟通管理方面可能出现的问题

（1）项目沟通计划不健全
（2）对项目干系人的信息分发不到位
（3）未能采用项目干系人能接受的沟通风格
（4）多个项目干系人对信息的采集不同步或理解有歧义

【问题2】如果你是赵某，应如何制定沟通计划？

（1）识别项目干系人
（2）对项目干系人的信息需求和沟通风格进行分析
（3）针对不同的信息需求和沟通风格，使用正确的沟通技术
（4）注意信息的同步问题
（5）监督信息是否获得正确理解，并在各分承包商中不会有歧义

【问题3】多个单位的沟通中需要注意哪些事项以保证沟通高效而顺利？

在和多个单位的沟通中，应注意项目内外的区别，即对内有分别，对外要一致。

在和对方沟通时，采用对方能接受的沟通方式进行沟通。在召开会议前，做好充分的会议准备，明确会议主题和议题，力求把会议办成高效的、真正解决问题的会议。会议结束后应对会议进行记录，会议决策应分发到相关人员进行执行。

主题：如何管理强势的关键性技术人员？

【案例背景】

在项目中有一些关键性的技术工作，且这些工作在行业内部非常保守、国内技术力量薄弱——也就说技术工作人员难找。在我们团队里有一个这样的关键性技术人员，项目必须经过他这一环。在他这一环时，时间计划完全被他控制——他说要多少时间就多少时间，而且这个时间非常随意，不给我任何商量的余地，更不要说去控制。同时，这个工作环节很难找到人代替或外包，这个人对公司好像也没多少留恋可言，纯粹看钱办事。

目前来说，该如何处理呢？和他沟通、高层出面还是其他方法呢？

【解决方案参考思路】

从案例中可以看到，项目经理苦恼的是关键资源的进度失控。

进度控制是项目经理的本职工作，除非超出你的能力范围，这个沟通工作当然还得你本人来做。

项目属于服务及运营类，自开始至今已经历时4年，而且是两地开发，这中间出现了很多问题，说明如下：

1、项目管理沟通问题：因项目过大，本项目中公司领导层过多介入其中。加之项目团队成员90%都是一同进入公司的同事，一直是处于各司其职的状态，没有体现出项目经理对团队成员应有的关心和照顾。但是作为和成员同龄人的我这个项目经理，确实不知道该如何拿捏这个分寸了。有几个项目成员比我还大几岁，经验比我还要丰富。这个问题很困惑。

2、项目范围变化：该项目虽说是按项目合同方式来进行，但是实际运行中一般都是客户提什么需求然后做什么需求，如果客户某段时间无紧急需求，再将合同中的内容完成。(客户在合同签订后提出的新需求属于应业务及市场的需求，是必须要完成的)这样导致项目验收困难，范围模糊不清，目前采用的方式是互相抵消，多余部分算做下一期的合同内容

小张是某集团信息处工作人员，承担集团主网站、分公司及下属机构子网站具体建设的管理工作。小张根据学习的项目管理知识，制定并发布了项目章程。因工期紧，小张仅确定了项目负责人、组织结构、概要的里程碑计划和大致的预算，便组织相关人员开始各个网站的开发工作。

在开发过程中，不断有下属机构提出新的网站建设需求，导致子网站建设工作量不断增加，由于人员投入不能及时补足，造成实际进度与里程碑计划存在严重偏离；同时，因为与需求提出人员同属一个集团，开发人员不得不对一些非结构性的变更做出让步，随提随改，不但没有解决项目进度，质量问题时有出现，而且工作成果的版本越来越混乱。

[问题1]分析该项目在启动及计划阶段中的存在什么问题？

处理组织内的冲突一般可选择三种主要方法：结构法，对抗法，促进法。

结构法和对抗法通常假定冲突已经存在并且要求处理。结构法往往通过隔离各个部分来减少冲突的直接表现。与之相反，对抗法则力图通过把各个部分聚集在一起使冲突表面化，促进法则以缺乏“足够”的冲突的假设为基础。因此，促进法力图提高冲突的等级、数量或者同时提高两者。

1．结构法。
组织通常运用以下五种方法来处理冲突，即运用职权控制、隔离法、以储备作缓冲、以联络员作缓冲和以调解部门作缓冲。

（1）运用职权控制。管理人员可通过发出指示，在职权范围内解决冲突。这些指示指出期望下级遵循的行动步骤。例如，在同一家企业的两位副总裁可能都在拟定组织的策略。一位副总裁可能倡导以增产为基础，而另一位副总裁要求把权力集中到组织的最高层，这样，增产和集中权力的目标发生了直接的冲突。总裁则应该行使权力来确定执行什么目标。

某电子政务项目涉及到保密信息。项目建设的资源尤其是人力资源必须从甲方单位内部获得，因为如果把项目的部分任务交给分包商，一方面要征得甲方的同意，另一方面要求分包商具有相应的保密资质，而保密资质的审核需要很长时间，等待审核结果也需要一段时间，这将严重危及到项目的交付日期。

当项目团队内的工程师完成90%的编码和测试任务时，项目承建单位的一名副总裁承揽了一个新项目，他把程序员、测试工程师从该项目上调走，去执行他新承揽的项目。

[问题1]发生上述情况的可能原因是？
（1）可能是单位没有对项目进行统一管理，谁的权力大谁的项目就获得优先支持。
（2）副总承揽了新的更重要的项目。
（3）项目经理忽视了单位内可能的竞争性项目的出现所带来的风险。
（4）可能是本项目的绩效不好，已失去了本单位有关方面的支持。
（5）可能是重要干系人如客户、公司高层管理者内定项目暂停或下马。

为什么成熟企业会延迟推出新技术？
在解释成熟企业为什么会延迟推出新技术时，经常被提到的一个解释是：担心现有产品的销售受到影响。
但如果新技术推动了新市场应用领域的出现，那么新技术的推出可能并不一定会侵蚀现有产品的销售。
但是当成熟企业等到新技术在新的商业应用领域逐渐发展成熟之后，才为了抵御自己的主要市场所受到的冲击推出相关技术产品时，那它们对市场侵蚀的担心就将发展为一个自我应验的预言。
新产品的障碍似乎并非来自工程技术部门，反对声音主要来自市场销售部门和管理团队。

为什么成熟企业会对破坏性技术置若罔闻？
似乎被它们的客户牵绊住了手脚

价值网络
即一种大环境，企业正是在这个大环境下确定消费者的需求，并对此采取应对措施、解决问题、征求消费者的意见、应对竞争对手的竞争，并争取利润最大化

成熟企业决策模式
步骤1：破坏性技术首先在成熟企业研制成功
步骤2：市场营销人员然后收集公司主要客户的反馈
步骤3：成熟企业加快对延续性技术的开发步伐
成熟企业改善现有产品，而不是对新兴企业从低端市场发起的攻击做好防备
步骤4：新企业已经出现，破坏性技术市场在反复尝试中逐渐成形
步骤5：新兴企业向高端市场转移
步骤6：成熟企业在维护客户基础方面棋慢一招

项目复盘会，可以说是项目团队有意识地向过去的行为经验学习的过程。在项目或里程碑完结之后，项目经理会组织召集项目成员，一起回顾一下。

但是，现实情况经常是，项目一个接一个地做，没时间做复盘；或是为了复盘而复盘，逐渐地流于形式。今天，分享如何做好项目复盘，以及如何通过复盘去培养团队的持续改进能力。

一、复盘会的基调设定

我们都知道复盘很重要，但实际上，在复盘会之前，想清楚我们复盘的目的，设定好复盘的基调，其实更为重要。

要想让参与者真正进入集体反思区，会前就要设定好开放的复盘基调。

首先，我们自己要先进入反思区。在复盘会之前，可以跟部门/团队的负责人或成员，就部门中反复出现的各种问题，进行过多次深度沟通。把问题一层层地剖开来看时，我们就会发现很多问题背后的深层原因。

其次，在会议刚开场，就要展示出自己的开放与坦诚，给复盘会奠定基调：这次复盘不是来挑问题的，而是为了找到问题的根源并改进的。复盘会上，负责人可以先讲自己这一年来的深刻反思，这就带动大家敞开心扉，直面问题。会议结束以后，部门还可以发起一项“整风运动”，从增强用户意识的讲座，到用户调研方法的培训，再到激励与考核制度的挂钩，让复盘会反思的成果，逐渐渗透到了每个人的日常工作中。