Monthly Archives: March 2013
Lean can be applied to the design any type of system, even a large system like a hospital.
Lean is a trend now in the design of space for architecture. Many architects are starting to apply lean manufacturing principles of waste reduction and flow to the internal processes inside of hospitals, but now lean is being applied to the design of the space itself.
Lean in design seeks to solve design problems by maximizing value and minimizing the drivers of waste.
As flow improves … excess space can be saved.
As wastes are removed … space becomes more efficient.
As the space becomes efficienct … space layout and footprint reductions can be achieved.
And with a reduction in footprint … more cost effective structures can be built.
In writing about one such project, Valerie Bauman of the Puget Sound Business Journal notes,
Much has been made about the “lean” approach to health care: efforts to eliminate waste and streamline day-to-day operations to make treatment cheaper, faster and better quality. Now architecture and design firms are finding ways to build environments that support maximum efficiency. That move has helped drive another trend in hospital architecture – lean design.” from bizjournals.com Hospital design follows “lean” trend for more efficiency, comfort March 4, 2013. Similarly, in the architectural interpretation of this movement, new designs are trying to reduce waste – whether it’s wasted steps, overcrowding, or otherwise – and improve the human experience.
According to ZGF Architects, the lean design of the Everett Clinic Smokey Point Medical Center contributes to a 24 percent reduction in non-patient care space yielding $2.1 million in savings and a 30 percent reduction in the number of exam rooms (from 82 to 62 right-sized rooms).
Lean seeks to eliminate wastes from the design from the start. The idea is to seek out the drivers of waste and remove them from the design.
In the Everett Clinic, variability is reduced because every operating room is standardized with the same layout, and complexity is removed by having the same equipment set-up for surgery in the same way in each operating room. These are just two of the seven techniques for designing out waste.
To drive out complexity architects can ask questions like:
- Are there parts of the space and process that are obviously overly complex?
- What parts of the space or process are hard to use for the nurses and doctors?
- Does my space have any unnecessary things in it?
- What do people complain about the most in existing spaces?
To drive out variability architects can ask questions like:
- Is the process in the space difficult to maintain and control?
- Can the space be improved to reduce variations?
- Can the space be standardized to reduce variation?
The other drivers of waste are precision, sensitivity, immaturity, danger, and skill intensive tasks.
Explore this blog to learn more of the techniques to apply lean to the design of solutions in architecture and space design. And please contact us if this has been helpful by leaving a comment to this blog.
The first goal of a lean design is to be directionally correct. Starting out in the right direction is the first priority. Teams should worry about the precision of hitting their target later.
This is in stark contrast to traditional software development methods in which teams are encouraged to gather all of the project requirements upfront. Often teams will spend weeks and months merely gathering system requirements. However, in lean development, the assumption is made that not all requirements can be known up front.
As the story goes, the IT developer went to the client and asked for all of their requirements. And the client said, show me what your system can do, and then I can give you my requirements.
Developers know intuitively that not all of the requirements for a system can be determined up front. While some gathering is needed, teams can often suffer from “analysis paralysis” if they spend too long at this phase.
Lean development seeks to be direction-ally correct in the beginning, and then worry about converging in on a solution later. A US Navy captain, Maurice Gauthier, put it this way, “Three successive pursuits of the 80 percent solution produce the 99.2 percent solution. However, pursuit of the 99 percent solution on the first attempt is a very poor investment of resources.”
The way to apply this to software development is to collect 80 percent of the requirements at the start, and then launch a series of rapid learning cycles. The end goal or target is set, or as Bart Huthwaite calls it, ‘the End-in-View” is determined upfront’. Then the team designs a series rapid learning cycles to learn, show feasibility, and to determine the course to take to hit the target. Taking the client, or future user, along with you on the journey is key. At the start of the learning cycle, tell the user what you expect to accomplish and what the team hopes to learn. Outline the questions that you hope to answer during the learning cycle. During the learning cycle and at the end, share your prototypes and your knowledge and ask for their reactions.
Every rapid learning cycle includes experiments and prototypes. In the IT system, this means that you are doing some type of rough prototype even in the earliest learning cycles. Showing the user the prototype might seem like a risk, but not if you tell them that ultimately it is an experiment that might even be thrown away later. At this stage the direction is set, but it has not been fine tuned. Then, listen to the user and let them help you inform the direction of the solution. In listening, additional requirements will be gathered and this will help to set the system in the correct direction. This is where you can gather the additional 20% of the requirements.
Each learning cycle should include some form of knowledge capture for the team for later reference. The metric sized A3 (11″ x 17″) sheet of paper, is the appropriate size to capture enough knowledge without over documenting. A lot of information can be recorded on one side of an A3sheet of paper. The A3 acts as a beacon marking where the team has been, and describes what has been learned.
I have seen this approach work with teams both large and small. It improves both the quality of the end solution, but it can also dramatically reduce the need for later user validation and testing because they were included in the early learning cycles. It is not agile development which assumes the requirements are set and the developer is merely writing code. This comes at the later stages of the project.
For a further description of rapid learning cycles, please refer to Innovative Lean Development. Thank you. And please send comments on how you have used learning cycles in your software development process.
Author: Katherine Radeka
Publication Date: 2013 CRC Press
Book Description: What’s the key message?
Katherine Radeka’s book is an exploration in the emerging field of Lean Product Development. Radeka notes that companies need to get their ideas to market faster, develop more of their ideas into products, and smoothly move them into production, with lower life-cycle costs.
The contents come from Radeka’s “going to the gemba” and observing actual lean product development at various companies. She started that journey in 2005, after leaving Hewlett Packard, and traveling throughout North America, and she continues to do this today as a consultant. Her recent journeys have extended throughout Europe.
Radeka characterizes development as “systematically solving problems to maximize values and minimize waste across the entire system.” This is, at its core, what the broader topic of lean design is all about. The original concept of the keeping problem solving back at the core of product development was taught by the University of Michigan professor Dr. Allen Ward. He called the problem solving method in development the LAMDA cycle; where LAMDA is a mnemonic for the steps in the problem solving method – Look, Ask, Model, Discuss, and Act. Dr. Ward also taught the benefits of documenting knowledge in the form of trade-off curves.
Radeka briefly explains how to determine value and spot wastes in the product development cycle. Then she teaches about the four value producing streams in development which are the customer value stream, the product design and test value stream, the production value stream, and the one the encompasses the other three – the knowledge creation value stream.
The remainder and bulk of the book describes how various companies have pioneered the principles of Lean Product Development. The companies include DJO, Scania Technical Centre, Ford Motor Company, Buckeye Technologies, Steelcase, Philips, Novo Nordisk, Visteon, A-dec, Nielsen-Kellerman, Vaisala, and Playworld Systems. Each of these companies has embraced the idea of placing lean problem solving and lean principles at the heart of the development systems.
What are the highlights? What works?
Radeka gives some excellent and current examples of companies who are applying lean in product development. The upfront material gives the reader a quick overview of the lean concepts that apply to development. The examples that follow are rich and detailed, and they will give the reader a closer look at how companies are exploring the application of lean principles inside of their product development functions.
What are the weaknesses? What’s missing?
Since the book is mostly case studies of implementations in lean development, it does not give the theory of lean design or an in-depth study of the concepts and principles of lean in development. Instead, Radeka’s intent is to share real-world examples of how lean concepts have been applied in companies all over the world. The reader will have to apply the ideas and examples in the book to their own development organization. Radeka does not go into depth on LAMDA learning cycles or the documentation of knowledge in the form of trade-off curves (per Ward) since those topics can be found in Allen Ward’s book Lean Product and Process Development and are explored by Schipper and Swets in Innovative LEAN Development. While she gives many examples, she does not critique them or comment on how effective they are in producing results at the companies.
How should I read this to get the most out of it?
The examples are very rich in detail, and there are many ideas to glean from these pages. Therefore, a great way to read this book is to share this with others in the development organization, and even to offer to make it a book study with the product development leadership and teams. The development organization can then collectively discuss how the best in class examples could be adopted or adapted to their own methods.
Lean Design Excellence Coach
Author of Innovative LEAN Development
Lean designers start with a review of the prior knowledge and proven ideas and end with documenting updates of that knowledge or new knowledge.
I have run a simple experiment which measured the effectiveness of knowledge sharing with groups simulating a develop environment. The simple experiment is an open-ended problem that requires problem solving to reach a solution. Knowledge sharing improves the outcome. After teams share ideas and knowledge, their success rate and quality improves by 100%.
A Knowledge A3 is simply knowledge captured on a single page of metric A3 paper (approximately 11 x 17 inches). They provide a vehicle to capture and communicate knowledge across the development organization. Reusable knowledge A3s written to capture knowledge take a certain amount of effort to create, but they are worth the effort!
These types of A3s are quite different from the A3s used by many Lean Manufacturing companies to manage a Kaizen used for tracking tasks to move from a current state to a future state. A Knowledge A3 is less about doing things, and all about documenting important knowledge and learning.
For knowledge and ideas to be reused and improve the development cycle for the next project, ideas and knowledge must be documented, but more importantly, they must be easily found and reused. The goal is to set up the knowledge pull within the organization. Therefore, the A3s must be put into a knowledge supermarket from which they can be pulled. (In this case, “pull” is defined as retrieving and reusing knowledge as it is needed or per the demand of the next project).
It is important to take the time to ensure that Knowledge A3 is truly generalized, that it is from a trusted source, and that it is accessible. These are three important characteristics of a well-functioning knowledge management system. Toyota did this for many years by creating the “Know-How” database. It was described in the book The Machine that Changed the World. It is one example of how a Lean company (Toyota in this case) approached their development process by focusing on knowledge. The “Know-How” database existed in paper form for decades before Toyota converted it to an electronic system. Toyota had kept knowledge on everything from door handles to transmissions. The “Know-How” database represented the knowledge, engineering guidelines, and checklists that guided the design process to ensured quality.
Your Knowledge A3s will be focused on your own products, systems, and sub-systems. The knowledge A3s work for IT systems and IT development just the same. Knowledge A3s might be about a particular set of user needs or use models. Alternately, the A3 might be about the architecture of the system itself, or about an important sub-system. The goal is to document the knowledge so it can be pulled and reused each time a similar system or sub-system is developed.
For entrepreneurs working at a new start up, knowledge reuse is even more important in these cases. Using prior knowledge to not reinvent the wheel for creating the business or the products certainly speeds up the time to market.
Lean design requires idea and knowledge sharing.
For Lean Development Excelence
Author of Innovative Lean Development.
The Huthwaite Innovation Institute’s Annual Mackinac Island summit is in its 20th year. The dates are August 13 through 15, 2013. This unique gathering brings together a select group of top executives for two and a half days of networking and work group sessions designed to foster the exchange of ideas and innovations covering the top obstacles implementing designs that are lean corporate wide. Executives will have the opportunity to further establish best practices for design through peer collaboration and executive education in a fun and relaxed environment.
At the end of the summit, you will know how to:
- Make innovation a sustainable management process, rather than a random event
- Integrate innovation into your existing continuous improvement initiatives
- Measure whether you are on the right track early enough to make course corrections
- Use innovation to find new market opportunities
- Apply innovation to improve your day-to-day business operations.
- Get all ‘stakeholders’ on board from Day One. . . and keep them on board
- Systematically go outside your corporate boundaries to discover new ideas
- Enable teams to innovate without creating chaos, delay, and low morale
Benefits of Attending:
Participation will enable the implementation of lean techniques for design within your organization. Participants will hear powerful “lessons learned” from other companies and will have the opportunity to share their successes and obstacles. We will discuss the greatest challenges implementing and lean system, and how companies are addressing those issues.