在项目执行的过程中如何进行项目的控制？
转载，供参考。
软件开发项目进度控制
一、影响软件开发项目进度的因素
要有效地进行进度控制，必须对影响进度的因素进行分析，事先或及时采取必要的措施，尽量缩小计划进度与实际进度的偏差，实现对项目的主动控制。软件开发项目中影响进度的因素很多，如人为因素、技术因素、资金因素、环境因素等等。在软件开项目的实施中，人的因素是最重要的因素，技术的因素归根到底也是人的因素。软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上。常见的问题有以下几种情况：
1、80-20原则与过于乐观的进度控制
80-20原则在软件开发项目进度控制方面体现在：80％的项目工作可以在20％的时间内完成，而剩余的20％的项目工作需要80％的时间。这个80％的项目工作不一定是在项目的前期，而可能是分布在项目的各个阶段，但是剩余的20％左右的项目工作大部分是在后期。所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉，使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。有些领导看到软件交付给用户了，就一块石头落地“总算交差了”，同时又可能撤出一些被认为不必要的人力资源。但很多情况下这是为了对付用户不合理的交付期限要求而采用的不得已的措施。这样的结果是拖延了后期的工作，同时如果软件还不成熟的话，会给用户造成不好的影响。
2、范围、质量因素对进度的影响
软件开发项目比其他任何建设项目都会有更经常的变更，大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧，用户是想改就改，造成需求的蔓延，项目经理有时还不知如何拒绝，加上要说“我能”的心理因素，一般都会答应修改。这样集少成多，逐渐影响了项目进度。
如果某项工作在进度上表面上达到目标了，但经检验其质量没有达到要求，则必然要通过返工等手段，增加人力资源的投入，增加时间的投入，实际上是拖延了进度。不管是从横向或纵向来看，部分任务的质量会影响总体项目的进度，前面的一些任务质量中会影响到后面的一些任务质量。
3、资源、预算变更对进度的影响
资源，最主要的还是人力资源，有时某方面的人员不够到位，或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。还有一个很重要的资源，就是信息资源，如某些国家标准、行业标准，用户可能提供不了，而是需要去收集或购买，如果不能按时得到，就会影响需求分析、设计或编码的工作。其他资源，如开发设备或软件没有到货，也会对进度造成影响。
预算其实就是一种资源，它的变更会影响某些资源的变更，从而对进度造成影响。
4、低估了软件开发项目实现的条件
低估软件开发项目实现的条件表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。
首先是低估技术难度。软件开发项目团队成员，有时甚至是企业的高级项目主管也经常低估项目技术上的困难。低估技术难度实际上也就是高估人的能力，认为或希望项目会按照已经制定的乐观项目计划顺利地实施，而实际则不然。软件开发项目的高技术特点本身说明其实施中会有很多技术的难度，除了需要高水平的技术人员来实施外，还要考虑为解决某些性能问题而进行科研攻关和项目实验；
其次，低估了协调复杂度，也低估了多个项目团队参加项目时工作协调上的困难。软件开发项目团队成员比较强调个人的智慧、强调个性，这给项目工作协调带来更多的复杂度。当一个大项目由很多子项目组成时，不仅会增加相互之间充分沟通交流的困难，更会增加项目协调和进度控制上的困难。
另外，企业高级项目主管和项目经理也经常低估环境因素，这些环境因素包括用户环境、行业环境、组织环境、社会环境、经济环境。低估这些条件，既有主观的原因，也会有客观的原因。对项目环境的了解程度不够，造成没有做好充分的准备。
5、项目状态信息收集的情况
由于项目经理的经验或素质原因，对项目状态信息收集的的掌握不足，及时性准确性完整性比较差。另外其它一些原因也会造成这种现象。某些项目团队成员报喜不报忧，不希望别人知道自己工作的不好的情况，例如软件程序的编制，可能会先编制一些表面的东西，现有界面，看起来好像完成任务了，实际上只是一个“原型系统”或演示系统。给领导造成比较乐观的感觉。
如果项目经理或者管理团队没有及时地检查发现这种情况，将对项目的进度造成严重的影响。当然，如果出现这种需要时时刻刻都互相提防的氛围，管理人员就应该从管理的角度，从制度的角度检讨一下，进行改进，让大家实事求是地进行沟通。温伯格说:“无论你多么聪明，离开了信息，对项目进行成功的控制就是无源之水、无本之木。”
6、执行计划的严格程度
没有把计划作为项目过程行动的基础，而是把计划放在一边，比较随意去做。例如对于项目团队内部沟通或外部沟通，在计划中要说明清楚人员、周期、方式、方法，不能遗漏，但在实际项目过程中，可能出现沟通没有按时或没有完整地达到所有项目干系人的情况。若项目计划本身有错误，执行错误的计划肯定会产生错误。如，计划制订者在计划系统框架设计考虑上的错误、进度安排上的失误等。实际的项目实施中，除了这种错误之外，还可能因为项目执行上的错误，造成项目的麻烦。例如，项目的客户及其他项目干系人没有及时为项目中出现的情况采取必要的措施或者所采取的措施的不适合具体的情况、没有效果或者有副作用等。另外，如果在项目中的某项工作（如某个子系统或模块、组件）被转包给第三方开发后，不能进行有效的管理，也会造成进度上的延误。
7、计划变更调整的及时性
渐近明细是项目的特点，特别是对于软件开发项目，并不是一个一成不变的过程。开始时的项目计划可以先制定得比较粗一些，随着项目的进展，特别是需求明确以后，项目的计划就可以进一步的明确，这时候应该对项目计划进行调整修订，通过变更手续取得项目干系人的共识。计划应该随着项目的进展而逐渐细化、调整、修正。没有及时调整的计划或者是随意的不负责任的计划的项目是难以控制的。在高技术行业，日新月异是主要特点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式，随着项目的进展进行不断细化、调整、修正、完善。对于较为大型的软件开发项目的工作分解结构可采用二次甚至多次 WBS 方法。即根据总体阶段划分的总体 WBS ，需求调研阶段结束、概要设计完成后专门针对详细设计或编码阶段的二次 WBS 。由于需求的功能点和设计的模块或组件之间并不是一一对应的关系，所以只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次 WBS ，根据代码模块或组件的合理划分而得出的二次 WBS 才能在详细设计、编码阶段乃至测试阶段起到有效把握和控制进度的作用。有些项目的需求或设计做得不够详细，无法对工作任务的分解、均衡分配和进度管理起参考作用，因此要随着需求的细化和设计的明确，对项目的分工和进度进行及时的调整，使项目的计划符合项目的变化，使项目的进度符合项目的计划。
8、未考虑不可预见事件发生造成的影响
假设、约束、风险等考虑“不周”造成项目进度计划中未考虑一些不可预见的事件发生。例如软件开发项目还会因为项目资源特别是人力资源缺乏、人员生病、人员离职、项目团队成员临时有其他更紧急的任务造成人员流动等不可预见的事件对项目的进度控制造成影响（即项目按时完成是基于如下假设：人力资源不会缺乏、人员不会生病、人员不会流动）。企业环境、社会环境、天灾人祸等事件对项目的进度控制造成影响。对项目的假设条件、约束条件、风险及其对策等对于进度的影响在项目计划要进行充分的考虑，在项目进展过程中也要不断地重新考虑有没有新的情况，新的假设条件、约束条件、潜在风险会影响项目的进度。假设是通过努力可以直接解决的问题，而这些问题是一定要解决才能保证项目按计划完成；约束一般是难以解决的问题，但可以通过其他途径回避或弥补、取舍，如牺牲进度、质量等等；假设与约束是针对比较明确会出现的情况，如果问题的出现具有不确定性，则应该在风险分析中列出，分析其出现的可能性、造成的影响、采取的措施。实际上像没有考虑人的疾病、人员流动这些情况本身也不是什么问题，因为任何人都不可能把所有以外的情况都考虑完整，实际上也没有必要。但有些诸如下班或节假日的加班时间都被安排用于项目工作的情况就会造成更多的项目不确定性。在可能的情况下当然要对所有可能情况都做到有备无患，但是有的时候也要冒一定的风险，同时对于风险的防范也需要考虑如果防范的成本大于风险本身造成的损失和影响，则这种防范是没有必要的。
9、程序员方面的因素对进度的影响
程序员方面有两种常见的心态影响了进度的控制：一是技术完美主义、二是自尊心。
技术完美主义的常见现象是，有些程序员由于进度压力、经验等方面的原因，会匆忙先做编码等具体的事情，等做到一定程度后会想到一些更好的构思，或者看到一些更好的技术的介绍，或者是觉得外部构架可以更加美化，或者是觉得内部构架可以更加优化，这样他们会私下或公开对软件进行调整，去尝试一下新的技术。而是否使用这些新的技术对完成项目本身的目标并没有影响，相反可能带来不确定的隐患。这种做法不是以用户的需求为本、或以项目团队的总体目标为本，可能对软件开发进度造成较大的影响。
自尊心的常见想象是，有些程序员在遇到一些自己无法解决的问题时，倾向于靠自己摸索，而不愿去问周围那些经验更为丰富的人。有些人也许会通过聊天室等方式匿名地向别人求教。如果运气好会很快地解决，否则要花很多实践摸索。而如果向周围的人求教，可能摸索几天的问题别人早就解决了。
10、未考虑软件开发过程的循环、迭代特性
对软件开发的各个过程分类过于精细，制定进度计划时各项工作过于紧凑、没有弹性，造成的后果是，定期提交项目进度阶段报告的制度只有在表面上起到效果，按照计划的时间表提交阶段成果也只是在表面上起到效果。因为“上有政策、下有对策”，强行的规定会使人产生一些错误的认识：如在项目计划中“规定”某个时间只能做某某类别的事情，那么严格执行的后果就是编码阶段就不能修改文档；另外错误的“里程碑”概念可能会使大家轻易地相信上一个阶段的工作成果都是“通过评审”最终定稿了，而实际上可能只是因为时间到了该提交的人提交、该评审的人评审了。如果上下阶段是不同的人就根本不会去检查其中是否还有错误；如果上下阶段是同一个人，就可能非正式地修改上一阶段的错误，但占用的时间和精力却是下一阶段的，并且这样的修改时没有记录的。这样关于阶段进度控制的措施实际上只是在表面上有效。最为普遍的情况是，用户在合同中限定了提交软件系统的时间，实际上这个时间对完成项目任务来说是远远不够的，但计划只能按照合同来进行，所以要不用户让步，要不只能按照时间的约定提交实际上还未完成的软件系统，完成系统的安装，但这时候的“完成阶段任务”只是一个表面现象，系统虽然安装了，但可能是没有经过严格彻底测试的，也可能是只完成了部分的功能，省略了某些功能，有些是整块功能省略，有的是省略了某些功能的某个过程，如数据录入里面隐含的数据录入前缺省值设置、数据录入检验等功能，而是实现了比较粗糙的功能。这样，系统交付并不意味着项目的完成，而在项目交付之后还要花更多的时间。
11、其他因素
以上这些因素是影响项目进度的几个主要方面，除此之外还有很多其他的影响因素。其实最主要的因素还是人的因素，这里的人包括所有与项目相关的人。项目经理的素质、管理者的水平、用户的因素、项目成员的因素等等，都会对项目进度造成影响，这是因为由于软件开发的特性。因为篇幅有限无法一一列举，只能在此分析一些常见的因素。
不可否认，软件开发项目进度可控性还是带有一定运气成分的。特别是需要用户配合的那些软件开发项目，其可控性与用户的成熟度、软件应用领域的成熟程度和行业标准规范的完备程度有很大关系。关于可控性方面会涉及到一些与客户打交道经验，虽然我们说，顾客是上帝、以顾客为中心，但并不是说我们要把主导权交给他们，而关键是我们如何去主导、引导、把握。因此，项目控制的好坏与相关人员人际关系方面的经验也有关系。
尽管存在很多不可控的因素，我们的任务是首先分清哪些是可以控制的，哪些是我们不能控制的。项目经理一是要尽量扩大可控的领域，减少不可控的领域，二是不要在“不可控”上花太多时间，而是多花一些时间把可控的工作控制好，做好防范措施，减轻不可控因素对项目进度的影响。
项目进入实施阶段后，项目经理的几乎所有的活动都是围绕进度展开的。进度控制的目标与成本控制的目标和质量控制的目标是对立统一的关系。项目的进度、质量和成本构成一个相互制约的三角关系，需要项目经理去平衡。
二、项目进度控制的目的
项目进度控制和监督的目的是：增强项目进度的透明度，以便当项目进展与项目计划出现严重偏差时可以采取适当的纠正或预防措施。已经归档和发布的项目计划是项目控制和监督中活动、沟通、采取纠正和预防措施的基础。
1、根据计划进行监控
项目控制的***个目的是根据计划对项目的各项活动进行监控，即根据已经制定并取得共识的软件开发项目计划来监控项目的实际表现和进度。为此应该根据项目计划来监控项目计划参数的实际值，这些参数包括进度表、项目成本、工作量、工作产品和任务的属性、使用的资源、项目成员的知识和技能；根据项目计划来监控项目团队所作的承诺是否已经或可能兑现、原来的确定的风险是否可以避免或减少损失，是否有新的风险出现；根据项目计划来收集、管理、使用项目数据；根据计划监督项目干系人的参与情况，监控各项任务承担人的参与活动；定期进行必要的进度评审，确定项目是否存在重大偏差、跟踪变更请求和问题报告直到变更或问题得到解决；在项目的里程碑对项目的成果进行评审。
2、管理纠正和预防措施
项目控制的另外一个目的是管理纠正和预防措施，即当项目进度或者结果已经或即将与计划有严重偏差时，对需要采取的纠正或预防措施进行管理。为此应当收集并且分析项目进行中可能存在的问题，并以此确定解决这些问题的纠正或预防措施；对已经确定的问题采取纠正和预防措施；监控要实施的纠正和预防措施，分析措施采取以后的结果，判断这些措施的有效性，确定和记录纠正与计划结果存在偏差的问题而采取的必要且合适的措施。
项目执行过程中仅仅靠最初建立的一份“完善”的基准计划是不够的，***的计划也未必会一直有效。根据项目任务渐进明晰的特点，特别是软件开发项目的特点，在项目进行过程中，肯定需要在适当和必要的时候对项目进行变更控制，这种控制过程包括定期搜集有关项目进展情况的信息，把实际进展情况与计划进展情况进行对比；如果实际进展情况比计划进展情况有差距，或可能会有差距，就应当采取纠正或预防措施。变更控制应当在项目期间定期进行，这里所说的变更控制不一定要进行真正的变更，而是说要定期对变更进行控制。
如果在项目生命周期内的某一时间点，把实际进度与计划中约定的进度相比对，显示出项目已经延误或即将延误、超出预算目标或不符合质量要求，就必须采取纠正或预防措施使项目回到正轨上来，重新符合计划的安排要求。在已做出执行纠正或预防措施的决定之前，应评估一下纠正与预防措施的有效性和无副作用性，以确保纠正措施使项目回到项目的工作范围、时间和预算约束内，并对项目的其他目标不会造成太大的影响。
3、在各种项目目标中进行平衡
如果经过评估确定项目确实已无法控制，就应当下定决心以牺牲软件功能范围、工作成果范围（如某些中间文档）、成本预算、进度计划或软件质量中的某一项目标为代价，来保住项目最重要的那些目标，在各种项目目标中进行平衡，最终确定一个最合适的解决方案。有效的项目控制的关键是定期及时测量实际进程，并与计划进程相比较，如有必要就立即采取纠正或预防措施。指望不采取纠正和干预措施，问题就自行消失的想法是不现实的。问题越早发现就越好改正，造成的影响和损失越小。问题越提前发现就越好采取预防措施，可以用最小的代价避免造成损失。基于项目实际进展情况，就有可能准确预测项目进度计划和成本预算的实施情况，以便顺利完成项目。如果这些项目参数超出项目目标的限制范围，就必须马上采取纠正措施；如果发现这些项目参数有超出项目目标的限制范围的趋势，就必须马上采取预防措施。
软件开发项目实施中进度控制是项目管理的关键，若某个分项或阶段实施的进度没有把握好，则会影响整个项目的进度，因此应当尽可能地排除或减少干扰因素对进度的影响，确保项目实施的进度。
三、软件开发项目常用进度控制措施
1、项目进度控制的前提
项目进度控制的前提是有效地项目计划和充分掌握***手实际信息，在此前提下，通过实际值与计划值进行比较，检查、分析、评价项目进度。通过沟通、肯定、批评、奖励、惩罚、经济等不同手段，对项目进度进行监督、督促、影响、制约。及时发现偏差，及时予以纠正；提前预测偏差，提前予以预防。
在进行项目进度控制时，必须落实项目团队之内或之外进度控制人员的组成，明确具体的控制任务和管理职责。要制定进度控制的方法，要选择适用的进度预测分析和进度统计技术或工具。要明确项目进度信息的报告、沟通、反馈、以及信息管理制度。
项目进度控制应该由部门经理和项目监控人员共同进行，之所以需要部门经理参与，是因为部门经理负责项目一般要负责一定人事行政的责任，如成员的考核、升迁、发展等。他们只有通过软件开发项目才能更好地了解项目成员，项目也只用通过对他们有切身利益的管理者参与管理才会更加有效。
2、项目进度控制主要手段
项目计划书：作为项目进度控制的基准和依据，项目负责人负责制作项目计划书。项目进度监控人员根据项目计划书对项目的阶段成果完成情况进行监控，如果由于某些原因阶段成果提前或延后完成，项目负责人应提前申请并做好开发计划的变更。对于项目进度延后的，应当分析产生进度延后的原因、确定纠正偏差的对策、采取纠正偏差的措施，在确定的期限内消除项目进度与项目计划之间的偏差。项目计划书应当根据项目的进展情况进行调整，以保证基准和依据的新鲜性、有效性。
项目阶段情况汇报与计划：项目负责人按照预定的每个阶段点（根据项目的实际情况可以是每周、每双周、每月、每双月、每季、每旬等等）定期在与项目成员和其他相关人员充分沟通后，向相关管理人员和管理部门提交一份书面项目阶段工作汇报与计划，内容包括：
a、对上一阶段计划执行情况的描述
b、下一阶段的工作计划安排
c、已经解决的问题和遗留的问题
d、资源申请、需要协调的事情及其人员
e、其他需要处理的问题
这些汇报将存档，作为对项目进行考核的重要材料。
在计划制定时就要确定项目总进度目标与分进度目标；在项目进展的全过程中，进行计划进度与实际进度的比较，及时发现偏离，及时采取措施纠正或者预防；协调项目参与人员之间的进度关系。
在项目计划执行中，做好这样几个方面的工作：
检查并掌握项目实际进度信息。对反映实际进度的各种数据进行记载并作为检查和调整项目计划的依据，积累资料，总结分析，不断提高计划编制、项目管理、进度控制水平。
做好项目计划执行中的检查与分析。通过检查，分析计划提前或拖后的主要原因。项目计划的定期检查是监督计划执行的最有效的方法。
及时制定实施调整与补救措施。调整的目的是根据实际进度情况，对项目计划作必要的修正，使之符合变化的实际情况，以保证项目目标其顺利实现。由于初期编制项目计划时考虑不周，或因其他原因需要增加某些工作时就需要重新调整项目计划中的网络逻辑，计算调整后的各时间参数、关键线路和工期。
3、进度控制内容
从内容上看，软件开发项目进度控制主要表现在组织管理、技术管理和信息管理等这几个方面。组织管理包括这样几个内容：
（1）项目经理监督并控制项目进展情况；
（2）进行项目分解，如按项目结构分，按项目进展阶段分，按合同结构分，并建立编码体系；
（3）制订进度协调制度，确定协调会议时间，参加人员等；
（4）对影响进度的干扰因素和潜在风险进行分析。
技术管理与人员管理有非常密切的关系。软件开发项目的技术难度需要引起重视，有些技术问题可能需要特殊的人员，可能需要花时间攻克一些技术问题，技术措施就是预测技术问题并制订相应的应对措施。控制的好坏直接影响项目实施进度。
在软件开发项目中，合同措施通常不由项目团队负责，企业有专门的合同管理部门负责项目的转包、合同期与进度计划的协调等。项目经理应该及时掌握这些工作转包的情况，按计划通过计划进度与实际进度的动态比较，定期向客户提供比较可靠的报告等。
软件开发项目进度控制的信息管理主要体现在编制、调整项目进度控制计划时对项目信息的掌握上。这些信息主要是：预测信息，即对分项和分阶段工作的技术难度、风险、工作量、逻辑关系等进行预测；决策信息，即对实施中出现的计划之外的新情况进行应对并做出决策。参与软件开发项目决策的有项目经理、企业项目主管及客户的相关负责人；统计信息，软件开发项目中统计工作主要由参与项目实施的人员自己做，再由项目经理或指定人员检查核实。通过收集、整理和分析，写出项目进展分析报告。根据实际情况，可以按日、周、月等时间要求对进度进行统计和审核，这是进度控制所必须的。
4、不同阶段的项目进度控制
从项目进度控制的阶段上看，软件开发项目进度控制主要有：项目准备阶段进度控制，需求分析和设计阶段进度控制，实施阶段进度控制等这几个部分。
准备阶段进度控制任务是：向业主提供有关项目信息，协助业主确定工期总目标；编制阶段计划和项目总进度计划；控制该计划的执行；
需求分析和设计阶段控制的任务是：编制与用户的沟通计划、需求分析工作进度计划、设计工作进度计划，控制相关计划的执行等。
实施阶段进度控制的任务是：编制实施总进度计划并控制其执行；编制实施计划并控制其执行等。由甲乙双方协调进度计划的编制、调整并采取措施确保进度目标的实施。
为了及时地发现和处理计划执行中发生的各种问题，就必须加强项目的项目的协同工作。协同工作是组织项目计划实现的重要环节。它要为项目计划顺利执行创造各种必要的条件，以适应项目实施情况的变化。
5、关于进度落后时的“赶工”措施
进度落后的情况下，有几种措施来弥补，如加人、加班、加激励等等，这些都是增加资源而又未必会见效的方法。根据Brooks原则，在某些项目进度延迟的情况下增加人手，有可能会使项目的进度更加延后。因为对于新加入本项目的员工来说，对项目相关背景、需求、设计的培训、对项目环境的熟悉和项目团队成员之间的沟通路径的增加
什么是项目执行？
同学你好，很高兴为您解答！
高顿网校为您解答：
项目管理的项目执行
项目执行：当项目启动和策划中要求的前期条件具备时，项目即开始执行。
作为全球领先的财经证书网络教育领导品牌，高顿财经集财经教育核心资源于一身，旗下拥有高顿网校、公开课、在线直播、网站联盟、财经题库、高顿部落会计论坛、APP客户端等平台资源，为全球财经界人士提供优质的服务及全面的解决方案。
高顿网校将始终秉承"成就年轻梦想，开创新商业文明"的企业使命，加快国际化进程，打造全球一流的财经网络学习平台！
高顿祝您生活愉快！如仍有疑问，欢迎向高顿企业知道平台提问！
项目高效执行的要素
项目要完成，高效执行是关键。
如何高效执行？
一是思路对。知道该做什么，关键节点在哪里，重点在哪里。
二是方法好。知道如何做，用什么方法多快好省。
三是行动快。知行合一，光说不练没用。
先说说该干啥。
一般情况下，项目管理分成启动、计划、实施、控制和收尾五个阶段，每个阶段都有一些要点值得项目经理重点关注。做到知己知彼，能让我们的管理工作更有章法。
1、启动阶段三件事
***，澄清项目目标，找准项目背后的问题所在。
第二，找准项目干系人，特别是潜在的支持者和反对者，团结一切可以团结的力量。
第三，风险评估，结合公司内外部的环境，做出风险预案。
2、计划阶段三件事
***，组建项目的核心小组，成员要能满足项目对于经验、技能和资源的要求。
第二，完成任务分解，跟据“横向到边，纵向到底”的原则，使项目的颗粒度足够分解到个人或小组可完成、可测量的程度。
第三,设置进度安排，为各项任务设定责任人、完成时间并匹配所需资源。特别提醒注意的是，项目经理要有从公司外部整合资源(人及财物)，以及适当“外包”项目工作的意识，要有超越公司边界的全局意识。
3、实施阶段三件事
***,带好团队，通过基于事和基于人的方式对团队进行激励。
第二，管理项目进度，通过会议、文档及相关的项目管理工作，使项目有序推进。
第三，处理好沟通协作的问题，特别是跨部门、跨部门的沟通问题，争取让各方都能在协作中实现各自价值。
这里我想特别提醒一下，协作的基础是价值共享，项目经理要争取让协作各方能够获得或物质、或荣誉、或情感上的回报，这样的协作关系才持久。
4、控制阶段三件事
***,识别计划的偏离，判断变化影响的是任务还是目标，因势而变。
第二，用好控制工作，包括费用表、人员负载量表等，使项目资源与项目进度相匹配。
第三，设定并管理项目的里程碑，通过不断实现“小”的胜利，来实现项目“大”的成功。
5、收尾阶段三件事
***,总结汇报，通过有效的形式呈现项目成果，并做完整交付。
第二，项目复盘，要深入分析项目目标、项目里程碑与最终成果之间的差距，分析得失，固化经验。
第三,项目知识管理，不单单是资料留存，更重要的是知识流转和应用。
当然，每个阶段要做的工作远不止三件，优秀的项目经理不需要死记硬背这些内容，因为这些要点已经融入到了他的全盘工作计划中。
重中之重是抓住项目管理的法宝：项目进度表。
项目进度表是对未来的理想化预测，高效地执行需要管理项目里程碑，评估当前状态，应对变化，并且在宏观与微观之间取得平衡。
项目执行的管理涉及的都是一些现实性问题的处置。我们最初的项目进度表是对未来事件的理想化预测，现实却总能让我们明白，我们对未来的预测太天真了。但这并不代表规划是徒劳的，反而凸显了规划的重要性。
好的开始意味着成功了一半。对于项目主管来说，好的开始意味着建立切实可行的项目计划。项目规划发挥的作用不只是描绘项目将如何开展的路线图，还能帮助我们了解项目的性质，让我们做好项目执行的筹备工作。
项目经理的真正敌人是未知事件。尽管有时候我们会怀疑这个敌人是有预谋地给我们添堵，但事实上它并不关心我们成功与否。只有当我们既未能精心规划，又不能妥善应对不确定因素时，这个强大的敌人才会拦住我们的去路。
因此，项目计划一方面非常有用，另一方面又需要不断进行调整。在环境变化导致计划失效时，固执地照搬原计划往往比毫无计划强不了多少。可如果规划得当，我们就有了一个非常强大的、能管理未来的工具。
如果项目经理不懂如何创建符合实际的项目进度表，也就不懂怎么去实现它。他们会先匆忙拼凑出一份进度表，但其中并未反映出项目的风险、质量和实现的手段。他们根据这份进度表乐观地预估了一个最终期限，并据此跟进项目进度。等到问题出现时，他们已经被大量的细节所淹没，没有时间停下来进行全盘思考。所以在这种情况下规划流程是毫无价值的。可惜的是，如果对流程规划得更得当，是可以防范或者规避项目过程中出现的很多问题，而不必埋头理会那么繁琐的细节。
怎样执行？
高效的执行与高效的规划一样，需要系统化的方法。要弄清楚怎么去规划，最有效的做法就是把它当成一个独立的流程或工作流，从而对各项元素进行分析。同样，在执行时你能够以不同的方式使用项目计划。这些方式组成如下工作流：
项目经理要注意的关键因素是：
前景规划：有着周密规划的项目会让你有时间定期停下来展望未来。下一个里程碑是什么样的？该做什么才能成功达到这个里程碑？
追踪和管理项目的执行：你的大部分时间会被用来追踪和管理项目的执行。项目进展情况如何？与计划有何不同？
评估当前状态：如果出现重大问题或有来自项目之外的变更申请，就要进行评估。项目计划与实际情况出现偏差意味着什么？应该怎么应对？变更申请有什么影响？
变更控制：应对变更是项目管理工作中必不可少的一环。实施与不实施所提议的变化分别有何影响？该如何调整才能让变化更容易被项目团队所接受？
重新规划：规划流程不会因为你已经定出了进度表的基准就大功告成！项目评估或变更请求需要的不止是对项目进度表的小小改动。也就是说，你可能需要大动干戈，重新进行项目的规划。
所有工作都是由项目计划主导，各元素之间也经由项目计划获得反馈。很明显，项目计划越实际，你就能越有效地管理整个项目。
项目执行的方方面面都会有你的项目团队的参与。他们是项目执行过程中承担实际工作的人，也应当参与前景规划、评估当前情况和重新规划项目的工作。这是保证团队合作和防止相互掣肘的关键。
宏观微观，自如切换
作为项目经理，你做的每件事都应该紧扣大环境这一背景——忽视这一点就一定会失败。相对地，你同时还负责项目的日常细节。在以进度表为核心的项目计划中，战略描绘的是全局，而进度表则给出了按任务逐项详细分解的工作流。因此，你必须依靠一手抓宏观，一手抓微观，才能实现对项目执行的管理。
对项目前景的展望，***步是描绘全局——战略。我们按照当前的项目节奏会取得什么成果它在整个项目中的运作机制是怎么样的？各项工作彼此之间有何关联？团队成员应该是知道这些问题的答案的——毕竟，他们会帮助你制定战略——但当他们关注具体的可交付成果时，可能会迷失原本的目标。因此，你需要时刻紧盯战略目标，检查支持这些目标的具体任务，以确保各项工作得以完成。当你了解的情况越来越多，你会希望确保相应的工作内容都按正确的顺序一一完成了。
追踪项目执行的工作大部分通过项目进度表来完成。与团队成员合作以记录其真实的工作完成情况——每个任务的开始、结束、工作量或持续时间——看看这些会对下一个里程碑和项目结束期限有何影响。如果进度表得到了精心维护，那么一旦有什么事偏离了原计划，你就能很快发现。一旦你发现了实际情况与原计划的偏差，就应对照战略理清其整体影响。尽管你可能会考虑对进度表进行调整以继续执行原计划，但你最应该该做的其实是抵*制这种诱惑。
有的项目经理在进度表上乱了方寸，不断把各种任务调来调去，以显示他们能够赶上最终期限。等到他们发现自己做不到的时候，已经没时间用别的方法挽救整个项目了。如果他们曾经停下来，对全局进行评估，就会发现项目的漏洞已经大得无法弥补，完全不是在进度表上改几个链接就能搞定的。这些项目经理没能很好地掌控细节，而是被细节牵着鼻子走。
当战略已经明显不可行时，你应当从工作中抽身，评估当前的状况，分析下一步的对策。对不同的假想情境进行剖析，你就能知道该在战略和进度表之间如何取舍。
等到你决心已定，就需要对战略进行重新规划了。首先更新你的战略，然后按照这个战略更改任务，对进度表上的链接和持续时间进行更新。这是你在项目规划阶段的工作的延续。注意计划相关性
作为项目经理，你有责任统筹全局。当项目团队成员专注于贯彻细节时，你需要确保这些细节能形成合力，得到切实可行的可交付成果。当他们专注于眼前的工作时，你的眼睛应当看到明天、未来几周和几个月后的发展。
在你制定战略时，首先会考察如何规划以逐渐打造出最终产品。在这一战略的每个阶段，你都要确定需要完成打造最终产品的哪些部分以最终进行整合。你需要对当前的阶段有着透彻的了解，还要清楚它对后继的其他阶段有何影响。这么做的重要性在于，一旦在当前阶段遇到了问题，你就不得不作出决策，而这个决策能直接影响后继的阶段。在某个阶段匆忙抛出的应急方案可能与后继的阶段发生冲突。你之后又不得不取消这个应急方案。因此，***是制定与未来的工作协调一致的解决方案来理会当前的问题。
在你管理团队的时候，需要明确对最终产品而言哪些功能是必不可少的，并强调将项目的所有成果按时整合的重要性。团队成员必须明白他们需要完成哪些工作才能开始进行整合，而这些工作与其个人认为的首要任务可能并不完全重合。比如说，当满足绩效要求的难度较大时，开发人员可能会专注于解决这些限制因素，从而忽略了其他团队成员需要的功能。然后，如果被忽略的功能正是开始整合过程所需的，这种缺失就会耽误其他团队成员的工作。
密切关注细节
反思战略（即全局情况）不用花太多时间。你真正需要关注的重点是项目进度表，以及项目计划中的各支持环节：质量、风险、实现的手段等。在战略方面，你应当预判接下来几个阶段的情况，也就是提前几个月进行预测。而在项目进度表方面，你应该关注更短的时间段（通常为四周左右）内的项目细节。
考察项目细节时，你需要处置的事项包括：
整个团队即将取得的下一个成就：必须达成什么目标和达成的方法。考虑如何统合团队，避免团队成员各自为政。
对哪些事项来说，时间比较关键：哪些必须提前完成或者前置期较长？是否该在某些事项上加快进度？团队成员的认知和首要任务与你不同，你觉得时间紧迫的事项可能会被他们忽视。你需要提醒他们，甚至协助他们的工作。
有什么风险？风险应当与可交付成果相关联，而且也应该有个时间表。在你生产这些可交付成果或按照给定的时间表提前准备时，应当考虑该怎么做才能最透彻地了解风险，从而确定在最初的风险计划里有哪些措施是行之有效的，以及在必要时可以采取哪些其他的手段来规避风险。
在规划阶段，你的项目计划可能会由于时间紧迫或无法预测未来，因而不得不进行假设或简化。现在你的时间更少，但同时你也开始了解到实际的进度。在你检查项目进度表时，重新梳理当初的假设，判断原来的时刻表是否依然合理。不要盲目地坚持已经失效的计划。不过，你还是必须努力坚持当初制定的里程碑。你必须尽一切努力避免违背自己的承诺。
追踪和管理项目的执行情况
尽管前瞻性的检查很重要，但你应当把更多的时间放在对项目执行的追踪和管理上。追踪就是判断和记录你当前的进度，并将其与标准计划进行比较，以衡量项目进展的健康程度。你为此对项目进行了快速评估，以便决定是否需要进行更详细的评估。如果你定期开展这项工作并且十分顺利，就有可能在问题刚冒出苗头时尽早发现它，从而得以留出更多时间来应对之。
追踪工作首先从项目进度表开始。针对正在进行或近期完成的任务，定期（一般是一周）收集以下相关参数：所有已开始任务的实际开始时间；实际完成的工作量；正在进行的任务的剩余工作量；已完成任务的实际完工时间；已分配资源的分配比例（如与原分配计划不同）。
这些就是你掌握的“实际情况”。
上面列出的并不包括完成比例，因为这个的参数可以变得非常主观。我有很多次都在已经完成了90%的任务上卡了好几天甚至好几周。这个参数很能误导人：如果你只更新完成百分比，你的进度表处置软件会将实际开始时间设置为预定开始时间，将实际完工时间设置为预定完工时间等。那么当进度表理应进行变更时反而不会有变化。更新上面列出的参数将迫使你的进度表处置软件为你计算完成百分比。该软件还会根据实际数据调整下游任务的日期和里程碑。现在你可以轻松地看出项目中哪些部分进度超前，哪些进度落后。
定期进行这样的追踪工作是很有必要的。只有经过正确地维护，你的进度表才会提醒你潜在的问题。而且，每周都对进度表进行更新的话，工作量并没有多少。如果你平时把更新工作放着不管，等做起来的时候就会叫苦连天。如果你的老板需要在几个小时后召开的会议上更新一下项目进展，你要么能随手拿出数据，要么就只能乱成一团，忙着更新早就过时的进度表。
维持适时更新的进度表是管理一个项目必不可少的，但这还不够。项目的重点不是时间，而是创造有用的产品。时间只是一个限制因素。根据你的预期，你让项目团队将精力集中在代表整合过程开始的重要里程碑上。在追踪时，你必须识别项目的当前状态：是否所有人都在整合期限前完成了进度？他们是否已经开发出了项目所需的和原计划预定的功能？是否存在潜在风险？然后将这些答案综合起来，看对未来的里程碑有何影响。比如，你的预估数据是否要进行更新？
在进行追踪时，记住你最宝贵的项目管理工具就是你的耳朵。倾听团队成员的反馈，你能从中了解到未曾预见到的问题和机会。利用你了解到的这些信息，你就能在成功管理项目方面大有作为。
还有，虽说项目经理容易牵扯进当日最重要的事务，但他们恰恰不应该这么做。项目经理应当有选择性地参与处置对全局有重大影响的问题，比如说，下一个里程碑。
收集信息
为了追踪和管理项目的执行情况，你需要收集信息，即搞清楚项目进展的实际情况如何。收集信息有两个好方法，一是与团队成员个人沟通，二是召集整个团队开汇报会。这两种方法是互补的，所以你不能只用其中一种。
一对一沟通：收集信息的***方式就是和你的团队成员保持联系。惠普为此引入了一个很有效的管理技巧，名为“走动式管理”（MBWA）。这不只是搜集项目状态信息的好方法，还能提高团队成员个人给整个项目带来的价值。实际上，只要团队成员手头没有什么十万火急的任务，你就可以走到他身边开始跟他聊。用这些问题作为开场白：工作怎么样了？有什么新问题或者麻烦吗？你需要什么帮助吗？
然后你听他说，接着再问一些问题，这样做既是为了确保你理解他的话，也是为了加强沟通的效果。这个时候很适合讨论接下来要达到的里程碑，并验证该团队成员是否能及时完成项目。如果按时完成有困难，你们可以讨论一下有无其他方法，可能的话或许能就解决方案达成共识。如果做不到，就让该团队成员继续考虑。如果发现了特别好或者特别糟糕的消息，你可能需要即时召开团队会议来进行讨论。
对于这类谈话，你需要谨记一点，这是一种简短的非正式的聊天而非拷问。你是为了帮助这名成员成功完成工作任务才和他交谈的。
项目状态会议。你应当定期（通常为每周）与整个团队举行状态会议。尽管你在状态会议期间也在收集信息，但让团队专注于项目，尤其是下一个里程碑，这才是更重要的事。所以，在会上应该让每个人快速汇报最新的进展和遇到的问题，并讨论接下来数周的安排。在合作意识较强的团队环境中，团队成员会与状态会议之外的人分享遇到的问题并拟定解决方案，但有时候项目中也会出现意外情况，很适合拿到状态会议上讨论。
一一询问每个成员，了解他们是否已经为即将开始的项目整合做好了准备，如果没有，是哪方面没有准备好。如果发现有人无法及时完成可交付成果，一定要召集大家集体讨论这一情况对其他团队成员的影响。让整个团队共同讨论不同的情境和潜在的应急方案。在讨论中要营造紧迫感。
一定要让团队结合战略进行讨论。这样你才是在管理最终产品开发的节奏，而不是单纯地对单独的可交付成果或者时间进行管理。
最后，会议开得越短越好。即使你原本打算开一个小时，也可以在15分钟之内就开完。如果没有讨论的必要，就不要多花哪怕一分钟。团队成员都愿意开短会。出现重大问题时就应当花多些时间开会，这一点是显而易见的，因为所有人都会参与讨论如何解决实际的问题。
关于项目执行和项目执行过程的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。