范围是有效管理需求变化的唯一途径。只有有了明确的项目范围，我们才能学习和分析范围内的操作过程，建立系统的功能需求，并在开发过程中有效地管理我们的工作范围，有机会在指定的时间内完成项目的交付。PMO项目管理办公室的相关操作可以有效减少IT项目过程中的变化。

在过去的几年里，我经常听到一些软件从业者的投诉，包括：他们（客户）基本上不知道自己的需求。他们对如何做不满意，功能不断增加。他们如何完成他们的系统建设？ 他们（客户）上周说他们想要这个功能。今天，他们说他们想要这个功能。为什么不告诉我们，这样我们就不必在开发过程中不断改变！一些类似的投诉只表明，我们的软件从业者基本上不了解范围建设的重要性，也不能在项目启动前建立项目范围。

从软件开发项目开始到今天，客户一直无法告诉我们需要什么功能，他们只能告诉我们系统需要实现什么目标。功能需求不是由客户或用户提供的，而是系统分析师理解当前手动操作后分析的结果。20世纪70年代，大多数项目主要由部门单独运营。自动化的目的是提高部门本身的运行效率，进行系统建设。到20世纪80年代，意识到，企业中的数据分散在不同的部门或子公司。

哪些数据是最新的？哪些是最准确的？应该决定哪个部门的数据？如何整合这些数据，如何获取即时数据，如何使用当时的区际网络(AreaNetwork)，客户/服务端(Client/Server)，遥程存取(Remote‐Access)数据库(Data Base)等待技术来更有效地提高企业的运营效率？这些问题为软件开发项目提供系统集成和数据共享，最终目标是围绕原自动化提高企业（不仅是70年代的部门）的整体运营效率。

如果功能需求与业务流程直接相连，了解业务流程，可以建立相关功能需求，利用技术完成相关工作，提高运营效率，减少业务部门的相关工作量和人员需求。

系统建设不是基于客户的需求，而是基于如何实现项目的最终目标和项目的最终交付。需求不是由客户或用户提供的，而是我们作为专业人士根据我们想要开发的项目目标（如何实现）和项目的最终交付制定的结果。没有项目范围，我们就无法建立相关系统的功能。没有项目范围，我们就无法控制任务的工作量，无法估计完成日期并按时完成。