“项目”，在二千多年之前就已经存在。著名的埃及金字塔、我国的万里长城都是国际上众人称颂的典型项目。项目管理发展到今天，应用相对成功的领域主要是在土木工程上，现已逐步应用于软件工程、航空、国防、金融、体育等行业。
一般来说，“项目”具有技术复杂，参与的人员还众多，时间又非常紧迫，因此，人们开始关注如何有效地实行项目管理来实现既定的目标。在这里，主要谈谈在软件工程领域中项目管理的运用，也就是项目管理能够给人们提供一种解决问题的思路和方法。
I. 当前项目管理存在的问题
一项调查表明，大约70%的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20%至50%，90%以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高。国内绝大多数的IT企业正或多或少地承受着“项目黑洞”的痛楚：项目无法按期完成、项目合作方的工作难以协调、用户需求经常变动、工作质量难以保证。很多企业常常抱怨说，我们的技术实力不比国外差，我们的员工也很努力，但是我们的产品和工作效率为什么总比不上国外？
诸如此类的问题，就是当前软件开发中，实现项目管理实施时带来的问题。虽然，项目管理在土木工程中，项目管理在中国已经实施得十分成熟。但是，软件开发不同于其他产品的制造，软件的整个过程都是设计过程（没有制造过程）；另外，软件开发不需要使用大量的物质资源，而主要是人力资源；并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。基于上述特点，软件项目管理与其他项目管理相比，有很大的独特性。其问题的具体表现为：
一、工期失控，计划失控。项目做多，往往会形成一种错觉：不按计划工期完成的项目是正常的；能按计划工期准时完成的，往往是不正常的。这说明，项目的实际工期和计划工期不符，是“家常便饭”。大多数工期延期，很少提前的。工期延期、失控，自然而言会导致计划无法执行；计划无法执行，成本就失控；产品就会变形．．．．．．
二、项目前期多数出现“没事做”，后期“没人做”。在项目启动后，因为人员的配置，人员的衔接，硬件的配置，客户需求的确定性，一般会造成很多人“没事做”。而有些事是必须放在项目前期做的。前期不做，会对中后期有很大的影响。或者放到中后期做，会，要多花几倍的人力、物力。到了项目后期，会出现“虎头蛇尾”，大量的事情需要人来做，项目的人员又是固定的，其他人因为不了解整个项目，无法“空降”，则只能删除一些事情咯。这样就造成很多事情，没人做，后果可想而知。
三、开发人员心态失控。延期，赶进度；晚上加班。还是延期，星期六也加班吧。
还是不能按期完成，又到项目后期，只好封闭开发。平时晚上加班，星期六、星期天也加班。这就是很多开发人员开发项目渐进式的流程。不同项目的开发人员，只要问问对方是否加班，就大概可以了解到对方参加的项目的开发阶段拉。先抛弃加班对开发人员的效率的影响，对开发人员心态的影响才是最重要的。每个人都有趋利弊害的天性，开发人员也不例外。既然要赶进度，效率没有提高的情况下，要缩短开发时间，那只有简化功能，减少处理异常的情况，能把功能完成再说，等以后测试或用户哪里出问题再说。如果侥幸不出问题，那就没问题拉。这种情况下，当然希望测试的水平越“水”越好拉。哦，别忘了，测试也是开发人员的一部分。工期延期了，上面要求的进度又越来越紧，测试时间就更短，强度大，那只有有意无意去逃避错误，这样就皆大欢喜拉。
这些共性的问题，就是项目管理所要解决的问题。只有解决了这些问题，项目管理水平就会得到质的飞跃！当然要解决这些问题，不是一两篇文章，一两个公司就能解决的，需要所有人的不断探索才能解决的。这里，主要是个人的一些思考，供大家参考。
II. 定位问题
有人会问，产品或项目的需求不就是包含了定位，何须重复讲呢。其实，这是一个误区。同样一个需求，在一个中学生中实现和在一个大学生中实现是完全不同的；在一个有经验的群体中实现和在一个缺乏经验的群体中实现是完全不同的。有些项目，由于定位未做好，未开始注定是失败的，无论是需求分析得如何好，编码、测试控制得十分完美，终究逃不过失败这一关。
做软件的都知道，是没有真正的软件。即使是通用做的最好的WINDOWS，也不可能是通用到每一类人，每一个国家，每一个民族的人，通用到那些只有几千人的少数民族。因此，一个项目的定位是十分重要的。
产品和项目的定位是不一样的。做项目不比卖产品，产品卖出就是成功，项目投产才算成功；产品是静态的，项目是动态的；产品质量有问题可以包换、保修，项目一旦失败，时间不能倒流，客户损失的可能就是市场竞争优势和机遇。
对于用户定制的项目，定位相对简单，只要了解到定制用户的使用范围，使用者的知识结构、行业经验、电脑的基本知识及是否用过相关软件即可。特别地，如果是用过相关地软件，一定要了解清楚，哪些操作、功能是必须保留地，哪些操作、功能是可以修改或必须修改的。一段用户的已习惯了某种办法、操作方式，是很能更改的，如果定制的项目不遵照用户的习惯进行开发，在软件的运行初期，往往会出现很多意想不到的问题。此外，还必须注视用户方人员流动、机构变化造成的影响。
对于产品的开发，定位则相对复杂些。由于产品的使用者是不确定的，是预测的。因而产品的定位显得特别重要。国内的产品，是不存在通用产品的。通用，只相对于某些大行业或某个行业而言。有些产品，号称是通用产品，既不能使通用领域的用户满意，更不能使专用领域的用户满意，是一个彻底失败的产品。相反，一些产品，一开始就定位于某个行业，某个细分的行业，反而做的很好，用户量比所谓的通用的产品的用户量还要多。
如产品定位于专用，必须考虑，专用的范围，是否能进一步细分，在细分的基础上，所属范围的特征，有哪些情况是不适用，哪些情况是适用的等等。对范围的特征分析得越清楚，定位越准确，产品失败得概率就越少。同理，对于定位于通用的产品，就是将要通用所属的范围的同性提取出来。基于国内软件水平的现实，做通用产品，应该是基于某些专用范围，再兼顾其他的范围，即以专用范围为主。因此，定位的准确，是确保项目成功的底线（Bottom Line）之一。
III. 项目经理及与开发人员的沟通
项目经理类似于电影中的英雄人物，是项目的灵魂，他的一举一动影响着项目的成败。在危难时刻，优秀的项目经理甚至可以力挽狂澜。众所周知，衡量项目经理一般是以在资质、素质、能力和经验等作为主要的依据,即统筹能力、领导能力、交往能力、处理压力、解决问题的能力和技术能力。但是，个人认为，项目经理的心态才是决定一个项目成败的关键因素。当然，能力和经验也会影响项目经理的心态。
一般出任项目经理，要么是由开发骨干兼任(这在中、小型项目中很普片)，要么是由销售或其他部门空降，专职项目经理。这两种方式都有各自的弊端。专职项目经理，专做项目管理而不做任何分析、设计、编码、测试等具体的技术实施工作，就会感觉“没事做”，或是在打杂；开发骨干，由于主要或全部精力均忙于具体技术工作，各种项目管理任务（如：项目分析/评估、项目计划的制定/检查/调整、上下左右的沟通、专业资源调配、项目组织调整、项目财务控制、风险分析/对策等）不可避免地疏于顾及，项目管理的事情“没人做”，导致项目控制的问题“积劳成疾”，后悔莫及。
专职项目经理，在项目管理过程中，一般比较注重对外的联络合作方面，即比较注重和销售、用户，其他部门的协调工作。相反，就会对技术及开发的技术重视不足。在很多情况下，只根据用户、销售确定的功能、工期来安排计划，对相应的技术难点不理解，每项功能所耗费的时间估计出现很大偏差，对每个开发人员的技术、知识水平认识不透彻。因此会造成有些任务需要强制、压迫才能完成，开发人员不是建立在心服口服的情况下完成的。正所谓，上有政策，下有对策。开发人员都是高智商的动物，骗“外行”就更容易了。一般都是采取虚报工作难度，把本来一天能做完的，拖到一个星期，十天才做完；或者把正常要半个月才能做完的工作，在上面“强制”要求下，压缩到一个星期做完，当然拉，其中必然要偷工减料，只有极正常的操作才能会满足要求，对非法操作，特殊情况的处理，项目经理或测试工程师发现一个才处理一个。不能发现的，就等用户去发现。项目的实施情况就可想而知拉。
在这种情况下，必须做到几点：
一、 从开发人员的角度出发，结合市场的角度确定项目的功能，动之以情，晓之以理，尽量使开发人员心服口服地开发某个功能。
二、 由项目组讨论确定每一项功能的开发耗时，以不是通过拍脑袋的方式确定耗时；
三、 加强测试；
四、 加强对开发人员责任心、成就感的教育。
技术骨干担任的项目经理，不可避免地存在着“技术崇拜”，尽可能采用新技术。即使是需求明确的功能，由于实现方式有多种路径，一般都是从技术上采取最优的路径，而不是从用户操作方便的角度上选择操作最方便、快捷的路径，用户必须严格按开发人员所预设的操作方式进行操作。说句老实话，用户是不管你用什么技术的，先进或落后的技术都可以，只要能满足用户的需求即可。这种类似闭门造车生产出来的产品，自然就是操作不便，功能差强人意的。还有一种情况是，这种情况一般发生在项目后期，开发产品的情况较多，随着开发的深入，总会发现缺少某些功能，或者某些功能不够强大。项目经理对功能的增加、删除、修改，不是通过集体讨论确定或通过从市场前线人员中了解确定，而是通过凭空想象，拍脑袋来作出决定。特别是对于某些功能的添加，由于项目经理都无法把握用户是否需要这个功能，需要这个功能的程度，因此是很难令开发人员把握此功能的目的。当然，既然大家都无法把握用户是否会用这个功能，那自然是应付式开发。只要过了测试，过了项目经理这一关就OK拉。
初当项目经理的人，经验不足是必然的，这并不是构成产品、项目失败的关键因素，心态才是主要的。新官上任三把火，而且还是怀着“感谢党，感谢组织，感谢领导”，有着一颗报恩的心态当上项目经理，自然就事事追求完美，没有缺陷。但是，理想和现实是永远都有很大的差距的。学会取舍才是项目、产品成功的因素，也是项目经理走向成熟的关键。
成熟的项目经理，应确保项目实施中业务参与的全面性、深度和权威性。
在一、二十年前，也许您会经常听到某位大侠单独完成了某种创举，成了人们崇拜的对象。可今天，这种大侠，已经很难有生存空间了。取而代之的是，某军团，又攻克了一座什么样的堡垒。这样，沟通，可以说已经变得无比的重要。在软件业，沟通可以说是快速学习和掌握新知识，达到技术上的更高层次的最佳途径。因此，无论是项目，管理都必须在以人为本的前提下进行，必须重视沟通。
以人为本，指的不只是软件开发人员这一部分。这里的人主要指的是一些与项目有利害关系的一些人，即项目干系人(stakeholders)，一般包括客户或者用户、项目团队、项公司的管理层等一些主要的利害关系者。 一个项目能否成功，很大程度上取决于能不能分清楚这些项目利害关系者各自对项目的影响，能不能利用好这些人力资源，沟通协调好他们之间的关系。
沟通是掌握各方信息，进行项目决策和项目协调的基础，也是项目管理的基本内容。项目经理最重要的工作之一就是沟通，通常花在这方面的时间应该占到全部工作的75%～90%。良好的交流才能获取足够的信息、发现潜在的问题、控制好项目的各个方面。尽早沟通、主动沟通就是其中的两个原则。总之沟通是一门很重要的学问，在项目管理中也有专门的沟通管理，因而在本文中我们就不再讨论了。
项目经理只有以人为本，重视沟通，才会避免出现以下的情况：客户在检查项目阶段成果时，指出曾经要求的某个产品特性没有包含在其中，并且抱怨说早就以口头的方式反映给了项目组的成员，糟糕的是作为项目经理的你却一无所知，而那位成员解释说把这点忘记了；或者，你手下的程序员在设计评审时描述了他所负责的模块架构，然而软件开发出来后，你发现这和你所理解的结构大相径庭．．．．．．
IV. 产品的需求、系统分析、设计
总的而言，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。开发软件就如八股文一样：总体规划、项目立项、需求分析、系统分析、系统设计、编码实现、项目测试、文档制作（八股文：破题、承题、起讲、入手、起股、中股、后股、束股），一切都按部就班。同理，信息系统集成项目管理一般的过程分为：需求分析、项目调研、方案论证、实施方案、具体实施、测试、验收、售后服务。同时项目管理按管理的方式可以分为售前、售中和售后。
在国内，做的项目越多，就越容易产生这样的感觉：项目感觉总是做不完，就像一个“无底洞”。用户总是有新的需求要项目开发方来做，就像用户在“漫天要价”，而开发方在“就地还钱”。 实际上，这里涉及到一个“范围管理”的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由“范围管理”来决定的。“范围管理”的相关知识，可以参考项目管理知识体系指南、项目管理九大知识体系的相关内容。这里只说说两点，核心需求和需求的变更。
一般说来，需求对用户来说，可以分为核心需求和辅助需求。对于中国贪心的用户来说，功能从来不嫌多的。核心需求就是用户使用本软件是，一定会使用的功能，没有这些功能，会影响用户的忠诚度。辅助功能，就是用户可用可不用的功能。有了这些功能，用户更喜欢，没有这些功能，用户不会太在意，或者是可以容忍。同样一个软件，不同的用户，核心需求和辅助需求是不一样的。在一个项目产品中我们应该知道对方需要什么，自己要做什么，这是项目成功的基础所在。
对于产品，因为用户是不确定的，确定哪些需求是核心需求，哪些是辅助需求，则比较难。但是如果定位合理，对定位的用户范围的特征分析得准确，则不是什么太难得事。但无论是产品还是项目，都必须考虑以下三点：1、对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由，并考虑由此而引申出来的问题，触类旁通，举一反三；2、对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；3、分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。
需求确立后，重要的是规范化，文档化，可参考常用的需求建模的方法如数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。
需求的变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。现在，重要的不是限制需求的变更，而是让用户、销售、开发都明白，不管是哪种情况下变更，只要是造成变更的一方，都要背负相应的责任。这就需要一个明确的约束机制。在制定制度时，大家都可以参议，提意见。但只要制度确定了，就必须恪守这个制度，是制度管人，而不是领导管人。也只有这样，才不至于开发处于遥遥无期的状态，而到最后则草草收兵。
本人认为，需求的确定可以分为三个阶段则比较合适，这样划分也涉及到计划、成本的管理，可参考后面的相关内容。
一、 项目初期，用户、销售、开发三者，应根据WBS方法确定整个项目的整体需求，即最起码要确定WBS中最顶层的父作业，如需求一，需求二．．．．．． 并尽可能详细地确定需求地具体划分，如需求一.1，需求一.2，需求二.1，需求二.1.（1）．．．．．．对于开发周期比较长的项目，则可以确定每个需求开发开始的大概时间，周期比较段的项目，则只需确定整个项目的开始时间即可。对没有确定的需求，则要明确在开发前一个相应的时间，必须在确定的时间之前来落实详细的需求。对已确定的需求则明确在开发前的一个具体时间内可以修改的内容，主要是框架性的需求。
二、 项目开发前，核实项目的所有需求，应当包括详细的需求，并明确告知用户以后只能修改细节上需求，主要是操作上的需求。如果在以后要修改框架性的需求，必须受到一定的约束，所产生的成本必须为要变更的一方负责。如是因为开发的原因造成的，则增加成本纳入到项目的成本中；如因销售工程师因销售压力而盲目对用户作承诺的功能，则相应成本必须纳入销售成本中；确定落实需求后，进行项目的开发阶段。
三、 项目开发完成后，提交给用户试用。用户使用后，用户明确要修改的内容，主要范围是操作上，细节的实现是否与需求一致，是否与用户真正需要的一致。如要对框架性的需要修改，则必须按先前的约束条件进行。确定修改内容后，向用户明确，以后的修改内容都只能局限于当前提出的修改范围，当然，程序出错除外。开发进行修改，用户使用，将修改范围进一步缩少。一次或多次迭代后，项目完成。
V. 工作量的估算及评价
项目管理最大的难度，就是每一模块的工作量、开发时间的确定，这也是项目实施的主要风险，最难预测、控制的风险。
比较常用的估算方法有：估计项目交付日期的方法有很多，如基于经验的估计、基于模型的估计等。一种简便易行的估计方法是采用Wideband Delphi估计方法，此方法可以降低不同人员所作估计的偏差。基于模型的估计方法则包括KLOC、FPA以及COCOMOⅡ等模型。在这里主要引用新的估算方法，以供参考。
如果，公司有着类似项目实施的丰富经验，则工作量、开发时间的确定则会更切实际。
首先，提取公司内部数据，统计出类似模块的工作量（M公）、开发时间（S公）。如果，公司没有这方面的经验，那如何办呢？不做这一步？！对，没办法，没时间时也可以放弃这一步。有时间，有精力时，可以通过了解社会对类似模块的工作量、开发时间的平均值再结合本公司的情况进行假设模块的工作量、开发时间。
其次，项目开发成员对这一模块的工作量、时间的估算。这一步是最耗时，这是很多公司都没有去做的，包括国内一些知名的软件公司。软件开发，不是工厂中的流水线生产，可以对产品的生产过程中每一个过程，每一个步骤，进行严格的控制和限制。在开发过程中，由于开发人员不同的学历背景、知识水平、经历、开发经验、对模块的理解程度、思维方式、编程习惯等因素，对同样的模块，所需求的工作量，开发时间是有很大区别的。因此，需要每个开发成员对相关模块了解熟悉后，进行估计，再根据不同的系数，通过不同的公式进行转换后确定每一个模块的工作量、开发时间。
公式为：M＝M（公）*X1+M(项)*X2;
S＝S（公）*X1+S(项)*X2;
M(项)＝M（开1）*Y1+M(开2)*Y2+…+ M(开n)*Y.n;
S(项)＝S（开1）*Y1+S(开2)*Y2+…+ S(开n)*Y.n;
每一模块，每项功能完成后，对小于原定工作量或成本的，可以直接以原工作量和成本作为考核的依据。对于超出原定工作量或成本的，必须组织相关人员进行成本、工作量的评估。主要的操作方法为，组织3到5人的评估小组，小组成员尽可能是在开发时对要评估模块相当熟悉的成员。小组成员利用一定的时间了解评估模块的代码，功能特点，模块实现思路，难点，简单的单元测试等，然后小组的成员假设是成员本人来开发评估模块，需要用的成本、工作量并转换为开发人员相应级别的工作量、成本，最后综合小组成员的估计的工作量、成本和开发人员开发时所耗费的成本、工作量进行加权平均，得出最后的成本、工作量，并以此作为考核的依据。
VI. 计划的编排
有人这样形容计划的，“计划，计划，纸上画画，墙上挂挂，计划不如变化，计划不顶领导一个电话。！”。根据美国Hackett公司的一项调查发现，只有37%的信息化项目在计划时间内完成，只有42%的信息化项目在预算内完成。计划很容易成为空话，特别是在软件工程中，影响计划的因素太多，计划就形同虚设了！但是，项目管理方法的主体就是项目计划、计划优化方法,其目的就是综合各种因素，制定合理的计划，并通过计划的实施，使其规范化，从而提高项目的效益，提高人员效率，降低项目的成本。
围绕着项目计划方法，可以把项目管理方法分为四个发展阶段：Gannt图阶段、确定性网络计划技术阶段，如关键路径法CPM（Critical Path Method）等、概率型网络计划技术阶段，如计划评审技术PERT (Program Evaluation and Review Technique)和多因素随机网络计划技术阶段，如考虑资金因素的PERT/COST，考虑活动风险的图评审技术GERT(Graphics Evaluation and Review Technology)和风险评审技术VERT(Venture Evaluation and Review Technology)，以及多种资源（资金、人力等）约束下的网络优化等等。无论项目管理发展到哪一阶段，本人认为计划要合理，合乎以后项目实施的实际情况，以下三点是前提：
一、 对计划的态度问题。如果计划只是为了让上面的头头看看，放在墙上挂挂。那基本上这些计划也就是没什么意义的计划，不说也罢。这些计划不是小数。笔者曾经看过这样的计划，某位同事出差在外面两周，但在最新的计划中，还有本周必须在公司完成的开发任务。这种计划，一经编排就意味着无法完成，或者要进行变更。还有，笔者亲身经历的，在收到的计划中（是8月15号制定的），已安排笔者在8月15号前的一个星期完成某一项工作。本人是在8月15号后才知道要完成这项工作的，自然就无法按时完成拉。这样的例子还有很多，不胜枚举。
二、 对计划的编排要做到有粗有细。
传统的计划编制是这样的：首先对项目进行估算，粗算出项目的总体进度。然后进行精化：确定概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段等阶段的具体要求、完成时间、投入人力物力，并确定几个关键阶段。这些关键阶段的要求进度必须在指定日期之前完成。最后充分考虑影响项目计划的因素，并做出相应的措施，做出项目进度表，列出在每个阶段的难点要点，要注意的问题。，并将需要分析阶段的内容和项目计划、进度表整理成文档，分发到相关人员手上。
这样的计划编制，在土木工程等运用项目管理比较成熟的行业时，还算相当成功，但具体运用到软件开发上，很多时候，就会出现变形，走样。例如有些计划，真是很细致，很细致，甚至细分到小时，分钟。这样的计划很难执行，只要外界有变化，或者前面的计划出现误差，则这个计划就完了。有些计划，很粗，很粗，粗到只有时间点，只有大框架，没有具体的内容。在实施时，根本无法知道具体怎样做。这样的计划，一般被称为里程碑式的计划，比较适合领导对计划的检查。
在国内，软件开发中，计划的制定，比较常用的方法为WBS方法，即将项目工作分解为更小、更易管理的工作包也叫活动或任务，这些小的活动应该是能够保障完成交付产品的可实施的详细任务。首先就是周密地做好范围计划编制；然后以项目进度为依据划分WBS，第一层是大的项目成果框架，每层下面再把工作分解，这种方式的优点是结合进度划分直观，时间感强，评审中容易发现遗漏或多出的部分，也更容易被大多数人理解。其中，这部分内容运用专门的项目管理软件比较适合。Microsoft的项目管理工具Project就可以自动为各个层次的任务编码，国内的项目管理软件中，同望EasyPlan不但具有自动编码功能，还可以在甘特图，单网图，双网图三种视图下快速编制计划图，并可对计划、资源、成本费用的优化，进行跟踪比较，盈余分析等等，是一个不错的软件。
但是，WBS方法的前提是，对软件开发所涉及的业务要比较熟悉，有多年的经验；要求涉及人员的流动性小，管理模式要稳定。人对事物的认识是有一个过程的，不同的阶段有不同的认识。因此，对一个计划来说，计划前期尽可能细化每一项工作，越具体越好。对于以往计划执行得比较好得的公司，项目受到外界干扰比较少的项目，前期计划可以细化到日，或半天。对执行得一般的项目，可以细化到两天、三天或一周。对执行得比较差，或者容易受到外界影响的项目，如项目组成员要经常出差，或支援其他项目，或者要中断进行前面项目的维护工作等等，可以细化到旬、半个月，最好不要超过一个月，否则计划失去其本来的意义。对计划后期工作的制定，则可以比较粗些，用以适应前期计划执行情况造成的变化。
当然，这样的计划，也要避免采取每周制定下周工作计划的逐周项目计划方式，避免“项目失控合法化”。项目计划的Breakdown或曰“粒度”，是一个需要小心把握平衡的问题。越细则控制力度越大（笔者曾见过细到0.25小时/人的），但项目管理的成本越高；反之亦然。以国内目前的状况，个人看法，项目的周期越长，应越粗。项目周期为三到六个月的，可以粗到一周或半个月。周期为一到两年的，则可以粗到一个月，一个季度。无论多大的项目，应该也不要超过半年。
三、关键线路的制定。一般来说，先确定关键工作，整个项目的关键线路。然后，确定非关键工作。最后通过甘特图（横道图），网络图（单代号网络图，双代号带逻辑时标的网络图）找出自由时差、总时差，并通过缩短关键线路的工期来对项目进一步优化。在这里，最重要的，关键线路的资源，即关键线路中的关键工作是由哪个开发人员负责。现在的项目管理工作中，存在这样一个误区，整个项目的关键路线通常是由一两个开发精英、骨干、核心来承担。这样存在很大的风险。当开发核心在项目中途离职或者不得不暂停开发工作，如生病，出差等，会造成整个项目延误，而其他开发人员窝工。同时，一个人长期处于高压下工作，当前工作延误了，导致整个项目的延误；下一个工作延误了，又导致整个项目的延误。反正已经连续延误了，就无所谓了，做到哪里就算哪里好了，整个人崩溃了，对开发计划确定的时间就放弃了，从而形成一人加班，全员加班。因此，一个好的计划，出关键线路合理外，还必须时关键线路有多个人员在不同时段进行承担，避免一两个人长期承担整个关键线路，同时，还要预料，还有哪些因素影响，使某些非关键工作会上升为关键工作，成为关键线路，影响整个关键线路。
VII. 计划的执行、变更
影响计划执行的因素可以分为主观因素和客观因素。客观因素有客户相关风险，外部环境的影响，停电，机器损坏，不能上网等原因。主观因素有：人的因素、技术因素，资源因素。如果项目计划的Breakdown或曰“粒度”不符合实际情况，也是影响计划执行的因素。
设立里程碑，加强项目进度的检查（与进度计划比对）和控制，维护项目计划的严肃性，是规避计划执行风险的一个有效办法。但这是不够的。只有建立合理、实用的计划，计划的执行才会有可能。依照前面所提到的计划编排原则，那计划的执行应是这样进行的。在执行计划A时，应先审查计划B的内容，利用WBS方法，确定计划B的内容是不可再细分，需求在现阶段是否要作进一步的调整，功能点是否要删除、修改、添加等等，然后再确定计划B的具体执行时间，粗略调整由此引发后面的计划的变更。换句话说，也就是，迭代计划B，使计划B更你能满足现实的情况。计划B的具体执行时间已经制定，就是“死的”，不允许作调整，必须想尽一切办法按时、按质完成计划。因为这时计划是比较符合实际的，不能按时按质完成，不是态度问题，就是效率问题。完成计划A，在执行计划B时，迭代计划C……通过执行，迭代，完成整个计划。总之，就是使计划处于相对动态中，不是静态，也不是动态的，频频变化，要避免“项目失控合法化”。
一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的。因此对变更的管理是项目经理必备的素质之一。在这里，我们定义在执行计划A前，对计划B的修改，称为调整；执行计划A后直到完成计划B中对计划B的修改，称为计划的变更。从常识来说，对计划的调整，相对而言，成本的变化不大。因此，计划的调整是约束最少的，只要有合理的理由，对整个系统没有特别大的影响，都可以进行调整。相反，对计划变更的约束是最大的，不是哪个人，哪个领导拍个脑袋，想怎么变更就怎么变更的。谁变更，谁就应该负担变更所引发的成本。在变更之前，应该进行集体讨论。这时，千万要避免项目领导闭着门，想个三天两夜，然后对众人来个宣布，决定要怎样怎样变更。这时，来个“一言堂”，项目很容易失败的。谈论时，要明确以下目的：一，为什么要变更？二，可不可以通过其他方法来弥补，而不需要变更？三，要变更，是最少的，最优的变更吗？？四，变更造成的成本差，具体由谁来负担，这一定要明确，不能模糊。总之，抓住一个宗旨：能不变更就不变更，能少变更就少变更，变更了就应该有具体的人员来负担相应的责任、成本。一般来说，可以变更的原因有客观原因和主观原因。客观原因，如项目组成员计划外出差，生病，公司大型活动等等而造成无法按计划执行，这时的变更所造成的成本，则只能有公司来负责或整个项目组来负责。主观原因，即使是加班加点，提高工作效率，也无法按计划时间来执行计划。这种情况，是制定和调整计划的人没有做好，需求的功能比较模糊，细化得不彻底，难点估计不足。这种情况下的变更，则计划的制定和调整者，应负担相当大的责任和成本，开发人员所负担的责任和成本则相应小一些。如果是由于开发人员的责任心不够而造成的变更，则开发人员要负担大部分的成本，开发人员的领导也要负担一小部分的成本。
不管怎么样，只要变更确定了，就应该严格执行，绝对要避免同一内容一而再，再而三地进行变更，使计划成为摆设。这时，对计划地对计划地执行，应该是专制的，“一言堂”式地进行。
VIII. 测试及产品的收尾阶段
目前市场竞争的激烈和市场的成熟度不足，可能导致应用开发项目的恶性竞争风险。客户希望物美价廉而加需求、压价格、压进度；厂商惟恐出局而拍胸脯、打包票。这是很多项目经理面临的类似的情况，特别是在项目后期。
到了项目后期，主要是在进度和软件质量取得一个平衡点。在实际的项目质量管理中，质量管理总是围绕着质量保证(Quality Assurance)过程和质量控制(Quality Control)过程两方面。质量管理就不在这里展开，主要还是说说，编码等的修改和进度与系统测试的关系。
一般而言，随着项目的深入，环境各方面的变化，具体实现总是和原先的设计或多或少地出现偏差。这是很正常，不必惊慌。原则上是，能不修改则尽可能不修改。实在要修改，则只要不是原则性的错误，尽量不要推倒前面所做的一切，重新做，毕竟以前做的时候也是考虑了方方面面的因素的，现在出现的问题只是在某方面考虑不周而已，一切都作废，太浪费了。还有，要是数据库字段已存在，除非万不得已，千万不要修改数据库字段，实在不行就添加字段。因为已经存在的字段，很有可能已被软件开发小组的其他成员在使用，不要因为你的修改而令其他人也要跟你做相应的修改。最后，软件界面的修改要慎重，界面的修改很容易使你忽略修改相应的内容，造成软件大问题没有，小问题一大堆。要尽量避免出现以下两种情况：一，不顾进度、成果，尽量修改，务必做到尽可能和预设功能一致；二，为了尽快完成项目，以时间点为准，做些表面修改，也就是不负责任的修改，以求尽快完整，早日解脱这个项目的苦海。这种情况，在管理过程中，出现波折，有大量、频繁的修改的项目，出现得特别多。
到了项目后期，迫于公司、用户的压力、或者项目本身已经延迟了，尽早结束整个项目，就是自然而言的事情了。大多数的做法是，压缩系统测试时间。系统测试的时间少了，发现的问题也就少了，时间就更加可控了。这样做，也没大错，但必须注意，如在系统测试发现的大部分问题是low的，则压缩系统测试时间问题都不大；如发现的问题有相当一部分是影响使用的，比较hight的，则不能压缩系统测试时间，甚至要延长系统测试时间。不要抱着现在先混过验收测试，等以后有时间再详细测。从我了解的情况来说，这是不可能的，只要一过了验收测试，不管是程序员，还是测试员，其心态都已经发生变化了，不可能全身心投入测试、修改中。即使是勉为其难投入，其效率就可想而知拉。不管怎样，进行系统测试时，
最后的修改，必须预备一定的时间进行较全面的测试，以避免修改而引发的错误，特别是简单的错误。经验告诉我们，很多低级错误，都是在最后修改时引入的，因为预料测试时间不足而没有被发现。
到了项目后期，即使是进度延误得十分厉害，建议还是不要增加成员。因为，新成员得加入，熟悉业务需要，了解、理解业务需要一定的时间，除本身所消耗的时间外，还会有意无意地损耗其他成员的时间，造成进度的进一步拖延，等完全熟悉时，能上手，可能就是项目结束之日。此外，还会因为不熟悉，而引入新的错误，新的不稳定因素。
到了项目后期，除了进度的执行外，也要特别重视和相关人员的沟通及处理相应的关系。主要沟通人员有：用户方的项目管理人员、用户方的业务人员、用户方的决策层、开发方的项目管理人员、开发方的软件编程人员等。主要的关系有：用户方与开发方的关系、用户方项目管理人员与使用人员(业务人员)及决策层的关系、项目管理人员与软件编程人员的关系、硬件与软件的关系、性能与灵活的关系。
这样，整个项目才会取得成功！！
