续上篇，有些企业在推进IT项目时，立项前通过内部梳理、外部对标、供方互动，对项目需求进行了完善及详细评估；
包括是标准功能实现，还是定制开发实现，投入工作量、实施节奏、保争拒弃等；它的核心作用就在于供方评估项目周期、投入工作量、投资金额等。
立项后供方入场后的项目范围说明书（或包含在项目章程中），是概况性的，从整体上确定项目的边界，归属于【项目范围规划】阶段；它的核心作用明确职责、风险防范等。
随着项目的深入，通过访谈、调研等方法工具，对项目需求进行进一步的深挖、细化等，最终形成项目需求规格说明书（或核心需求列表），在评估这些需求是保争，还是拒弃时，对项目至关重要，这归属于【项目范围的定义】。
不限条件地满足用户的需求，不敢说NO，导致需求蔓延，超出项目范围，增加项目风险，这种做法当然不可取；
而简单粗暴说NO，不能与用户形成共识，甚至将本属于项目范围内的需求进行了拒弃，同样不合适，那么如何形成共识，这就涉及到定义需求范围的方法与工具：
1、 邀请评审小组进行评审需求，其中最好有专家成员，这样更容易达成共识；
2、对产品功能进行分析，并与需求进行匹配，如果属于功能模块的标准功能，就应进行保争，如果不属于本模块的标准功能，而属于其它系统或模块的功能，一般应进行拒弃；
或通过定制开发实现，就要评估风险、工作量、投入金额等。
评审后的需求，形成需求更新文件，通过项目计划（WBS）进行管理，纳入项目推进范围；在【确认范围】阶段，可通过需求跟踪表，对需求进行过程管理，确保需求最终落地到IT系统中；
当然，变更是不可避免的，需要通过变更流程，经过变更委员会（CCB）进行评审，形成最终的结论，将保争的需求纳入需求跟踪文件中进行管理，这属于【控制范围】。
通过范围规划，从宏观上确定项目边界，确定哪些法人、哪些功能等做还是不做；
其次，通过定义范围，从微观上确定哪些业务、用户需求是保争，哪些是拒弃；
然后，制订项目WBS计划，通过需求跟踪列表，对需求（范围）进行确认，以保证该做的要落地；
同时，对变更的需求，进行规范化的管理，控制好项目范围。
