项目的性质：过去和现在
IT 业内早期的项目比较直接，简单。大部分是把企业内部的运作进行自动化，例如薪资管理系统，库存管理系统等。这些项目的范围可以从功能部门的工作内容，和雇员的工作说明，按人工运作流程等方面搜集功能需求，进而建立项目的范围。
到了今天，大部分的项目是从概念进而立项，成为项目。例如一些网站的建设，或客户关系管理（CRM）系统等，这些项目都是跨部门的需求，而且没有任何模式可以依从。在客户来说，功能需求也只是一个很模糊的概念，当我们接收一个类似的项目开始进行交付的时候，最感觉头痛的问题便是如何建立整个项目的明确范围，建立项目的功能需求。不但合约的服务内容常常含糊不清，或者只有一个服务框架的说明，让很多技术人员发觉合约签订后所建立的『范围』内包括的工作和交付物，绝对不能按合约签订时的服务价格和指定的工期内可以『成功』地把项目完成。
建立项目的范围
上世纪80年代中期，一些编程工具开始提供系统快速示范模板建立的功能，利用『快速应用开发』（Rapid Applications Development 简称RAD）模式进行系统开发，利用工具建立一个示范程序，让客户可以看到一些结果，从而启发客户对系统的功能需求，一些技术人员认为只有采用这模式才能够建立初步项目范围，可惜这是一个错误的观念。
任何一个客户在决定投资系统开发的时候，肯定已经很明确的知道这系统所能够带来的商业效益，不然客户绝对不会花费这笔系统开发的费用，签订有关的合约。纵然是内部的系统开发，要没有一个商业效益，企业绝对不会投资在系统的开发项目。
当我开始负责加拿大满地可银行的客户关系管理（CRM）系统建设的时候，银行对这项目的目标和最终效益有一个明确的指示：了解客户对银行的服务要求，提供客户所需的高效、优质服务，为银行建立准确的客户财务信息，提升客户对银行的满意度，提供客户财务投资机会和建立客户的财务记录，包括个人帐户，跟个人有关的企业帐户，信用卡、贷款、投资、按揭等信息。
从表明上看，我们可以从不同的现有数据库内有关客户的记录进行汇总，建立有关的客户数据库，让银行能够得到有关信息来管理客户的关系，但客户信息管理只是项目的一部分要求，如何才能够了解客户对银行服务的要求，如何提升客户对银行的服务满意度，如何为客户提供所需的高效优质服务呢？这些都是整个项目的最终效益要求，如何才能够达到这些要求呢？
为效益建立定义
首先我们为这些效益建立个别的定义。我们组合了十数名跟银行关系密切的客户，包括企业客户和个人客户，共同进行效益定义的探讨，同时在不同的分行内为客户进行调查，以服务范围和服务态度等方面从中了解客户对服务的要求和满意度。我们从实际客户口中和客户小组的研讨过程中建立有关的效益定义，了解客户对银行服务的实际需求和期盼，也了解客户所希望达到的服务水平和质量要求。
从客户的服务需求中我们明确地知道客户希望银行能够为客户进行全面的理财服务，而且希望能够让客户在实际的服务需求前有足够的时间进行分析和决定，同时能够为客户提供财务的状态分析，让客户能够全面掌握本身的财务管理信息。
为效益建立解决方案
接下来我们跟银行的业务人员共同进行探讨，如何能够从业务的角度来建立个别效益的解决方案（见附图），透过业务流程的开发，数据库的处理，系统的建设和开发来达到项目的功能需求和商业效益。从解决方案的建立，我们制定了有关的项目范围。
建立范围的模式
每一个项目都有期待的商业效益，而每一个效益按有关的功能需求来完成，只要能够建立有关的效益定义，是建立范围的基础。每
一个效益有一样或多样的功能需求才能完成，从功能的需求上我们可以建立一个或多个有关的解决方案，而每一个解决方案均有一定的交付物，可能是一个或多个的业务流程，一个或多个系统的建设，一个或多个数据库，一个或多个的方法。这些交付物将建立项目的范围周边，要能成功地完成项目的指标，我们还需把项目范围内的工作内容和工作需求建立起来，才能够有效地管理范围的变动。
这一个案例让我们了解范围的建立并不单依靠客户所能提供的信息。往往客户不知道本身的需求，故此无法提供项目的范围，要建立服务的范围，我们必需从效益的定义开始。也只有让客户了解项目的最终效益的描述，而能够让客户了解如何能够提供期待的效益，才能够降低开发过程的范围变动，才能够减少项目过程中的返工，修改。才能够有效地管理项目的交付。