Free Trial
Watch Demo

Eric Graves

Aerospace and mechanical engineer turned NPD systems engineer, Eric spends his time engineering better product develop systems, using PLAYBOOK as his tool of choice!

Search Result

Posts containing:

What is Lean Agile Project Management? (Part 1)

Eric Graves- 07/17/18 11:48 AM

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 Agile Project Management and Visual Work Management methodology and tools that work for hardware development teams. 

To introduce the series, we start with a quick review of the primary goals of hardware product development systems, some fundamental conditions that drive success, and a review of the problems in project management that prevent project teams from achieving success...

What is Lean Agile product development?

First, the goal of product development, and projects of many other types, 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.

You can see the complete guide here to Lean and Agile Project Management here.

View the Guide

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 and how to calculate it.)

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 product development projects require the right innovative product, at the right price, delivered to market cost effectively, quickly, and predictably.

To illustrate this discussion, I will refer to 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.

Delving deeper into the triple constraint of hardware 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, it takes on the shape of a 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



What is the goal of Lean Agile product development?

The goal of Lean Agile Product Development (LPD) and Lean Agile Project Management (LPM) is to continuously drive to make the triangle flatter by continuously shrinking cost and schedule (project duration) relative to a continuously increasing scope. All of the many solutions out there 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 many problems that plague hardware product development

Shown below is a Current Reality Tree (CRT), which is one of the many tools and methods 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 Project Management 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.

Reducing cost 

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 more thinly – 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. 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.

Other tools and methods as our disposal - visual work management

In addition to healthy risk management, there are a lot of other Lean Agile 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 thet 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 VWM tools and methods do (and don’t do) to improve our systems.

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 systems!

In Part 2we 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.


Check out two paradigm shifting ideas around the cause of project delays in this 9-minute video.

Take a Product Tour


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 we begin 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 2016 and has been updated for accuracy and comprehensiveness.