Agile Process Design—Simple Methods to Launch Processes that Work
October 11, 2015
The Design Imperative
Lean Six Sigma has been around for a lot of years now — over twenty in fact. Total Quality Management or TQM has been around even longer. So you may have thought that every process problem would be fixed by now. Not quite. Four problems persist:
1) In spite of the ever‐growing army of Green Belts, Kaizen Leaders, and Black Belts who are busy executing process improvement (DMAIC) projects, the rate of new process problem creation appears to exceed the rate of process problem resolution. Like Tantalus in Greek Mythology, the "low hanging fruit" can never actually be reached. Or more accurately, the fruit grow back as fast as they are picked.
2) Finding and fixing problems is inherently wasteful. Operational Excellence programs track DMAIC projects with pride, and we think nothing of it…but what if they were saying "look at all the rework we've done!"? That's right: rework. If processes were designed to be capable in the first place, DMAIC projects wouldn't be necessary. But the projects are necessary, and the critical preventive upstream design work isn't happening. The rework factory is running flat out on three shifts!
3) Service processes can be very difficult to change, or pivot, as they often require training widely distributed groups of people. It's hard enough to get those people to do their original tasks properly, let alone change those tasks across an entire network. So it's critical to launch all new processes with pre‐validated tasks and procedures that are known to perform as intended. It's just too hard to change course quickly.
4) Product and process life spans are also shortening. If a product or process only lasts for a short time before it is replaced by something new, there's less time to spend improving it. If there's no time for improvement projects, then the design needs to be right when the process is launched. So there is an increasing premium on preventive action rather than corrective action.
It's apparent that the only way we'll ever make real progress on process quality is to design and launch new processes that perform as intended. That's going to require some new thinking about our design practices so that processes behave properly right from the start. That new thinking highlights the importance of building capable and reliable design methods. Process design has become a critical skill for every organization — but it's too often left to chance.
Designing the Design Process
Every day, everywhere, folks are busy designing new processes with not much more to work with than good intentions. Whether it's the workflow through their own email inbox, their internal department, or a critical new customer‐facing service, everyone is a process designer. And all too often, the design of those new processes is an ad hoc affair that yields substandard results.
We wouldn't pick someone who is not an accountant to handle all the SEC filings for a public company, or someone who is not an architect to design the new headquarters building; yet it seems we're comfortable allowing almost anyone to design a new critical customer‐facing service offering. With that approach, poor results should not be unexpected.
Over the last year, we've queried over 100 large organizations about their process design practices. The overwhelming majority of them do not have a systematic process design process. Those that DO employ systematic methods believe they enjoy much better results. Those who don't take a methodical approach to new process design report sub‐par results. The more ad hoc the design process is, the worse the results are. The data clearly support the assertion that it's worth the time and trouble to use a defined process for new process design.
Not surprisingly, the solution is to redesign the process that is used to design new processes — to turn process design on itself. Our approach is to incorporate all of the best design methods from across the landscape of design practice into one method that is powerful, practical, simple, and flexible: an approach we call Agile Process Design.
Agile Process Design
Agile Process Design (APD) borrows the most useful approaches from several related design disciplines, while discarding the baggage of overly complex tools. APD mashes up of the best of the best practices, like a perfect plate from a church potluck. Agile Process Design is not an esoteric, complex, engineering exercise, it's a practical method that requires only simple tools and common sense methods — a recipe with three main ingredients:
1) Design Thinking based on two critical design attitudes: respect for the Voice of the Customer (VOC) and a spirit of experimentation.
2) A Design Roadmap to guide activity in a systematic fashion using critical questions. We find the five‐phase DCDOV roadmap to be useful: Define ‐> Concept ‐> Design ‐> Optimize ‐> Validate. The road map provides a framework of systematic questions to guide critical thinking; it is not a checklist of tools, and it's also not a linear process — it's iterative.
3) Simple Analytical Tools to measure outputs, generate ideas, evaluate concepts, make choices, and implement changes. The core tool is virtual prototyping — process simulation to think, to create, to test, to refine, and to validate.
From Design Thinking, Agile Process Design incorporates a deep respect for the customer experience, manifested through customer insight and empathy, and accomplished through direct customer observation and participation. Secondly, APD borrows the philosophy of "Building to Think" — fashioning rough mock‐ups and prototypes to tease out latent customer requirements and fuel creative thought about possibilities that wouldn't have otherwise come to light.
From Design for Six Sigma, APD incorporates robust Voice‐of‐the‐Customer (VOC) Analysis, including customer segmentation and empathy‐driven understanding of customer requirements, both spoken and unspoken. APD employs practical methods to map the quality function, not getting bogged down in complex tools like QFD unless absolutely necessary. Design for Six Sigma also contributes the DCDOV roadmap of critical questions, a strong drive to understand and model the transfer function of any new process, also known as Y=f(X), and a simple risk management tool called Failure Mode & Effects Analysis (FMEA) that is a powerful error‐proofing technique.
From Lean Startup thinking, APD adopts the emphasis on speed to market, a spirit of experimentation, prototyping, select use of "minimum viable products" to garner early customer feedback, and an emphasis on fast iterative learning (the build ‐> Measure ‐> Learn cycle).
From Agile Software Development, APD emphasizes short timelines, collaborative cross‐functional teams, modular test‐driven development, multiple short cycles of building and testing, and adaptive planning.
MoreSteam's development of Agile Process Design adds virtual process prototyping as the primary engine to drive ideation, testing, revision, and optimization — the core iterative design cycle through the Concept, Design, and Optimize phases. By simulating prospective process designs using software, designers are able to explore a much wider design space and expose process designs to the impacts of input variation — things like spikes in demand, quality problems, resource constraints, or extreme processing times that cannot be evaluated by static models.
Future state process maps that are drawn on a wall can be useful to visualize a new design with less wasteful steps, but they just don't incorporate one of the most significant drivers of waste, which is variation. If you can't model variation, you can't predict performance, and if you can't predict performance, you can't launch a flawless process.
In classic Design for Six Sigma thinking, trial and error is viewed as wasteful rework. Design for Six Sigma sought to employ analytical methods to derive the one best answer in a more linear fashion. Agile Process Design takes a much different approach, where virtual prototyping and the trials and errors that come with it are embraced as a creativity exercise. If simulation is fast and simple, you can start with any crazy idea, then build, test, revise, and learn.
Once a prototype is built, new ideas emerge that wouldn't have come to light without expressing early ideas as something functional to experience. We could call it Experiential Design. Instead of a linear path to one best answer, APD evaluates many potential answers, more like a genetic algorithm, and embracing mutation rather than viewing it as waste.
The key to making virtual process simulation work is to employ easy‐to‐use simulation software. Whether discrete event simulation or a Monte Carlo simulation, it can't take days to build a model, and the exercise can't require experts to man the controls — simulation‐building must be accessible and simple. The universal experience with simulation software has been something like: "that's a great idea, but it's too complicated, so we don't do it." New tools like EngineRoom and Process Playground make it much simpler to build high fidelity dynamic models.
Once a model is built that accurately represents a planned reality, it becomes possible to use simulation software for stress testing — more trial and error to determine how input variation and design options will impact the output. Learning the transfer function and determining which levers to move in order to achieve a desired result provides more predictable performance when the new process is launched. And accurate prediction is the key to avoiding problems so they don't need to be fixed by a follow‐up improvement project. Ultimately, confirming high process capability prior to launch is the best way to avoid waste and delight customers. Agile Process Design is a practical method to realize that potential.
We're excited about this new approach, and we've been developing a blended learning model to build Agile Process Design capability. More on that soon.