Feeling like you are using the wrong tools to achieve your product development goals?
This is Part 2 of a series of posts on Lean product development, project management and visual work management.
In this post, we review the different Lean schools of thought, and discuss that by investing in the right (Lean) Visual Work Management tool and method, you can move your projects forward much faster -- often over 50% faster.
History of Lean product development
We are often asked to define Lean simply and clearly. However defining Lean simply and clearly is nearly impossible with so many similar, yet different schools of "Lean." Unlike Agile, there is no standard, guiding manifesto.
You can see the complete guide here to Lean and Agile Project Management here.
We can speak to the origin of Lean. This is the Toyota Production System (TPS), which focuses on customer needs (customer value), pull (tasks) instead of push (tasks), and making work visible to the team with Oobeya rooms. The Toyota Product Development System (TPDS) also looks at mitigating risks and fast learning (knowledge capture, problem solving A3s, set-based development, etc.).
The result of TPS was better products, delivered more quickly and consistently.
Agile Software Development takes many of it's ques from Lean. For example, it focuses on customer needs and learning (iterative development), as well as visible work and pull (Scrum or Kanban boards).
The creators of the Agile Manifesto also place importance on improving requirements definition (user stories), inaccurate schedules (story points & burn-down), persistent resource overloads (sustainability), and multitasking (WIP constraints).
In addition to Agile, there are many offshoots or like-minded methodologies such as the Lean Startup movement, Critical Chain, and Product Development Flow.
There is one common theme among these various schools – to improve the overall throughput of the system, sustainably, in ways other than just simply throwing more money and resources into it.
Lean - working smarter not harder
The common goal is to get more out of the system simply by doing things differently -- by working smarter, not harder.
We know that not all Lean techniques are ‘smart’ in all systems. It’s clear that manufacturing systems are different from product development systems and that some Lean manufacturing techniques don't apply to product development.
Similarly, software development systems are different from hardware development systems, which are different from services oriented systems like health care, etc. These systems are different enough that good solutions in one can be detrimental in another, even if they share some things in common.
What is the definition of Lean product development?
Boiling it down to a 10-second definition of Lean is very difficult, if not impossible. But what the heck, I’ll try it anyway.
Lean is any process improvement that substantially improves the throughput of your system, sustainably.
So, it is with this definition in mind that we turn our focus to hardware development and find the ways to substantially improve throughput in these systems, sustainably.
How do we measure ROI for Lean product development?
System throughput in a hardware development system is usually measured in profit (per unit of time) and it is this system we will be analyzing throughout this blog and webinar series.
The substantially of an improvement is can be looked at using this simple equation.
Return on Investment (ROI) = how much it improves throughput divided by how much it costs.
For example, a process change like an investment in knowledge capture might cost $100k/year in labor and tool expense, in some high-innovation environments where everything changes a lot.
After considering the cost of delay incurred by stopping to capture the knowledge, maybe it only generates $400k/year in increased profits (after the $100k cost is deducted) for a 400% ROI. If we could make more than 4-1 hiring more resources and doing another project the old way, then that process change isn’t very Lean.
What is Lean, to me, are process improvements that have a greater ROI than what we could make on another new product.
Which Lean Agile practices deliver the highest ROI?
So, which of the many schools of thought or potential process improvements deliver high ROIs in typical hardware development systems? Well, according to our analyses, in most companies, the big two process improvements with the highest ROI are Visual Work Management and Project Risk Management.
If you have the right tools, Visual Work Management and Project Risk Management, the ROI is exceedingly high - easily in the hundreds and often in the thousands – when considering the Cost of Delay (Value of reduced Delay to market of a product) into the equation. If you have the best VWM tools and methods available for your type of development system, you can solve a lot of these problems and go a lot faster with relatively little cost and effort.
How does visual project management accelerate projects?
How does visual work management accelerate projects? And how do the tools used in Hardware development need to work differently than the ones in Software development or other types of projects?
Well, I’m glad you asked. This will be the topic for the remainder of this blog series and an upcoming webinar series, where we will be digging below the surface and looking at the hardware development systems to understand the characteristics which drive success in solving these problems.
Traditional visual work management vs. a new breed of tools built specifically for hardware teams
In the next post, we will start with a quick, high-level review of ‘traditional’ visual work management tools and how they work. And in subsequent posts, we will examine the enormous impact of the following in Lean product development:
1) Visibility and manageability of resource queues
2) Effective management of resource utilization in the highly variable world of product development
3) Pull vs. push in work flow
4) Reduced information flow batch sizes and faster feedback
5) Clear, correct priorities across projects
6) Shared project buffers
7) Decentralized project planning and management
8) Proactive learning management
Along the way we will assess the value of each of these in real dollars using some typical examples.
Stay tuned…In Part 3 we discuss why visual work management is a key component of Lean Agile transformation and why investment in the versions of Visual Work Management that are purpose-built for the unique conditions of hardware development projects is critical.
Want to know more about PLAYBOOK Lean Project Management methods and software? Request a demonstration video.
In Part 1 of this series we recognized that one of the primary drivers of success in product development is the speed with which we achieve the right product at the right price.
In Part 3 we discuss Visual Work Management’s role in lean transformation and why investment in Work Management software that is purpose built for the unique conditions of hardware development projects is critical.
In Part 4 start our review of Lean principles - the first principle: Visibility and manageability of resource queues.
In Part 5, we cover resource overload and variability on product development systems.
In Part 6 we look at pull vs. push in a development system, and show the importance of establishing "pull," first at the resource level and eventually the system level.
In Part 7 we discuss multitasking and the value of effective pull systems and having clear, common, and correct priorities.
In Part 8 we consider replacing individual task buffers with shared team buffers.
Part 9 discusses decentralized project planning and execution.
And in Part 10 we look at daily standup meetings for fast feedback and execution.
Editor's note: This post was originally published in 2017 and has been updated for accuracy and comprehensiveness.
