在大部份机构，项目经理与商业方及管理层共同建立项目范围，评估所需资料。而项目经理在这几项工作中，通常会依赖技术架构师协助。
定义范围
- 客观地根据用例定义项目范围，及获取商业方同意
- 在项目开发期间更改范围会严重影响进度及降低员工士气
- 当商业方在开发期间增加额外需求，记录入用例中及安排它们在未来的版本中。或者简略评估每个用例，并向商业方提供资料以便他们作出决定
- 获取项目投资者对用例的同意
- 因为用例是以商业述语编写的，可以作为一份商业方与管理层之间，关于何时交付什么的“合约”
- 与商业方共同选出本次项目将会被实现的用例，其它的保留作下一版本（或另一项目）
- 就算范围是口头上的，也要被记录及以电子邮件通知所有项目相关的人。确保保留一个幅本。
- 当项目范围被确认后，强制跟从
评估的基础
- 在项目初期的评估在有更详细计划及设计后，应该定期地细化及重新评估
- 当完成外部接口、完整物件及数据模型的定义后，应该可以更准确地作出评估
- 以项目组中最慢的资源作为评估
- 评估应该是合比例的
- 因为计划及设计阶段包括了用例分析，这应占据整个项目生命周期的50%
- 考虑开发、测试及生产所需的环境搭建时间
- 开发人员评估编码及单元测试任务会比较合理
一个评估的算法
技术架构师只负责以小时计算评估，项目经理应因其它项目的工作及假期所引至的缺席等因素
- 确定每个用例的画面、接口、数据表及转换等的数量
为项包括的用例组作以下的评估。并非每个用例都有齐所有项目，括号中的基准评估适合开发组尚未成立，如果开发组已经成立，应该可以评估得更准确。因对象模型尚未完成，此时的评估受到对象数量未知的因素影响而未能准确评估
- 用户界面（2人/星期）
- 外部应用程序接口（4人/星期）
- 数据表（2人/星期）
- 表或文件转换（2人/星期）
- 评估每个用例所需编码及单元测试所需的时间
基于第1步的评估，计算基准评估是简单地计算各用例的结合，如：所有用例合计有4个画面，2个外部应用程序接口，5个数据表，0个数据转换及2个环境设置，则基准评估如下：
(4x2) + (2x4) + (5x2) + (0x2) = 26人/星期，或1,040人/小时
- 将第2步中的基准评估值乘2.5
如果编码及单元测试占每个用例的整体开销的1/3，则总开销应是基准评估的3倍。因为在此阶段约完成了50%的分析工作，总开销应是基准评估的2.5倍，因此，剩余的总项目小时是：1,040 x 2.5 = 2,600
- 为项目中每个额外的开发人员增加20%
因基准评估假设项目只有1个开发员，每增加1个开发员都会增加沟通及调配的时间约20%，虽然这些时间并非用于开发，但这是必需的开销。因此，如果项目有5个开发人员，估计时间是：2,600 x (1.2)4 = 5,391hr。为说明这只是一个评估而非实际用时，最好取四舍五入为5,500hr。假设每周工作32小时（其余时间可能用于行政等工作），即开发组每周可以工作160小时，约8至9个月可以交付系统。此时以月或季度作为评估时间可避免给人一个准确交付期的观念
- 与开发组成员共同讨论（review）这个评估
开发人员在未得到更详细资料前，不会感受到这个评估范围。告诉他们当设计完成后会重新评估是很重要的
更多的人手很少能挽救一个被延误的项目
因为必承担沟通、调配、行政等开销，加入更多人手只会令一个已被延误的项目更延迟更多。架构师通常会被要求在所有分析完成前做一个活动领域评估（ballpark estimates）。虽然并非是字面上正确，你可以在活动领域评估中加入各项假设。