This is the third part of our series on Lean product development, Lean project management and visual work management and visual management boards for hardware teams.
In this post we discuss Visual Work Management’s and visual work management board'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.
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.
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 visual management 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.
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).
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.
Figure 4: Generic Kanban Board
Most digital VWM tools available today use Generic Kanban and/or Process-specific Kanban formats.
Why don't these visual management boards 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 visual management boards 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 visual work management systems such as PLAYBOOK, which are purpose built for hardware development, increase the effectiveness of visual work management 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.
Want to learn more about how PLAYBOOK can help your team get to market faster? Watch the demonstration video.
The series is broken into 10 parts that cover the following topics.
- Part 1: What is Lean Agile project management?
- Part 2: What is the ROI for investment in Lean project management methods and principles
- Part 3: Visual Work Management’s role in Lean project management
- Part 4: Lean project management principles and methods
- Part 5: Resource overload and variability on product development systems
- Part 6: Pull vs. push in a development system
- Part 7: Multitasking and the value of effective pull systems and having clear, common, and correct priorities
- Part 8: Replacing individual task buffers with shared team buffers
- Part 9: Decentralized project planning and execution
- Part 10: Daily standup meetings for fast feedback and execution