In this post, I want to share an incredible case study that demonstrates the unexpected results that can be achieved when you apply the proper set of Lean Product Development principles. This story was first told by the Engineering Director in a webinar for Management Roundtable, and there's a link to that video at the end of this post. But I'll provide an outline of the presentation here...
This is Part 3 of a series of posts on Lean Agile Product Development and Project Mananagement.
PC Medical was a small startup with groundbreaking technology when they were bought by Arthrex. Video imaging for arthroscopic surgery was a mature market with a lot of competitors, but PC Medical was the first to demonstrate wireless capability within these systems. With this new technology still in the early prototype stage, Arthrex knew it was important to finish development and get to market as quickly as possible.
Impossible GoalThe project plan showed it would take fourteen months to have the entire product suite ready for launch. This included the need to double the team size along the way, as well as comply with all the regulations around medical products. But the upcoming American Association of Orthopedic Surgeons conference was just seven months away. The team understood the importance of not missing the launch opportunity so agreed to give it a shot, but said, “Making the conference with a product suite ready for launch would be the equivalent of climbing Mount Everest!”
“Making the conference with a product suite ready for launch would be the equivalent of climbing Mount Everest!” - Arthrex Project Team
The initial temptation was to hit the ground running! Instead, they paused and spent a week learning and adopting the latest lean and agile product development processes and tools that would make this a success...
The first step was to develop a Project Economic Model which gives the entire team the necessary context for rapidly making decisions using profit as the common denominator. This clearly highlighted that their Cost of Delay (COD, impact of being late) was the primary driver in most decisions.
The next step was to implement a Project Risk Management process. This allowed them to focus on the areas where the most learning was needed and do so early in the project. By tracking the burndown rate of risks (or the equivalent rate of “Rapid Learning”), the product development team could be confident there would be no late surprises which would cause them to miss their extremely tight launch date. The mitigations of these risks were planned along with the rest of the work on the project, and many of them ended up being on the critical path.
Closely tied with Risk Management is the concept of Information Theory which teaches teams how to learn as fast as possible. It also allowed the team to understand the importance of maximizing design iterations. Most companies try to reduce iterations when the best practice is to do more, smaller, and faster ones in order to increase the rate of feedback.
Modular Architecture and De-batching
The concept or modular architecture was introduced to further isolate and mitigate the product risk. This created cost tradeoff decisions that were made using the Project Economic Model. Once the Risk/Rapid Leaning plan was in place, the team looked for ways to de-batch the work. Small batches are a key concept in lean manufacturing but rarely used upstream in Lean Product Development. Once they understood how batches create queues where work sits and waits (and has a negative impact on speed), the team was able to identify them in R&D and effectively reduce queues. In fact, “big batch” became a common part of the vocabulary when referring to detrimental activities.
Decentralized Planning and Critical Chain
When the plan was developed the entire team participated via a Decentralized Planning process. This enabled the team members to include the necessary level of detail so the plans became accurate, and the team was bought into the schedule because they understood it. They also used the Critical Chain Project Management method with project buffers where they tracked the progress of the key subsystems within the product.
Daily Meetings and Project Boards
Finally, the Arthrex team held short 15-minute daily standup meetings where they discussed yesterday's progress, and any issues affecting the critical path tasks. This ensured that any delays were surfaced within 24 hours and greatly enhanced communication.
These meetings were held around a visual project board that clearly showed what each team member was working on, and whose tasks were critical. When tasks were complete, new ones were pulled from a prioritized backlog which ensured that everyone had clear and correct priorities for the day and prevented bad multitasking.
The team could also see how their work fit into the overall schedule as PLAYBOOK has both a kanban/project board view alongside the overall project plan.
“One of the detractors of progress is having to stop and give management updates. By having management attend the daily meetings, we not only negated that requirement, but they could help resolve the constraints in real time.” - Craig Speier, Director of Engineering, Arthrex
The end result was the Arthrex team completed the entire project in seven months (half of their original planned time!) and were at the AAOS conference a year earlier than they would have been otherwise. Since they were the first ones to market with this groundbreaking technology, they received 150 orders for their product and estimated they netted an additional $15M in profit by being to market early.
In the meantime, catch Craig Speier, Arthrex's Director of Engineering, talk about the Case Study in a webinar produced by The Management Roundtable. (Note that you can check the Slide Changes box on the left in their control panel to open a list of slides that allow you to rewind to various topics within the presentation.)
What's the real cause of project delays? It's not what you think. Watch this video to find out.
- In Part 1, we cover the science and economics behind “failing fast” and the optimum rate of failure when learning.
- In Part 2, we discuss why Lean Agile product development really is the opportunity of the century.
- In Part 4 we discuss the Lean Agile product development value chain and why in hardware development we have spent too much time focusing on the wrong end.
- In Part 5, we share tips on how to get started with Lean Agile product development.
- In Part 6. we discuss other key methods and principles of Lean Agile product development
- In Part 7, we discuss why cultural resistance in not the key barrier to Lean adoption.
- In Part 8, we share 4 ways to ensure your Lean Agile product development initiative won't fail.