When I think of development vs production I’m thinking of manufacturing specifically. These terms mean slightly different things in, say, software, where development is where you make the thing stable enough to run and production is where you run it.
On the other hand maybe that’s not so different after all. Development makes it run, production runs it.
But that’s all very obvious. I want to think about product development and production in more conceptual terms, thinking about how each area does what it does. And I want this to be a little abstract. So I’m going to talk about development and realization instead of “production”. (Just to prevent any confusion here, I’m using the term a little differently than the ISO 9001 spec does, where design, development, and production are all subsets of realization.)
First, product development and realization are two separate things. This isn’t obvious to some people. You know who these people are. I once heard a developer friend of mine years ago (he worked at a bank, which in kind of super-scary) describe his co-worker as a “cowboy”. The sort of person who doesn’t value (or worse, understand) the difference between development and production, who pushes changes from development to production with minimal or no check (or worse, develops in production).
This was software, but manufacturing has the same sort of thing. In a system like ISO 9001:2008 development and realization are considered two different domains, each with their own sets of paperwork, processes, work instructions, and potentially different management teams.
In a large company you might have development plants or skunkworks. This makes the separation super obvious. And obvious for a reason, you don’t just push development changed into a realization scenario where you can make 10 million widgets wrong.
In a small company the domains get a little muddier. This is why a conceptual framework is useful. The same people might be managing the development, producing prototypes, doing testing, as are managing the production lines, running the production lines, and doing inspections.
There might not be a clear reason to separate development from realization (at least at first), especially as a 1-person or few-person outfit. When you’re a small company, you’re probably not making 10 million widgets where development is a much smaller part of your overall cost structure. If you’re developing a lot of one-offs and specialty products, maybe most of your time can be taken up with development.
This is why a development/realization conceptual framework is important. It helps separate domains, and by doing so helps you to stop making the same mistakes over and over again.
First, product development and product realization have different inputs. An input, of course, is just something you dump into a process in order to do some work on it and get something out the other side. This can be materials, specification, people, processes, etc. (And usually realization has as one of its inputs the results od
They also have different causes and effects. Things that go wrong in development often are (but don’t have to be) very different from things that go wrong in realization.
Even more abstractly, they have different purposes. So let’s start there.
Realization exists to make a product, to bring it to market in a certain form. It might seem at first that development also exists to make a product (as prototype), but that’s not exactly true. Or, if you’re doing in that way, you’re potentially doing development wrong.
Development actually exists to make knowledge. Specifically, reusable knowledge.
Why would you develop, let’s say, “a tool that doesn’t vibrate while cutting Titanium”? That’s a narrow goal. It’s applicable to just one thing. A more abstract and useful expression of this development process would be “a type of geometry that doesn’t vibrate in a material with certain properties”.
Then you can take that knowledge and reuse it for different items of that class. I think of this as a sort of don’t repeat yourself (or DRY) for product development.
Instead of ending up with a tool, you end up with a set of criteria than can be applied to tool, plural. And instead of that knowledge accumulating in one person’s head, it accumulates as a set of specifications.
I’ve seen this so very many times. Someone says “My customer wants a tool that does x and y”, a single person does the development and realization process at the same time, no specification is written, the tool goes out, and the knowledge is nowhere to be found. This makes for a very valuable person but a useless procedure.
(This doesn’t even touch on the amount of waste generated by this kind of process conflation; think of all the extra time spend developing the same tool again and again, reinventing the wheel, only to have the product returned because something went wrong somewhere in this crazy whirlpool of a development process. It might seem like time has been saved in the short term, but as with most things, it’s a long-term disaster.)
Different Causes and Effect
When you do development and realization at the same time, you risk conflating cause and effects, which are different in each domain.
Typically in development, causes of failures are related to development type things (experimentation going wrong as it always does, etc). Since you’re developing a specification and creating knowlege, you’re venturing into the unknown where unknown things can happen.
In realization, causes of failures are usually related to process type things. The processes should be nailed down enough that when something goes wrong (apart from the usual acts of God) you can track down where the process hasn’t been followed or where the process needs to be changed.
These causes and effect, when taken together, when development and realization are bundled, become exponentially more tricky. Suddenly your production causes and effects are no longer bounded by adherence to processes, instead you have to look at your processes and your development criteria, and so on. Suddenly your troubleshooting tree has way, way more branches. It can become so complex that you just can’t troubleshoot at all, and you just ship and pray.
I don’t think I need to say why guess & test plus ship & pray is a terrible, terrible idea.
My final thought is that development and realization have different inputs. In fact, one of the inputs of realization is a specification from development.
Development takes existing knowledge, engineering expertise, and customer specifications, and outputs a specification. This can be an prolonged period of prototyping and testing, but if you’re doing similar things quite often it can be simply spitting out a specification with small modifications. (Eg, my customer wants this thing that we already make, just with a different dimension or material.) In fact, with the proper ongoing research and development efforts, even a small company can radically shorten development engineering lead times with reusable knowledge.
Not only that, but reusable knowledge doesn’t have to be domain-specific. For instance if you’re improving one process, it’s quite possible you can reuse that improvement in many processes. The knowledge generated by development can be diffused across both development and realization. This is the kind of thing that can save serious cash by improving processes across the board and shortening lead times.
Realization on the other hand takes as one of its inputs (possibly one of many) the specification produced by development. With proper modularization it may even be possible to create a series of specifications that can be mixed and matched to achieve different results as required.
For instance where I work we could have a meta-specification that simply calls out other specifications and mixes in the customer’s special requirements.
Or if the customer needs something truly oddball, a new specification is created. (From my experience 90% of our custom work would easily be covered by a meta-specification.)
Just to wrap things up, this is why I see development and realization as two different domains. They accept different inputs, they produce different outputs, they have different causes and effects, and they exist for different purposes.
I hope I’ve done a decent job of explaining why I see conflating the two domains as a really dangerous idea.
That said, I think a lot of companies, especially small outfits, don’t see the immediate benefit of decoupling development from production. Maybe this is because of cost concerns (I need to make a whole new division!) or because of lead time concerns (I have to do two things in line instead of at once!).
The problem is the value proposition here is kind of hard to quantify. If you’re worried about those things you’re probably also not doing proper analytics on scrap rates, production breakdowns, customer satisfaction, nonconforming product returns, and all the other fun stuff that comes along with doing too many things at the same time.
And there’s no way to really make this sexy. This is sort of the least sexy possible domain. There’s nothing really clever, there’s no Suits-esque maneuvering here.
All I can say is that decoupling development from production is a proven long-term success story. It’s going to be one of the ways you make your company (at least, if that’s what you want) into an organization instead of a random collection of people and things those people do. It’s going to result in fewer lost man-hour trying to reinvent a process or specification (again). It’s going to cut down on the amount of lost time and money on returns, replacing faulty tooling, dealing with upset customers, and scrapping out nonperformant parts.
The greatest benefit, though, is something really intangible. It’s peace of mind. You’re not relying on one guy who just “knows” things. You’re not guessing and testing. You’re not shipping and praying.
I don’t know about you, but peace of mind if kind of a big deal for me.