项目管理12点思考

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

欢迎共阅

项目管理12点思考

1、项目组织运作

由于一些通信设施建设中需要大量复杂的协调工作,往往并非通

信项目建设单位自身力所能及,如对于电信网络的建设,项目承建方

组织方式便于分工协作,明确各自责任,但必须有明确的分工

和规范化的工作接口程序规定,否则会出现推诿责任的情况。

(3)以通信企业成立项目管理组织运作为主,适当吸收项目建设单位等部分外部人员参与项目管理。在这种项目管理组织的运作

下,通信企业容易把握项目目标的实现,容易进行通信企业内

部有关的工程协调,易于通信企业项目决策,但同时通信企业需要担负相应的项目决策责任。

与此同时,可以根据部分IT企业的做法,根据项目的不同阶段以及不同内容,在通信企业中成立相应的项目小组,如:项目领导小组:主要负责审批项目计划、对重大事情进行决策(如

目实施过程中支持组无须全程驻扎在现场。

项目组织结构应保证用户的充分参与,并充分发挥项目组织中用户资源的积极性。高效健全的项目组织结构是项目成功实现的有力保障。项目组织结构也要求每位成员必须能胜任其角色任务,承担相应的责任。

2、项目沟通是润滑剂

项目沟通管理的目的是使项目组内部成员和项目干系人能及时、准确地得到他所需要的信息,并能正确地理解相关信息。

良好的沟通机制是项目各干系人之间思想交流的重要保障。有效的项目沟通管理,使全体项目组成员的思想高度统一、步伐协调一致。

内,目的是为了及时发现项目中出现的问题,并讨论解决措施。

定期例会:每周五或周一项目组内部有一个定期交流会,主题是互相交流一周内的工作进展情况;分析已经出现和潜在的风险与问题;总结项目实施中取得好的经验,以保证每一位项目成员在项目中都能发挥出良好的作用。

与上级主管的沟通:除了定期的周报和月报,项目经理应与上级主管保持随时的交流与沟通。如果发生突发事件或重要情况,项目经理应立即与上级主管联系,使问题得到及时反映和解决。

项目组外的沟通主要是与用户之间的交流和沟通:此类沟通的目的是,使用户及时了解项目进展情况,保证项目按照计划和用户要求

式可以多种多样:可采取面对面沟通、电话沟通、电子邮件沟通、传真沟通或书面报告等多种方式。沟通是信息的传递,也是相互之间加深了解的桥梁,作为项目经理,必须掌握一定的沟通方法和技巧。

3、项目责任界面要清晰

一个项目的成功往往涉及到多方的合作,特别是需方的参与。在

许多的工程项目中我们发现:客户会产生一种依赖性,认为我花钱买了你的业务,应该什么都是你来做,我只需看到预期的结果。实际上,一个项目的成功很大程度上取决于供、需双方的配合程度。

经常有遇到过因责任界面不清晰而导致项目成本大幅上升甚至项目失败的情况。在某个112系统的项目实施中,因对测试头进行调

4

·计划编制

作为一个项目实施计划,必须经过项目经理的深思熟虑:考虑要周密,资源利用要合理,WBS分解要细致、可控。项目计划的编制工具采用目前流行的项目管理软件PROJECT,在项目计划制订前,客服事业部结合以往的经验制定出不同产品线(或项目)的标准WBS

分解表模板。

模板是在先前一系列项目执行过程当中总结出来的较为合理的工作计划和工作量基准,一般要求每个WBS子项不超过2个工作日,对于一些小的但高频次出现的工作也必须单列,如周报、对用户每周的汇报等。项目经理只需按照标准的WBS分解表制订计划,其中由

取措施。每周要求对上周的计划执行情况进行分析总结,并修正下一步的计划,相对大的项目除总结分析本周计划进度,还必须编制双周滚动计划,并知会全体项目实施成员和项目干系人。

·计划变更

对于项目计划的变更必须有变更流程。我们在操作过程中规定:

对于三天以内的计划变更,直接由项目经理确定,但必须在项目计划中标明并通报项目各干系人;如果是一周以内的计划变更,则必须由项目执行小组审批;超过一个星期以上的计划变更必须报项目领导小组审核或会议讨论,同时采取紧急处理措施。

项目计划是项目执行的一条准绳,只有合理的计划和定期的监

5

评审其科学性、规范性、逻辑性和合理性等等;在项目结束后对项目实施的进度、费用、质量、文档、客户满意度等方面进行调查、总结和改进。

项目评审的目的是:在事前做到对项目实施成本和风险的充分估计;对项目进度计划合理论证;积累经验、逐步提高、逐步完善项目

管理。

6、项目范围管理不能忽视

在以往的工程施工我们曾有过这样的经历:很早就听说一些系统要竣工,却迟迟未能峻工。为什么?这是因为用户对系统的参与比较深入,同时也提出诸多需求,在这些需求中,有的已超出合同范围,

范围变更的角色,一旦发现范围变更即马上与项目经理进行沟通。项目经理有责任组织讨论并确认变更类型:a)确是范围变更,b)只是范围定义不清晰,c)适应性改进或错误。如果项目组不能达成一致意见,则把该问题上报项目领导小组解决争议。

对于情况b),项目经理应向全项目组员阐明。

对于情况c),则项目组内部先解决排除,若需其他成员支持按服务流程中的问题单流程处理。

对于情况a),继续如下步骤。

·评估项目范围变更的影响

所有被确定的范围变更将被分配一个序列号。项目经理有责任写

员宣布最初的项目范围。该流程将在每个阶段开始时都由项目经理重复一次。在每个阶段的结束时,项目经理需再次传达经修改的项目范围,并特别强调在本阶段修改的内容。对于范围管理不仅包含范围的扩充,也包含项目范围的缩小,如果出现因客观原因原订合同范围内的内容无法实施等重大变故,我们必须将相关已实施的内容、下阶段

实施的内容和变更的内容按阶段整理并发布。在项目交付时项目经理必须提交项目范围变更表。

·项目风险管理是必要的

项目一旦启动,风险就与之并存。项目经理必须具备识别风险的能力,并力求将风险消灭在发生之前,对于无法安全回避的风险,必

段过去后,可能A风险就消失了。所以说不同的阶段风险重点也不一样,风险因素是一个变化的过程,每周或每阶段我们都需要对风险因素进行一次回顾,检查原风险因素是否消失,新的风险因素是否已产生。对于下一步将遇到的风险,则应立即采取预防措施。

·项目质量管理

相关文档
最新文档