学员：王永宁 时间：2019年4月23日
一、项目整合管理：
项目经理在介入项目之前，有必要开一个售前交底会，又叫项目内部启动会议，一般这种会议领导层都会参加，项目经理需要了解领导的期望是什么，会上项目经理需要打打预防针，以便让领导心里有一个合理的预期，这也叫管理相关方的期望。会后形成售前交底会议纪要，里面会记录项目中确实存在的问题和风险，这样做可以避免背锅。
实际项目中的项目章程又称：项目经理任命书、立项书等，内容包括项目名称、项目工期、项目预算、项目经理是谁、项目经理职责、项目经理能做哪些事情。项目开始前有必要刻一个项目章，用于跟客户签订确认文件或方案报审等资料，因为如果是大型公司如果用公章的话是要走流程的，比较麻烦。所以这里建议用公司的公章去授权我们项目上的项目章。
项目开始后会有一次碰头会，也就是第一次会议。内容包括项目内容、项目目标、我们的组织架构、项目团队架构、谁负责什么、总体的进度计划，特别需要在会上强调变更流程，沟通制度，问题升级程序，这里项目经理最好准备一份PPT去汇报（第一PPT有各种模板）。会议时，一般甲方爸爸的领导会在会上提些意见，这里要注意项目的甲方牵头人的一些意见，关注他们的高层级要求。第一次会议上包括有甲方领导、乙方领导、监理方、专家等都会在场，结束后要当场打印会议纪要，会议纪要中决议的内容需要安排同事当场修改，当甲方领导说完，乙方领导表态结束后，项目经理说话让大家看看对会议内容和会议形成的决议有没有什么问题，没有问题的话，就拿着会议纪要让甲方项目经理或甲方的对接人签字确认一下，带上项目章的话就现场盖章。第一次会议纪要做到各方签字，这样有助于后续需求确认的时候，甲方领导才敢签字。在项目前期就定好规矩所有的确认文档都需要签字敲章。因为在项目的前期项目经理一定要体现自己的专业性，要跟客户定好一些规矩，到后面才会做得规范。人和人的沟通从建立信任开始。
项目管理本质上最终还是搞定所有的人，包括客户以及项目团队，各个相关方。相关方登记册中关于相关方的期望最好记在心里，一般不写相关方登记册，而是写一份通讯录。第一次会议中，作为项目经理可能还需要关注团队吃饭在哪里吃，是否有员工食堂，包括附近的医院、银行在哪里。此外第一次去到甲方场地还要做好一些开工报审的手续，前期开工报审的完整材料可以找监理方要。
二、项目范围管理：
如果项目的系统很大，比如涉及到13个子系统，收集需求的过程中都可能会出现需求的变更。比如说招投标中规定的东西到签订合同过程中会有一段时间，期间可能会有一些内容需求上的出入，比如采购的设备型号等。这时候可以采用深化设计（类似渐进明细）的方法，首先定义好各个子系统的大致框架和总体功能（高层级的）保证不会变化，至于如何实现、具体怎么做那么就再一个系统一个系统的去深入，一些需求的细节先不去确认，有助于减少大的需求（高层级的需求）的变更。所以针对大型项目收集需求的时候可以先把大的整体的需求定下来。这里也是有必要尽早形成基准，要不然细的需求变来变去会有大量变更以至于很难形成基准。
关于收集需求（需求调研）工具的使用，一些合同中明确规定范围的就不需要使用头脑风暴了。在收集需求之前需要先看招投标文件和合同以明确需求大致要做什么东西，然后以它为基础先整理一遍，写出一个需求调研大纲，大纲里面需要明确调研内容、调研方法、调研对象。在找客户调研需求之前需要跟客户提前预约时间，提前先把需求调研大纲给他看，让他去协调协调需要哪些部门哪些人员参与，让甲方对接人确定一个时间。
如果出现客户那边有两个或多个部门，部门之间的需求有矛盾，这时候项目经理最好不要深入到甲方各个部门，而是让甲方的对接人或项目经理去把这些东西汇总一下，乙方的项目经理就找甲方的项目经理对接，至于甲方内部有什么矛盾有什么冲突让甲方项目经理去协调，这样做可以避免陷入甲方的利益纠葛，可以避免莫名其妙的得罪人。
收集需求的时候首先需要倾听对方在说什么，需要知道对方说的是不是真实的需求，需要深挖。收集需求什么东西最重要，how（怎么做）并不重要，最重要的是why（为什么要做）。因为有时候客户会没有说清楚或者没有准确表达他的意思。
做需求分析的时候一定要搞清楚客户说的需求在不在合同范围内，要分清楚强需求（必须要有，不能少）和弱需求（虽然合同中有，但是意义不大），高频需求（这个功能是客户要经常使用的）和低频需求（有些功能可能也就用个一两次就不用了，如软件行业的数据迁移功能，这就不需要花太多时间去做）。关于需求我们要重点关注重要的、不紧急的需求。
敏捷里面有一种需求收集方法叫MOSCOW法。Must(必须要做的) or Should(应该要做的)，Could(可以做的)，Won't(不要做的)，可以通过这个方法给需求去排序，哪些需求是必须做的，哪些需求是应该做的，哪些需求是可以做的（可以考虑考虑，影响不大），哪些需求是坚决不做的（因为代价太大了，超出范围太多了）。以上就是做的需求排序，排序排好之后需要做一个需求确认（对最终的需求文档或叫需求评审最终的一个确认），因为只有确认过的需求文档，当客户要求修改时，才叫走变更流程。
PMBOK中的定义范围在实际项目中一般都叫确认需求（需求分析）。需求确认（形成基准）后可以变更，但是要走变更流程。在项目的早期就要让客户养成签字的习惯。如果遇到客户不愿意在需求文件上签字可以有以下方法：
1、审查自己的需求文件写的是否合理？不能照搬照抄合同或招标文件上的条款。
2、一般客户不愿意签字大部分原因是不敢担这个责任（他会说万一我签字了，需求需要修改而你们乙方却不肯改，那我该怎么办），所以他会一直拖着不签。面对这种问题，我们首先应该学会换位思考，项目经理可以这么说：***老师，需求确认其实是一个依据，我们后续的许多工作都是以这个为依据的，我们公司的话也需要这样一个东西报上去审批，接下来公司才会安排资源来给我做这些东西。至于你担心的问题我也可以理解，我可以让你在确认的时候写上这么一句话“如果后续有需求发生变更，我们会走合理的变更流程进行评估，至于是否会产生额外的时间和费用，双方或者几方可以协商解决”。
3、如果客户还是不愿意签字，那么还有一种办法就是找他的领导，可以这么说：***领导，目前我们的需求都已经定的差不多了，但是可能最终有些东西呢还希望领导过来把个关，领导您有没有时间，我们一起来讨论一下有什么问题。这里找领导需要找分管领导，管这个项目的。领导来了之后，我们还是需要把需求文档在从头到尾过一遍，有问题解决问题，没有问题的话，再要求客户把需求文件签一下字。这时候领导在场，一般都会签字。
4、如果领导不愿意过来开会，说这个事情你们自己协商。那么这时候可以选择破财消灾，项目经理可以找几个专家过来正式的搞一个需求评审会。评审的结论是基本上没啥问题，可以找3个或5个专家（这里涉及到专家费），会议后专家出具专家意见并签字。这样可以显得项目流程非常正规，没啥猫腻，而且甲方也会放心一点，感觉专家都说没问题了应该就不会有啥问题了，甲方客户的责任可以适当分担一些。如果甲方担心专家有问题，那么可以让他自己请1个专家，由乙方出钱。这里找专家的主要目的就是尽早的让甲方确认需求文件并签字。
需求变更里面假如需求真的有问题，那是确实需要变更的（比如需求不合理、设计方案也不对等）。最常见的需求变更是客户要求加需求，如果不加，那么客户心里就会不满意。遇到这种情况，常见的办法有以下几个：
1、不建议客户加这个需求，因为项目是有进度约束的、也有成本约束的，你让我加功能，但是之前确认的需求文件中是没有这项功能的，如果说加的话那是不是会对成本进度计划都有影响的。那么最好就是建议客户在二期的时候去考虑这个新需求，为什么要在二期的时候考虑，因为明年甲方您这边是不是要去申报一些项目的预算，如果说没有新的东西做，那要怎么去向主管单位要钱呢，所以你这些新需求可以作为二期，我配合你们去出一些方案，找经信委、找发改委去申报一些新的项目，争取一些新的费用。那么这样你们不仅有钱了，而且项目也起来了。
2、客户如果说这个需求非常着急，不想等到二期，现在一定要做。那么我们可以跟他谈一谈是否可以这样做，根据之前的MOSCOW需求排序，我们去掉一些不重要的功能需求。走一个功能变更流程，原来是什么功能的变更成新的功能。这样做的好处在于，我的进度可以在可控的范围内，成本呢也可以挂得住，这样对大家都好。做功能交换。
3、如果客户还是说这个办法不行。那么我们可以先看看客户要加的东西具体怎么样，看看我在这一期可不可以先做一个大概的东西，把这个需求适当弱化一下，把一些基本的做一做，至于更详细的可以放到后面再说。因为公司也要考核我的绩效，本身呢要做额外的东西按照正常的项目管理规范来说就不正确，那么我现在帮你做了，工作量适当少一点，让我在可控的范围内行不行。
4、如果以上方法还是不行。这里呢也尽量不要跟甲方关系搞崩。可以让监理方（或第三方）介入，比如开会时可以问问监理方：在我们正规的项目管理中，遇到这种情况我们应该怎么做。监理方一般也会有一套规范的做法，四控三管一协调（其中一个控制就是变更控制），这时候他一般会说我们正规的变更管理新加一个功能应该如何如何管。如果监理方直接说客户让你做你就做吧，这时候我们也不要去说甲方，而是要去说监理，这里就可以把变更管理那一套说出来了，可以说我们需要先评估一下新增加的功能对我们之前定下来的需求基准有哪些影响，然后接下来该怎么样怎么样。
5、如果以上办法都还是不行。那么就要检查自身原因了，我们做事情需要低头做事，同时也要抬头看路。如果方向不对，那么再怎么努力都无济于事。我们要看看根本原因是甲方真的想增加新功能还是说他要搞我。我们可以跟售前或销售沟通一下，现在甲方是啥情况，看看当初我们对甲方的一些承诺做了没有，比如商务费用，该给的给了没有。如果没有这方面问题，那么销售还是需要火力支持，从商务手段上想想有没有什么办法。
6、实在没办法，也可以找相关专家过来正式的搞一个变更评审会。
7、最后一个办法就是找自己的领导出面协调。这里需要跟领导提前打好招呼，要说明现在的情况是我们所有需求都已经确认过了，而且是书面签字过了，哪怕最终走到法律程序，我们也是比较主动的。这时候一定避免领导过去甲方那里谈的时候就是一口答应了，这时候一定打好招呼叫领导不要一口答应，前面我已经顶了那么久了，告诉领导一口答应的后果就是以后甲方有问题就不找我项目经理了，而是直接找你领导了，这时候项目经理在项目现场就没有任何地位，就只是一个传话筒，而领导则变成了项目经理。这时候领导可以说我们这个项目确实还是挺复杂，而且进度和成本很吃紧，那么我们项目经理的这个做法也是对的，而且我们公司最近对项目的审计（比如内部审计QA）也是非常严格，确实压力很大，从长远的角度来说，你们也是我们的目标客户，我们也希望有二期三期的合作，所以从战略的角度来说，我们可以做一些微调，双方配合配合，至少可以做到一些功能上的弱化，也不是不做，可以适当做一点点，我们呢可以取一个折中的方案。当然不到不得已时候，不要把事情推到领导。
我们项目经理做需求的时候一定要做到不卑不亢。
三、项目进度管理：
估算活动持续时间的时候应该由项目团队中最熟悉具体活动的个人或小组来估算。一般来说开发人员在估算活动持续时间的时候会比实际估算的时间多出几天来提交给项目经理。这时候项目经理在估算活动持续时间的时候遇到困难可以采用“敏捷扑克”的方法，他是基于德尔菲的方法。比如要估算一个活动，那么可以叫三个技术人员坐下来，每人发一个扑克或白纸，让每个人互相不要交流各自写下估算的时间，这时候一个写3天，一个写5天，一个写8天，写完之后，大家公布结果，然后请3天的人说一说为什么只要3天，问问他是不是有更好的方法或者更好工具或者更好的框架等等，总之要问一问为何只要3天；说完之后再请8天的人说一说，为何需要8天时间，你是不是考虑到了什么问题或者什么风险所以你要8天时间。大家都说一说，然后项目经理该澄清的澄清，该解释的解释，接下来再来一轮，让大家基于刚刚补充的情况，大家再估一估需要多长时间，经过两轮或三轮之后，大家估算的时间应该是基本接近了。确定之后，项目经理再拿这个去排进度计划了。这样做的好处在于：1、这个时间不是项目经理一个人拍脑袋想出来的，而是大家一起估出来的，对项目经理比较有好处；2、这个时间相对来说会比较准确。
关键链法。本来两个项目活动估算出来是需要14天时间，但是项目经理分配给开发人员的时候是说只给你7天时间，然后另外多出的7天时间项目经理自己捏在手上作为缓冲时间，所以项目经理做的计划实际上是阴阳两份计划，这时候如果发现团队成员第一个活动的时间不够做不完，那么项目经理就会跟他说：兄弟，我跟甲方爸爸谈了好久，好不容易他们总算答应再给我们2天时间，你呢，尽量把它做做掉。然后这个团队成员就会觉得这个项目经理好牛逼，帮我们争取了好多时间，挺好的，然后实际上项目经理手上是捏了7天时间的。所以这种方法实际上也叫作帕金森或学生综合征，所以这种方法还是容易出问题的。比如说做软件行业，按照常理我们在开发中是需要考虑到灵活性和可扩展性的，但是如果采用关键链法，那么由于项目经理死咬着进度工期，那么开发人员就只能是把有些东西写死在里面，固化在里面，一旦这么做等到后期项目想要优化或扩展的话就无法实施了，除非就是推掉这个模块重新再来。所以这个方法还是要谨慎使用，虽然表面上看项目经理手上捏了很多时间，但是到后面项目的扩展性会出现很多问题，因为他会一味的去赶进度而不顾质量。所以关键链法是一把双刃剑。
假设日志。制定进度计划中有一个输入叫假设日志，实际做项目的时候，这个东西非常重要。比如做项目时，一开始做进度报审的时候（即汇报总体进度时），项目刚起来的时候肯定要跟监理方到客户那边去，首先要做开工报审、施工组织方案报审以及总体进度报审，这里做总体进度报审的时候不管哪一份计划一定要特别注意假设日志，当时进度计划是这样写的：首先会有一张甘特图把计划排出来，然后里面肯定会有一些重要的里程碑，排好这些之后，里面肯定还会有一些前置条件（或叫假设条件、前提条件，这份文件作为附件和进度计划一起提交），前置条件一定要写明某个里程碑对应的前置条件是什么，比如说进度中要求3月份设备调试完成，那么前置条件就是要求3月5号一定要开通电信宽带并开放80端口，然后第二个里程碑必须在什么时候完成，那么前置条件就是甲方必须在什么时候提供好必要的东西。
项目中，项目经理遇到很多事情，要善于使用阳谋，学过PMP®之后就不要用阴谋。就是说我们说的东西一定要能够放得上台面，千万不要说那些放不上台面的话。做项目的时候要尽可能的学会换位思考。还有一点就是跟别人说的时候，不要直接说做不到，而是要带着解决方案去跟别人说，第一种方案是什么，第二种方案是什么，比较建议用哪一种方案，领导你看行不行。如果直接说做不到，那么就是客户会直接找到领导向你施加压力，或者就是不利于你的客户关系。所以PMBOK®指南上说的问题解决思路是：1、定义问题；2、了解问题的根本原因是什么；3、提供几种解决方案供其选择；4、确定一个方案；5、实施这个方案；6、去验证这个方案的有效性，如果无效则赶紧用别的方法解决。
遇到有些小项目，有和没有、好和不好是两码事，有些东西你要先让它有，如果有什么问题，后续再考虑优化、迭代。最后一点就是做项目加班时家常便饭，但是项目经理一定要照顾团队的关系，由于高强度的加班，所以项目经理一定要用人际关系技能或叫软技能来激励团队。
四、项目团队管理：
项目经理该具备的基本素质，第一点就是尊重团队里面的每一个人，关注每一个人的需求。这一点相对来说外企会做的比较好，外企会首先承认你是人，其次你才是我的员工，而很多我们国内的企业的这一点没做好，他会说首先你是我的员工，然后他才会考虑你还是一个人。
第二点就是要公平公正，不能有功劳呢都是自己的，出了问题的话都是团队的，因为项目经理是带领团队的人，而不是剥削团队的人。
第三点就是要保护每一位团队成员。尤其是项目中涉及到那种工程项目的，比如做集成项目的，会涉及到综合布线、登高作业、包括做机房的精密空调，肯定会涉及到用火用电之类的，特别是土建刚刚起来的时候用临水临电，以上这些工作的时候肯定要做好团队成员的保护工作。如果项目上因为一些安全隐患而挂掉一个人，那么问题就严重了。我们做政府项目的时候如果出一次安全事故，那是要发停工令的，包括甲方爸爸那边也会吃不消，这是要问责的。出现这些问题后果会非常的严重，项目上早一天晚一天这都还是小问题。安全问题此外还包括团队成员上下班的安全问题以及生病作息劳累等问题这些都要注意。政府项目中，如果项目上出现这些安全问题，那么分管领导的职业生涯可能就是到此为止了，他再往上爬就爬不上去了，他的政治前途就被断送了。那么我们公司将会面临什么样的后果就不得而知了。
第四点项目经理要注意领导大家和支持大家。你能做的要带着大家往前做，不能做的也要做好支持。
另外项目经理还要大气一点，这点表现在很多方面。比如让团队成员带饮料，带十次没有一次给人家钱的，即使对方嘴上不说，但心里是不舒服的。项目经理还需要经常请人家吃吃饭。比如说有一个项目经理，领导要给他加工资，他却说把这点加的工资加到他助理身上，要知道任何事情都是会传到别人的耳朵里的。千万不要去坑自己人，做到真诚，知彼解己，不卑不亢。
勇于承担、乐于分享。出现问题，先想一想是不是自己的问题，不要一开始就找别人的原因。要为团队成员考虑他们的人身安全，维护他们的尊严，保护团队劳动成果，为他们争取利益。这里如果不为他们争取利益，团队成员会觉得反正我做好最差都是一样的，这样不利于团队的良性发展。
要注意照顾团队成员的情绪，特别是在会议上，有的人做的很不好，在会上当着甲方的面骂自己的团队成员，这样做很不好。所以不要再公共场合去批评自己的人，有什么问题就稍微说一下就好，回头私下再该怎么做就怎么做。
项目经理的领导是指我冲在前面，弟兄们跟着我一起冲，带领大家实现目标。而单纯的管理是指项目经理坐在上面什么也不干，而只会指派别人干嘛干嘛，拿个鞭子在后面抽，所以这种项目经理就是一个单纯的管理。所以领导和管理团队这两种项目经理即使带领同一个团队，那结果也会有天地之差。特别是外地项目，第一件事情就是吃饭，团队里面定规矩，加班的时候只要一个团队成员加班，那么项目经理就必须在现场，一定是陪着加班的。项目经理如果有事情做那就做事情，如果没有事情做那就做好服务工作。比如说买点夜宵、烧烤饮料啥的，或者不想吃东西的话可以给团队成员做做同性按摩啥的增进感情。如果没事的比如也可以学学Project怎么用，做原型的Axure怎么用。如果就是几个人加班，其他人都回去睡觉了，那就会感觉不舒服，会想凭啥就我加班啊。所以项目经理就是要么做好领导带着大家冲，要么做好仆人式的领导（服务）。
另外一点就是要无保留，勤分享，比如晚上不加班的话，可以好好找个地方吃点东西，点一盘花生一盘毛豆，大家工作中遇到什么问题可以提出来，以前遇到类似问题我是怎么解决的也可以分享分享。我们说进一家公司是1万元，有一天走的时候，我们能达到三万元，那么说明我们就赚了，如果说走的时候，我靠不知道该干嘛了，那么就说明我们这公司的三年虚度掉了。
先做事，后谈钱。去向公司要求加工资的时候，一定要先想好我这一年下来给公司带来了什么，比如说我参与了什么什么项目，在项目里面我做了多少事情，我做的这些事情起到了什么作用。所以说谈钱的时候先把事情做好，做了多少事情再去谈这个要求。
一般来说，实际项目中团队成员分为以下四种：1、带头干。这种我们称之为最佳队友，这是很牛逼的一种人，可遇不可求，我们要珍惜他；2、跟着干。这种人有什么事情他没有带头干，但是看到有人干了他会跟着干，渴望提高、团队意识强，这种就还不错，要好好培养；3、老实干。朝九晚五，老老实实干的，上班打卡、下班打卡，属于一般成员，有待提高，普通人，要好好跟他说一说，我们是追梦人，我们都在努力奔跑；4、对着干。不但不好好干，还跟你对着干，一天到晚散布负面消息，什么公司股票又跌了，最近好像谁又离职了，然后到别的公司工资就一下翻倍到多少多少，还说你不要干了，干得这么苦，领导知道吗，会给你加一毛钱吗。遇到这种人建议直接把他干掉。一个团队中10个人里面有2个人对着干，那么其实团队就危险了。
团队和团伙。团队是愿景驱动的，大家是有使命感、有责任心的，团队是互补共赢的，你伸出五个手指，肯定有长有短，每个手指头的作用是不一样的，抠鼻孔用小拇指，指别人用实指，表扬用大拇指。大家应该是分工明确，互补的，相互配合的，有什么问题大家一起想办法解决，一起去推进这个项目，敏捷里面叫做自组织团队，有一句话叫做“败则拼死相救，胜则举杯同庆”，团队就应该是这样的。而团伙是利益驱动的，个人得失，不珍惜团队成果，斗争和推诿，别有用心，比如说我不爽就把服务器的数据全部删掉，像这种就是注定走不远，也没有什么出息。团队里面尽量还是保持一个积极乐观的态度，有一句话叫做“但行好事，莫问前程”，认认真真把事情做好，总会有一个好结果的。
项目经理要注意一点就是平台的实力和你个人的实力是不一样的。所以说有时候要冷静下来好好思考，以后的路该怎么走。团队建设是锦上添花的事情，而不是雪中送炭的事情。
五、项目其它管理（成本、质量、会议、验收等）：
实战里面讲不了成本管理，因为项目经理往往不知道我这个项目中采购的费用是多少，有多少费用是给甲方的费用，招待费用、商务费用等。一般来说项目经理管的是实施费用，包括房租费、吃饭的费用、团队建设的费用、交通费、电话费。所以公司里面最好订一个标准（额度），比如500万的项目要多少实施费用。一般来说用多少就拿着发票去报销就可以了，只要报销不超过这个额度就可以。
实战里面关于质量。作为IT行业的话，关于质量其实没那么重视，质量在制造业中比较重视。一般有什么变更，都需要先跟客户和监理方私下沟通，私下基本达成一致了，会议上再走个流程，沟通的时候一定要注意换位思考，要学会摆事实讲道理，要有合理的理由来支持自己的观点，讲大家的道理。如果说供应商的一批货到了，比如说服务器到了，叫团队成员搭把手，帮忙绑到机房去，这时候最好不要帮忙，因为这里面涉及到到货验收的责任问题，万一团队成员手一滑掉了，损坏了，这时候就不知道算谁的责任了。
关于项目周报。项目状态提示：当前状态、总人力投入、本周人力投入；项目关键里程碑：近期里程碑列表、里程碑达成情况、任务名称；本周计划完成情况：任务名称、起止时间、完成情况、计划调整说明；详细工作描述：详细描述本周完成的工作；下周工作计划：任务名称、起止时间、责任人、完成目标；存在的问题和风险：描述、等级、发生时间、建议解决方案。做项目的时候有可能是写两份周报，一份是发给业主方和监理方的，一份是发给自己领导的。发邮件时最好把重要的东西写到正文里面。正文里面最好把大致的进展说一下，然后把风险和问题也说一下，然后再是详见附件。
项目状态报告（阶段报告）。PMP®中也叫工作绩效报告，当前阶段工作完成情况：概述、进展报告；偏差及偏差原因：是否存在偏差，出现偏差的根本原因是什么；纠正措施：正在用什么方法纠正偏差，预计达到什么效果；拟定的变更：是否需要相关的变更，将如何处理变更；存在的风险及应对：存在什么风险、应对计划是什么、预计达到什么效果；下一阶段工作说明：下一阶段将主要完成哪些工作。
内部审计（QA）。不定期的审计，公司审计部门会拿着核对单一项一项的审计。
变更单。要变更首先进行私下协商，然后在提交工期变更单，需要自己敲章，监理方敲章，工程监理敲章，投资监理敲章，甲方也同意了，但是变更单配套的附件是很多的，附件一：变更的情况说明，附件二：要做哪些变更，附件三：涉及到的工作量和报价是多少，附件四：涉及到的型号的变化，包括原型号和新型号都要写下来。以及其他一些资料都要完整。所以说实际上走变更的时候会非常的复杂，变更也是非常严格的。如果说后期项目有几百个变更，几千个变更，那说明项目在前期规划的时候是有问题的。
最后关于项目的验收。验收准备包括对照合同验收标、与业主私下沟通验收事宜、提交验收申请、整理文档，打印装订。验收会议流程，首先是监理汇报项目实施情况，接着业主方总结项目实施情况，然后是项目经理做验收汇报（也要准备PPT），接着是专家提问（一般就是一些小问题），专家组长总结，专家闭门磋商形成专家意见，最后业主单位拿着专家意见在竣工报告上签字确认，形成验收报告和备忘录。
