信息系统项目的范围管理非常重要。范围管理决定了项目要做哪些事情。范围管理也决定了项目不要做哪些事情。这个事情直接影响项目的成功。项目范围不清楚会产生问题。项目范围经常变化也会产生问题。这些问题会导致项目延期。这些问题会导致项目成本增加。这些问题会导致项目质量下降。

项目范围管理需要首先收集需求。项目团队要和客户认真谈话。项目团队要了解客户的业务。项目团队要知道客户想要什么。客户有时自己说不清楚需求。项目团队要帮助客户理清想法。项目团队可以问很多具体问题。项目团队可以拿出类似的系统给客户看。谈话的内容要全部记录下来。记录的需求要请客户确认。客户签字确认的需求文档很重要。这是后续工作的基础。

收集需求之后要定义范围。定义范围是把需求变成项目的具体工作。项目团队要编写范围说明书。范围说明书说明项目要交付什么。范围说明书也说明项目不交付什么。范围说明书要写得很详细。范围说明书要包括项目的目标。范围说明书要包括项目的交付成果。交付成果可能是一个软件系统。交付成果可能包括用户手册。交付成果可能包括培训材料。范围说明书还要说明项目的假设条件。假设条件是项目团队认为成立的事情。假设条件可能包括客户会及时提供资料。范围说明书还要说明项目的约束条件。约束条件包括项目的预算。约束条件包括项目的时间要求。范围说明书需要客户和项目团队共同同意。

然后要制作工作分解结构。工作分解结构是把大任务拆成小任务。工作分解结构像一棵倒立的树。最上面是项目总目标。下面一层是几个大的部分。每个大部分再拆成更小的部分。一直拆到每个工作包都很具体。工作包是能够分配任务的最小单位。工作分解结构帮助项目团队理解全部工作。工作分解结构帮助项目经理分配任务。工作分解结构帮助估算项目成本和时间。工作分解结构要涵盖范围说明书的所有内容。不能遗漏任何该做的工作。也不能包含任何不该做的工作。

项目范围需要得到正式确认。项目团队要请客户审查范围说明书。项目团队要请客户审查工作分解结构。客户确认这些文件是正确的。客户确认这些文件是完整的。客户确认这些文件代表了双方的理解。客户签字表示正式接受项目范围。这个签字是重要的里程碑。签字之后项目范围就基线化了。基线化的范围是后续变化的比较基准。

项目进行中范围可能变化。客户可能提出新的想法。市场情况可能发生改变。技术可能出现新的可能。范围变化不一定是坏事。但范围变化必须受到控制。项目需要有一个变更控制流程。任何人提出变更都要提交书面申请。变更申请要描述变更的具体内容。变更申请要说明变更的原因。变更申请要评估变更的影响。变更会影响项目时间吗。变更会影响项目成本吗。变更会影响项目质量吗。变更会影响其他功能吗。

变更控制委员会负责评审变更申请。变更控制委员会包括项目经理。变更控制委员会包括客户代表。变更控制委员会包括重要技术人员。变更控制委员会开会讨论每个变更。他们分析变更的好处和代价。他们决定接受变更还是拒绝变更。不是所有变更都要接受。接受变更要考虑项目整体目标。如果变更被接受就需要更新项目文件。范围说明书需要修改。工作分解结构可能需要调整。项目计划可能需要重新制定。变更决定要通知所有相关人员。客户要知道变更后的新范围。项目团队要知道新的工作任务。拒绝的变更也要记录原因。记录的原因可以帮助回答后续问题。

项目团队要持续监督项目范围。项目经理要定期检查工作成果。检查成果是不是符合范围要求。检查工作是不是按照计划进行。如果发现偏差就要及时纠正。偏差可能是团队做了范围外的事情。偏差可能是团队遗漏了范围内的事情。早期发现偏差容易纠正。晚期发现偏差纠正代价大。项目会议可以讨论范围问题。项目报告可以反映范围状态。良好的沟通能帮助范围管理。

有效的范围管理带来很多好处。项目目标清晰团队成员明白做什么。项目范围稳定团队工作更有效率。范围变化受控项目避免混乱。项目更容易按时完成。项目更容易控制在预算内。项目成果更容易让客户满意。客户满意意味着项目成功。

实际项目中范围管理会遇到挑战。客户可能不愿意花时间确认需求。项目团队可能急于开始编码。变更控制可能被认为太麻烦。项目经理必须坚持原则。项目经理要向客户解释范围管理的重要性。项目经理要带领团队遵守流程。好的习惯需要时间养成。坚持几次之后大家就会看到好处。工具可以帮助范围管理。可以使用软件记录需求。可以使用软件制作工作分解结构。可以使用软件跟踪变更请求。工具让过程更规范。工具让信息更透明。

信息系统项目很复杂。范围管理是应对复杂性的关键手段。认真收集需求准确定义范围。详细分解工作正式确认范围。严格控制变更持续监督范围。这些步骤不能跳过。这些步骤不能马虎。每个步骤都用简单的方法做扎实。项目范围清楚项目就成功了一半。范围管理是项目经理的核心工作。掌握范围管理就能提高项目成功率。