总结项目进度管理经验

1总结项目进度管理经验一、概述项目的进度、成本、范围、质量构成项目的四大目标，简而言之：多快好省。对于这四个方面的管理组成了项目管理的核心部分，而进度管理是对于时间的管理，项目成本、范围、质量都与时间密切相关。另外一方面，项目还存在其他一些目标，如客户满意度、公司的认可度等等，这些往往也都与项目的进度目标是否达到密切相关。因此可以说，项目进度管理是项目目标管理的中心。项目是特殊的，为了独特的项目目标所进行的一次性活动。项目过程中存在了或多或少的变化，这些变化往往是导致项目各种各样症结的直接原因。俗话说计划不如变化，可我要说，没有计划，我们就无法应对变化，兵来将挡，水来土掩的传统手工作坊模式项目管理在大部分现在的项目中已经暴露出它的缺点。通过进度计划、进度监控、风险应对措施等手段才能更好的应对变化，保证项目进度目标的实现。在项目管理过程中，所有的计划都不是一成不变的，需要在各个特定的时间点（如面对变更、人力资源调整、项目外部环境变化等等）上进行调整或细化，这样的计划才是符合项目实际情况的，才是可行的。既然项目的进度如此的关键，怎么样才能最大限度的保证项目如期交付？作为对项目成败负直接管理责任的项目经理，我们应该采取怎么样的管理办法才能提高项目在进度方面的“成活率”，不在死亡之旅中苦苦挣扎呢？希望看完本文，大家能有所收获。二、进度计划项目进度计划是为了明确项目所有交付物或完成这些交付物所必须的工作的一份时间进度表，它应明确每个子工作的时间要求：计划开始时间、计划完成时间、允许的浮动时间、前置工作、后续工作等等。对于制定项目的进度计划，需要完成项目的估算。在项目启动伊始，获取了项目的初步范围、完成了项目的整体估算之后，我们便可以制定出项目的整体进度计划。需要特别指出，在这份计划中，通常我们把项目的生命周期划分为规划、执行、收尾三个阶段，执行阶段根据项目的实际情况还可以划分为若干个小阶段并且设置里程碑检查点。并且需要细化规划阶段的工作。至此，我们已经明确了，项目的各个大的目标的大致时序，并且可以在相应的里程碑节点上去检验这个里程碑的交付物是否都已经达到了。这样做的好处是，通过里程碑完成节点上的检查，我们可以判断清晰的项目的进度的执行情况，并可以相应的对之后的进度计划做出调整，更好的应对变化。也许你会问，这样的一份计划并没有细化，怎么样才能知道我们的项目管理工作呢？这样我要说的是，我们的大致思路是这样的：计划往往是不能做到一步到位，非常详细的，因为很多时候我们的信息尚未获取完全，比如需求分析还没完成、从客户处获取的部分交付物时间要求还没有明确等等。这种时候，我们需要将这些前置条件的时间要求细化进进度计划，并监控这些活动的进度，当这些工作完成时，我们便应该着手细化我们的计划了。例如，假设这个项目的需求分析工作在规划阶段将全部完成，那么在规划阶段完成后的计划。在进度计划计划的过程中，我们需要考虑各方面的因素，如项目的紧迫程度（我们是否需要将部分工作并行进行，同时承担一定风险）、项目的人力资源情况、客户对部分交付物的时间要求等等。那么到底细化到什么粒度才是合适的呢？这个要根据项目各个活动的实际情况来判断。首先我们要明确的是，我们所做的计划都是为了指导项目工作开展，指导我们之后说要进行的进度监控所制定的。所需要的监控力度也就决定了计划的细化粒度。例如，某一模块的设计工作由一位非常有经验的并且曾经从事做类似功能设计的项目组成员负责，那么也许我并不需要对这一活动细化的很详细，只需要明确整个模块的设计工作计划即可。毕竟项目管理更重要是对人的管理，项目管理成本也是相当的重要，频繁的监控将消耗更多的成本，极端情况下还有可能引起工作负责人的不满。另外一个例子，如果某一活动被认为存在风险，如技术很陌生、人员技能水平不足、客户时间要求紧迫且严格，那么我们往往需要将工作足够的细化，并且在监控中步步跟进才可以确保工作的如期完成。还应该注意的一点是，计划无论细化到粒度，每个活动都应该是有明确的交付物和完成标准的，这样我们才可以去进行监控。三、进度监控与计划调整项目的进度控制就是在既定工期内，编制出最优的进度计划，在执行计划的过程中，经常检查项目实际进度情况，并将其与进度计划相比较，若出现偏差，便分析产生的原因及对工期的影响程度，确定必要的调整措施，更新原计划，这一过程如此不断地循环，直至项目完成。对于项目进度计划的监控，就是对我们进度计划中的里程碑和各个子活动的监控。只有所有里程碑目标达到，项目目标才算达成；只有里程碑内定义的所有子目标和活动完成，里程碑才算完成。而每一个活动完成必须以活动定义的交付物完成为标准，例如功能通过测试、文档经过评审、模块完成发布并经过用户确认等等。所以，对于一个最小单位的活动，完成情况只有0%和100%两种状态。针对交付物去检验项目的实际完成情况，然后比对我们的进度计划，就可以知道项目现在进度方面的健康状况，如果存在偏差，就应该判断是否需要调整我们的计划了。面对已经滞后的进度，我们可以采取哪些方式调整计划才可以将落后的进度追赶回来呢？我们可以在下面的这些方法中，根据项目的实际情况判断，做出最合适的应对措施。1.赶工赶工的意思是，临时抽调项目组外的资源，突击某个关键活动或工作，以达到缩短工期的目的。赶工的缺点是：需要人力资源条件允许；新注入的资源对于项目需要一个熟悉的过程，存在一定风险；会增加项目的成本。是一种用成本换进度的方式。2.快速跟进快速跟进的意思是，将原进度计划中串行执行的活动，调整为部分并行，例如最典型的边设计边开发。缺点也是显而易见的，存在相当大的风险，处理不当很可能造成返工，加剧项目进度滞后的状况。是用质量换进度的方式。3.外包外包也是我们的选择之一，它其实是变相的加入项目的人力资源，它的缺点和赶工相似，存在更大的风险，另外还需要投入一定的管理成本和沟通成本。经过分析和决策，选定了一种或多种方法以后，我们就可以对项目进度计划进行调整，也就是在新的条件下，重新编制我们的进度计划的相应部分。并按照这个计划执行。执行计划――监控――调整计划――执行计划…往复这个过程，让计划确实可行，才可以最大限度的保障项目的如期完成。4.采用新的工具使用新的工具可以节约项目开发的周期，但是往往需要做好足够的前期工作，确定工具是否适用，是否存在技术风险等等。另外，新的工具也许需要支付一定费用，也会增加项目的成本。5.加班很多时候我们会谈加班色变，认为加班是不好的，不应该的。但是合理的适度的加班也是可取的一种应对措施。加班的缺点是：如果控制不当频繁的连续的加班，可能成员的效率会降低，积极性也会降低。三、结语面对项目中各种各样、错综复杂的情况和变化，我们只有关注更多，了解更多，投入更多，才能收获更多，取得更多成功。分享个人经验，希望本文能对大家有所帮助。2调侃项目经理t手机项目经理之悲哀夫手机项目者，初学模，工资未及房租生活之费，不逮大厂之分配，适值山寨手机横行,模具厂扩招，纷纷弃模具而改做项目之职。数年后,离关外，进市内，转行相继，乃成项目经理。纵观华强北行人来往匆匆,手戴金表,脖围金链,腰挎皮包之众为国包地包炒货者;衣衫不整,手提麻袋,背驼大包,颈挂厂牌之流皆是供应商打样送货也;然项目经理者,其特征最为明显:面黄肌瘦，神色黯然，双目无神，怒发冲冠，电话不断,声嘶力竭觅生计，几年无休，开模跟模，修模改模，披星戴月；试产量产，催样签样，秉烛达旦；方案确认，软件硬件，昼夜难眠；催货交货，装机发货，寝食难安；上班下车，坐车挤车，不厌其烦；一日三餐，地沟油饭，饥饿狂啖如此反复数年，蓄币十万。楼市暴涨，不足购房，遂投股市，翌年缩至万余，抑郁成疾。医保曰，不符大病之条例，拒赔。乃倾其所有，入院一周，无药自愈。一友怜之，赊三鹿一包，冲而饮；另一友怜之，购桶装地沟油一小瓶、海南缸豆半斤、转基因大米一碗，煮之，食毕，卒!(网友zyh191)本文来自：我爱研发网(52RD.com)-R&D大本营3项目管理软技能简单总结一、工作内容1、对项目进行前期调查、收集整理相关资料，制定初步的项目可行性研究报告，为决策层提供建议。协同配合制定和申报立项报告材料。

2、对项目进行分析和需求策划。

3、对项目的组成部分或模块进行完整系统设计。

4、制定项目目标及项目计划、项目进度表。

5、制定项目执行和控制的基本计划。

6、建立项目管理的信息系统。

7、项目进程控制，配合上级管理层对项目进行良好的控制。

8、跟踪和分析成本。

9、记录并向上级管理层传达项目信息。

10、管理项目中的问题、风险和变化。

11、项目团队建设。

12、各部门、各项目组之间的协调并组织项目培训工作。

13、项目及项目经理考核。

14、理解并贯彻公司长期和短期的方针与政策，用以指导公司所有项目的开展。二、工作原则1工欲善其事，必先利其器；2名不正则言不顺，言不顺则事不成；

3其身正，不令而行；

4凡事预则立，不预则废；

5磨刀不误砍柴功；

6统筹兼顾；

7无以规矩不成方圆；

8欲速则不达；

9众人拾柴火焰高；10不知言，无以知人也。三、在项目实战中，沟通的重要点

1、项目启动会议上的项目目标的沟通。

2、项目管理计划中的负责人和任务完成节点的沟通。

3、激励沟通。

4、检查沟通。

5、出现问题时的解决问题的沟通。

6、项目验收沟通。

7、项目庆功沟通。

四、项目经理沟通的基础

1、明确你的授权上级的想法，深入了解项目目标，并能及时反馈。

2、其他职能部门搞好关系，方便资源调用。

3、了解你的项目团队成员的工作习惯、优势、劣势。要发挥所长，避其弱点。

4、在里程碑和关键节点上必须要有提前量。并提早制造气氛。4从PMBOK到项目管理实践的个人感悟笔者一直从事通信行业软件开发工作，下面结合PMBOK谈一谈自己的工作与学习体会，希望对大家有所帮助。最近刚刚结束一个项目，以下简称S项目，就以此次为例来来说一说。

首先简单介绍一下S项目.S项目的目标是在用户上网的同时为用户实现语音通信接续功能。S项目作为一个项目具有以下项目的特点：

临时性：该项目的整个周期从2011年8月份开始到2012年5月结束。

独特性：该项目的独特性体现在它提交的成果完成了一个新的功能开发。它是一个较大的复杂项目，分成了2期进行开发，并且在二期开发中还包括两个子项目。

在本人所在的公司，一个项目的干系人通常比较多，而且复杂。其中主要的干系人是产品开发负责人，产品范围负责人，项目集负责人，职能经理。其中前面两位对项目的质量和验收影响最大，后面通常在项目初期确定资源的时候影响较大，后期影响相对较小。

就公司的组织架构而言，公司应该是属于矩阵型的架构，一个team是跨职能的team。从项目经理的权限和职能经理的权限来说应该是弱矩阵结构，因为虽然有一位员工作为teamleader,但他并没有太大的权限，还有50%的时间是要参与项目开发的。Teamleader大多数扮演的是一种对外接口人的角色。

项目的周期是启动，规划，提交和收尾。

一．启动

这个可以对应到PMBOK上的启动过程，从项目集经理处获得授权做这个项目。Teamleader开始准备项目启动的材料，项目组成员开始做项目的预研。这个阶段teamleader做的工作比较多，确认项目范围是否确定，项目完成的日期，项目组成员和其他硬件资源是否已经准备好，项目之外的support资源是否已经准备好。

二．规划

对应到PMBOK上的规划过程。规划过程是保证team成员能够正确理解项目内容和承诺目标的实现。项目组成员中的systemmanager会创建WBS,把项目范围划分成小的活动，项目组中的开发人员和测试人员根据这些小的活动去估计effort。Teamleader根据估好的effort去排项目计划。根据项目计划确定最终交付的时间。

估算成本和制定预算对我们这种项目来时一般都是指时间成本，基本上预算之中的10%是做一些其他的和本项目无关但是又比较重要的活动，例如bugfixing等。

在风险分析和应对方面，主要体现在和其他项目的依赖性方面。例如S项目就和一个同时开发的E项目在测试方面有依赖性，E项目如果延期交付就会影响到S项目的工期。S项目的一个缺陷就是在此时没有做好风险应对计划，造成后期测试的时候非常紧张。

三．提交

提交包含了PMBOK上的执行和监控两个过程组，包含从规划开始到最后提交这一段时间的过程和进行交付的动作。在项目执行过程，项目组成员的劳动都是在这一阶段体现的。

TeamLeader在执行过程中的主要任务是组建项目团队和建设项目团队以及管理项目团队，向项目集经理汇报项目的进度。而指导与管理项目的执行在我们公司这种弱矩阵架构中，并不是太突出。因为teamleader也只是项目组中的一个成员，往往并不比项目组成员中的骨干更精通项目的运作，所以在项目执行的时候往往会更多的需要听取组员的意见，这不知道是否与PMBOK的精神有点不一致。

质量保证更多的是组员和产品开发负责人一起来保证的。其实监控过程应该是执行过程的一个方面，主要体现了teamleader的工作任务。最主要就是更总审查目前项目的进度，可以由一些工具作为帮助，目前主要有sprinttable和burndown

chart。和PMBOK一致，在我们公司teamleader需要负责实施整体变更控制，范围的核实和控制，进度控制，当进度有压力的时候，选择加人或者去掉一些可以不做的事情。Teamleader还要同时负责汇报项目组成员绩效给职能经理。

监控风险是一个非常复杂而又艰巨的任务，首先意识到风险的到来就不是一件容易的事，如果遇到之前没有预料到的风险，应对起来就更难了。S项目就遇到了其中一个风险就是项目过程做的一些对现有产品进行改进的任务，预估影响不足，结果是项目的quality面临很多问题，并且已经是处于项目后期，才发现这些问题，所幸项目组成员解决问题的速度非常迅速，才使项目没有延期。最后是所有软件测试结果通过，按时提交项目成果。

四.收尾

收尾过程就是完成项目提交之后一些完善性的工作。也就是文档归档，开发总结。如果有遗留问题，解决这些遗留问题。

五、总结都是个人经验总结，有不足之处还希望大家提出来，我们一起讨论，一起学习。（作者：周萍，PMP）5项目管理之精益管理随着企业的发展，管理者们纷纷探索如何以最小资源投入，包括人力、设备、资金、材料、时间和空间，创造出尽可能多的价值，为顾客提供新产品和及时的服务，这就是精益管理的主要内容。

法国巴黎银行是全球最大的银行之一，法国巴黎银行CIO（首席信息官）ThierryPécoud，他从2009年就在IT部门策划了一次长期转型计划，并基于此在IT部门启动了全球精益管理计划。

对此，ThierryPécoud表示，精益管理是正确的途径，因为它不仅是一个普通的业绩改善活动，更是一个全面的转型计划。这种计划可以使一个部门按照自己的工作方式不断改进。

他认为，精益管理是一个持续的努力，通过不断改进低效来促进部门发展。精益管理转型就意味着给员工正确的工具，教会他们如何评估自己的工作方法并进行永久的改进，同时又不破坏软件开发过程中的创造性本质。精益管理很适用于IT这个大环境，因为软件开发师一般都不善于管理自己的时间和精力。鉴于IT在资本市场业务中的关键作用，对IT部门进行精益管理就更为必要。

他提出三点精益管理项目是否成功，第一，检查管理人员是否将精益管理的原则融入到自己的工作习惯中――灵巧编程方法、绩效管理、浪费跟踪、持续改进的思维模式。对我来说，只有在行为上发生变化才意味着对精益管理的真正理解。第二，完成为提高产能所设定的目标。我们成立了一个投资委员会，由前台、IT以及运营部门的管理层组成。我们跟踪了精益管理转型后所释放的产能并将其分配到新的行动计划中去。到目前为止，这项工作已经走上正轨，转型团队中10％的员工将得到重新分配。最终，根据IT部门的存在理由，我们将通过具体的“客户之声”调查来衡量客户满意度，并以此评估用户体验的改善情况。此外，他坦言，精益管理在大规模、定期的实践起来的过程中确实遇到许多困难，且对于其他部门合作也产生影响，但这些发展极大地鼓舞了管理人员。综上所述，项目管理想要更好地发展，就摇把目光放远些，追求精益管理，无疑是未来项目管理发展的主流。6小督办解决项目管理大问题A集团公司经过十年的发展已经形成一家以化工产业为主，并涉及相关上下游不同行业的集团化公司，集团总部对下属各分公司的管理方法有财务管控，也有全面的经营管理，还有参股的独立核算型的分公司，2011年为提升集团公司整体的管理水平。集团公司在信息化方面进行了整体的规划，在原有财务系统的基础上，又使用了ERP、OA系统。集团在规范化及效率方面都了很好提升。

不过最近一次小小的失误，给公司造成了不小的损失。不仅丢失了客户，还对公司的品牌形象造成了恶劣影响。这让集团高层开始思考，如何更好地对细节进行把控？管理者身居高位，事必躬亲不现实，事无巨细很累人，但用什么方式来弥补细节失误所可能带来的损失？

集团公司提出要加强内部的监管，把问题处理在萌芽之中，对各职能范围内出现问题实行问责制。在各分管领导看来，定战略、带团队、打硬仗都没为题，但却常常免不了在不起眼的细节处摔跟头，如今集团公司的一纸令文也可谓是当头棒喝。如果说，以前的失误是可以弥补的，这次的教训却让大家开始怀疑结果型的工作管理是否合理？有没有更好的管理模式？过程管理如何更好地实现？

过程管理的重要性不言而喻，但由于管理面广，并非事事都能时时跟踪。即使工作通过OA系统实现了电子化，也依然难以实现理想中的过程管理状态。OA？当想到OA应用以来，公司在流程管理上的提升，高管们再一次想到了OA系统。有没有办法通过OA实现更加科学规范的过程管理？！当各位高管聚集在信息中心时，所有的压力突然间转移到了信息中心的c主任身上，问题像雪片一样飞向信息中心，都是需要支持的。还好，多年的管理经验让c主任很快冷静下来，梳理思路、分析总结，他发现问题集中在两个方面：1、在管理范围内但是没有直接参与的流程，也可以随时查看；2、如果我发现问题，是不是可以随时给出建议，进行指导和指正,从而影响执行的结果。

这不就是“督办”？！c主任突然想起不久前在泛微公司的OA深度应用培训，主题就是“督办”。当时感觉这个功能确实是为整个OA系统锦上添花了，但并没有深入思考这个功能的业务应用，现在看来，一些小小的功能背后可能隐藏着管理之道呢！

马上行动！c主任赶快找来文档查看，并咨询了泛微公司的客服人员，终于吃下了定下丸！“流程督办：为了满足一部分管理员不在流程设置的流转范围内，但是需要对某些流程进行监督催办，系统通过提供流程督办功能来指定相关人员对指定类型的流程有查看的权限，并能对流程提出相关的督办意见。”就是这样！

C主任马上和业务部门的负责人进行了沟通，在泛微客服人员的协助下搭建了测试环境。当各分管领导再来信息中心的时候，C主任要做的，就是登陆系统，点一下督办菜单，把所有督办事宜展现出来！

督办功能的上线使用顺理成章。很快，“督办”功能成为高管们最常使用的工具之一。由于高层的督办，事务处理效率在原来基础上又提升了一个台阶，细节的把控更加到位，管控风险大幅降低，信息化助力企业提升管理能力得到了又一次的验证。综上，在项目管理中，负责监管的督办其实负有很大的责任，虽然作用不是很明显，但是对于一个项目来说，却是无可替代，举足轻重的。7谈谈SCRUM中的项目经理1.谁喜欢被管制

公元两千多年前，我们脚下的这片土地，处在一个人人向往的太平盛世，以至于现在我们这些后人，都时时引之以为荣。（更有些高高在上的人，不知脸皮为何物地吹嘘当世可以为它的翻版。）这段我们向往的历史，即是“文景之治”。其治理策略更为人所熟知-“无为而至”，“轻徭薄赋”，“与民休息”。（说白了，就是什么也不干?）

很不幸，作为开发人员，似乎我们很难碰到像刘恒或刘启那样的老板。正好相反，项目经理或者更高级的主管们往往会在我们沉静在思考中时，像苍蝇一样嗡嗡地飞来采集进度-不懂技术的，只是一个会说话的监视摄像头；略知技术的，往往会提出一些干扰性大于操作性的建议；即使有真的精通技术的，除了提了建议炫耀自己的专业实力，更多的是打击开发人员并养成其依赖性......

结果......

我常常听到下面的人抱怨：我们领导烦死了，除了监工啥也不干!

同样有趣的是，我也常常听到管理者抱怨：下面这些员工啊，素质低，爱偷懒，不把工作当回事，只图完成任务交差而已！

软件开发归根到底是人为主导的行业，人性化是无法忽略的。我们渴望在软件开发工作中抛弃官本位，拒绝垂直命令，解放自己，同时也解放管理者。

2.SCRUM的一个原则–拜托，请您不要管太多！

SCRUM提醒经理们，你的任务是支持开发人员，扫清障碍。而不是传统的命令和控制！习惯了当官的人不明白-支持？只是支持？不会吧？那种自我膨胀和虚荣的感觉都没了？我必须得控制，得发号施令！再说不这样也不行啊，不催项目就会延期。

让我们对比一下大家常见的真实世界和SCRUM提倡的情景吧！看看究竟那种方式更有成效。

场景一：初步制定了一个开发周期计划以后，开发组和项目经理一起开会讨论计划，表述了计划日期和原因以后：

真实的世界=>

开发组长（小心翼翼地）：“您看着计划如何，同意否？”

项目经理：“恩，还行。不过我觉得这个功能看起来没有那么难吧，嗯哈...你们估算的时间怎么这么长？”

开发组长:“（陈述原因）......”

项目经理：“哎...大家加加班，辛苦点嘛...有什么要求尽管可以提嘛...（画饼。通常提了要求也得不到满足）”

后果：开发组不得不听从上头意见加班，满肚子怨气，责任心进一步降低了。开发组长觉得自己的评估遭到否决，自己的话语权被剥夺，还要为了缩短的时间不断压迫成员。

SCRUM的世界----开发组是交付成果的真正负责人！！=>

开发组长（小心翼翼地）：您同意否？

项目经理：你们觉得该计划没问题？能按时按质量完成？

开发组长：是的。

项目经理：那就按照你们的做。

后果：开发组长对自己有了信心，开发组成员感觉到了自己的话语权（虽然是很有限的），即使加班，也是对自己的计划负责，怨不得上级压迫。

场景二：开发组例行会议.项目经理也来凑热闹

真实的世界=>

会议开始，开发组长打开一个word或者什么文档，然后请每个人轮流汇报进度。

会议进行中，每个人轮流汇报进度...项目经理突然就汇报中的某问题提问，开发人员回答解释....

会议趋于尾声，开发组长请项目经理发言

项目经理：“恩，我觉得...你们应该注意*#@#$$，你们还要#%#$...还要#%$T#$”

会后结局：开发组认为自己被干涉，上面管的太多太琐碎。

SCRUM的世界----只有开发组自己才能对自己负责！=>

项目经理：“我不应该出现！！这个会议不是为了向我汇报成果展示绩效,而是为了解决开发过程中的问题，应该由他们自由讨论。”

会后结局：高效的会议！组员不只是为了秀自己的进度给上级，更关键的是提出了自己的问题和困惑并得到其他成员的支持去解决问题。

场景三：交付成果审查，项目经理发现了一个问题

真实的世界=>

项目经理：“你们这里有一个漏洞，我知道一个解决方案，你们应该#$#$@#...”

结果：开发人员的信心被打击，并趋向与养成对经理审核的依赖性

SCRUM的世界--项目经理不应该干涉过多，发现问题，解决问题都应该留给开发组自己！=>

项目经理：“恩，非常好！不过好像没有考虑到一个问题，(但是我不会说出来)，我相信你们自己会发现，请仔细审查一下。”

结果：开发组自己发现并解决问题，面子被照顾，并且日后会更加认真。同时对项目经理的专业能力表示赞同。

场景四：不干涉不行-重回老路？？

实施SCRUM有一段时间后，项目经理发现开发组的工作效率和工作热情都提高了！一切似乎进行的不错，开发组长和组成员都开始从心里对项目，产品有了较高的负责心，不再只是单纯为了对付上面的任务了。可是有一天，项目经理的上司，公司的高级经理来了。

高级经理要求审视所有进度和发布成果。在项目经理完成展示后，高级经理很不高兴。

高级经理：“这个项目进度不好！客户要求很急！你应该保证进度！”

项目经理：“可是我们正在实行SCRUM，自我负责的开发团队已经建立。开发人员工作热情很高而且他们已经很努力了！这个进度已经是建立在大家尽全力工作基础上了…”

高级经理:“这个不是我需要关心的！开发那边对他们自己负责，你也需要对你任务负责！你的任务就是保证按时完成！”

真实的世界=>

项目经理明白，SCRUM没有饭碗重要，于是他找到开发组

项目经理：“从今天开始，每天早晨我必须参加你们的会议！你们每个人都要及时汇报进度和问题，上面催的很急！”

开发组长：“可是我们已经很努力了…您的意思是…？”

项目经理：“不行，我不放心你们，我必须亲自跟踪监控”

结局：项目经理越来越多地参与各个组的会议，甚至高级经理也在关键问题上参加开发组的会议来催促进度。管理模式回到了垂直的老路上。开发人员又开启了消极的一面，因为完成任务应付上面的质疑成了唯一的工作动力（如果还算是动力的话）。有人开始跳槽…有人开始怠工…项目最终仍然延期。

SCRUM的世界–每个经理都必须明白命令和压迫是有害的=>

项目经理有义务保护下属并提醒高级经理，SCRUM的原则是自我组织，自我负责-这一条不能放弃。即使不断压迫下级，也未必能取得满意结果。

3.并非什么也不做！勿以小事而不为

无为不是毫无所为，除了发号施令，经理们还有很多事情需要做，概言之，即扫清一切开发中的障碍，保护项目成员的工作不受任何负面影响。这包括协调资源，激励士气，优化流程，创建好的环境和氛围等等，一切的一切-甚至是给每个开发人员一个座椅的靠垫。

让每个人都有参与和负责的权利，并尽全力保障他们的这种权利，这就是一个身处SCRUM中的经理该做的事。

我相信不少人人都遇到过垂直管理的问题，作为被领导者，每个人都渴望平等（哪怕表面的），被尊重（哪怕偶尔的），有归属感（哪怕仅仅两三年）。在软件行业，SCRUM确实是提高员工工作热情的一个已经被实际证明有效的模式。但是不得不说，SCRUM是需要一定的企业文化的！！而在中国实行真正的SCRUM，我个人认为，真的非常难。SCRUM要求管理者，尤其是中层管理者，对下属提供相当的支持和保护，作为下层员工，获取自由的同时，则要承担相当的责任，并从心底认可这一点！可是我们国人现在的社会中，彼此信任是如此艰难。上对下，更多的是粗暴压榨，而不是对其激励和负责。反之，下对上所谓的“尊重”，更多是迫于对权势的恐惧，而不是真正的钦佩。上下级之间朋友般信任的关系，如同白娘子要遇许仙，千年修一回。

作为知识型组织的软件公司，专家权力无疑是最有效并最被员工从心底认可的。我觉得，每个PM都应该想想，下属们对你的尊重，其中有多少来自你的“专家权力”？以此类推，你对自己的上级，也有多少发自内心的钦佩？8、项目管理的准备阶段今天的话题是项目准备阶段需要做些什么，我现在自己也正好在项目的准备阶段，正好写写自己的感受，希望对大家有帮助。每个项目的开始之前都有很多的准备工作，而且这些准备工作都是必不可少的，这就好比编程，必须要有思路和想法，整理好以后再下手处理。做一个项目之前先要把项目进行分类：1、这个项目是产品类还是项目类，产品类是指平台底层，考虑通用性、适用性、对这个产品要进行生命周期的评估，这个产品希望能支撑多少时间，用户可以使用多长。一般企业都不会经常换平台，因此此类的项目开发较少，每家公司都会有一个成熟在用的系统平台。2、对于项目类也分为一次性还是多次的。一次性比如像一些企业特有的功能模块，安全许可证、销售系统等。此类都会根据公司性质不同而改变的，此类项目的准备也只是人力资源、项目的目标之类的定义。3、类似项目的开发，如我们公司有请购、采购、验收、付款的流程。不管是什么样的公司都逃不了这样的业务处理，如果是这样的项目，前期的准备就会比较复杂些。

我拿我自己做项目的经验来举例吧。背景：我们是一家集团公司，本公司是负责集团内部的流程管理，第一次做这样的项目要规划需要提前两三个月，主要制定项目目标，识别干系人，预先对一些关键用户进行电话邮件沟通，以确保系统上线后每个关键用户能清楚今后的系统大致的开发方向和如何完成现有的业务处理。首先来讲一些干系人的定义，项目干系人又称为项目相关利益者，是指积极参与项目、或其利益会受到项目执行或完成情况影响的个人或组织。作为我们把干系人分为几个层次，第一层次为底层用户，我们称之为EndUser，对于这些用户集来说，是个庞大的团体，因此不可能召集所有的用户都来参加培训和测试，必须通过关键用户的协助处理EndUser的简单操作问题。因此引入了第二层关键用户，我们称之为KeyUser，所谓的关键用户是项目实施业务组成员，是一些企业内部精通各自业务流程的人员。对于这些用户需要特殊培训，特定沟通，以确保系统的适用性，是系统上线的稳定因素。第三层次为流程所有者，我们称之为ProcessOwner，利用这部分支柱力量不断发展、完善、优化业务流程，从而保持企业竞争优势策略，系统生命周期延长，这类人是系统持续发展的基础。第四层次为领导者，是项目上线成功的保障。能尽早让总经理级别了解项目上线会带来的收益，就能尽快促进项目的发展。

识别干系人是为了让项目能顺利开始和谢幕，而定义项目的整体目标，是为了让对内团队成员齐心合力，对外用户明确配合方向。整体目标分为大目标和小目标两类。大目标称为总体目标，如本次项目开发是为了系统升级，整理各公司业务系统；或是流程引擎优化，提升项目开发速度等。而小目标我定义为概要目标，是指此次项目必须在达到的吸引人眼球的那几个点，如图形化流程设计、用户自定义表单开发等。

对每个干系人都需要不同对待，沟通是贯穿项目始终的一个很重要的手段，在整个项目中是必不可少的。沟通的方式多种多样，在项目准备前可使用邮件、电话、面对面沟通三种方式。邮件作为一种成文的公告，通知大范围人员的项目进展，如一些重大会议的通知，项目进度的公告，用户之间交流的确认信息的存档记录。这类操作一般可面向于所有干系人。而电话是辅助工具，对一些重要的、特殊的会议通知、说明进行提醒，以加深对方的记忆。这类沟通方式我们一般用于第二层和第三层，主导项目成败的关键因素。面对面沟通是针对第四层次的干系人，较大级别的长官。这些人比较忙，一般系统只有运行不下去才会直接找资讯部主管反映问题，因此正好利用项目准备期，和这些领导们进行沟通，了解在日常工作中有哪些系统可改进的地方，或是他们自己觉得可以简化的操作。一来可以提高系统的使用度，另外可以加强系统的推广度。如果做得比较道位的，可以在项目前准备一些针对此次项目开发的满意度调查表，使得系统开发更有的放矢。或是也可以对一些第二层或第三层的部分经常打电话来骚扰的人员特殊沟通，咨询他们的意见。我个人认为很多的反馈不好或是报怨，是因为沟通不好或是误会所造成的。越是不好沟通越是要当面多次沟通，才能把敌化友，纳为已用。

我们识别了项目的干系人，明确了项目的目标，知道了如何沟通，这些都是基本对外的，对内我们要做的是整理项目所要做的主要内容。我们做的项目都和流程有关，因此在项目开始前我会先将此次涉及的流程先用Visio的方式整理好，流程都是有一段适用期的，用户只会管流程在当时的时候可以用，决对不会管你现在系统上这样的流程的合理性。所以作为一个项目经理，不仅是要考虑项目的管理、技术上的可行性、系统的设计，更主要的是要考虑系统是要给用户使用，在贴近用户业务的情况下，尽量得使它不要产生冗余。所以一位好的IT项目经理是了解各部门大致业务，如申请单位的一般物料、资产类、工程类的处理、采购员询报议核或是统购的工作方式，再者会计做帐生成会计凭证的方法，能评估流程的合理性。系统永远是为用户服务的，用户决对不希望来适应系统。所以永远不要认为以前就是这样，现在依然这样是正确的，永远要带个疑问去分析现有的状况。有好的想法，可以先和组员或是关键用户、流程所有者讨论，得到认可后一来可提升系统的运行效率，二来也可增长自己的业务知识。永不满足，海绵才能吸得更多。

当然整理出来的条条框框只是为了梳理清现系统中可优化补充的地方，可以这么说，没有一套系统是单独存在的，在现在这个社会中，都讲究集成。因此在考虑自己系统的同时，别忘记把其它相关的外围系统考虑进去。在项目开始之前也必须考虑到他们的配合时间，尽早通知也可让他们尽早安排，不至于项目结束后留下遗憾。在外围系统的整理中主要也分两个层次，一是需要改进的接口，为了提高系统效率，用户一直希望及时，但有些大范围的数据，做到数据及时在时间效率上是不合算的。一来影响了服务器的资源，二来不及时对业务营运也不会造成影响。所以我会建议此类的接口，可采用服务器定时的方式处理，五分钟至十五分钟不等，数据量较大的，可按小时频率处理，这样即可达到原有的效果，又可以专用一台服务器来处理这些定时代理，而不浪费用户的应用资源。这只是一个方面，其它的改进接口还包括一些单条处理改为批次处理的等等，这些需要列一个清单，在项目前需要提前准备好，并提交告之相关所属部门整理的大致情况。另一个层次是不需要改进的接口，也需要整理。做一个项目其实就是为了让文档更全面，系统功能合理，提升系统性能，增加系统功能。

如果这个项目是升级案，那还有新旧系统差异表是必不可少的，而且需要准备两份。一份是对外的，作为用户需要改进的内容。作为IT项目经理，大多是技术出生，很容易写一些开发方面的内容，比如会出现一些增加一个字段，服务器之类的字眼，这些用户是不会懂的，什么叫字段？什么叫服务器？对他们而言是能看到什么，能做什么。不能用语言表达，可以用图片辅助。比如说界面上有不同，先用文字概述一下，增加哪些功能，然后用个例子再往下贴图，用新旧图片对比来展示功能，一目了然，非常直观。对内的话就比较详细些，也就是对应的对外的详细写出要做到哪些，增加哪些字段，列出表格以便追查项目中的各阶段是否这些要求已经达到。

项目准备阶段既不是单纯的需求调研，也不是单纯的准备一些项目启动会的资料，还有一些很多深层次的工作需要辅助处理。当然对于项目开发的成员如果技术、业务水平不达标的话，在这项目准备时期还需要不断的用各种方式提高成员技能，以便项目正常运作。一定要使大家，包括项目成员和用户都在目标统一的情况下，才能使项目有个好的开始。不打无准备之仗，个人认为项目准备阶段是项目成功的第一步，如果这个阶段处理得好，那后面做事沟通都会比较方便，而且还会有人大力支持，会省心不少。9每个人首先都应当是自己的项目经理每个人首先都应当是自己的项目经理，这取决于看本文的你对于“项目”一词的理解，在狭义上，“项目”指的是一项特定的工作。让我们来看看PMI制定的PMBOK中对于“项目”的定义：项目是为提供某项独特产品、服务或成果所作的临时性努力（PMBOK指南第3版）。

其中，临时性是指每个项目都有确定的开始和结束。当项目的目的已经达到，或者清楚地看到该目的不会或不可能达到时，或者该项目的必要性已不复存在并已终止时，该项目即达到了它的终点。（PMBOK指南第4版）。临时性不一定意味着时间很短（PMBOK指南第4版），短到几天，几星期，长达数年数十年，都是有可能的。但是，在任何情况下项目的期限都是有限的，项目不是持续不断的努力（PMBOK指南第3版）。

PMBOK还提到运作与项目的共通点（运作的概念不在讨论范围，这里就不提了）：

1、由人来做；

2、受制于有限资源；

3、需要规划、执行和控制。

ok，如果我现在有一个家庭旅行计划，让我看看这个计划，能不能成立一个项目：

1、这个计划不是需要持续不断的努力的，当整个家庭完成旅行或者我发现没办法进行这项活动时，该计划就算结束

2、家里一致同意由我来制定这个计划——它包括协商决定旅游路线、经费预算、选择旅行社和交通工具等等

3、我们有一些限制条件——它包括，必须大家都有时间、开销预算必须符合家庭收入承受范围、该计划最晚必须于12月之前实施——否则就没机会了

4、好的、好的，这一切现在都交给我来规划并执行了，感谢大家对我的信任，我的目标是让参加此次活动的所有家庭成员都有一次愉快的经历

是的，这完全符合一个“项目”的标准，如果你把它当作一份工作来做。你可以想象你现在是一家非常有钱的上市公司的CEO，好的，现在，一般的没有新意的旅行已经无法满足你寻求新奇刺激的神经，ok，你这样交代你的秘书和人事经理；“我在今年8月想出去旅行，我想要新奇一点好玩的地方，你们给我提供方案出来。秘书你去办，人事部配合。”

“是的，您放心，我会提供您满意的方案。”秘书回答。是的，项目组就这样成立了，秘书会利用好资源为你办妥这件事。这确实是一份工作。不