一、项目整合管理：

在项目经理介入项目之前，需要召开一个售前交底会，也称为项目内部启动会议。通常领导层会参加这样的会议，项目经理需要了解领导的期望。在会上，项目经理需要预防性地提出问题和风险，以便让领导对项目有一个合理的预期，同时也要管理相关方的期望。会后需要形成售前交底会议纪要，记录项目中确实存在的问题和风险，以避免责任推诿。

实际项目中的项目章程又称为项目经理任命书、立项书等，内容包括项目名称、工期、预算、项目经理身份、职责和权限。在项目开始前，有必要制作一个项目章，用于与客户签订确认文件或方案报审等资料。因为如果是大型公司的话，使

用公章需要走流程，比较繁琐。因此建议使用公司的公章来授权项目章。

项目开始后会有一次碰头会，也就是第一次会议。内容包括项目内容、目标、组织架构、团队架构、责任分工、总体进度计划，特别需要强调变更流程、沟通制度和问题升级程序。在会上，项目经理最好准备一份PPT去汇报（第一PPT有各种模板）。一般甲方领导会提出意见，在这里要注意甲方牵头人的高层要求。第一次会议上包括甲方领导、乙方领导、监理方、专家等都会在场，结束后需要当场打印会议纪要。会议纪要中决议的内容需要当场修改，并请甲方项目经理或对接人签字确认，带上项目章的话就现场盖章。第一次会议纪要需各方签字，有助于后续需求确认的时候甲方领导才敢签字。在项目前期就定好规矩，所有的确认文档都需要签字敲章。因为在项目的前期，项目经理一定要体现自己的专业性，与客户定好规矩，以便后续工作规范进行。人和人的沟通从建立信任开始。

项目管理的本质是最终要处理好所有的相关人员，包括客户、项目团队和其他相关方。相关方登记册中记录了相关方的期望，我们最好能记在心里，通常不会在相关方登记册上写，而是制作一份通讯录。在第一次会议中，作为项目经理可能还需要关注团队用餐地点、员工食堂的情况，以及附近的医院、银行的位置。此外，第一次去甲方场地时，需要办理一些开工报审的手续，前期开工报审所需的完整材料可以向监理方索取。

二、项目范围管理

如果项目的规模庞大，涉及到13个子系统，在需求收集的过程中可能会出现需求的变更。比如在招投标阶段规定的内容到签订合同时可能会有一些变化，比如设备型号等。这时可以采用深化设计的方法，首先确定各个子系统的大致框架和总体功能，保证不会变化，具体实现和细节可以逐个系统深入讨论，先不确认一些需求的细节，有助于减少大的需求变更。因此，在收集需求时，可以先确定整体的大需求。这也有必要尽早形成基准，以避免细节需求频繁变更导致基准难以形成。

在使用需求调研工具时，一些合同中已经明确规定的范围则不需要进行头脑风暴。在收集需求之前，需要先查看招投标文件和合同，明确需求大致要做什么，然后以此为基础整理需求调研大纲，明确调研内容、方法和对象。在与客户进行需求调研之前，需要提前预约时间，并让客户提前审阅需求调研大纲，协调需要哪些部门和人员参与，并确定时间。

如果客户的不同部门之间存在需求矛盾，项目经理最好不要深入到甲方各个部门，而是让甲方的对接人或项目经理汇总这些信息，由乙方的项目经理与甲方的项目经理对接。至于甲方内部的矛盾和冲突，则由甲方项目经理去协调，这样可以避免陷入甲方的利益纠葛，也可以避免不必要的冲突。

在收集需求时，首先要倾听对方的需求，确保理解对方的真实需求并深入挖掘。需求收集的重点在于了解为什么要做某件事情，而不是怎么去做。有时客户可能没有清楚表达意思，因此需要深入了解。

在进行需求分析时，必须明确客户需求是否在合同范围内，并区分强需求（必须满足的）和弱需求（合同中包含但意义不大的），高频需求（客户经常使用的）和低频需求（偶尔使用的）。重点关注重要但不紧急的需求。

敏捷方法中有一种需求收集方法叫MOSCOW法，即Must(必须要做的) or Should(应该要做的)，Could(可以做的)，Won't(不要做的)，通过这个方法对需求进行排序，明确哪些是必须做的、应该做的、可以做的和不做的。排序完成后需要进行需求确认，确保最终的需求文档经过确认，以便在客户要求修改时进行变更流程。

PMBOK中的定义范围在实际项目中一般都叫确认需求（需求分析）。需求确认（形成基准）后可以变更，但是要走变更流程。在项目的早期就要让客户养成签字的习惯。如果遇到客户不愿意在需求文件上签字可以有以下方法：

1、审查自己的需求文件写的是否合理？不能照搬照抄合同或 招标文件 上的条款。

2、一般客户不愿意签字大部分原因是不敢担这个责任（他会说万一我签字了，需求需要修改而你们乙方却不肯改，那我该怎么办），所以他会一直拖着不签。面对这种问题，我们首先应该学会换位思考，项目经理可以这么说：***老师，需求确认其实是一个依据，我们后续的许多工作都是以这个为依据的，我们公司的话也需要这样一个东西报上去审批，接下来公司才会安排资源来给我做这些东西。至于你担心的问题我也可以理解，我可以让你在确认的时候写上这么一句话“如果后续有需求发生变更，我们会走合理的变更流程进行评估，至于是否会产生额外的时间和费用，双方或者几方可以协商解决”。

3、如果客户还是不愿意签字，那么还有一种办法就是找他的领导，可以这么说：***领导，目前我们的需求都已经定的差不多了，但是可能最终有些东西呢还希望领导过来把个关，领导您有没有时间，我们一起来讨论一下有什么问题。这里找领导需要找分管领导，管这个项目的。领导来了之后，我们还是需要把需求文档在从头到尾过一遍，有问题解决问题，没有问题的话，再要求客户把 需求文件 签一下字。这时候领导在场，一般都会签字。

4、如果领导不愿意过来开会，说这个事情你们自己协商。那么这时候可以选择 破财消灾 ，项目经理可以找几个专家过来正式的搞一个需求评审会。评审的结论是基本上没啥问题，可以找3个或5个专家（这里涉及到专家费），会议后专家出具专家意见并签字。这样可以显得项目流程非常正规，没啥猫腻，而且甲方也会放心一点，感觉专家都说没问题了应该就不会有啥问题了，甲方客户的责任可以适当分担一些。如果甲方担心专家有问题，那么可以让他自己请1个专家，由乙方出钱。这里找专家的主要目的就是尽早的让甲方确认需求文件并签字。

需求变更如果确实存在问题，比如需求不合理或者设计方案不对等，那么是需要进行变更的。最常见的需求变更是客户要求增加需求，如果不满足，客户就会不满意。面对这种情况，通常有以下几种常见的处理方式：

1、建议客户不要增加这个需求，因为项目有进度和成本的限制。如果要增加功能，而之前的需求文件中并没有包含这项功能，那么增加功能是否会对成本和进度产生影响呢？因此最好建议客户在下一个阶段考虑这个新需求。为什么要在下一个阶段考虑呢？因为明年您可能需要向主管单位申报项目预算，如果没有新的内容，那么如何向主管单位申请资金呢？因此这些新需求可以作为下一个阶段的内容，我们可以一起提出方案，向相关部门申报新项目，争取到新的资金。这样您不仅有了资金支持，项目也可以继续进行。

2、如果客户坚持这个需求非常紧急，不想等到下一个阶段，一定要在当前阶段实现。那么我们可以跟客户商讨是否可以通过去掉一些不重要的功能需求来实现。可以采取功能变更的方式，将原来的功能变更成新的功能。这样做的好处是可以在可控范围内保持进度，并且成本也可以承受得住，对双方都有利。进行功能交换。

3、如果客户还是坚持认为以上方式不可行。那么我们可以先了解一下客户要增加的内容具体是什么，看看是否可以在当前阶段先实现一个初步版本，适当降低需求的强度，先完成一些基本的部分，而将更详细的部分留到后面再实现。因为公司也需要考核我的绩效，按照正常的项目管理规范来说，做额外的工作并不合适，但我可以适当减少工作量，在可控范围内完成一部分工作，这样可以吗？

4、如果以上方法仍然无效。在这种情况下，尽量不要破坏与甲方的关系。可以请监理方（或第三方）介入，比如在会议上询问监理方：在我们正规的项目管理中，遇到这种情况我们应该怎么处理。监理方通常会有一套规范的做法，包括四控三管一协调（其中一个控制是变更控制），这时他们通常会说明我们正规的变更管理，新加一个功能应该如何管理。如果监理方直接说客户让你做你就做吧，那么我们也不要去找甲方，而是要去找监理方，这时就可以将变更管理的流程说出来，我们需要先评估新增功能对之前确定的需求基准有哪些影响，然后接下来该怎么处理。

5、如果以上方法仍然无效。那么就要检查自身原因了，我们做事情需要低头做事，同时也要抬头看路。如果方向不对，那么再怎么努力都无济于事。我们要看看根本原因是甲方真的想增加新功能还是故意为难我们。我们可以跟售前或销售沟通一下，了解一下甲方目前的情况，看看当初我们对甲方的一些承诺是否兑现了，比如商务费用，是否已经支付。如果没有这方面问题，那么销售还是需要提供支持，从商务手段上想想有没有什么办法。

6、实在没有办法，也可以找相关专家过来进行正式的变更评审会。

7、最后一个办法就是找自己的领导出面协调。这里需要提前跟领导打好招呼，说明现在的情况是我们所有需求都已经确认过了，而且是书面签字过了，即使最终走到法律程序，我们也是比较主动的。这时一定避免领导过去甲方那里谈的时候就是一口答应了，一定要提前告诉领导不要一口答应。因为我已经顶了那么久了，告诉领导一口答应的后果就是以后甲方有问题就不找我项目经理了，而是直接找你领导了，这时项目经理在项目现场就没有任何地位，只是一个传话筒，而领导则变成了项目经理。这时领导可以说我们这个项目确实还是挺复杂的，进度和成本很紧张，项目经理的做法也是正确的，而且公司最近对项目的审计也非常严格，确实压力很大。

从长远角度来看，你们也是我们的目标客户，我们也希望有二期三期的合作，所以从战略角度来说，我们可以做一些微调，双方配合一下，至少可以在功能上进行一些弱化，也不是不做，可以适当做一点点，我们可以取一个折中的方案。当然在没有万不得已的情况下，不要把事情推到领导那里。

三、项目进度管理：

在估算活动持续时间时，应该由项目团队中最熟悉具体活动的个人或小组来进行估算。一般来说，开发人员在估算活动持续时间时会比实际估算的时间多出几天提交给项目经理。项目经理在遇到估算活动持续时间困难时可以采用“敏捷扑克”的方法，这是基于德尔菲的方法。比如，可以让三个技术人员坐下来，每人发一个扑克或白纸，让每个人互相不要交流各自写下估算的时间，然后公布结果并进行讨论。经过两轮或三轮之后，大家估算的时间应该是基本接近了。确定之后，项目经理再拿这个去排进度计划了。这样做的好处在于：1、这个时间不是项目经理一个人拍脑袋想出来的，而是大家一起估出来的，对项目经理比较有好处；

2、这个时间相对来说会比较准确。

另外一种方法是关键链法。比如，本来两个项目活动估算出来是需要14天时间，但是项目经理分配给开发人员的时候是说只给你7天时间，然后另外多出的7天时间项目经理自己捏在手上作为缓冲时间。这种方法实际上也叫作帕金森或学生综合征，所以这种方法还是容易出问题的。因此，在实际操作中需要注意避免因为进度压力而牺牲灵活性和可扩展性。

假设日志是进度计划中的一个重要输入。在实际项目中，特别重要。比如，在项目刚开始时，需要进行开工报审、施工组织方案报审以及总体进度报审，其中在总体进度报审时，特别需要注意假设日志。进度计划通常包括甘特图、重要的里程碑以及前置条件。前置条件需要明确指出每个里程碑对应的前置条件，以确保项目按计划进行。在项目执行中，项目经理需要善用阳谋，而不是阴谋，并且要学会换位思考。在解决问题时，需要定义问题、了解问题根本原因、提供解决方案供选择、确定方案、实施方案，并验证有效性。在项目加班时，项目经理需要照顾团队关系，使用人际关系技能来激励团队。

四、项目团队管理：

项目经理应该具备的基本素质之一是尊重团队中的每个成员，关注他们的需求。相对来说，外企在这方面做得比较好，他们首先承认员工是人，然后才是员工，而国内很多企业在这一点上做得不够好，他们会首先强调员工是员工，而忽略了员工也是人。

其次，项目经理应该做到公平公正，不能独占功劳，出了问题就推给团队。因为项目经理是团队的领导者，而不是剥削团队的人。

第三点是要保护每一位团队成员。特别是在涉及到工程项目的情况下，比如做集成项目，会涉及到综合布线、登高作业、机房精密空调等，肯定会涉及到用火用电等安全问题。在做这些工作的时候，必须要做好团队成员的安全保护工作。如果因为安全隐患导致项目出现问题，后果将非常严重。

第四点是项目经理要注意领导和支持团队成员。能做的要带领大家一起前进，不能做的要给予支持。

此外，项目经理还需要大度一些，在很多方面都要表现出来。比如让团队成员带饮料，却从未给过钱，即使对方嘴上不说，心里也会不舒服。项目经理还需要经常请团队成员吃饭。另外，要避免坑害团队成员，做到真诚、知己知彼，不卑不亢。

勇于承担责任，乐于分享。出现问题时，先反省自身问题，而不是一开始就找别人的原因。要考虑团队成员的人身安全，维护他们的尊严，保护团队劳动成果，并为他们争取利益。如果不为他们争取利益，团队成员会觉得无论表现好坏都一样，这对团队的良性发展是不利的。

在会议上要注意照顾团队成员的情绪，特别是当有人表现不佳时，不应当当着甲方的面指责团队成员，这样做是不合适的。因此，不要在公共场合批评团队成员，有问题时可以稍作提及，然后私下再进行处理。

项目经理的领导方式是指引团队一起前进，实现共同目标。而单纯的管理是指项目经理坐在那里不做实质性工作，只会指派任务，像拿着鞭子在后面驱使别人。因此，领导和管理团队这两种方式即使带领同一个团队，结果也会有天壤之别。特别是在外地项目中，第一件事就是吃饭。在团队中要制定规矩，加班时只要有一个团队成员加班，项目经理就必须在现场陪同。如果项目经理有事情要处理，就去处理事务；如果没有事情要处理，就要做好服务工作。比如买一些夜宵、烧烤食品和饮料，或者给团队成员做一些按摩等增进感情的活动。如果只有几个人加班，其他人都回去睡觉了，那会让人感到不舒服，会想为什么只有我在加班。因此，项目经理要么做好领导带领大家一起奋斗，要么做好仆人式的领导（服务）。

另外一个重要点是要无保留地勤奋分享。比如晚上不加班的时候，可以找个地方好好吃一顿，点上一盘花生和毛豆，大家在工作中遇到问题可以提出来，分享自己以前遇到类似问题是如何解决的。我们可以把进入一家公司比作1万元，而当我们离开时，公司能够获得三万元的价值，那就说明我们为公司创造了价值；如果我们离开时感到毫无所获，那就说明我们在这家公司虚度了三年。

先做事情，再谈报酬。当向公司要求加薪时，一定要先想清楚自己这一年来为公司做了什么贡献，比如参与了哪些项目，在项目中承担了多少工作量，自己的工作对项目产生了怎样的影响。因此，在谈加薪时首先要把工作做好，做了多少事情再提出相应的要求。

一般情况下，在实际项目中，团队成员通常可以分为以下四种类型：1、积极主动。这类成员被称为最佳队友，他们非常出色，难得一见，我们应该珍惜他们；2、跟随执行。这类成员并不会主动带头，但是一旦看到有人在做，他们会跟着一起做，渴望提高自己，具有团队意识，这样的成员也不错，需要好好培养；3、老实努力。他们按时上下班，踏实工作，属于普通成员，有待提高，需要和他们好好沟通，告诉他们我们都是追梦人，都在努力奔跑；4、对抗执行。这类成员不仅不努力工作，还会和你对着干，整天散布负面消息，抱怨公司股票下跌、有人离职，然后到其他公司工资翻倍等等，建议直接解雇这样的人。如果一个团队里有两个人对抗执行，那么团队其实已经处于危险之中。

团队与团伙。团队是被愿景驱动的，大家都有使命感和责任心，团队是互补共赢的，就像五根手指长短不一样，每个手指的作用也不同，小拇指用来挖鼻孔，食指用来指别人，大拇指用来表扬。大家应该分工明确，互相补充，相互配合，遇到问题一起解决，共同推进项目，就像敏捷开发中的自组织团队一样，“败则拼死相救，胜则举杯同庆”，团队应该是这样的。而团伙是被利益驱动的，只关心个人得失，不珍惜团队成果，斗争和推诿，心怀鬼胎，比如不爽就把服务器数据全部删掉，这样的团伙注定走不远，也没有前途。团队中应该保持积极乐观的态度，“但行好事，莫问前程”，认真做好每件事情，总会有好结果。

项目经理需要注意的是平台的实力和个人实力是不同的。所以有时候需要冷静思考未来的路该怎么走。团队建设是锦上添花的事情，而不是雪中送炭的事情。

五、项目其他管理（成本、质量、会议、验收等）：

在实际项目中，很难进行成本管理，因为项目经理通常不清楚采购费用的具体数额，以及哪些费用是为甲方支付的，例如招待费用、商务费用等。一般来说，项目经理只负责实施费用，包括房租、餐饮、团队建设、交通和电话费用等。因此，最好在公司设立一个标准额度，例如500万项目需要多少实施费用。通常只要按照发票报销，且不超过额定金额即可。

在实际项目中，质量管理在IT行业并不像制造业那样重视。对于任何变更，都需要先与客户和监理方私下沟通达成一致，然后在会议上进行流程确认。在沟通时需要注意换位思考，讲道理时要有合理的理由支持自己的观点，并要考虑整体利益。例如，如果供应商送来一批服务器，最好不要让团队成员帮忙搬运，因为这涉及到到货验收责任问题，一旦发生损坏，责任归属会很难界定。

关于项目周报，内容包括项目状态提示、人力投入情况、关键里程碑、本周计划完成情况、详细工作描述、下周工作计划以及存在的问题和风险。有时可能需要向业主方和监理方发送一份周报，同时向领导发送另一份。在发送邮件时，建议将重要内容写在正文中，包括大致的进展情况、风险和问题描述，然后再附上详细内容。

项目状态报告（阶段报告）也称为工作绩效报告，内容包括当前阶段工作完成情况概述、偏差及原因、纠正措施、拟定变更、存在的风险及应对计划以及下一阶段工作说明。

内部审计（QA）。公司审计部门会不定期进行审计，逐项核对审计内容。

变更单。变更前需要进行私下协商，然后提交工期变更单，需要各方敲章确认，包括自己、监理方、工程监理、投资监理以及甲方的确认。变更单的配套附件包括变更情况说明、变更内容、涉及工作量和报价、型号变化等详细资料，因此变更流程非常复杂且严格。如果项目后期出现数百甚至数千个变更，说明项目在前期规划存在问题。

项目验收。验收准备包括对照合同验收标准、与业主私下沟通、提交验收申请、整理文档并打印装订。验收会议流程一般为监理汇报项目实施情况，业主方总结项目实施情况，项目经理做验收汇报并准备PPT，专家提问并形成专家意见，最后业主单位确认专家意见并签字确认，形成验收报告和备忘录。

需要推荐靠谱PMP/软考/NPDP/CSPM机构的同学可以关注我后台回复【推荐机构】

备考资料分享如下：