Use RLCs to Control Risk

The surprising thing is that in turbulent markets “best practice” phase-gate development processes actually increase risk and waste: External factors force change on your project before you can complete it, and frozen plans increase the cost of change.

The challenge and the solution:  Your challenge as a product developer is that your biggest opportunities lie in these turbulent markets.  If you can control risk and the waste that goes with it, you can beat your competitors to these choice opportunities.

The solution is to change your dogmas about controlling waste with phase-gate processes.  Katherine Radeka pioneered Rapid Learning Cycles as a means to accelerate innovation, but it also reduces project risk.

The primary cause of project disruptions and schedule slips is that key decisions about design options and requirements must be frozen before project kickoff.  But then those decisions get baked into the design, causing long, slow loopbacks when they prove to be wrong.

The RLC framework pulls learning forward and pushes decisions later, so the decisions are made with better data reducing the risk of mid-project changes.

Why are RLCs important?  In turbulent markets, frozen decisions don’t eliminate uncertainty, they just paper over it.  When customers’ needs change, the frozen decisions are embedded so thoroughly into your design that it’s very expensive to make changes.  Paradoxically, trying to prevent mid-project changes actually exacerbates risk by increasing the cost of change.

RLCs bring fresh thinking about risk and change in turbulent markets. Surprisingly, the key to reducing risk and waste is to keep design options open as long as you can so that you have the latitude to respond quickly to market changes.

But open design options needn’t create excessive cost.   In the RLC framework, teams learn on a cadenced schedule to close key decisions before they incur excessive cost.

Are RLCs right for  you?  Costly mid-project changes can be caused either by market turbulence or by poor planning.  What makes it tricky to tell the difference is that in companies with a deeply ingrained phase-gate mentality, all mid-project changes are attributed to poor planning or sloppy execution.

Instead, explore the cause of the change.  Did a customer change his mind after your project started?  Were changes driven by customers learning more about their application while you were developing the solution?  Was the change forced by your competitor offering a new solution?  Any of these situations indicates that you’d benefit from the RLC approach.

Another key symptom of the need for RLCs is hard to see because project post-mortems will never spot it.  This is the risk of sticking to a plan that should have been changed.  When the market target moves but developers fail to adapt, developers get kudos for meeting the plan but the product doesn’t meet its profit goals.

RLC resources:  If you think you might benefit from the flexibility of RLCs to meet the challenges of turbulent markets, here are some resources to look into.

I have a brief explanation of FPD on the Silver Streak Partners on the RLC Basics page.

And there are links to more information on the Explore page.

Use RLCs to Control Risk