如果项目范围即既定的的面积S不变，C、Q、T就可以在一个固定的S的边界限制下给出一个约束的关系模型。但是，如果S的值并不是固定，就如上图所示出现边界模糊或者向外扩展时， C、Q、T就失去可依赖的边界限制，其之间的约束关系就会变得复杂。因此，我们在对项目范围进行控制时，一是要保证项目初期的S是准确可靠的，尽量减少边界的模糊性；二是要保证项目实施过程中S的稳定，尽量避免扩大化，或是说让扩大化受到合理的控制。
2.1内部价值链
项目预算——项目拆分及概算分摊——项目合同——订单——采购——库存——材料发放——合同支付——成本归集
可以看出价值链中的每个环节构成了企业内部的核心业务，因此，我们在定义项目范围的时候就可以贯穿着这个价值链，把价值链中的每个环节定义成具体的项目需求和范围，并且遵循一个闭环的原则来进行描述，如下述对项目预算范围定义中，从预算编制开始到预算回归分析，接着又进行预算编制，形成一个完整的闭环。
通过上述的定义，我们就可以为价值链定义出多个闭环，而每个闭环将构成一个整体的闭环，同时也构成项目范围的边界。
2.2内部管理成本
业主在实施项目过程中，对超出了原项目范围内定义的需求我们可以用以下的标准来作出判断。
2.2.1是否对关键业务构成关键的影响
项目实施中，在对业务部门进行详细需求调研的阶段，业务部门不可避免地会提出很多与其业务相关联的业务，或者是一些新的想法，当遇到这种情况的时候，业主方的信息部门要作出一个合适的判断，是否可以包含在项目范围内。
首先，这个业务需求是否在关键业务描述中已经涵盖，或者说这个需求是否对关键的业务构成足够的影响力。如果不是，建议可以不纳入项目的范围内，或者暂时不纳入本次的项目范围内，而作为日后一个扩展的功能。
其次，如果此需求对关键业务构成必要的影响，那么信息部门应该进一步作以下分析：
（1） 目前系统功能是否可以解决这个需求？如果可以，实现难度如何？
（2） 如果实现难度不大，可以纳入项目范围。如果实现难度大，那么进行成本分析。
2.2.2项目成本分析
（1） 内部资源是否足够应付新需求的实现？包括业务部门人员、技术人员、软硬件支撑。
（2） 在整体项目计划当中是否允许作这样的调整？能否在项目计划时间内完成？
（3） 是否能保证项目的质量？会不会对其他功能造成影响？
如果上述成本分析回答都是肯定的，那么就可以把需求纳入实施范围，如果全为否，建议就不把其纳入本项目范围。但是由于该项需求是一个关键业务需求，可以考虑把此项目作为扩展功能在以后实现，目前可以采用其他灵活的方式处理。如果上述的回答中有肯定也有否定的，那么我认为首先要以内部资源的问题作为重点，如果此条件不能满足，即使勉强把其纳入项目范围内也只会造成项目的延迟，还不如干脆等条件满足的情况下再实施，目前先采取其他灵活的方式处理，这样既保证当前项目在原既定范围内完成，新需求在新的项目中实现。如果内部资源条件满足，那就要判断是否对项目的计划和质量造成影响或者说造成多大的影响？这种影响能否被接受和控制等等。如果会失去控制，建议不纳入范围而采取其他方式解决。
此文章共有4页 上一页 1 2 3 4 下一页
文章来源：畅享网
|
Leadge.com首页 > 知识库 