通信项目策划管理要点分析

1、通信项目治理治理要点分析1、项目组织运作由于一些通信设施建设中需要大量复杂的协调工作 , 往往并非通信 项目建设单位自身力所能及，如关于电信网络的建设，项目承建方往往 无力协调通信企业的各部门如传输、网管、基建、打算、电源等工程相 关部门的合作。在这种情况下，通信企业往往必须与项目建设单位一 样，针对同一项目抽调专门项目相关人员，还可能成立自己相应的项目 治理组织，协调配合项目建设单位的项目治理组织参与项目建设。现 在，项目建设单位，项目业主人员，还可包括如项目设备制造商、系统 集成方、技术提供方、项目设计单位等不同项目治理和项目工程人员面 临如何工作协调配合的重要问题。解决这一问题的做法要紧

2、有；（1）成立统一的项目治理组织，同时共同成立项目决策委员会，决 策人员由双方共同 担任，共同协商进行项目决策。（2）各自成立项目治理组织，各自负责项目工作中的一个部分，同 时协商彼此的工作接口，明确项目的工作程序。这种项目治理组 织方式便于分工协作，明确各自责任，但必须有明确的分工和规 范化的工作接口程序规定，否则会出现推诿责任的情况。（3）以通信企业成立项目治理组织运作为主，适当汲取项目建设单 位等部格外部人员参与项目治理。在这种项目治理组织的运作 下，通信企业容易把握项目目标的实现，容易进行通信企业内部 有关的工程协调，易于通信企业项目决策，但同时通信企业需要 担负相应的项目决策责任。与

3、此同时，能够依照部分 IT 企业的做法，依照项目的不同时期以 及不同内容，在通信企业中成立相应的项目小组，如：项目领导小组：要紧负责审批项目打算、对重大情况进行决策 （如 项目范围、项目风险等） 、组建验收小组并主持验收工作；项目验收小组：属于项目竣工后临时成立的组织，一般由项目领导 小组主持，各相关部门人员参与，要紧职责是确定验收内容，并组织项 目验收；质量监督小组：要紧负责在系统实施过程中对工程质量进行监督， 一般由技术上较为资深的第三方参加；项目执行小组：要紧职责是制定和操纵项目打算、合理安排资源、确定业务需求等；项目实施小组：要紧负责主机、数据库、各平台软件的安装与调试项目文档小组：制

4、定项目文档治理打算及文档的输出、归档等；项目支持组：要紧针对技术难题的支持和问题的远程处理，在项目 实施过程中支持组无须全程驻扎在现场。项目组织结构应保证用户的充分参与 ，并充分发挥项目组织中用户 资源的积极性。高效健全的项目组织结构是项目成功实现的有力保障。 项目组织结构也要求每位成员必须能胜任其角色任务，承担相应的责 任。2、项目沟通是润滑剂项目沟通治理的目的是使项目组内部成员和项目干系人能及时 、准 确地得到他所需要的信息，并能正确地理解相关信息。良好的沟通机制是项目各干系人之间思想交流的重要保障 。有效的 项目沟通治理，使全体项目组成员的思想高度统一、步伐协调一致。因 此，项目沟通是项

5、目治理的一个重要组成部分，也是项目治理成功与否 及执行好坏程度的一个关键问题。一个项目涉及到的各种未知和风险因素专门多 ，需要协调的情况也 多。项目经理的任务之一确实是做好沟通和交流。项目的沟通包括项目 组内的沟通及项目组与外部之间的沟通。项目组内的沟通要紧指项目组成员内部的交流沟通 。为了让项目组 每个成员都能专门好地领会项目的目标和下一步打算 ，让每位成员都清 晰自己的任务和责任，项目经理必须保持与项目组成员的日常沟通，听 取每位成员的工作心得及其工作进展情况 ，激励项目组成员的工作积极 性。随时的交流与沟通：关于重大的工程，会不定期地或在每天下班后进行一次针对当天工作情况的小沟通，时刻较

6、短，通常在十几分钟内， 目的是为了及时发觉项目中出现的问题，并讨论解决措施。定期例会：每周五或周一项目组内部有一个定期交流会，主题是互 相交流一周内的工作进展情况；分析差不多出现和潜在的风险与问题； 总结项目实施中取得好的经验 ，以保证每一位项目成员在项目中都能发 挥出良好的作用。与上级主管的沟通：除了定期的周报和月报，项目经理应与上级主 管保持随时的交流与沟通。假如发生突发事件或重要情况，项目经理应 立即与上级主管联系，使问题得到及时反映和解决。项目组外的沟通要紧是与用户之间的交流和沟通 ：此类沟通的目的 是，使用户及时了解项目进展情况，保证项目按照打算和用户要求的方 向推进，使用户认同项目

7、的进度并建立预期。除了平常的口头沟通，项 目经理负责依照项目治理规范中的沟通打算 （比如双方定期的工作进展 报告、交流），反映项目实施中出现的问题，并与用户协商解决方案； 正式提出需要用户提供的支持或配合事项及需要用户确定的业务流程 等。在现场时，我们每周都会与用户进行周例会总结工作、制订打算， 并配合解决工作中遇到的相关问题。每周的例会邀请用户相关各部门的领导参加 ，有决定权的领导的出 席，交流会才有效果。我们应积极进行协调，主动邀请用户主持此类的会议。通过增进与用户的沟通，分散和降低项目实施的风险，保证项目 最终的顺利割接和验收。所有与用户之间的交流沟通 、项目组内部每周的例行沟通都要列入

8、会议纪要，并统一作为项目治理的文档输出一部分。项目沟通的方式能 够多种多样：可采取面对面沟通、电话沟通、电子邮件沟通、传真沟通 或书面报告等多种方式。沟通是信息的传递，也是相互之间加深了解的 桥梁，作为项目经理，必须掌握一定的沟通方法和技巧。3、项目责任界面要清晰一个项目的成功往往涉及到多方的合作，特不是需方的参与。在许 多的工程项目中我们发觉：客户会产生一种依靠性，认为我花钞票买了 你的业务 ，应该什么差不多上你来做 ，我只需看到预期的结果 。实际上， 一个项目的成功专门大程度上取决于供、需双方的配合程度。经常有遇到过因责任界面不清晰而导致项目成本大幅上升甚至项 目失败的情况。在某个 112

9、 系统的项目实施中，因对测试头进行调测时 涉及到修改交换机数据，需要用户配合完成，但用户认为合同差不多签 订，全部的工作都要由供方来做。经多次协调，用户同意修改，却提出 每个交换局必须由供方支付费用的要求，如此的情况，整个项目显然已 无法再进行下去。回过头来考虑一下不难发觉，假如在技术方案或施工 前期明晰双方的责任界面，就可不能发生此类情况。项目责任界面按不同的实施时期进行划分 ，明确列出哪些是需方的 责任，哪些是供方的责任，并标明完成时限。如此可有效幸免施工中的 种种被动局面的出现 ，并促使项目在双方的共同协作下朝着既定的方向 进展。4、项目打算要到位项目打算是由治理者对资源、成本和进度进行

10、合理的估算。项目打 算的目标是在治理者与项目之间、项目组内部达成共识。打算编制作为一个项目实施打算，必须通过项目经理的深思熟虑：考虑要周密，资源利用要合理， WBS分解要细致、可控。项目打算的编制工具采 纳目前流行的项目治理软件 PROJEC，T 在项目打算制订前，客服事业部 结合以往的经验制定出不同产品线 （或项目）的标准WBS分解表模板。模板是在先前一系列项目执行过程当中总结出来的较为合理的工作打算和工作量基准，一般要求每个 WBS子项不超过2个工作日，关于 一些小的但高频次出现的工作也必须单列，如周报、对用户每周的汇报 等。项目经理只需按照标准的 WBS分解表制订打算，其中由于工作量和

11、使用项目资源的不同，在时刻上也存在差不。同时由于诸多项目之间存在相似性，采纳标准WBS分解表将大大简 化项目经理制订打算的工作量，同时也增强打算的可操作性。项目打算 的制订必须按照关键路径法列出项目里程碑，如此，在进行打算操纵时 我们只要重点操纵关键路径即可。项目打算在实施前还必须由项目经理提出由项目执行部组织进行评审，打算评审合格方可进入现场施工，并在现场与用户进行确认。评审合格后的项目打算统一纳入配置治理。打算实施与监控关于项目打算的监控，在某大型通信项目中，我们要求“三天一回 忆，一周一总结”，即要求项目经理每三天就要比较项目执行的实际情 况与原项目打算 ，检查是否偏离了打算 ，如有偏差

12、 ，则要及时采取措施。 每周要求对上周的打算执行情况进行分析总结，并修正下一步的打算， 相对大的项目除总结分析本周打算进度，还必须编制双周滚动打算，并 知会全体项目实施成员和项目干系人。打算变更关于项目打算的变更必须有变更流程。我们在操作过程中规定：关 于三天以内的打算变更，直接由项目经理确定，但必须在项目打算中标 明并通报项目各干系人；假如是一周以内的打算变更，则必须由项目执 行小组审批 ；超过一个星期以上的打算变更必须报项目领导小组审核或会议讨论，同时采取紧急处理措施。项目打算是项目执行的一条准绳，只有合理的打算和定期的监控，才能保证打算的持续有效性。5、项目评审特不有必要项目评审一是确认

13、预备工作是否充分 ，让项目组成员对项目实施内 容做到心中有数、有据可依，并确定项目绩效系数；二是确定项目实施 结果，进行总结交流以持续改善项目治理方法，并评定项目绩效；三是 引入第三方，加强对项目的监控。项目评审要紧依据项目标准 WB、S 项目实施打算、项目实施治理规 范、项目费用预算、项目绩效评估方法、项目输出文档、项目移交情况 （含项目质检内容） 、客户中意度调查和项目总结报告等。项目评审通过第三方在项目开始前对项目目标、项目范围、工作分 解、资源使用、项目组织、项目制度、责任界面、项目文档、沟通打算、 风险操纵、质量治理、费用预算、项目激励等内容进行评审，评审其科 学性、规范性、逻辑性和

14、合理性等等 ；在项目结束后对项目实施的进度、 费用、质量、文档、客户中意度等方面进行调查、总结和改进。项目评审的目的是：在事前做到对项目实施成本和风险的充分可 能；对项目进度打算合理论证；积存经验、逐步提高、逐步完善项目治 理。6、项目范围治理不能忽视在以往的工程施工我们曾有过如此的经历 ：专门早就听讲一些系统 要竣工，却迟迟未能峻工。什么缘故？这是因为用户对系统的参与比较 深入，同时也提出诸多需求，在这些需求中，有的已超出合同范围，实 际上，用户方使用部门的人员对当时合同情况不知情，他们只是从系统 的实际应用情况动身，认为需要增加功能。关于我们的工程人员来讲， 情况却越做越多 。根源在哪里？

15、确实是我们没有在项目一开始就做好范 围治理。范围治理要紧包括如下内容：项目范围的确认项目经理依照合同方案及配置的定义整理出合同项目的项目范 围，要求项目范围描述详细到系统各模块的子功能点；整理出来的项目 范围需要开发项目组、销售项目经理 / 客户经理共同确认，并作为初稿 纳入项目治理规范的项目范围章节。项目开工时，必须与用户共同确认 项目范围的定义，在项目范围确认书上签字。确认项目范围变更在项目实施过程中 ，项目组每个成员都有义务积极承担确认项目范 围变更的角色，一旦发觉范围变更即立即与项目经理进行沟通。项目经 理有责任组织讨论并确认变更类型： a) 确是范围变更， b) 只是范围定 义不清晰

16、，C)适应性改进或错误。假如项目组不能达成一致意见，则把 该问题上报项目领导小组解决争议。关于情况b)，项目经理应向全项目组员阐明。关于情况 C) ，则项目组内部先解决排除，若需其他成员支持按服务流程中的问题单流程处理。关于情况 a) ，接着如下步骤。评估项目范围变更的阻碍所有被确定的范围变更将被分配一个序列号 。项目经理有责任写成 文档并评估它对项目打算、资源和成本的阻碍。项目范围变更申请依照变更的描述、分析以及对项目的阻碍评估，项目经理写出申请报告向双方项目领导小组申请，以便该变更被批准或拒绝。假如范围变更被拒绝，项目经理必须在项目会议上向项目干系人通报该信息。项目治理相关内容的调整和确认

17、假如范围变更申请被批准，项目经理必须修改项目治理相关内容，包括项目范围、打算、资源、预算等，并在下一次项目会议中向所有的 项目成员宣布所修改的内容。项目时期性范围治理要求项目范围治理流程开始于项目经理在项目启动会上向项目组成员 宣布最初的项目范围 。该流程将在每个时期开始时都由项目经理重复一 次。在每个时期的结束时，项目经理需再次传达经修改的项目范围，并 特不强调在本时期修改的内容。关于范围治理不仅包含范围的扩充，也 包含项目范围的缩小 ，假如出现因客观缘故原订合同范围内的内容无法 实施等重大变故，我们必须将相关已实施的内容、下时期实施的内容和 变更的内容按时期整理并公布 。在项目交付时项目经理必须提交项目范 围变更表。项目风险治理是必要的项目一旦启动，风险就与之并存。项目经理必须具备识不风险的能 力，并力求将风险消灭在发生之前，关于无法安全回避的风险，必须事 先制定风险补救措施，将风险的危害程度减少到最小化。风险的治理一般包括 ：风险的识不 、风险的分析 、风险的预防措施、 风险的补救措施、风险的启动条件等。识不出风险后，分析风险存在的 缘故，造成的危害，并分析风险存在的可能性及危害程度。关于风险的 可能性和危害程度我们一般采纳量化的方式 ，如将风险的可能性分为三 个等级， 3为发生的可能性极大， 2为可能性中等， 1 为可能性较小； 危害程度我们也能够