VUCA is one of the most common challenges in modern projects—and it’s often hidden. Clients usually don’t sense it proactively, which is why many of mine still insist on a waterfall approach at the policy level. I don’t blame them. They’ve been working that way for years.
But as their financial situation has worsened, they’ve started to realize they can’t operate like before—finish one product, then fund another to compensate for defects. That’s when I introduced VUCA to them. I explained that if even a single key area of a project scores “high” on VUCA risk, something has to change—and Agile becomes necessary. I may have sounded strict, but the discomfort of transition is unavoidable.
They tried hard to think through my questions, but each one pointed directly to potential variables hidden inside their requirements. Eventually, they sighed and said they were willing to try—but only within a very small scope. Their regulations were built around waterfall, and no one wanted to be the first to take the risk of changing the process. In their words, a wrong step could end someone’s career.
I responded that I would keep changes to the absolute minimum. Here’s what I did next:
1) Turn one long waterfall into multiple “mini-waterfalls”
Instead of forcing a full process overhaul, I reframed waterfall into a series of smaller waterfalls. This didn’t challenge their deeply rooted preference for the traditional model, but it made a critical difference: they could see usable results much earlier than their original plan.
Even if each early result had limited functionality, it gave them something concrete. They could see what their money had turned into—and they could check whether the output was actually close to what they wanted from the start, even if they couldn’t clearly articulate it at the beginning.
2) Add lightweight monthly acceptance for each deliverable slice
Because of institutional constraints, they already had many monthly meetings, which reduced the time they had for real work. Still, once we agreed to deliver one part each month, I asked them to set aside time to “accept” the monthly increment together.
The word acceptance made some of them immediately cautious. They were afraid that participating in “acceptance” too early would mean approving something unfinished—and later being held accountable. It took a lot of time to explain that each acceptance was not a final sign-off for the entire product. It was simply confirmation of the deliverable slice for that month.
This also helped them report progress upward sooner. If the increment met expectations, they could feel more confident about the remaining work and reduce anxiety about whether the project was heading in the wrong direction.
Honestly, I only discussed these two changes with them, and even that took significant effort. Deeply ingrained beliefs rarely shift until people see real results. I also couldn’t push too aggressively—because that, in itself, is part of Agile thinking: start with the smallest change that can produce visible outcomes.
Sometimes what clients fear most isn’t change itself—it’s what they can’t imagine. Once they saw real progress each month, everything shifted. We showed results, collected feedback, confirmed priorities between fixes and new development, and then delivered what they cared about next.
Over time, they became genuinely willing to participate in monthly iteration acceptance meetings. Their attitude changed from initial distrust and reluctance to share ideas, to open communication—explaining their needs clearly and focusing less on picking faults and more on shaping the best possible outcome.