A的做法是不可取的。
在案例中，老王的初衷是好的，提醒小项通过需求管理降低项目拖期的风险，小项在对待李经理提出的变更请求时也坚持了变更管理规范（虽然他拒绝变更的闭锁态度并不可取）。
但也许销售部经理太强势，也许是小项他们的管理规范不够细致，总之正常的变更管理流程先是被老王“简化”成一句话，而后又被小项进一步“演绎”成了空洞的文档填写，需求管理至此彻底失去了“管”住风险的机会。
其次，掌握需求管理的技巧
对需求管理，我们不但要正确认识其本质，也要具备足够的能力，掌握需求管理所需的能力和技巧，真正做到“管理”需求。
管理已确定的需求
一份通过评审并取得各方认可的《需求规格说明书》是需求管理的基础，在此基础上建立起的《需求库》和《需求跟踪矩阵》能够帮助需求管理员对分析、设计、开发和测试阶段，每个需求点被实现的情况进行跟踪和管理，这是做好需求管理的基础。
《需求规格说明书》和《需求库》是产品的设计基线，要进行严格的版本控制，不能随意修改。在对其改动前，必须通过变更管理委员会的评审，以保证需求的稳定性，防止需求蔓延的风险。
案例中的小项编制了这些文档，但是却没有给与足够的重视，尤其是在变更频繁、进度落后的压力下，他选择了罔顾QA小郑的提醒，把这些当作纯粹的文案工作来对待，忽视了产品基线对于稳定需求的重要性，导致需求变更失控，需求说明书成了摆设。
管理变更的请求
没有哪个项目的需求是不发生变化的，只是多少不同罢了，因此，如何管理变更就显得更加重要。案例中，小项的项目其实是有变更管理流程的，只是没有发挥应有的作用而已。
一般来讲，我们会通过一系列的表格和报告来实现变更的管理，比如《变更申求表》、《变更评审报告》、《变更实施记录》、《变更请求处理报告》等，千万不要把这些报告看作是僵化无用的文档，它们实际上体现了组织对变更的管理方针，从变更的提出、评审、执行、结果监控到基线变更管理的全部过程，只有对每一步都认真执行，才能实现变更的有序管理。
管理用户的需求
在我们看来，用户总是会提出各种奇怪的要求，并且总是犹豫不决，常常要求推翻之前的论断从头再来。对此不必太紧张，用户的需求不是小怪兽，我们也无需变成奥特曼，只要掌握一定的规律和技巧，用户的需求也是可以管理的。
为了控制变更的数量和频率，与各方干系人就项目的目标达成一致是十分必需的，通常情况下，用户不断增加需求是基于“这点改变不会影响项目进度”的认知提出的，如果让用户了解变更对进度的影响，对目标实现的影响，只要我们是据实以告，大多数情况下用户是能够理智对待的。
对于案例中的小项来说，后期频繁的需求变更主要是由于销售部架构调整和业务负责人更替造成的，属于重大的意外情况，应当作为重大变更来处理。小项应该就此事与项目的各方干系人坐下来讨论，必要时由老王出面协调，对有关项目工期、范围和需求变动等关键问题重新评估并达成一致，制定出一分新的启示可行的项目计划。这样既避免了无限制的延期，也不会被变更压得喘不过气来。
最后，强调需求管理的跟进
对需求管理，持续跟踪是王道，无论进度压力多大都不应该松懈，这样才能达到“管理”需求的效果。三天打鱼两天晒网的做法，从来不是需求管理的那盘菜。
需求跟踪是一件艰难琐碎的事，从《需求跟踪矩阵》的表格设计就可见一斑，它几乎涵盖了软件开发所有阶段的需求点实现情况，除非该项需求通过变更评审后被关闭，否则必须从需求分析阶段跟踪到验收测试阶段，不能有任何遗漏。