项目的范围、成本与质量相互制约。
如果不能使用合理的手段和方法确定项目范围,不能在项目过程中有效的控制范围,不能让项目范围在各相关方之间达成一致,那么会对项目造成严重的伤害。
如无情消耗项目资源,影响范围内工作的有效完成,团队加班,PM背锅等……
几乎没有人喜欢范围蔓延,但这一情况却又经常出现。
公众号:美丽Young有更多PMP项目管理知识技巧。
如何控制项目范围——
控制项目范围的关键步骤有5步,如下图:
首先,我们对项目范围要做的是规划范围管理,以定义《范围管理计划》来记录如何定义、确认和控制项目和产品范围。
然后就是要采用不同的工具和方法收集需求。这里涉及到的方法工具众多,比如用户故事、思维导图、看板、访谈记录单、调查问卷、原型试错(Axure RP)等,其中用户故事比较能够适应当前复杂需求环境的工具和方法。收集需求的各种方法灵活程度很高,作为项目经理应该能在不同的方法中选择一个合适的,就能获取到项目的真正需求。
接下来是定义范围的过程,根据收集上来的需求,去制定项目和产品的详细描述,并且能够定义这些产品或者成果的验收标准。
再接下来就是创建WBS,WBS也叫工作分解结构,WBS在项目中起到的作用在于,通过把项目的范围分解到较小的工作包,并形成一定的层次结构。使项目的范围易于维护,便于对项目的交付内容提供框架,以及对交付过程进行跟踪。
最后就是确认范围,也就是对项目可交付成果的最终验收,这一步一般是由甲方来做的。
软件PM老李曾接过一个项目,是给一个区的几所小学做家校系统。当时涉及的需求方非常多,所以在获取项目范围的时候,也遇到了难以想象的困难。甚至在很多个关键需求上,某些需求方观点直接是相反的。
为了明确各相关方想在项目中实现什么目的,老李研究了多种需求收集的方法,经历了各种波折后,最终收集了一个基本涵盖了所有相关方诉求的一份需求文件,确定了项目的范围,并根据这份文件签订了合同和开发协议。
但是,在项目过程中,不断有新的需求或变更提出,并且都说是“必要的修改”。做不包含在合同范围中的事情,肯定会影响项目的进度和质量;不做呢,就不能获得客户的验收,老李和项目团队头疼不已。
好在老李身经百战,没有让需求方牵着鼻子走,他认为是不是“必要的”,这是需要评估和调查的,然后要执行一个固定的变更流程才能在项目中执行。必要的时候,老李还通过对项目合同做一些变更,才执行了某些新需求。
此外,在前期收集需求的时候,老李就告知了客户做变更的程序和方法,这也作为一种交流和沟通的手段,让客户与项目团队能够在一定的程度上在同一个标准下开展工作。
在项目进行的过程中,老李尽可能多的向用户做演示和交流,及早的发现项目范围的变化。在项目团队方面,用尽量小的可运行产品甚至原型去与客户进行确认需求,将变更的成本和对项目的影响降到最低。
最终甲方对项目和产品表示满意,项目成功交付了。
项目经理及其团队要学会“拥抱变化”。
其实拥抱变化不等于范围蔓延,作为项目经理,在多变的需求环境中,要有意识的去管理需求变更对团队产生的影响,而不是阻止或者放任需求的变化。
而且,在项目团队中,要尽早的识别这种变化,越早识别对项目的健康越有利。