Playbook_Logo.png
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:

Lean Agile Project Management (part 3): Visual work management

Eric Graves- 07/26/18 10:34 AM

This is the third part of our series on Lean product development, Lean project management and visual work management for hardware teams.

In this post 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.

The benefits of visual work management 

Consider this. If you were to survey the traditional manufacturing floor, how would you know where the system was breaking down? Sometimes there would be flashing lights indicating a fault in the system, but even if there weren't any, you could still tell which machine was having issues by the big pile of parts in front of it.

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

View the Guide

But when you look around development departments today and a team of knowledge workers, how can you tell where the problems are? Where is the task that is the most critical today? Where is the blockage which is delaying your project today? Where is the one that will delay your project tomorrow? These problems are hidden from view.

Visual work management was born to solve this problem of ‘invisibility’ of knowledge work. The purpose of Visual Work Management is to make knowledge work visible (just like the parts on the factory floor), so we can see it, react to changes better, and keep the project flowing quickly to completion.

Visual Work Management (VWM) is a solution which has primarily evolved in software development projects, although forms of it appear in Toyota’s "Obeya rooms," and many other forms have appeared in many other places. Its primary goal is to make the work in the product development system more visible so it can be better managed.

Visual work management in hardware development

Visual work management's early beginnings and subsequent evolution in software project management is significant as the typical versions of VWM are designed to support the unique properties of software development projects and systems, not hardware.

The result of the application of this type VWM to hardware projects is usually slightly faster projects as depicted by the lighter shade of orange in the top issue in Figure 1.

p3f1

Figure 1 – Impact of Typical Visual Work Management

With better VWM tools built specifically for hardware teams we can address a lot more problems and achieve much faster projects.

Typical project boards

The most common form of VWM consists of sticky notes (stickies) on a white board or similar. The primary formats include Wall Gantts, 'Generic' Kanban boards, and 'Process-specific' Kanban boards.

p3f2b

Figure 2: Wall Gantt

A Wall Gantt is characterized by dates or weeks in the columns, resources in the rows, and tasks of any kind on the stickies. A Process-specific Kanban has steps of a process as columns and the items going through the process on the stickies (e.g., a new software feature undergoing design, coding, unit testing, and integration steps).

p3f3

Figure 3: Process-specific Kanban Board

In the more advanced cases, there can be any number of different colors, lanes, columns, holding areas, resources, dots, icons, magnets, tag-along stickies, and other aspects that show different information under different conditions. For many reasons, these two formats are used relatively rarely among hardware teams.

More common among hardware teams today is a Generic Kanban board. In this format, tasks of any kind go through a very generic ‘process’ from the backlog to in-process, to done. Sometimes there are planning steps or various other high-level stages, when the process is standard enough for those other steps to be part of it regularly.

p3f4

Figure 4: Generic Kanban Board

Most digital VWM tools available today use Generic Kanban and/or Process-specific Kanban formats.

Why don't these formats work well for hardware teams?

If you have read our series on the many differences between Software and Hardware development and the applicability of Agile techniques to hardware projects, you know that we see several clear and largely unavoidable differences between hardware and software projects. We will expand the list of differences here to include more aspects which impact the best format and tools to use :

1. High variety of project and activity types
2. Number and complexity of dependencies between activities and tasks
3. Lead times and other forced ‘wait time’ within the processes
4. Limited modularity (high impact of change across the design)
5. Increased delay and total cost of the average change
6. Increased number of team members
7. Larger variety of skills and knowledge, more specialists
8. Completion date predictability is more profitable
9. Time required to support production, quality, and other activities

Although traditional VWM is usually better than nothing, there are many reasons why even the digital versions don't work very well for hardware project delivery. We will touch on these as we go through the remainder of this blog series, starting right now...

Why don’t process-specific Kanban boards work well in hardware development?

It’s best to use an example to highlight the issues of applying software development methods and tools to hardware development. Let’s start with applying a Process-specific Kanban board approach to hardware.

Resources in hardware teams typically have a lot of different types of projects to execute simultaneously including new product development, cost reductions, sustaining engineering issues, corrective/preventative actions (CAPAs), and process improvements to name a few. Within each of these, there is a high variety of sub-processes, from mitigating risks, to designing and testing parts, talking to suppliers, etc.

Even if we could put each of these into the form of items going through standard processes, it is a different process for each type of item which requires separate boards and makes the work across all of them much more difficult to see.

Also, the 'items' in these processes cannot usually be broken down and processed quickly enough to move them to the next step every couple/few days. To make matters worse, the wait time involved (e.g. procurement time) results in many resources having several in-process tasks at any one time. As a result, these boards lose the ability to show blockages well, keep daily priorities clear, reduce multi-tasking, and help keep the work flowing.

These are only a few of the many deficiencies of a process-specific Kanban format, but let's move on.

The Evolution of VWM to support hardware development

Before we developed PLAYBOOK, we tried each of these different formats of project boards to accelerate projects. Each form was beneficial in some ways and depending on the application, some more beneficial than others. However, each one had significant deficiencies because, simply put, hardware development project management is more complicated.

New VWM systems such as PLAYBOOK, which are purpose built for hardware development, increase the effectiveness of VWM in improving new product development systems— for hardware development projects. Everyone can clearly see the system at work, team members’ daily priorities, bottlenecks, overloads, multitasking, blockages, and queues. Product development teams can see when the system is overloaded with work, see the impact of delays and understand their costs, effectively evaluate and manage all types of risk, and much more.

Tools and process go hand-in-hand

Ultimately tools and process go hand-in-hand. You need the right tool for the job to support your process. Through the next several posts in this series, we will examine the key underlying principles which drive success in hardware projects, and how the various Visual Work Management tools available today do or don’t enable teams to leverage these principles.

As a quick introduction we will discuss:

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 management
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

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.

Stay tuned for part 4 where we look deeper into the visibility and manageability of resource queues 

Want to learn more about how PLAYBOOK can help your team get to market faster?  Watch the demonstration video.

Show me the video

The series is broken into 10 parts that cover the following topics.