一. 项目要进行整体管理，善始善终

　　整个项目开始要做好项目整体计划，在项目的整个过程中，始终要按照项目计划执行，如若遇到项目发生变更，要进行影响分析，得到批准后制定变更计划，并按变更计划执行。变更的影响情况，如：费用，时间进度等要通知相关的项目利益干系人，说明变更的原因和产生的影响。

　　项目首尾工作也是项目管理中，一项重要的工作。需要将项目过程中产生的文件资料进行整理，归档;对项目的费用和进度进行审计和审核，对项目的质量进行检验和验收;对项目的整个过程的利弊得失进行总结和交流。

　　变更计划在软件项目中经常遇到。控制好软件项目的变更，首先需要做好项目的开始目标基准的确定，基准的用户需求明确，才能衡量出哪些是需要变更的。否则变更的东西和开始要求的东西混在一起，变更计划就无从制定，变更的界限也无从划清。

　　自己做过的一个项目，开始为了占领市场和尽快拿下合同，在用户需求还没有详细提供的条件下，就与用户签定了合同，后来不仅费用受到限制，就连时间不够，在项目过程中，用户方还总是变更软件的功能和要求。因为没有一个基点，我们认为是变更需求和新增功能，而用户方认为是合同范围，不能因此增加费用和时间。这个项目在开始好象签定了合同我们争取了主动，其实需求不明确，使我们在后来的项目进程中一直处于被动。

　　所以项目从一开始就要做好计划，搞清目标。只有项目的目标明确，合理安排时间、费用、人力和其他资源，控制好项目的变更，这些是保证项目能够顺利完成的基本条件。

　　二. 项目范围管理理论解决了项目开始需求不清的问题

　　需求管理是项目范围管理中的问题，这是因为它实际上是开发过程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况下，软件开发才能以一种有计划的有序的方式进行。实际上，没有文档化的需求，在开发工作完成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在其他关键过程中涉及的原则，都是从一个稳定的基础开始的，那就是文档化的需求基线。

　　什么需求?需求是指“分配给软件的系统需求”，或者更简洁地说，“分配需求”。这些需求有可能是技术方面的(比如：功能和性能需求)，也有可能是非技术方面的(比如：发布日期，开支限度)。

　　区分开需求管理和软件需求分析是很重要的。一旦分配需求被文档化，并且被所有受影响部门(客户，系统工程，软件工程)通过，需求管理的基本工作就完成了，所剩下的就是管理变更而已。没有证据证明分配需求本身就可以十分清楚完整的作为软件开发的全部基础。事实上，通常它们不是。

　　优化和精确描述需求，填补漏洞，将含义表达得更清楚是软件需求分析要做的，分析的结果被称为“软件需求“。这样，作为需求管理的输出的分配需求实际上就成了软件需求分析的输入。需求管理远远先于软件开发的技术行动，而软件需求分析则是关键开发技术行为的第一步。

　　从这里的描述看来，需求管理的活动简直太简单，太基础了，显然没有哪个软件开发组织会不有效的进行着这种活动。问题经常出在企业对透明度的惧怕。客户觉得保持需求含糊不清，松散或者无正式文件能够给他们更多的机会去说：“那并不是我所要的，那并不是我认为的需求的含义”。文档化清晰的需求可能迫使用户在系统满足了文档化的需求但没有满足实际需要的情况下，为开始变更负责。相似地，开发人员觉得含糊不清，松散或者无正式文件的需求能给他们更大的余地，允许他们与预算和进度尽可能地接近，然后说：“这就是我们所认为的需求的含义，如果你需要其他的什么东西，你必须另外付出代价。”文档化清晰的需求会迫使开发者承担满足这些需求的义务，并使他们暴露于开支、进度评估不准确的风险之下。

　　这样一来，尽管客户与开发人员的利益动机相对，但他们却走到了一起。每一方都认为他们在保护自己的利益，巩固自己讨价还价的地位，但是事实上每一方都在走向将来的失望和争吵，为项目埋下了一刻定时炸弹。

　　三.项目时间管理理论指导我们在项目管理中怎样抓主要矛盾

　　以前进行项目管理时，是根据经验和每个人的工作特点，进行项目的分工的，软件项目基本是按照需求分析，概要设计，详细设计，代码编程，调试和测试，用户验收等几个主要过程来进行的。但将项目分工更加细化，每个小过程的时间估算是多少，整个项目可以最短用多少时间来完成，怎样合理安排人员，怎样抓项目中的关键环节等等，这些都没有进行过量化的分析和管理。