This is the second part of our series on Lean Agile Project Management.
In Part 1 we recognized that one of the primary drivers of success in product development is the speed to market.
We also presented a Current Reality Tree (CRT) (below) that shows many of the largest problems slowing down typical hardware or integrated product development teams today.
This post answers the question, What is Lean Agile Project Management?
Before we jump into the role that Visual Work Management plays in enabling Lean Project Management in hardware teams, I feel compelled to put it in context by reviewing the many schools of Lean.
There are many similar, yet different schools of Lean, each of which focuses on various subsets of these issues. For example, the origin of Lean was the Toyota Production System (TPS), which focused on customer needs (customer value), pull instead of push, and making work visible to the team with Oobeya rooms.
The Toyota Product Development System (TPDS) focused on customers and making work visible, too, and added some focus on mitigating risks and fast learning (knowledge capture, problem solving A3s, set-based development). The result was better products, delivered more quickly and consistently.
Agile Software Development is another example and like TPDS focuses on customer needs and learning (iterative development) as well as visible work and pull (Scrum or Kanban boards). In addition, the creators of the Agile Manifesto focused on improving requirements definition (user stories), inaccurate schedules (story points & burn-down), persistent resource overloads (sustainability), and multitasking (WIP constraints). This, again resulted in better products delivered more quickly and consistently.
In addition to these schools of Lean, there is the Lean Startup movement, Critical Chain, and Product Development Flow that each shed light on some of these problems, and/or other problems not shown here. All of them are Lean, because they, in theory at least, result in better products delivered more quickly and consistently.
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. The common goal is to get more out of the system simply by doing things differently -- by working smarter, not harder.
And yet, 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 are detrimental 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.
In short, boiling it down to a 10 second definition of Lean is very difficult, if not impossible. But what the heck. Here it is again:
Lean is any process improvement that substantially improves the throughput of your system, sustainably.
The key is what is Lean depends on the system. So, it is with this definition in mind that we turn our focus to our hardware development systems, and find the ways to substantially improve throughput in these systems, sustainably.
System throughput in a hardware development system is usually measured in profit (per unit of time) and it is this system we’ll be analyzing through this blog and webinar series.
The substantiality of an improvement is its Return on Investment – how much it improves throughput divided by how much it costs. For example, a process change like 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.
So, which of the many schools of thought and potential process improvements will deliver high ROIs in typical hardware development systems? Well, according to our analyses, in most companies, the Big Two are Visual Work Management and Project Risk Management, which we call Proactive Learning Management because we extend it beyond the traditional confines of Project Risk Management.
If you have the right tools for these jobs, the ROIs in these areas are 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 do these solutions work to 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.
In the next post, we will start with a quick and high-level review of ‘traditional’ Visual Work Management tools and how they work. Through the subsequent posts, we will examine the enormous impact of the following:
In each case, we will review the aspects of our hardware development systems, which drive the value of the principle, and the methods by which we leverage that principle to achieve success in our projects and profitability in our systems. Along the way we will assess the value available to us by achieving each of these – in real dollars, using some typical examples.
Stay tuned…In Part 3 we will discuss why Visual Work Management is a key component of Lean transformation. We review its beginnings in manufacturing and why investment in the versions of Visual Work Management that are purpose-built for the unique conditions of hardware development projects is critical.
----
What is the number one cause of project delays? It's not what you think.
Lean project management
Lean project management methodology
Lean project management Kanban
Lean project management principles
Resource management
Pull vs. push
Task management
Shared project buffers
Decentralized planning
Daily stand-up meetings
Guide to Lean Project Management