作为生产管理的大脑，项目管理是指挥中枢系统的关键链接来源处。最为关键-项目管理的计划性、统筹性、进度的落实细化、预决算检讨成本对比等内容是项目启动以后成败的关键。

项目管理的协调功能必须尽力去发掘，因为从项目立项开始到结束的一个周期内，从采购到详图设计、从生产到品管等时刻都必须围绕在项目进度这根指挥棒底下运转，保质保量落到实处其实很大地需要依赖项目工程师的综合协调能力的具备和配备，尤其进度是生命，这点不容忽视。

安全体系也是项目工程师必须注重主抓的。

业主客户指令必须尽快传达到相关人员，这也是项目工程师必须去做的。

合同的细节必须详细了解，涉及到更改变动之处必须及时洽谈列取变更清单。

以下几点必须牢记：

督促图纸文件和相关程序的及时上报客户批准，确保所有程序、图纸已被批准，确保规范、图纸和批准的程序在开工以前送到生产车间以及已中标的分包商手中，如果有需要，应召集技术品管生产等部门协调员，分析处理解决现存实际问题。 跟踪关注提醒项目专项材料的及时供货到位。

监督已批准的程序、计划等在制造过程中的实施。

负责每一个项目已批准的变更和增加的工作量及时的控制、费用控制直至结束。

进度质量的相互调整、安全的重视。

周安全例会的召开。

项目完工总结。

对本项目的HSE负全面责任。

项目部和各部门的协调

营销部：下发项目号、项目预算，召集项目部、技术部、品管部、采购、生产参加合同介绍会，介绍特别要求和范围后移交给项目部。

安全部，下发每季度组织由公司各部门OHS代表以及员工代表参加的OHS沟通会，会议着重了解各部门OHS运作过程中的问题以及员工对OHS系统运作的意见和建议。

项目管理的关键

项目自从成立立项以后，项目经理负责建立项目管理组，并与有关部门经理协商确定项目组织机构，包括：项目工程师、计划工程师、费用工程师、项目秘书、技术负责人、施工经理、物流采购负责人、QA/QC负责人、安全负责人。组织机构表应得到总经理批准后发至有关部门。

项目经理应负责组织编写“项目执行计划”，其内容应包括：项目的组织形式、人员的职责、工作界面的划分、工程计划、建造方案、质量计划HSE计划等。以便对项目实施过程中的各个环节实施策划。

项目经理应负责组织编写“项目管理程序”，其内容应包括：

项目组织机构、人员职责、建造计划、人力分配、进度权重分配方法，进度控制、费用控制、变更控制、内外部沟通/协调方式，件控制、质量控制、安全管理。

关于文件控制

项目文件准备的进度表，业主批准后项目组应填写业主要求的项目文件表并送到有关部门做准备。

文件交付状态表项目组应填写交付文件表以例于文件控制，促进业主对交付文件作出回应是项目组的责任。

受控文件表：项目组应予确定文件为受控或非受控级。对受控文件，此表用于将受控文件不同版本定期传送到受控文件持有人手中。

文件分发数量表，项目组在征询相关部门所需文件拷贝数量后应建立文件发放分配一览表，供项目运作期间执行。

关于计划

工作进度表应由总计划，详细的分类计划、S曲线、直方图、表格及报告组成，工程过程必须保存。

业主项目总计划表需要业主审核及批准。一旦获得业书面批准，它将成为并在此后作为“已批准计划表”使用。

已批准计划表应根据实际工作进展而进行定期更新并准时提交业主。

总计划表应当是一个以粗线条表示的综合的项目进度表，它建立在时间表的基础上，该表以星期/月为单位。

详细计划应包括工程周期、场地制造周期、安装周期以及可能需要启动的其他项目。

关于变更控制

项目经理应指定专人管理变更事宜，应当在七天内或在合同规定时间高效快速向业主提出。包括合同之中的条款、服务的改变、可能产生的影响。变更数目、变更的简短描述、提交业主的变更日期以及合同价格的影响十分重要需要注意。

关于分包控制

新分包商应由QA审查其质量保证能力，QA可通过审核报告推荐或否决分包商。审核报告由QA/QC经理批准

获批的分包商应列入“已批准分包商名单”该名单与分包商其他资料一并于QA/QC部建档。

分包合同的签定按合同制定的程序执行。

对进入长盈场地施工的分包商，安保部应对其安全保证能力进行审核，并出具安全审核报告。

分包商在长盈场地的工作应完全符合长盈已建立的质量与职业安全卫生管理体系及有关项目程序文件的要求。

若分包商的操作程序不合质量或安全要求，QA/QC经理或安保部可以建议将其从“合格分包商名单”上踢出，并出具书面报告提

交DGM/GM批准。

分包商在其分包工作完工时，项目组、QA/QC及安全部应对其工作进行评估，评估表由QA/QC部存档。

关于生产管理过程控制

项目组应在生产过程中通过有效地执行制造程序和质量安全控制程序来确保工程质量与安全。

重要构件的制造及安装时，要协调确保QC检验员全程跟踪。 项目组应监督工程进度的实施，作业人员资质必须备案。 质量控制过程

所有过程检验标识清晰。

NCR关闭必须及时。

 

第二篇：项目管理心得

项目管理心得：一个项目经理的个人体会、 项目管理心得：一个项目经理的个人体会、经验总结
本人做项目经理工作多年， 感到做这个工作最要紧的就是要明白什么是因地制宜、 因势利导， 只有最合适的，没有什么叫对的，什么叫错的，项目经理最忌讳的就是完美主义倾向，尤其是做 技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。以下是本人一些做项目 的个人体会，写出来供大家指点，在讨论过程中共同提高水平。 项目开始阶段是一个最重要的阶段。 项目经理在接手一个新项目的时候， 首先要尽可能地多 从各个方面了解项目的情况，如： 1.这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。在 国内很多客户都很不成熟的情况下， 千万不要根据项目的名称望文生义地去想象项目的目标。 一 个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算 机生产管理辅助信息系统系统。前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就 越小。 2.这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督 方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目 监理公司、 业主的行业主管机构等。 项目经理需要了解每个方面的人对这个项目的看法和期望是 什么。事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪 些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人， 让事情向你所希望的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话 作为项目经理是一定要记住的； 3.基本了解了客户的情况后， 下面的事情就是了解自己公司各方面对这个项目的看法。 首先是高 层领导是否重视， 这个决定了你在需要资源的时候， 公司是否会根据你的要求提供最有力的支持。 领导口头肯定是说支持的， 你需要做的是了解公司对这个项目的实际期望， 是想把项目越做越大 还是想赚钱？是想做样板工程还是干脆想敷衍了事， 公司领导对项目的态度决定了你做这个项目 的战略，而这个战略方针将对你做项目计划产生直接的影响； 4.在做整体项目计划前，还要大致计算一下你手上的资源。首先是时间，现在市场竞争激烈，往 往很多项目要求在几乎不可能的时间范围里完成。 对于这一点， 你在做项目的风险控制计划的时 候要充分考虑。其次是人员，根据项目预算和已往经验，大致计算一下未来的项目小组有多少种 角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员， 招聘的准备工作要尽早启动。最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以 后不管发生设备等人还是人等设备的情况，浪费的都是你的时间； 5.现在是做项目说明书的时候了。 一份好的项目说明书不仅将要做的事情描述得很清楚 （主要是 讲做什么，而不是说怎么做），而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做 哪些事情，也让客户的业务人员（一般不懂技术）知道项目做成什么样就算完成了。简单地说， 项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。 6. 是到做总体计划的时间了吗？不，你现在已经知道了客户的目标和你手上的资源，那么做计 划以前，你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的，你需要

写一份报告， 详细分析这个项目的风险以及对资源的需求情况。 如果一些问题不能得到解决的话， 将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个项目的投入。甚至在条件 许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，如果项 目经理不能尽早发现风险，那么就只能去当烈士了。 7.明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略， 现在是成立项目小组的时 候了。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想 要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客 户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。我经常看到的情况是我 们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不 懂技术。其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎 么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择了客户，有了 客户你才有工资拿，心平气和一点吧。 对于这种需求天天变的客户，你就一定要事先做好规矩： 一、统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句， 如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组 只认一个的意见， 有什么要求你们内部先统一再和我谈， 我不想卷入你们内部业务部门之间的矛 盾之中； 二、所有需求变更全部要有书面文字，这点切记！这样做好处多多： *有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的； *便于需求变更管理， 需求如何慢慢演变的历史可以看清楚， 从而更深切地体会客户的目的； *对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是 否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎 多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了； 8.现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎 么做，什么时候要他们做什么准备这些事情将是你的主要工作。既然沟通这么重要，那些事先定 义一下沟通的原则也是一件很要紧的事情。 很多沟通原则都是潜规则， 如果你在一个部门时间做 长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个 单位，不把沟通规则说清楚，你以后就会吃亏。下面的东西看起来无聊，其实还是很管用的：第 一个是规定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，不管 通过电话、邮件还是书面方式，保证将信息传达到每个人。这种情况适合小项目，人少；拉的意 思就是项目经理就是一个类似 web 服务器，你自己需要什么信息就去问他。当然，没有项目经理 把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是 项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊， 其实里面牵涉信息传达不完全的责任问题。当然，这些都是指一般的方式，而且不要绝对化，一 般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导 沟通。第二个问题就是文档问题，很多人怕写文档，但是项目经理一定要牢记“好记性不如烂笔 头”的道理。 有理有时候为什么会说不清呢？就是因为没有证据。 所以项目经理开始就要和客户 说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外所有 达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯 皮的时候，就能做到有据可查。记住：说了的就和没说一样，只有写下来大家签字后才算真正发

生了的。还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题， 结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，但是注意要留记录， 标明是谁的责任；另外，如果你在开始阶段就和领导商定：如果批示提交三天后没有得到领导答 复就算对方同意，这样你就会主动很多。再比如不同事件的审批流程问题：什么等级的事情记录 在项目日志里、 什么等级的事情要双方项目经理专门签署备忘录、 什么等级的事情要双方领导出 面签署合同附件等等。事先想得越周到，以后的工作就越主动。 9.好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。这一节，任 意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会就是了。首先是 找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几 块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里 说的是怎么做的问题。这里要强调一点：完成一个目标有很多种方式，你要选一种你最熟悉的， 而不是看上去最完美的， 这个思路会让你的项目减少很多风险。 有时候客户会被某种新技术打动， 坚持要你采用那种新技术，你就应该告诉他：你选我做这个项目，就应该容许我采用自己最喜欢 的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害 者。采用一个计划会让你的工作更加明确，比如用微软的 Project 软件，你填写完表格以后，就 可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗 的时间有多长，完成后有什么标志等。所有的结果最后用一个叫做干特图的形式表现出来。你做 完这个表以后会惊奇地发现， 干特图上项目的结束时间会远远落后于你的计划结束时间 （签合同 的人永远不会先征求你的意见的）。当然，学过项目管理的人会大谈什么 WBS、优化路径之类的 东西， 但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。 如果你没碰到这个 问题， 在我恭喜你挑了一个轻松活之前， 请你再去确认你是否罗列了所有要做的事情和正确评估 了他们所需要的时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。按照什么 标准牺牲？这个项目的战略！我们在第三节提到过的战略。我的经验是如果你什么都赶进度，其 结果可能就是十件事情你一件也没做好，想想多么失败啊。所以，把资源投到你熟悉和有把握的 事情上， 最后的结果是十件事情， 你有三件做成了精品， 三件完成， 还有四件因为某些原因延误， 成绩单是否靓丽了很多呢？战略决定优先级， 而正确排列事情的优先级是一个项目经理能力的主 要体现。 好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制定了项目的策 略，然后编制了项目的整体计划，项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的 时候，不像前期的时候项目经理要象记者一样到处和不同的人接触，搞清楚他们在说什么，努力 猜测他们在想什么和他们的真正目的，那才是最累人的事情。当然，小项目的项目经理往往自己 也是一个资源，要做很多事情，这时候反而比谁都苦。项目经理这段时间的主要工作是保持和客 户领导以及自己领导的沟通。和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你 才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些 领导不懂的细节，比如：“王局长，最近项目进度还算正常，就是 JVM 经常发生一些内存泄漏的 情况…”王局长：“(*&$@@”。和自己的领导汇报也要注意这个问题，除非他是一个技术高手， 你需要他的技术经验， 否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了， 有 些需要他支持的地方，比如资源调用需要说详细一点。和组员开会，除了一些项目进度跟踪会议 以外，还有很多讨论会，需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员， 他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强（如果总结得不对，欢迎大家拍 砖），所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者 的角色。一个问题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。

这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都 应该认为，他们提出的方案，从他们的角度来看是最合理的。你的长处是掌握事情的优先级，评 估各个方面的轻重缓急，从而根据他们的意见得出一个合适的（而不是正确的）方案。所以，在 会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带 入无休止的争论 （你要让大家知道事情不是非黑即白的， 而是多元的， 我们的教育惹的祸…） 唉， 。 会后，你自己写文档，做决定。会议上大家的面子都被照顾了，自己实施起来的阻力就小，如果 还有意见的，你就私下找他聊，如果还不能说服他，你就要让他明白，因为你负责这个项目、你 担当风险，所以，这个优先级应该你来判断。组织中的高层，并不见得水平会比一般的成员高， 但是， 他要承担组织的风险， 加之信息的不对称性， 所以， 对事情的优先级的判断肯定比下属强。 在开发过程中， 内部管理还要注意的一点是时刻强调以验收为目的的思想， 每个任务的最终可交 付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知 道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划， 里面有一个任务 【开发人员熟悉 EJB 编程】 这个任务， ， 除了让这些人去参加一些专业认证考试， 否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意 的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决 定工作计划。 很多项目开始了很久， 还不知道如何验收， 那么这个项目出问题的可能性就很大了。 做项目就是为了验收， 我们的角色不是研究机构， 我们的目的就是在付出那么多劳动后得到结果。 另外我插一句：我是极其不主张到客户现场开发的。尤其是一大群技术人员直接和客户交 流，很容易引起冲突和矛盾（技术人员的本性决定的）。我的做法是项目经理和项目实施人员到 现场， 软件开发人员还是在公司做项目。 项目实施人员就是初级项目经理， 他们了解自己的产品， 懂得一些客户的业务，关键是在于他们具有良好的沟通能力，俗称“皮厚”。他们是客户和研发 人员的桥梁，其职业方向也是很机动灵活，以后可以有很多方向可以转，比开发人员的路要宽得 多。 接着，我们再谈谈最让人头痛的需求变更问题。变更通常分为两种：一种是部分更改了原先的目 标，即需求变更；另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小 到界面的布局，都是属于这类。碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户 随着项目的进展，慢慢想清楚了问题，改变了以前的思路。这时候，如果需要改并且你的战略是 容许这种情况的，那么注意下面几点： 1. 确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把 你的工作停下来， 赶快再和客户自己确认一下你的方案， 然后让他签字， 避免以后说话没有凭据； 2. 和客户坐下来，自己探讨他修改的根本目的是什么，是不是有同样能达到相同目的，但 是对你来说有代价更小的选择？ 3. （项目初期的工作）明确更改流程，一般是客户指定一人签字（否则客户每个领导都有 权力来插一杠子，你就废了），以正式项目文件的方式提交给你，然后，你做评估分析，分析对 成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由 此带来的不确定后果（这个东西先写出来，后面如果真的发生了，至少不是你的错）。然后再让 客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗？对，就学习那个，让大家 都意识到任何的更改都有成本和代价。

系统开发告一段落后， 就进入客户培训、 系统验收阶段， 这个阶段， 我一般会注意以下几个问题： 一、给客户做培训前，多注意一些表面功夫。很多程序员认为，系统的逻辑核心是否正确 是关键，至于界面如何，界面上的用词是否准确，那是无关紧要的问题，而且培训的时候也是信 手拈来，想到哪里说到哪里，下面听讲的人不知所云，云山雾罩，培训效果自然可以想象。我的 体会是， 给客户做培训的版本， 如果你在做多次测试以后仍然不能确定逻辑是否合乎要求， 那么， 你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等，总之不要让 客户看到一些他不该看到的东西。文档方面，准备至少两个文档：用户手册和培训手册。这两个 文档的内容很多都是一致的，但是角度完全不同。用户手册往往是站在系统设计者的角度，按照 自己的思路，分模块讲解系统的操作和功能；而培训手册，一定要站在客户业务人员的角度，根 据每个角色面对不同业务的办理，如何通过使用本系统的一系列功能来实现目标。所以，第一次 培训以前，系统界面是否完整正确、培训文档是否完备都是很关键的因素，第一炮打不响，以后 就麻烦很多。 作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源 以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型 的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把快放在第一位，各 方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如 果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没 有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望 值，让他们从理想回到现实也是项目经理的分内工作。 验收前，除了做好文档工作，即可交付成果以外，多花时间搞清楚客户的做事情流程是很 重要的事情，这些在前面已经有所提及，这里就不再多说。 我对验收最大的体会就是举证问题。即千万不要让客户这么想：你必须有证据证明你的系 统是没问题的。这样你就没戏了，微软那么多天才，做了 XP 还天天打补丁，要你的程序没问题， 既不可能，你也没办法拿出证据。你要让客户明白，所谓验收，就是我按照测试文档的测试用例 跑一遍，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正，他可 以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例。如果他认为系统不符合要 求，那么他应该举证，证明这个系统和最初设计相背离的。所以，参考法律概念，千万不要举证 倒置。另外，认为系统完美了才能验收的想法也是错误的，软件开发合同里一定要注明验收以后 维护期的费用问题，否则，客户担心一旦验收就得不到你们的支持，自然不配合验收，那么，你 这个项目经理就很难交功课了。