项目的性质：过去和现在
IT 业内早期的项目比较直接，简单。大部分是把企业内部的运作进行自动化，例如薪资管理系统，库存管理系统等。这些项目的范围可以从功能部门的工作内容，和雇员的工作说明，按人工运作流程等方面搜集功能需求，进而建立项目的范围。
到了今天，大部分的项目是从概念进而立项，成为项目。例如一些网站的建设，或客户关系管理( CRM )系统等，这些项目都是跨部门的需求，而且没有任何模式可以依从。在客户来说，功能需求也只是一个很模糊的概念，当我们接收一个类似的项目开始进行交付的时候，最感觉头痛的问题便是如何建立整个项目的明确范围，建立项目的功能需求。不但合约的服务内容常常含糊不清，或者只有一个服务框架的说明，让很多技术人员发觉合约签订后所建立的『范围』内包括的工作和交付物，绝对不能按合约签订时的服务价格和指定的工期内可以『成功』地把项目完成。
建立项目的范围
上世纪 80 年代中期，一些编程工具开始提供系统快速示范模板建立的功能，利用『快速应用开发』( Rapid Applications Development 简称 RAD )模式进行系统开发，利用工具建立一个示范程序，让客户可以看到一些结果，从而启发客户对系统的功能需求，一些技术人员认为只有采用这模式才能够建立初步项目范围，可惜这是一个错误的观念。
任何一个客户在决定投资系统开发的时候，肯定已经很明确的知道这系统所能够带来的商业效益，不然客户绝对不会花费这笔系统开发的费用，签订有关的合约。纵然是内部的系统开发，要没有一个商业效益，企业绝对不会投资在系统的开发项目。
当我开始负责加拿大满地可银行的客户关系管理( CRM )系统建设的时候，银行对这项目的目标和最终效益有一个明确的指示：了解客户对银行的服务要求，提供客户所需的高效、优质服务，为银行建立准确的客户财务信息，提升客户对银行的满意度，提供客户财务投资机会和建立客户的财务记录，包括个人帐户，跟个人有关的企业帐户，信用卡、贷款、投资、按揭等信息。
从表明上看，我们可以从不同的现有数据库内有关客户的记录进行汇总，建立有关的客户数据库，让银行能够得到有关信息来管理客户的关系，但客户信息管理只是项目的一部分要求，如何才能够了解客户对银行服务的要求，如何提升客户对银行的服务满意度，如何为客户提供所需的高效优质服务呢?这些都是整个项目的最终效益要求，如何才能够达到这些要求呢?
