Article Overview
Lean is an approach to the work that focuses on the value added – or the value the customer receives from the product. A lean approach coupled with a Kaizen (continuous improvement) approach, results in reduced costs of the product. These techniques can be applied to project management and product development, and not just manufacturing of the product.
Table of Contents
- Mura – Un-evenness of Demand or Action Required for Success
- Muda – Waste and Uselessness
- Muri – Overburden – Pushing Equipment and People Beyond the Performance Limits
When it comes to project scheduling, we have at least two options, a directed system or a pull system. The directed system is demonstrated in Gantt charts. The Gantt chart identifies the individual tasks, along with start dates, hours to accomplish and end dates. This is a directed system as the project plan directs when the tasks start, some may be able to start early, contingent upon proceeding – depending tasks connected. The benefits of this approach are we can see how the tasks are interconnected- that is we can see the dependencies. The downside is these tasks have start and completion dates which implies some certainty about the duration of the task that may not be justified. By missing or not achieving the task completion by the end date, will result in more time spent on this task and likely some depending tasks that are interconnected. Directed systems are demonstrated via Gantt charts like the one below.
The pull system is like it sounds, rather than assign a start and end date, the pull system expects the team to pull the next item from the list to work on once the present work is completed. There are limits to the amount of work undertaken to accomplish the project objectives. This system is sometimes referred to as Kanban and is one of the approaches to managing the project in Agile methods such as Scrum.
This pull system, coupled with limits on work in progress (WIP). This pull work items from the list, and limit the amount of work undertaken, thus a smoothing or evening out of the work as it moves through the organization. There are examples of web-based Kanban tools that can work with distributed teams both within a company and when then the team is distributed across companies.
Muda is waste in the system. With material, we can have defects in the output, often tracked as product yield. That is the system has some variation that will produce products that are errant, that may be restored via rework or remains as waste.
This does not apply only materially but can also include project management and other non-product deliveries. Any project documentation that is delivered that has defects will have down-stream work. Consider a specification with errors in it, the errors left undiscovered, will ripple to the next stage, perhaps the design of the product. This error will result in a defect or unwanted behavior in the product that will require some form of rework, which is a waste.
There are more wastes than just rework, we can spend too much time detailed planning months out as if we have a clue of the detail’s months in the future. Spending time building a detailed project plan 2 years out is the waste of overproduction.
In conventional project approaches that uses, for example, Gantt charts, that places the work and dependencies onto the schedule. When delivery of the preceding activities is late, the depending activities are then in a position of waiting, unable to start until the precedent event is completed. We end up waiting to start based upon this interconnectedness.
Some of our project management governance activities may bring heavy additions of bureaucracy to the project, that is not commensurate with the project objectives. This is analogous of excess processing. If the level of enacted bureaucracy does not add value to the project outcome, then this is waste.
Our governance may also produce waste due to transportation, that is documentation or project’s intermediate artifacts are transferred all throughout the organization often for signoff or approvals. These exchanges and transitions take time and can impede project advancement or accomplishing of the objectives. These signoff for phase advancements or spending represent an excess of processing.
The way we engage the talent in our organization can also amount to a waste. For example, when we have talent in one area, but have that person handling topics that have nothing to do with their area of interest and demonstrated competence. If this is not received well by the person, as in not personally motivating, we may be eroding the morale of that person. We may not be making the most use of their skill which is less than ideal for the project. If we are not employing to the maximum, not engaging the person, not providing opportunities for the person to learn, we are not making the most of the opportunity. We have covered a few of these, but the complete top-level list of the wastes is provided below:
- Defects
- Overproduction
- Over-processing
- Waiting
- Transportation
- Inventory
- Talent
- Motion / Excess processing
This happens when we push the equipment and the talent beyond their capacity. Every project that ends up behind schedule, often resorts to over burdening the talent and equipment. All hands-on deck events are times where employees will be “asked” to work overtime – often un compensated. Likely all of you reading this has worked late nights, weekends and perhaps over holidays to deliver the project objectives. This often happens late in the project, and in some instances, when the late condition of the project was well known many weeks earlier, but we have taken no actions in the belief that magical things would happen and there would likely be no need for overtime.
Let’s assume the hours of overburden are beyond the 40-hour work week, this might not be true, and we need to start somewhere. This assumption then would mean the overburden damage to the talent happens for hours more than the 40-hour work week. Does that include travel time? Who knows? The point is, a demand more than whatever the baseline hours of work, results in an overburden of the talent. These restrictions also apply to project processes as well. For example, let’s consider a product development organization and a process for approving and releasing drawings into the product management system (PLM – Product Lifecycle Management). The system has multiple projects releasing drawings and other product artifacts that the company requires to go through this system. Suddenly, (or at least uncontrolled) the system is overwhelmed by a spate of drawings to be reviewed and released into the system. Thus, the process is overwhelmed or overburdened, throughput cannot be predicted, opportunities for defects (Muda) to enter or propagate through the system are increased.
Overburden has more than the introduction of errors. There are other losses rather than the system or individual overload. Too much load also causes task saturation1:
is defined as the perception or the reality of having too much to do and not having enough time, tools or resources to get them accomplished. In order to stay productive, you must figure out what’s most important, stay focused on what matters and create time to be creative.
When we work to ensure our team, members are working close to the edge, booking all the available hours to projects for example, we are doing much more harm than good. Knowledge work or the variability of the work, requires excess capacity in the system. The closer we attempt to schedule the work to fill the available hours, the worse we will make the throughput, much like traffic systems. A quick look of this can be found in the Harvard Business Review, Six Myths of Product Development2. If you are a more hard-core reader of this type of material, consult Factory Physics3.
Directed systems attempt to predict – or are predicated on the ability to predict, the durations and outcomes of tasks and effort. For some organization and some types of work, this level of prediction is possible or required. Other times the project and organization are not able to work from a script that is analogous to conventional project management approaches. We (Rick Edwards and others) have the belief that both the conventional and lean approaches can be merged, taking the best of both worlds that improves both throughput and success rate while improving morale of the team. We will write more on this in later posts.