Feeling like you are using the wrong tools to achieve your product development goals?
This is Part 1 of a series of posts on Lean Project Management methods, principles and tools that work for Lean hardware product development teams.
Lean project management
What's the goal of Lean Project Management?
The goal of Lean project management is most often profit. In order to achieve profit several conditions must exist.
Profit is driven by sales volumes, Cost of Goods Sold (COGS), sales price and expenses.
Sales volume and price are heavily driven by time-to-market (project duration) and the Cost of Delaying market launch (COD) is usually quite high. (Please see our blog series on Cost of Delay).
Sales volume, price, and COGS are also heavily driven by the level of innovation in our products. With innovation comes risk (uncertainty) and variability, and required learning. Innovation is often required to reduce COGS (e.g., new manufacturing processes) as well as increase sales volumes and price via new capabilities in our products.
The rate of our learning heavily impacts the duration of our projects. This rate is impacted by many, many problems as we will discuss below and through the rest of this series.
The earlier we can accurately predict when we will be ready for launch, the more profits we will realize by having ramped-up production, marketing, and sales capabilities.
To summarize, successful Lean and Agile product development projects require the right innovative product, at the right price, delivered to market cost effectively, quickly, and predictably.
Scope, Schedule and Cost
To illustrate this discussion, I will invoke the use of the proverbial triple constraint of scope, schedule, and cost.
Figure 1: Traditional Project Management
It is becoming more accepted that this triangle is an oversimplification and a flawed model.
I completely agree.
I've even read that this model originated in Theory of Constraints, but I'm not sure about that. If it is true, here is another area where my thoughts differ from Goldratt's.
Triple constraint of project management
The Triple constraint of project management states that, “One side of the triangle cannot be changed without affecting the others.”
This isn't entirely true.
And certainly we can impact them in different ratios. The triangle isn't really always equilateral. And different shapes deliver different business value, as we'll see below.
Not to mention the fact that it isn't really a triangle when you split out Quality as is commonly done, to make it the project diamond. I believe we should separate out COGS, too, which is yet another semi-dependent variable relating to project expenses, schedule, and scope. Nonetheless, I'll use a simple triangle to illustrate my point.
The sides of this triangle are more independent than the original theory recognizes. It is absolutely possible to maintain or increase scope while reducing schedule or cost or both, and Lean shows us many ways to do just that. We do it by working smarter, not harder.
Figure 2: Lean Project Management
Lean Product development
The goal of Lean Product development is drive the triangle flatter by continuously shrinking cost and schedule (project duration) relative to a continuously increasing scope. All of the many solutions calling themselves Lean Product Development, in various ways, try to flatten out this triangle. All of the problems which LPD addresses drive the triangle to be taller than it needs to be.
The problems that plague Lean Product Development
Shown below is a Current Reality Tree (CRT), which is one of the many tools and methods that I like from the Theory of Constraints body of work. It shows many of the largest problems plaguing typical hardware or integrated product development teams today. It shows the symptoms toward the top, the root causes toward the bottom, and the self-reinforcing loops (shown in dashed lines) which tend to exacerbate these problems and keep our projects stuck in low-gear.
Figure 3: Biggest Problems in NPD Today
Note, this is a simplified form of the conditions in product development. Many other connections and problems have been omitted to make it readable. (You probably have a few to add to this list.) It’s truly a mess out there, and our challenge in Lean Product Development is to solve all of these problems and a great many more, in one way or another, without creating any new problems in the process.
Why reducing cost is not the answer
By close examination of these related problems, we can start to see some of the ways we got into this mess.
One of the root causes is placing too much emphasis on reducing expenses (budgets), which can backfire. The result of a tight budget is often a longer and more expensive project as we realize the costs of risks we didn’t mitigate, including the risk that our customers won’t buy it.
Reworks cause delays and/or cost overruns, and/or sales suffer. This makes managers want to get started on the next project in hopes of completing the next product earlier, but this is the self-reinforcing loop which causes more tight budgets, and resources spread even thinner – and so the cycle continues until it ends up looking like the triangles below.
Figure 4: Project Management with Focus on Reducing Costs
As shown in the triangle on the right, where we successfully reduce cost a little, we may pay for it by increasing time to market a lot. One common example is to plan our resources to high levels of utilization. The result is multiple overlapped projects with much, much longer durations.
However, with Cost of Delay as high as it is ($500,000 per month is not unusual), we often want the shortest possible duration, with costs being whatever it takes to get that short duration. For example, with a $500K/mo COD, we make $400K more profit by making the expenses line $100K longer to make the schedule line 1 month shorter. An optimum (maximum profit) Lean shape looks more like this.
Reducing the project schedule
We achieve the shape of the triangle below by bringing the Cost of Delay to light and making economic tradeoffs at a system level, which lead to reducing (actual) schedule and increasing profits.
Figure 5: Lean LPM with Cost of Delay Incorporated for Maximum Business Value
Note, what matters is reducing actual project duration. Making planned schedules shorter via ‘just do it faster’ pressure often has the same impact as tight budgets. This approach actually makes projects longer and more expensive in the same risk-realizing ways. This is one of the big problems at the center of the tree. We shorten both planned and actual schedules by working smarter, not harder.
For example, in the typical company depicted in the CRT, ‘do it faster’ results in planned schedules which are the ‘everything-goes-right happy path’, which almost never works out. As delays occur, more risks are taken, and the delays multiply.
Visual Work Management and Risk Management
Achieving the shortest actual schedule generally requires a high level of planned project risk management, proactive knowledge and learning management, which makes the planned schedule a bit longer than the happy path, but a lot more realistic.
In addition to healthy risk management, there are a lot of other Lean Agile project management methods and tools we can use to flatten and reshape the triangle. The best tools and methods for us depend on the types of projects we execute. For example, not everything that works for software projects works well for hardware projects, and vice versa. We will start to examine the different solutions in more detail in the next post.
One solution which is beneficial in a vast majority of projects, and one of the themes of series of posts, is what is commonly called "Visual Work Management" (VWM). There are several different forms of VWM, some of which are better than others for different types of projects.
In this series we will explore the underlying characteristics and principles of our hardware product development system, in order to see what the various visual work management tools tools and methods do (and don’t do) to improve our systems. You can also view the compete guide to LPM here.
Where to from here?
Please join us as we examine these problems, and their solutions, at a more detailed level where we uncover some powerful ways to quickly improve our product development systems.
In Part 2, we will review some different schools of Lean and their take on the problems slowing down development teams today. We set the metric of Expected ROI as the measure of a solution’s Leanness and suggest that Visual Work Management is one of the top two solutions that consistently has a high ROI.
----
Watch this 9-minute video to see two paradigm shifting ideas around the real cause of project delays. It's not what you think.
Related articles
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
