Shipulski On Design

I had the best teachers.  They taught me to assess the situation as it is before trying to improve it.  Early in my career, my leaders did not understand the importance of spending the time to define the current state.  Hurry up and fix it!  Why are you spending time analyzing the existing product? Why do you want to create a functional analysis of the product we want to obsolete?  Why do you want to understand why customers purchased our legacy products?

By assessing the system/products as they are, I learned how to identify the elements to reuse, to improve, and to reinvent.  This has been a great way to focus the resources on the most important elements and increase the intensity the allocated resources.  When you don’t spend time on the 50% of the system that can be reused, you double the resource intensity over a complete redesign.

So, I ask you – how do you decide what can be reused, what must be improved, and what must be reinvented?

Regardless of the system’s size or scope of the project, assessing the current state is the right first step.  For example, there is great interest in improving the business model.  First question (that no one can answer) – What is our business model?  There are tools to define business models visually to show the partners, competitors, customers, data flow, money flow, product flow.  The tools show who does what to whom and how, who helps whom and how, and what’s missing.  One of the tools I like is Wardley Maps.  While Simon (Wardley) doesn’t talk much about mapping business models, I’ve misused his maps for business model mapping.

A rule for business models:  If you can’t describe your business model visually on one page, you don’t know what your business model is and you can’t improve it.

And assessing the current state is effective at the leaf-level (the lowest level).  Mapping the system functionally (functional decomposition with Axiomatic Design) and defining a problem rigorously (TRIZ), allows the team to place the problem in the context of the whole system AND to define the problem at the smallest level possible (think telescope to microscope).

A rule for problems – There’s nothing worse than solving the wrong problem, so you better be sure you’re solving the right one.

A long time ago, I led a project that took the time to assess the baseline product (existing product) for cost, part count, and part type.  Using DFMA, ee knew where the parts were, and we designed them out and we knew where the cost was and we designed it out.  It took a “long time” to do that work, but we radically improved the profitability of the new product (7X improvement in profit per square foot of the factory).  We also did a full functional decomposition on the baseline product and learn that there was one subsystem that caused trouble with all the electronic systems and created problems for customers.  We hardened the design against that subsystem’s devilish energy.  And we created robustness tests where we tested the baseline product and demonstrated improved robustness on the new product. (We used TRIZ to solve the right problems.)  Those efforts reduced warranty cost per unit by 4X.

Rigorously assessing the current state (products, processes, systems, business models) seems too slow and a big waste of time.  It is my experience, though, that it’s faster and improves the outcomes of the new product development and improvement projects.

But don’t take my word for it.  Give it a try.  And if you need some help, let me know.

Image credit – Calsidyrose