篇一：实施项目经理的心得
在项目的不同阶段，项目经理要考虑的事情也不同，要做的事情也不同，下面按照项目不同阶段来谈谈我的体会。
一、项目前期阶段：
项目的前期阶段是一个项目最重要的时期，在这个时候项目经理对项目情况了解越多，后期项目风险就越小。
1．细读项目合同，弄清楚这个是什么项目，项目的目的是什么，项目合同中有那些客户关注的问题。有哪些是新的功能，这些功能现有系统通过实施变通的方法能解决吗？如果不能解决是否要进行二次开发？了解项目实施的范围是如何，这次实施是推行主要业务还是全部业务，是帮企业推行个别部门还是整个公司以及整个集团？
2.从项目合同中了解情况后，还要从其他方面了解这客户关注的问题最终又是那些部门、那些岗位甚至是那些人员提出的，在项目调研阶段主动到这些部门拜访这些人员，真正理解他们的需求，还有了解各个方面对这次项目看法和期望，有助于在实施中碰到阻力的时候，就每件事情分析那些人会支持你，那些人会反对你，从而好联合支持人去对抗反对者，让项目向成功方向发展。记住，想办法让企业有声望的部门领导成为你坚强的支持。
3.了解客户的基本情况后，再了解自己公司高层领导对该项目的态度。公司高层是想把项目做大还是想赚钱？是想做样板工程还是敷衍了事，这个决定了你项目实施策略，这个策略将影响到你项目的整体计划。
4.知己知彼，现在来估算项目资源和分析项目风险。项目资源之一是时间，按照项目的合同要求是否可以完成项目，如果完不成，是那些资源不足，能否增加这些资源，那些任务必须要并行工作，那些任务要简化。项目资源之二是人员，根据项目情况和经验，分析需要那些角色，每个角色目前公司是否有人，这些人员能否为项目所用，如果这些资源不够，提前向公司汇报，争取这些资源到位；另外你还需要和你的经理以及销售经理充分沟通项目中相关的风险以及风险对策。然后写成风险评估报告，详细分析这个项目的风险以及风险应对措施。如果
这些风险是你以及你的经理还有销售经理解决不了的，那么把问题反应给高层，提出你的意见，要么增加对这个项目的投入，要么放弃这个项目，否则你的项目“出师未捷身先死”了。
5.项目沟通原则和方式确定
A、项目沟通原则之一是指定对口人：一般事情的处理对口人是客户的项目经理，解决不了的事情对口人是项目领导，如果领导有多个，要求客户指定一个为总负责人，要不你这个领导这么说，那么领导那么说，最后你无所是从。
B、项目沟通原则之二是项目文件签字：项目经理开始就要和客户说清楚有些文档是必须签字的，比如需求变更，项目周计划以及周总结，所有达成共识的东西--比如会议纪要，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。特别强调需求变更必须要签，这样做好处如下：
? 有书面签字，如果再次做变更的时候，告诉他以前要求做的情况，
如果多次了，他自己也不好意思再提了；
? 便于需求变更管理，可以清楚看到需求变更的过程，从而更深切地
体会客户的目的，同时万一由于客户多次的变更导致项目延期，那
么责任在客户方，同时如果变更量大也可以收取一定费用；
? 对于客户来说，嘴巴一动最方便，他不会全面考虑他所提的要求是
否合理，是否和项目的目的一致。但是如果要他写书面要求，还要
签字盖章，那情况就不同了，他必须考虑全面，同时还要用文字表
达出来，这个过程给他增加了难题，那么很多无理要求也就“流产”
了；
C、项目的沟通方式：需要进行信息交流的的主要成员有：你的领导、项目成员和客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么，需要那些资源。这里需要规定信息的流动方式和介质，一般情况下产品数据管理系统都有项目管理，有的还集成了邮件系统，那么首先从系统信息化项目做起，所有的项目计划、会议记录、项目文件等文件全部在系统中保存并发布，分配企业所有的人员只读权限，其他地方不进行通知，并约定项目小组周例会制度，在周例会上总结上周工作，安排下周工作。
6.前期做好充分准备工作后才开始做整体计划。在做整体计划的时候你必须确认是否罗列了所有要做的事情和正确评估了他们所需要的时间。这时候，你要考虑那些任务需要并行工作，那些任务需要简化。具体操作按照什么标准？那就是按照这个项目的实施策略以及综合考虑客户的关注点。
二、项目实施阶段：
现在项目已经完成了前期工作，了解了项目的目标、清楚了资源和风险对策，制定了项目的策略、项目游戏规则，然后编制了项目的整体计划，项目进入实施阶段。
项目经理在项目调研阶段主要任务是带领实施工程师以及项目组人员到企业进行详细的业务调研，重点拜访在前期提出一些企业关注的问题的客户，形成调研文件并让客户签字。在调研的时候，注意引导客户说出一些关键业务。在前期项目经理要及早弄清楚企业历史数据（包括产品BOM以及历史图纸），及早分配整理任务。产品数据管理这个系统基本运行需要一定的数据量以及这些数据达到一定程度的准确性，系统才能正常运行，提前进行数据整理工作是你项目成功的保障之一。
项目调研后进行系统建模工作，在建模工作中尽量培训企业人员进行建模，让企业项目组人员快速熟悉你的系统。这样好处多多：其一是减少顾问方的工作量；其二是为你的项目培养一个本土的实施人员；其三是为了降低后期维护风险，如果你没有在企业培养一个人员，那么当你的人员一走，电话就响个不停了，甚至有些地方你电话教他去设置，还找了大半天，既浪费了你的“银两”，又浪费了你的时间；其四也是降低项目的风险，如果企业没有人知道怎么去建模，企业的业务发生了变化，那么系统没有更改过来，系统后面还能很好运行起来吗？呵呵，你的项目不是变成了豆腐渣工程了，最后被企业废了。
在项目过程中，必须时时保持和客户领导以及自己领导的沟通，和客户领导沟通时要注意态度积极点，同时具体点，不要讲很多系统细节的事情。在和项目小组成员沟通的时候，要先灌输系统管理念。在每次会议的时候，你都应该认为，
项目成员提出的方案，从他们的角度来看是最合理的，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论，只有他们的面子被照顾了，后面实施的阻力就小了。如果确实有意见，可以私下沟通，如果还沟通不了，那么找企业项目经理一起去说明项目风险，必须按照你的意见进行执行，因为你们要对项目负责。
在项目过程中有时遇到项目变更，变更通常分为两种：一种需求变更；另一种是程序优化。如果需要改并且你的战略是容许这种情况的，那么注意下面几点：
? 将变更情况写成书面的文件，签字并导盖章；
? 弄清楚更改的根本目的是什么，有没有同样能达到相同目的方法，
只是操作上复杂了点，是否可以想办法说服客户。
业务调研以及系统建模完成后，就进入客户培训、项目试运行以及正式运行阶段。
1、给客户做培训前，多准备，其中包括培训通知下发、会议室联系，是否需要投影仪，培训文档准备（PPT），同时按照培训的思路在系统中操作一次，看看系统是否存在程序的问题。强调一点培训手册一定要站在客户业务人员的角度，根据具体业务讲解如何通过使用本系统的一系列功能来实现。所以，第一次培训以前，系统是否存在问题、培训文档是否完备都是很关键的因素，第一次培训不好，以后就麻烦很多。在培训时一定要参加培训人员进行签名，告诉他参加培训后需要进行考试，如果成绩不理想，会影响以后的工作，同时企业会采取相应的处罚措施，在培训时候建议一次培训的人员不要太多，大概在30~40个人一场为宜，太多效果往往不理想，在培训过程中为了提高培训者兴趣，可以在培训快要结束的时候要求培训人员上台来进行一次简单操作，看看效果如何，同时也有利用下一场的改进。
2、项目进行试运行，选定一些功能，这些功能在试运行过程中可以只考虑过程，不要考虑试运行文件的准确性，其目的是为了验证系统功能与实际业务结合的时候，看那些地方还需要修改，发现问题尽快解决，同时也要安排专门的人员进行跟踪，全方位了解运行过程中的问题，解决客户疑难。提高他们的兴趣。
在试运行阶段根据自己经验以及企业实际情况，考虑如何设置非电子化运行的障碍，最大限度保证企业业务人员使用你的系统。
3、在项目正式运行以前，全面测试系统功能，尽量在设置上少出问题，减少客户投诉，准备项目正式运行文件，要求企业领导签字下发，下发系统正式运行文件的目的是为了整个公司重视，减少在正式运行时候的阻力。根据系统大小，考虑是否要召开正式运行启动会议。根据项目试运行得到的经验，与对方的项目经理协商设置减少非电子化运行的障碍。这个障碍对于不同的企业不同情况，处理方法也不同：
? 企业存在文档服务器：处理的情况是在运行以前，现转移文件服务器的
文件，在项目正式运行后，关闭文件服务器。
? 存在旧的系统：处理情况是在正式运行以前，转移以前系统的所有数据、
业务流程到新的系统，在正式运行后，该系统只作为历史查询，关闭新增功能。
? 存在信息发布系统：关闭其他信息发布系统，全部转移到新的系统，关
闭新增功能。
? 存在其他流程系统：处理情况是转移业务流程，关闭原有新增功能。 ? 没有存在其他系统，但是却继续使用纸档：处理情况是与相关的领导以
及资料发布归档人员联系，所有的资料审批和发布必须以电子档为准，其他不受理。
其他的不一一例举了。
准备工作完成后，进入项目正式运行阶段，全面跟踪项目的刚刚开始的各种业务，及时处理出现的问题，同时每天编写项目运行日报，向领导、项目成员甚至所有客户通告系统运行基本情况，及时表扬表现好的单位或个人。
作为项目经理，要考虑的事情就是：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级，最后把款收回或协助把款收回。所以项目经理要注意：第一保证项目进度；第二是控制好费用；第三在能力范围内尽量把质量提高；第四是降低客户的期望值，让他们从理想回到现实；最后在每个阶段项
篇二：项目经理的感受
对于这种需求天天变的客户，你就一定要事先做好规矩：
一、统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，我不想卷入你们内部业务部门之间的矛盾之中；
二、所有需求变更全部要有书面文字，这点切记！这样做好处多多：
*有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的； *便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目的； *对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了；
系统开发告一段落后，就进入客户培训、系统验收阶段，这个阶段，我一般会注意以下几个问题：
给客户做培训前，多注意一些表面功夫。很多程序员认为，既然很多系统采用原型法，有一个由粗到精的过程，那么系统的逻辑核心是否正确才是关键，至于界面如何，界面上的用词是否准确，那是无关紧要的问题；而且培训的时候也是空手上台、信手拈来，想到哪里说到哪里，下面听讲的人不知所云，云山雾罩，培训效果自然可以想象。我的体会是，给客户做培训的版本，如果你在做多次测试以后仍然不能确定逻辑是否合乎要求，那么，你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等，总之不要让客户看到一些他不该看到的东西，否则，仅仅因为一些无关紧要的报错就让客户第一印象觉得系统不稳定，那你就真的比窦娥还冤了。如果工作再做得详细一点，可以做一些类似Flash的东西，把一些你要强调的重点用通俗易懂、轻松愉快的方式表达出来。文档方面，准备至少两个文档：用户手册和培训手册。这两个文档的内容很多都是一致的，但是角度完全不同。
用户手册往往是站在系统设计者的角度，按照自己的思路，分模块讲解系统的操作和功能；而培训手册，一定要站在客户业务人员的角度，根据每个角色面对不同业务的办理，如何通过使用本系统的一系列功能来实现目标。所以，第一次培训以前，系统界面是否完整正确、培训文档是否完备、培训时所举的例子是否有代表性都是很关键的因素，第一炮打不响，以后就麻烦很多。
上面讲的是培训的时候，丑媳妇要化妆好再去见公婆的问题。其实，项目实施中还有一个考验项目经理功力的就是如何调动客户积极性的问题。一般来说，客户是懒的，这就是他花钱找你做事情的原因。一个项目的成败，和客户的配合程度很有关系。根据我的分析，一般项目中的客户都可以分为三类：支持的、消极观望的、抵触的。他们人数的分布一般是一个纺锤形：支持的和抵触的人少，观望的人多（如果你接了一个人人都抵触你的项目，那你还是不要做了）。首先，分析一下那些人为什么支持你和抵触你。很简单，于公于私两个方面分析，上了新系统，谁的工作量有所变化？谁的潜在利益是否受到威胁？谁的岗位是不是因为新系统而消失？传统的利益格局因为新系统的使用而发生怎么样的变化，这些东西，都是项目经理必须去了解的，这样，你才能团结那些支持你的人，消减那些抵触你的人。项目经理是一个很奇怪的角色，属于典型的责任大、权力小的角色，他能做的只有借力打力，不管在自己公司还是在客户那里，一定要依靠别人才能完成自己的目的。只有了解哪些人会因为什么而帮助你，哪些人会因为什么而抵触你，你才能让客户配合你做工作。比如上一些内部计算机辅助管理系统，其必然后果就是让本来管理混乱时有人可以浑水摸鱼的一些利益消失掉了，这样，有些人肯定就要捣乱，到处诋毁这个系统。这时候，你就可以散布一些"谁抵制新系统就说明自己屁股上有屎"这类的论调去压制他们，减弱他们的影响。总之，团结积极分子，打压敌对分子，带动大多数是你的基本策略。
还有一个体会和大家分享：千万不要觉得对方的领导（中层干部）是应该配合你工作的，特别是一些国营单位，多一事不如少一事，他干吗要帮你？我的经验是：对方领导如果没有拿
你的事情作为内部斗争的武器而从中作梗（当然，他针对的不一定是你），那已经是算合作的了，记住，他不捣乱就是帮你忙了。
作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。一般说来，项目经理在考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，把项目控制在一个合适的范围内，让客户从理想回到现实也是项目经理的分内工作。
验收前，除了做好文档工作，即可交付成果以外，多花时间搞清楚客户的做事情流程是很重要的事情，一个公司做事情必定有流程，所以搞清楚流程十分关键。比如验收、付款这些你极其关心的事情，客户那边的流程是怎么样的，谁牵头组织、哪些人参加，要什么文件、走什么程序、哪些人签字、最后出什么文档等等，都要搞清楚，特别要事先分析和打听哪个环节容易卡壳，做好事先的准备。
我对验收最大的体会就是举证问题。即千万不要让客户这么想：你必须有证据证明你的系统是没问题的。这样你就没戏了，微软那么多天才，做了个Windows还天天打补丁，要你的程序没问题，既不可能，你也没办法拿出证据。你要让客户明白，所谓验收，就是我按照测试文档的测试用例跑一遍，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正，他可以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求，那么他应该举证，证明这个系统和最初设计相背离的。所以，参考法律概念，千万不要举证倒置。另外，认为系统完美了才能验收的想法也是错误的，软件开发合同里一定要注明验收以后维护期的费用问题，否则，客户担心一旦验收就得不到你
们的支持，自然不配合验收，那么，你这个项目经理就很难交功课了。
最后，我想谈谈如何评价项目经理的绩效的问题，我认为，项目经理有以下几个档次： *最差的项目经理：项目过程中总是出现意外，然后自己又解决不了，结果成为烈士； *二流的项目经理：项目也经常出现意外，但是他一马当先，奋勇向前，解决了一个又一个问题，最后，勉强算把项目结束了，获得了领导的一致好评；
*一流的项目经理：平时很少见他做具体的事情，整天找人聊天，然后就是写报告、做计划，最后项目顺利结束，整个过程平淡无奇；
项目管理到底是一门科学还是一门艺术呢？所谓科学就是经过反复论证，输入和输出有必然规律的东西，种瓜得瓜；而艺术就是思想火花的闪耀，主要靠灵感。项目管理这个东西，据一个前辈说，在国外是科学，80%是有规律可循的；在国内是艺术，主要靠个人魅力、感染能力等东西。看明白了PMBOK，学会了一些做事情的方式，只是搞懂了那个20%的科学的东西，还有80%的空间，属于见仁见智的领域了。所以，加强很多方面的个人能力，如练就出色沟通能力、提升自己的个人魅力对于项目经理来说是多么重要啊，无论是对内还是对外。作为一个一流的专业人士，在顺利让客户签字的同时，如何让自己的领导知道你的价值，这也是体现自己能力的一种途径。
项目经理应具有三种协调关系：
一、协调好和客户的关系
二、协调好和上级的关系
三、协调好和下属的关系
项目经理应具有的四个能力：
一、学会引导客户
二、对客户需求的认知及把握开发进度估算
三、如何有技巧地说不和点头
四、计划与实际现场运作的时间点观念及协调统一
我国的企业大部分是以接项目的形式做为生存和发展的途径，项目有(转自：wWw.XiAocAoFanWeN.cOm 小 草 范文网:项目经理工作心得体会)大有小，大的二三百万，小的三五万，因此项目的成败及效率就直接影响着公司运营成本和利润以及大家的薪金收入。而项目经理的人选则决定了项目的成败和收益，因此结合自己的经验谈谈项目经理在主持项目实际运作时的二个责任观点三种协调关系和应具备的四个能力。希望对大家的实际工作会有所帮助！
项目经理应时刻记住自己的两个责任和观点：
一、如何尽快地将项目验收回款，为公司和团队创造更多的利润，为下属带来更多的利益。
二、如何在做项目的过程中将项目提练成产品。
作者的观点是以项目提炼出产品并养活产品，而产品则更好地为项目服务以创造更大的利润和发展空间。
项目经理应具有三种协调关系：
一、协调好和客户的关系，保证客户交流时的气氛活跃活泼，事情做不完，明天可以再做，但客户的心情一定要开心！
二、协调好和上级的关系，这样你才会有行使项目经理的职权及争取到更好的资源配置。
三、协调好和下属的关系，他们才是为真正为项目打拼并出成绩的核心人员。
项目经理应具有的四个能力：
一、学会引导客户。
作为MIS软件，会不会引导客户是整个项目进度的成败。因为一个软件公司做项目时一般都有一个半成品，这时候项目经理和客户谈程序时的作用就是举重若轻，若会引导客户，则程序的二期开发量将会非常小，笔者当初拿着一个程序版本和客户谈时，连续三个大模块都获得客户的认可，只有3×0.5天工作量，而内部计划里则是3×20天的工作量的，同样项目提前了近两个月就转入验收期了。笔者当初获得这么大的成功，主要有两点：一是对自身软件产品非常熟，谈时扬长避短，并引导了客户。二是当时和客户谈时我说的都是模块的整体业务和模块的业务流程运作，引导客户并在大方向上达成了一致，不陷入技术细节。题
篇三：项目经理心得体会与经验
十四冶项目管理培训心得
创鑫公司 工程部
李自光
一． 项目要进行整体管理，善始善终
整个项目开始要做好项目整体计划，在项目的整个过程中，始终要按照项目计划执行，如若遇到项目发生变更，要进行影响分析，得到批准后制定变更计划，并按变更计划执行。变更的影响情况，如：费用，时间进度等要通知相关的项目利益干系人，说明变更的原因和产生的影响。 项目首尾工作也是项目管理中，一项重要的工作。需要将项目过程中产生的文件资料进行整理，归档；对项目的费用和进度进行审计和审核，对项目的质量进行检验和验收；对项目的整个过程的利弊得失进行总结和交流。 变更计划在软件项目中经常遇到。控制好软件项目的变更，首先需要做好项目的开始目标基准的确定，基准的用户需求明确，才能衡量出哪些是需要变更的。否则变更的东西和开始要求的东西混在一起，变更计划就无从制定，变更的界限也无从划清。 自己做过的一个项目，开始为了占领市场和尽快拿下合同，在用户需求还没有详细提供的条件下，就与用户签定了合同，后来不仅费用受到限制，就连时间不够，在项目过程中，用户方还总是变更软件的功能和要求。因为没有一个基点，我们认为是变更需求和新增功能，而用户方认为是合同范围，不能因此增加费用和时间。这个项目在开始好象签定了合同我们争取了主动，其实需求不明确，使我们在后来的项目进程中一直处于被动。 所以项目从一开始就要做好计划，搞清目标。只有项目的目标明确，合理安排时间、费用、人力和其他资源，控制好项目的变更，这些是保证项目能够顺利完成的基本条件。
二． 项目范围管理理论解决了项目开始需求不清的问题
需求管理是项目范围管理中的问题，这是因为它实际上是开发过程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况下，软件开发才能以一种有计划的有序的方式进行。实际上，没有文档化的需求，在开发工作完成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在其他关键过程中涉及的原则，都是从一个稳定的基础开始的，那就是文档化的需求基线。
什么需求？需求是指“分配给软件的系统需求”，或者更简洁地说，“分配需求”。这些需求有可能是技术方面的（比如：功能和性能需求），也有可能是非技术方面的（比如：发布日期，开支限度）。 区分开需求管理和软件需求分析是很重要的。一旦分配需求被文档化，并且被所有受影响部门（客户，系统工程，软件工程）通过，需求管理的基本工作就完成了，所剩下的就是管理变更而已。没有证据证明分配需求本身就可以十分清楚完整的作为软件开发的全部基础。事实上，通常它们不是。 优化和精确描述需求，填补漏洞，将含义表达得更清楚是软件需求分析要做的，分析的结果被称为“软件需求“。这样，作为需求管理的输出的分配需求实际上就成了软件需求分析的输入。需求管理远远先于软件开发的技术行动，而软件需求分析则是关键开发技术行为的第一步。从这里的描述看来，需求管理的活动简直太简单，太基础了，显然没有哪个软件开发组织会不有效的进行着这种活动。问题经常出在企业对透明度的惧怕。客户觉得保持需求含糊不清，松散或者无正式文件能够给他们
更多的机会去说：“那并不是我所要的，那并不是我认为的需求的含义”。文档化清晰的需求可能迫使用户在系统满足了文档化的需求但没有满足实际需要的情况下，为开始变更负责。相似地，开发人员觉得含糊不清，松散或者无正式文件的需求能给他们更大的余地，允许他们与预算和进度尽可能地接近，然后说：“这就是我们所认为的需求的含义，如果你需要其他的什么东西，你必须另外付出代价。”文档化清晰的需求会迫使开发者承担满足这些需求的义务，并使他们暴露于开支、进度评估不准确的风险之下。
这样一来，尽管客户与开发人员的利益动机相对，但他们却走到了一起。每一方都认为他们在保护自己的利益，巩固自己讨价还价的地位，但是事实上每一方都在走向将来的失望和争吵，为项目埋下了一刻定时炸弹。
三．项目时间管理理论指导我们在项目管理中怎样抓主要矛盾 。
以前进行项目管理时，是根据经验和每个人的工作特点，进行项目的分工的，软件项目基本是按照需求分析，概要设计，详细设计，代码编程，调试和测试，用户验收等几个主要过程来进行的。但将项目分工更加细化，每个小过程的时间估算是多少，整个项目可以最短用多少时间来完成，怎样合理安排人员，怎样抓项目中的关键环节等等，这些都没有进行过量化的分析和管理。 项目管理的实施最为直观的就是缩短项目时间。利用项目管理理论、方法，有许多缩短时间的例子。美国路易斯维化工厂检修时把检修流程精细分解，按导向图建立起控制关系。他们惊奇地发现，检修过程选择不同路径总时间是有差别的。通过反复压缩最长路径上的任务，将工期反复优化，最后只用７８个小时就完成了通常需１２５小时完成的检修，节省时间３８％。这就是至今项目管理工作者还在应用的著名的时间管理技术ＣＰＭ，即“关键路径法”。 所以我们在软件的项目管理中，也要将时间控制理论运用进来，结合软件工程的实际，将任务分解的更加详细，并用网络图将整个工作过程建立起来，估算好每个阶段的历时，找出关键路径，并通过快速跟进方法，将关键路径的工期缩短，以提高工效。
四． 质量管理是项目成败的关键
我们在进行软件项目过程中，对软件的功能测试一直认为还是比较认真和严格的，每次测试都要有测试计划和用例的编写，然后才能进行测试；测试要有记录，并将记录整理成测试报告。 但通过此次培训后，感觉到我们的测试工作与质量管理的要求还差的远，有距离。质量控制要深入到每个与项目相关的人，要深入到项目的每个过程中，从一开始，就要树立质量第一的理念，每个过程都要进行质量的控制，而不是到最好测试时，才想到质量，才去衡量是否符合标准。标准化设计，标准化管理是项目质量的保证。参加质量体系认证有助于企业提高项目的管理水平，有利于提高工程项目质量。CMM模型已得到广泛的认可和接受，CMMI沿用其模型的组织方式，有5个等级和18个要素。通过5个等级的认证和加强管理，企业对项目的管理将经过5个境界的提高：从混乱，到里程碑的检查，到定义清楚的管理体系和标准，到进行统计过程控制量化管理，到最后的优化过程、评价工作流程、进行工作过程的改进。 本人以前参加过为日本软件进行部分功能的设计和编程工作。日本的软件企业对一个项目的质量控制就做的比较细致，用我们的观念衡量简直是不可容忍。做一个模块的详细设计，要用他们提供的标准的图形语言进行描述，用标准的设计摸版进行说明；并在设计完成后组织相关人员对这个设计进行评价，有问题需要修改设计，然后在评价直到通过才能开时以此为设计文件，进行代码。代码写完后，不是见到结果就完事了，要将代码打印出来，相关人员对代码的整个实现过程进行评价，提出修改建议，代码修改后，需要再审，也是通过以后才能提交入代码库，进行代码的组装。 当时认为日本的方法太浪费时间和人力了，对技术人员个人的能力估计的太低，怎么能提高工
作效率呐。可是软件质量问题的频繁出现，是我们不断的认识到，开始浪费一些时间和人力，控制好每个细节的质量，就是省去了许多时候为解决质量问题而进行的新的时间和人力的支出。省去了大量的软件后期的质量维护费用。总的来看是核算的。为提高项目的质量，降低成本，必须从项目的开始就要做好质量的控制工作。
五． 沟通管理中的一些策略的使用可以使项目更好的完成
做项目就需要与客户接触，就会出现一些正式和非正式的谈判。双方都会为自己方的利益而进行讨价还价。与客户之间搞好沟通，是项目进展是否顺利的一个条件。沟通中有许多的策略在平时的实际工作中可以使用，目的不是坑害别人，而是为了更好地完成项目，达到双方事先确定的目标，而采用的一些艺术手段而已。沟通的技巧包括：下达最终期限，使用吃惊方法，采用有限权利法，不露面的人，公平合理，战略延迟，双方一起论理，撤退，不合理，既成事实等。本人就是成功的采用了战略延迟法，将客户方的一笔项目质保金及时地催要了回来。 体会还有很多，总之通过这次学习自己对项目的管理又有了新的认识，我会将这些理论知识运用到实际工作中去的。以提高项目的管理水平，提高项目的质量，降低项目的成本，降低项目的风险，最终提高企业的效益。