背景：因为计算机的普及、软件的广泛使用，公众对于软件项目是个啥东西都有一个概念上的认识。非常多人对于公司哪些地方将要应用一套软件系统，已经可以提出一定的想法。然而，在从想法到软件落地应用的过程中，软件项目要经历若干艰苦的变化，才干逐步将之前的理想转变为现实。作为工作多年的人，有必要在这个信息共享时代和大家分享一些这方面的感悟和经验。
项目期初，一般而言，总会有那么一个或者几个人，对公司某方面的业务或者市场潜在产品需求产生想法，觉得能够通过软件来构建业务信息系统或者是新一代产品，这样将给公司带来可观的收益。这一期间，称之为项目理想主义期。考虑这个软件的人，看到的往往都是软件利好的一面，大脑皮层环绕软件项目给公司及市场带来可观的利益。项目理想主义期推动了公司高层指派一位重要人士全权负责论证项目的背景、可行性、范围、风险、成本、时间、商业价值等等一系列项目特征性质的问题。而这位重要人士，在项目兴许发展过程中，我们一般将会认识到他非常可能就是项目经理。
至此为止，项目的萌芽已经在少数人其中孕育。项目经理着手收集高层次的项目想法、目标。在国内，政策性影响往往比其它的项目影响因素所占的比重要比国外的市场化标准占比要大得多。比方说，领导想上一套旅客跟踪服务系统，项目经理在收集论证可行性方面就显得毫无意义，无论客观方面可不可行，终于的结论总是可行，而且非常easy实现。再比方，领导指示必须自主研发，而项目经理的论证结论肯定是可行。诚然的说，有了高层次的想法和目标，下属们才有工作的方向和动力，仅仅只是，在项目建设这个客观事实的基础上，没充分客观考虑到方方面面的可行性，项目建设后期将花大量的精力来弥补前期工作欠缺考虑所带来的大量问题。
你作为一个合格的项目经理，要了解到项目開始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况。
1. 准确了解项目目标。这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。在国内非常多客户都非常不成熟的情况下，千万不要依据项目的名称望文生义地去想象项目的目标。一个名为“办公自己主动化”的项目非常有可能在进场以后一个月才发现客户事实上须要的是一个计算机生产管理辅助信息系统系统。前期了解情况的工作越具体，后面的吃惊就越少，项目的风险就越小。2010年，接客户建设须要，将要建立一套停车场抬杠系统，而在深入了解客户需求时，发现是要建立一套停车场旅客引导服务系统，内容将要包含停车场抬杠系统、航显子系统、广播子系统、短信服务平台，这样直接导致项目建设成本大大添加�，项目周期拉长。
2. 收集项目干系人。这个项目里牵涉哪些方面的人，如投资方、详细业务干系方、项目建成后的运营方、技术监督方等等，非常多项目里除了业主单位的结构非常复杂以外，另一些其它单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。项目经理须要了解每一个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，能够让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。没有永远的朋友，也没有永远的敌人，仅仅有一致的利益，这句话作为项目经理是一定要记住的。2010年，遇到过一个项目，本来项目所要建设的系统是客户的核心业务系统，前期已经规划出来要做好部门经理、公司经理级别的需求调研计划，而结果是从来就没办法去接触过对方的数个部门经理，更别说公司领导层面了。这种后果之中的一个将导致了兴许项目出现的业务分歧不知道找谁来核定。
3. 了解各方支持的程度。基本了解了客户的情况后，以下的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视，这个决定了你在须要资源的时候，公司是否会依据你的要求提供最有力的支持。领导口头肯定是说支持的，你须要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱？是想做样板project还是干脆想敷衍了事，公司领导对项目的态度决定了项目经理做这个项目的战略，而这个战略方针将对PM做项目计划产生直接的影响。作为PM，头疼的事情之中的一个是领导口头支持，但公司各级人员不太配合：人员调动不了、公司资源缺乏而採购部门又迟延项目採购、公司在此项目的投入大大低于项目经理的预期。
4. 掂量自己的实力。有了各方积极的配合，至少项目在建设过程中将少一份外部空虚的压力。而在做总体项目计划前，还要大致计算一下你手上的资源。首先是时间，如今市场竞争激烈，往往非常多项目要求在差点儿不可能的时间范围里完毕。对于这一点，你在做项目的风险控制计划的时候要充分考虑。其次是人员，依据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每一个角色眼下公司是否有人，能否全然归这个项目使用，是否须要另外招聘一些人员，招聘的准备工作要尽早启动。最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以后无论发生设备等人还是人等设备的情况，浪费的都是你的时间。2010年所做的一个项目，因为有部分模块採购外部资源，在主要模块建设完毕后，我们启动了子模块的採购工作，严重拖后了项目的进度。而且项目子模块的接口设计工作理应该在项目总体设计期间就定义好，以促成项目的并行工作，节约项目研发的时间。
5. 重视项目说明书。如今是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描写叙述得非常清楚（主要是讲做什么，而不是说怎么做），并且把怎样检查也说明得非常透彻。也就是说它不仅说明确了要做哪些事情，也让客户的业务人员（一般不懂技术）知道项目做成什么样就算完毕了。简单地说，项目说明书描写叙述项目做哪些事情和每件事情做到什么程度以及怎样检查每个结果。非常多人认为，项目方案就是项目说明书。我仅仅能这样说，项目方案前面章节描写叙述的是项目说明书的内容，但项目方案还包含了项目将怎么做。而这里的项目说明书，将是甲乙两方理解项目各项内容指标的基础。在此之后的项目阶段交付物和项目验收，视此为重要參考。并且，项目说明书将是甲乙两方在项目公允价值上的共识根据。另外，非常多客户在提出项目需求时候，都想建立企业的项目数据规范，作为项目经理，应该了解到，数据规范和项目建设是两种类型的事情，在项目说明书中，我们不能将数据规范的大量工作加入�到项目范围中，这样会添加�项目建设难度。
6. 分析项目机会和风险。是到做整体计划的时间了吗？不，你如今已经知道了客户的目标和你手上的资源，那么做计划曾经，你还须要和你的经理和客户充分沟通资源的问题。由于非常多资源是还不明白的，你须要写一份报告，具体分析这个项目的风险以及对资源的需求情况。假设一些问题不能得到解决的话，将发生什么样的后果。假设资源不够，就要高层改变策略，添加�对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完毕一个不可能完毕的任务，假设项目经理不能尽早发现风险，那么就仅仅能去当烈士了。
7. 挑选符合项目须要的团队成员。明确了要做哪些事情和你手上的筹码以及你做这个项目的整体策略，如今是成立项目小组的时候了。非常多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成依据项目不同，相差较大，非常难有什么详细要求，可是，一定要有精通客户业务的人，非常多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，两方才干够相互理解。在企业里面，有一部分技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。事实上，明确自己想做什么的客户已经是非常好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在。可是要明确一点，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧，客户的指责和议论是应该的。作为项目经理，要积极主动和气的挑选符合项目须要的团队成员。
8. 重视项目沟通管理。如今你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。既然沟通这么重要，那些事先定义一下沟通的原则也是一件非常要紧的事情。非常多沟通原则都是潜规则，假设你在一个部门时间做长了，对这些规则的运用认为是一件理所应当的事情，可是，你如今面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。以下的东西看起来无聊，事实上还是非常管用的：第一个是规定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动公布信息，无论通过电话、邮件还是书面方式，保证将信息传达到每一个人。这样的情况适合小项目，人少；拉的意思就是项目经理就是一个类似webserver，你自己须要什么信息就去问他。当然，没有项目经理把自己搞得那么累，他会用公布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。说这些看似非常无聊，事实上里面牵涉信息传达不全然的责任问题。当然，这些都是指一般的方式，并且不要绝对化，普通情况下，主动沟通和被动訪问是同一时候存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。第二个问题就是文档问题，非常多人怕写文档，可是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢？就是由于没有证据。所以项目经理開始就要和客户说清楚有些文档是必须签字的，比方项目经理的项目日志，每一个星期至少让客户签字，另外全部达成共识的东西，比方会议纪要，甚至领导的讲话记录，都要写成文档，两方签字，这样以后扯皮的时候，就能做到有据可查。记住：说了的就和没说一样，仅仅有写下来大家签字后才算真正发生了的。另一些问题，比方你提交的报告，给领导（包含本方领导和客户领导）做一个选择题，结果领导压住不批，让你无所适从，结果迟延了进度。这时候，你能够等，可是注意要留记录，标明是谁的责任；另外，假设你在開始阶段就和领导商定：假设批示提交三天后没有得到领导答复就算对方允许，这样你就会主动非常多。再比方不同事件的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要两方项目经理专门签署备忘录、什么等级的事情要两方领导出面签署合同附件等等。事先想得越周到，以后的工作就越主动。
项目允许而且你已经在为项目的建设做非常多准备的工作了，接下来就是项目的详细性质的工作。这样的详细性质的工作，包含为项目系统的开发所做的计划、项目需求获取、设计论证、技术方案应用论证、项目开发、项目測试、项目实施、项目收尾类型的工作。
1. 编写项目计划。做了非常多前期工作，定义了一些游戏规则，如今是坐下来做计划的时候了。首先是找几个关键组员，比方客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做，每一块完毕什么，模块之间的信息怎样交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这里要强调一点：完毕一个目标有非常多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目降低非常多风险。有时候客户会被某种新技术打动，坚持要你採用那种新技术，你就应该告诉他：你选我做这个项目，就应该容许我採用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是由于吃亏的人还不多，我不希望你成为第一批受害者。採用一个计划会让你的工作更加明白，比方用微软的Project软件，你填写完表格以后，就能够知道这个项目有多少件事情要做，每件事情须要什么资源，他们之间的前后关系怎样，消耗的时间有多长，完毕后有什么标志等。全部的结果最后用一个叫做甘特图的形式表现出来。你做完这个表以后会惊奇地发现，甘特图上项目的结束时间会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的）。当然，学过项目管理的人会大谈什么WBS、优化路径之类的东西，可是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。假设你没碰到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否罗列了全部要做的事情和正确评估了他们所须要的时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。依照什么标准牺牲？经验是假设你什么都赶进度，其结果可能就是十件事情你一件也没做好，想想多么失败啊。所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件做成了精品，三件完毕，还有四件由于某些原因延误，成绩单是否靓丽了非常多呢？战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。项目计划作为PM向公司领导层、客户领导层以及项目内部管理都非常重要，使得大家在每个时间节点上有统一的关注度。此外，做好项目计划后，项目经理非常有必要依据计划给项目团队成员做一次项目培训，这些培训内容包含：项目目标的重申、项目各成员任务的分配、项目沟通接口的说明、项目文档模板的统一、项目各工作标准的理解、项目进度及里程碑交付物的说明。这种培训，为的就是环绕项目统一思想、统一认识。
2. 实施项目计划-管理项目需求。前期PM花了大量的精力，考量了项目方方面面的工作，也为项目实质性进展做了大量的准备，接下来就是组织项目资源运行计划、定期汇报项目、解决项目面临的实际问题。在项目需求阶段，项目经理须要业务专家、需求分析师的支持，高速获得系统需求。项目经理最忌讳的一点是客户高层用一句话概括了项目的建设内容，并因此认定为这就是项目全部需求。我在2011年參与过审计部门提出的一个内部评审控制系统的意向建设工作。当时客户提出了内部评审控制系统需求是：依据审计对象制定评审指标，对比评审指标统计分项得分，终于给出审计对象的整体得分。当我再去细化调研需求时，客户说不出来还有什么样的需求，并提供给我一大堆有关评审指标的文件，要求我深入了解系统需求。面对这种需求，我直接给出了系统无法建设的结论。此外，客户在项目建设过程中，非常有可能常常变更需求。对于这种需求天天变的客户，PM就一定要事先做好规矩：一、统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，假设他们意见不一致，那你仅仅有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组仅仅认一个的意见，有什么要求你们内部先统一再和我谈，我不想卷入你们内部业务部门之间的矛盾之中；二、全部需求变更全部要有书面文字，这点切记！这样做优点多多：*有书面证据，以后他还想改，你有了他曾经要求的证据，告诉他：你曾经但是这么说的；*便于需求变更管理，需求怎样慢慢演变的历史能够看清楚，从而更深切地体会客户的目的；*对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是假设要他写书面要求，还要签字盖章，他就要慎重多了，并且一写东西，思想就会更加深入，非常多无理要求也就这样胎死腹中了。对于有着大量需求的系统，PM要注意设立全职的需求管理人员，便于收集整理客户需求，并针对客户的大量变更予以合理的接受和拒绝。
3. 实施项目计划-做足设计论证工作。项目设计是认可项目需求的第一步，还是项目从需求变成项目实现的桥梁。项目经理在这一过程中要重视系统的功能设计、数据库设计、接口设计工作。依据项目大小，有必要分步做好概要设计和具体设计工作。而这些工作的组织实施，全然在于项目经理对于项目总体的把控。设计的论证工作不可缺少。我之前遇到过一个样例，项目经理全然信任自己的团队成员，指派了项目各模块的设计人员，并要求设计人员与需求分析师及项目开发project师沟通好就可以。项目阶段省略了设计方案论证工作，导致兴许的开发阶段，开发project师全然不认可设计人员的设计方案，开发project师的不能进入开发阶段，有的开发project师为了赶项目进度，直接操练起模块的设计工作来，又导致兴许开发的系统全然不符合项目需求，客户无法验收项目。因此，项目设计方案论证工作，是必须完毕的一步。
4. 实施项目计划-有必要做好技术方案应用论证工作。有的项目，要求应用先进技术解决棘手问题。项目经理必须组织专家论证会议、技术应用指导大会，强调系统的重要部分将怎样借助先进技术，解决一些重要问题。这一阶段的工作，视项目情况而定，可深可浅。
5. 实施项目计划-管理项目开发。项目开发工作，并不只指项目编码工作。在开发前期，项目经理必须组织准备良好的项目研发工作环境、配备选用合适的项目研发工具，在开发周例会上，收集项目进度信息，协调解决项目问题。有必要强调一点的是，项目经理要重视项目版本号管理，制定各文档、源码的版本号管理制度，向项目组成员强调版本号管理的重要性。在2012年的一个项目中，我经历一个项目的研发，当时的项目开发者就两个人，项目经理及其高层领导觉得这种团队更加利于管理和开发，而开发project师们各自负责独立的模块开发，所有成员都没有考虑各文件版本号管理工作。当项目需求变更时，开发project师负责跟进修订项目模块，加上项目实现方案上，发生了开发project师们推翻过去方案的事件，导致项目实际情况严重偏离了项目计划。项目经理在查找究竟在哪一时间点发生故障时感到非常迷茫，文件不知道何时被改动的，更不知道为何被改动了。项目只得推倒所有重来。怎样管理项目开发，是项目经理在开发阶段要重点协调的工作。一般而言，我们有非常多版本号管理软件使用，比方SVN、VSS。在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每一个任务的终于可交付成果一定要是能够被检查的，比方，【界面要求：美观慷慨、简洁明快】，这个要求我就不知道怎样检查。所以，给开发小组布置任务的时候就要考虑怎样检查结果，比方我见过一个计划，里面有一个任务【开发者熟悉EJB编程】，这个任务，除了让这些人去參加一些专业认证考试，否则，结果非常难被检查。所以，时刻考虑怎样检查结果、怎样向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看怎样验收和验收标准，然后决定工作计划。非常多项目開始了非常久，还不知道怎样验收，那么这个项目出问题的可能性就非常大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。
6. 实施项目计划-管理项目測试。非常多人不重视项目測试工作，觉得项目流程走得通，项目能处理客户业务、满足需求就能够了。这是极其可怕的事情。项目測试工作，是要发现项目中隐藏的各类缺陷，减少因项目质量问题而给客户带来灾难性后果的风险。測试的结果不是项目通不通过验收，而是项目健不健壮。对于非常多软件来说，实现客户基本需求是软件必须具备的功能，处理一些突发情况则是软件应该具备的能力，如断电前的数据备份，软件崩溃后自己主动重新启动，软件边界的无差错处理能力，高密度数据处理能力，不正常流程操作的系统容错能力等等。作为项目经理，应该做到管理好项目測试的全方位工作。你能够指定測试经理来分管測试工作，也能够自己承担測试经理的职责。项目測试工作包含：測试环境的部署、測试工具的选择、软件測试版本号的管理、測试用例的设计与运行、測试报告的编写。当系统的功能、性能还达不到要求时，这种工作将重复进行。我所知道的IBM的产品，拥有非常强大的測试团队，一个产品，在多国有几百人上千人的測试队伍，不但涵盖了功能性測试、性能測试，就连不同操作系统环境下的细粒度測试，他们都会列出具体的測试计划，交由专门的測试project师负责处理。
7. 实施项目计划-管理项目实施。这是一项非常难的工作，毕竟前面的工作大部分面向团队内部成员，非常多的工作能够通过项目指令来完毕，而如今的实施工作是真刀真枪的实战场，没有机会给自己犯错误，给自己留面子。客户的抱怨和不满将接踵而来。项目实施，要做到提前向客户提出实施计划，要求客户为之准备些什么、怎样配合工作。另外，指派熟悉项目产品又会沟通的人员组成实施团队，在客户现场实施产品。若是涉及到升级改造项目，项目实施工作将要重点保护原有业务系统能正常工作，以便在实施过程中发生意外时能及时切换系统。项目实施过程中，严格依照既定的实施流程，做好实施记录，跟踪观察已经部署的项目的执行情况。当项目执行到约定的时间点，记得及时向客户报告运营状况并请求客户签字确认。毕竟这是项目验收的必经环节。项目实施中另一个考验项目经理功力的就是怎样调动客户积极性的问题。一般来说，客户是懒的，这就是他花钱找你做事情的原因。一个项目的成败，和客户的配合程度非常有关系。依据我的分析，一般项目中的客户都能够分为三类：支持的、消极观望的、抵触的。他们人数的分布通常是一个纺锤形：支持的和抵触的人少，观望的人多（假设你接了一个人人都抵触你的项目，那你还是不要做了）。首先，分析一下那些人为什么支持你和抵触你。非常easy，于公于私两个方面分析，上了新系统，谁的工作量有所变化？谁的潜在利益是否受到威胁？谁的岗位是不是由于新系统而消失？传统的利益格局由于新系统的使用而发生怎么样的变化，这些东西，都是项目经理必须去了解的，这样，你才干团结那些支持你的人，消减那些抵触你的人。项目经理是一个非常奇怪的角色，属于典型的责任大、权力小的角色，他能做的仅仅有借力打力，无论在自己公司还是在客户那里，一定要依靠别人才干完毕自己的目的。仅仅有了解哪些人会由于什么而帮助你，哪些人会由于什么而抵触你，你才干让客户配合你做工作。比方上一些内部计算机辅助管理系统，其必定后果就是让本来管理混乱时有人能够浑水摸鱼的一些利益消失掉了，这样，有些人肯定就要捣乱，到处诋毁这个系统。这时候，你就能够散布一些“谁抵制新系统就说明自己屁股上有屎”这类的论调去压制他们，减弱他们的影响。
8. 实施项目计划-管理项目培训。项目要给客户用，必须教会客户怎样用。项目经理要求规划好项目培训工作，指派团队善于沟通的、懂产品的project师负责客户培训。这个阶段，项目经理一般要注意下面几个问题：一、给客户做培训的版本号，一定要保证全部流程的正确性，注意每一个界面的布局、用词、链接的正确性等等，总之不要让客户看到一些他不该看到的东西。文档方面，准备至少两个文档：用户手冊和培训手冊。这两个文档的内容非常多都是一致的，可是角度全然不同。用户手冊往往是站在系统设计者的角度，依照自己的思路，分模块解说系统的操作和功能；而培训手冊，一定要站在客户业务人员的角度，依据每一个角色面对不同业务的办理，怎样通过使用本系统的一系列功能来实现目标。此外，培训可能分部门培训，这就要求准备不同内容和版本号的培训手冊。所以，第一次培训曾经，系统界面是否完整正确、培训文档是否完备都是非常关键的因素，第一炮打不响，以后就麻烦非常多。二、抓住一切机会给客户灌输你的实现方式，给他们心理准备，不会感觉新的东西太突然。三、培训、试执行过程不宜过长，免得搞得两方都非常疲劳。从编码结束、培训、新系统数据准备到试执行，一定要紧凑，让大家在忙碌中上线。否则，时间拖长了，再给客户挑出几个小毛病，项目的组员士气下来了，人心散了，队伍就不好带了....
9. 实施项目计划-管理项目收尾。项目收尾意味着项目收钱。项目经理往往在这个阶段积极性最大，也最忙碌。项目经理必须在最快的时间内准备验收各文档、阶段性验收报告、了解客户实际的验收需求和交付物。在国内，非常多企业在验收乙方的交付物时，往往和项目開始阶段制定的验收标准有一定的区别，这是国内实情。项目经理所做的大量工作即是满足客户的验收需求。此外，有一些企业又喜欢拿出行业标准来约束乙方的验收过程，这势必添加�项目经理的工作，但项目经理又没有办法不去运行这些需求。一旦交付物和验收报告工作都完毕了，项目收尾工作还剩下最后一项重要的工作——项目经验的总结。这不可是项目经理对整个项目建设过程的回想，更是为接下来的项目建设工作提供重要的參考，有利于项目经理把控更复杂的项目研发。一般而言，项目总结工作有必要在项目团队中开展。而一些注重项目团队建设的公司，通常还会召开项目总结大会，提供项目庆功的平台，让项目团队成员之间、项目与内外部人员之间相互了解，以达成项目收尾的效果最大化。
项目从想法到实现，经历的环节大致有以上所述的过程，每个成功的项目，都不可省略这些过程，否则，项目从总体上来说是失败的。作为整个项目的实际控制人，项目经理要面临诸多实际的问题，并为之制定有效的方法逐一解决。