In 2012 our founder had a breakthrough.
"Starting in 2010, four companies in two countries approached me with the same question at around the same time: Could we use Agile principles to get better results from early product development so that we could solve the problems in late development that cost too much time and money, and built up disappointment? Two years later, we knew we had achieved a breakthrough."
— Katherine Radeka, Founder & CEO, Rapid Learning Cycles Institute
She uncovered the root causes behind late product launches, and developed a systematic, repeatable project management framework to eliminate them at their source.
She learned that the only way to deliver better results in late product development was to head off these problems through better decision making in early product development.
She observed that teams got their products to market faster, with a more stable and mature design. So they also experienced lower product costs and better quality at the same time.
Product development took too long, cost too much, and delivered disappointing results.
Her clients' engineering managers knew that the back end of product development was messy. It often proved to be much harder to scale up a technology than expected.
Projects experienced costly delays as they scrambled to develop and qualify a production process that could build the product at scale.
Problems with the product design itself often were discovered at this stage for the first time — poor reviews from early-look customers, quality problems that didn't show up in lab prototypes, and vendors who could not meet their commitments.
All of these things ate up time and money, when teams could least afford it. As a result:
- Products were late to market
- The first customers suffered from quality problems
- The products were not as profitable as they should have been,
- The next project teams started late — and were already behind schedule.
All these problems had a common root cause
By examing Engineering Change Requests, interviewing product developers and reviewing other project artifacts across companies, Katherine was able to trace these problems back to a common source.
They all had their roots in decisions made earlier in development, before the team had sufficient knowledge to make a good decision. These decisions failed validation steps late in development, triggering expensive rework.
This was not new, NPD experts have known about this consequence of "waterfall development" for years.
The breakthrough came when she identified the common characteristics of the specific decisions that triggered these problems, and then started coaching teams to flag these Key Decisions for special attention and trace them through early development.
What if we could eliminate this obstacle at its source?
Tracing the Key Decisions showed that they often triggered changes at the worst possible time: right before a major system integration build or during what was supposed to be final testing.
Most teams treated all of their decisions (requirements, specifications, etc.) the same, and tried to lock them down early — before the team had enough information to make a good decision.
For most of the decisions that a team has to make, this is the right approach. The decisions were made early, and held through development.
But Key Decisions were the ones that usually didn't stick. Sometimes a decision that looked right in early development didn't work out well in middle and late development. Sometimes new information came in forcing the decision to be reset. Sometimes these decisions got stuck in multiple levels of decision loops, without clear authority to make the final, risky calls.
Katherine learned that if she could help teams make these Key Decisions first-time-right, they would achieve breakthrough performance.
Right Time, Right People, Best Available Knowledge
Katherine's mantra became "Right People, Right Time, Best Available Knowledge." Of these, the Right Time was the biggest area of opportunity.
Katherine learned that each of these important decisions had a Last Responsible Moment (LRM) — the last point in time when the team or the decision maker could finalize the decision without incurring any costs-of-delay, or adding additional risk. When teams made decisions at the LRM, they were much, much less likely to revisit that decision later, when it would be a lot more costly to change.
Not every decision needed this. Some decisions could — and should — be locked down as early as possible. But for these major decisions, the extra time allowed the team to build better knowledge that led to a more confident decision that lowered risk for the entire program.
The Rapid Learning Cycles Framework
Once Katherine had that core insight, she sought out the best ways to make this guidance actionable in a series of experiments, in collaboration with these four clients, who did not know each other at the time.
One major experiment focused on using Agile principles. Another focused on process optimization. Yet another focused on pulling learning forward, earlier in development.
They all addressed one aspect of the problem, but none of them worked well on their own. The pieces needed to come together.
She fed the results of the experiment at one company into the next team at a different company. Over about two years, the pieces of the Rapid Learning Cycles framework came into focus, and then clicked into a comprehensive framework to eliminate the root causes of decisions that had to be revisited later.
All four clients had converged on the framework by the end of 2013, and all four are still using the framework to some degree today.
