VUCA是现代项目中最常见遇到的问题，它们不仅隐蔽，而且客户很难主动的感知到。所以我的客户到现在都还在从政策上坚持使用瀑布方式，这并不怪他们，因为他们就是这样工作了很多年。
但是由于现在客户的经济状况越来越糟糕，他们开始意识到他们不能再像以前那样可以先完成一个作品，如果有缺陷就再投入资金去做下一个来弥补。我借此向客户介绍VUCA并告诉他们，如果项目中的一些关键部分哪怕只有一个点再VUCA中属于高分数，就得做出改变，使用敏捷——虽然我看起来有点过于苛刻，但是阵痛期是必须要经历的。客户努力的思考寻找答案，但是每一个我提出的问题都直指他们的需求中可能出现的变数。
他们最终叹了一口气，表示愿意尝试，但是只能在很小的范围内做改变，因为他们的规定就是根据瀑布方式定的，谁都不愿意冒险踏出做改变的一步（这可能会导致他们的职业生涯直接结束）。
我也回应只在最低限度的改变他们的项目流程，接下来就是我所做的：
1）将传统的瀑布流程改为多个迷你瀑布方式
这样并不违背他们根深蒂固的观念催生的意愿，这样可以在投资在比原本计划要早得多的时候就能看到一个可以用的结果。
哪怕这个结果的功能很有限，但至少可以让他们看得见已经支付的钱变成了什么东西，以及这个产出究竟是不是他们一开始就想要但是又无法准确描述的。
2）设置月度验收流程用于轻量级的交付。
尽管他们由于制度原因，每月都会有各种会议参加，这也导致他们做实际工作的时间会比较少，但是在定好每个月给一个部分的成果时，希望他们能抽空一起验收。有些客户在听到验收这个词的时候非常的警觉，生怕过早的参与“验收”会导致交付成果没有成型就被通过而被问责，这花了很多时间向他们解释每一次验收都不是对最终产品进行某种整体交付的签收，而是每一部分成果的确认。
这也可以让他们更早的向领导交差，如果成果是他们满意的，他们可以更早也更多的放心后续的工作进展。
我只和他们沟通了这两点改变，其实已经非常消耗经历，根深蒂固的观念是很难在没有看到切实的成果前能改变的，因为我也不能操之过急的要求他们改变太多，这也是敏捷思想的一部分——先做最小的改变，让客户能看到成果。
客户有时候害怕的是他们无法想象的事物，而不是改变本身，当然最终是做出改变的这一部分，很成功，每一个月让客户看到成果，并且给出反馈，再向他们确认修改的内容和开发的内容各自的优先级，然后下一次又让他们看到他们想看到的。
之后每个月都非常乐于参与迭代验收会，他们在会上的态度也从最开始的不信任、不爱透露想法转变为，愿意沟通，解释需求和不过于对成果挑刺。