Have you ever tried to explain what quality is? Let’s say you know perfectly well how to develop a quality product, but your arguments are undermined all the time by fragmented details. Time and again you have to step back to sort out the details, in order to make a renewed attack.
But somewhere along the debate you get stuck. The details never get sorted out. There are too many of them, and you don’t share their definitions. After an hour or two you give up, and you revert to the old way of working, although you know you could do so much better.
Now there is a solution to your frustration. The complex product development model explains all details and puts them together into a holistic and consistent lodestar for all engineers, managers, and teachers dealing with development of products containing a mix of mechanics, electronics, and programs.
This model is an update of best practices from the most applicable development models in the world, scrutinized through a lifetime of product development experience in local, regional, and international product development companies.
This book explains Cpdm principles in-depth, with numerous real examples. Difficulties and complexities are illustrated by a wealth of drawings, figures, and tables. You can go back and forth to understand every aspect.
Over a product’s life cycle, development cost is seldom significant. Development time is sometimes important, but most often the crucial shortage lies in quality, capability, and predictability.
The Cpdm toolbox is available—use it to win your debates and start to improve this industry forever.
The Author’s Comments About the Book
If you have an honest chat with senior developers, they admit the book on Cpdm is very uncomplicated.
The book tells the developers to first start with capturing requirements and plan staffing.
After that, the developer should propose solution alternatives, including appropriate samples from suppliers.
Then the developers have to make an architecture of all chosen solutions.
First now, the development of all details can be done and finalized.
The developers then integrate their part into the surroundings developed by others.
Finally, the integrated parts must be verified against the once captured requirements.
If a product is large, you partition it hierarchal, and repeat above for each product level.
The complication occurs when applying these uncomplicated steps in reality.
There are managers not understanding enough, and there are gurus not accepting things to be simple.
Time constraints often skip the first steps, and detail development rushes off without common understanding.
Most developers know how things used to turn out in reality, and results in failure and unfriendly products.
The Cpdm book contains all the simple steps above.
But the big difference is, the book also shows all nitty-gritty details, preventing any unintended (or intended) misunderstandings.
Use the Cpdm book to apply uncomplicated and straightforward steps, preventing messy product development.
During a professional lifetime in product development, I have, of course, had a lot of knowledgeable contacts. It is not humanly possible to enumerate them all here, but some of them have been essential when navigating the crossroads and making decisions for life. The important influences below must be acclaimed.
This was my grandfather, acting as my second father. He had a small carpentry in Åsafors in the countryside in Småland, where I spent all my free time up to six years of age, and much time during later school holidays. I was the chief designer and he was my carpenter and butler. We built small machines for everything needed in my life, such as a machine for playing with cats, for spanking my little brother, for automatically passing nails when hammering, and so forth. He was old already at that time and is no longer alive.
Kjell is an engineer married to one of my father’s sisters. Every time I met him at family reunions, I jumped up on his knee and discussed engineering until he got tired and almost apathetic. He was more formally educated than my grandfather, so I could discuss even some electronics with him.
We met in the Värnamo Gymnasium School. He was an amateur radio operator and constructed his own colossal radio transmitters. I was impressed and started to construct colossal audio amplifiers. At that time all our constructions contained radio tubes, which were fatal for a fumbling teenager, but we obviously had guardian angels. Per-Olof now has his own successful company, helping with EMC (electromagnetic compatibility) problems.
Bertil Lindberg and other student friends.
At the Chalmers University of Technology in Gothenburg, we were a group of students from the surroundings of the city of Värnamo, who among others constructed electronics. Bertil was always my helpful genius, and we attended many classes and took many labs together.
This was a unique bohemian and autodidact from Skillingaryd, the small village where I grew up. He was a radio and television repairman and served customers from the whole Småland province. During my summer vacations, I practiced in his company, and we traveled around and repaired truck communication equipment. Later he became a close friend to me. Unfortunately, he smoked a lot and died of lung cancer.
Erik Dahlbergs Gymnasium colleagues
For a couple of years in the early eighties I was a teacher in electric power and control engineering, and met truly brainy people at this school. I developed an enjoyable intellectual relationship with the crazy and egocentric adventurer Ludvig Bergström , and I worked on a silicon custom design education with the ultradynamic and friendly Anders Lindberg.
I met Gunnel during her education in program development at the University in Lund. Apart from sorting out a lot of technical problems together, we fell in love and married, and we now have a sweet family together with our sons Sebastian and Jonathan.
Axis Communication colleagues
I worked at Axis during their startup period in the late eighties, when there were only three development groups. The genius Per Zander worked in the same group as I, and was shockingly skilled in constructing computer boards for complex printers. The Axis manager, Mikael Karlsson , was talented and incredibly promising, but sadly got a fatal cancer some years after I had left Axis. The director for new products, Martin Gren , was a spontaneous genius, which is quite the reverse of my own inclination, and despite our problems in communication, we always aimed to respect each other. At Axis I also met the technician entrepreneur Bernt Böhmer , and together we collected wines of unreal quality, and we still meet for super dinners with special wines and technical discussions.
A dynamic Norwegian Geir Fagerhus set up this consultant company during the economically harsh times in Sweden in the nineties. He succeeded in finding dozens of extraordinarily dynamic and skillful people, such as Henrik Cosmo and Anders Gustavsson , to mention two of them. Q-Labs collaborated with many universities and several international product-developing corporations, and used the Capability Maturity Model (CMM) of Bill Curtis at SEI, and the Cleanroom methodology by Harlan Mills in Florida.
Sony Ericsson colleagues
I have been in various positions at Ericsson and Sony Ericsson for more than a dozen years. I began as a mobile phone technical manager under the highly talented Jan Svensson , who afterwards had a long, successful career ending at the absolute top of the development departments of both Ericsson and Sony Ericsson. After some years, I shifted to operational development and together with Mats Pettersson , another talented manager, got the yearly award from the hands of the president, Miles Flint. A great deal of this success was attributable to Jan Sjunnesson , who was the knowledgeable consultant mentor during this period. During my operational development work I met many technical geniuses, such as Even Andre Karlsson and Magnus Augustinsson, to mention some. My ever present social mentor was Per Göran Ohlsson.
Cooperation with the academic world
At many of the companies where I have worked, there was a tight connection with the technical universities. I got to know professor Claes Wohlin during the Q-Labs era; I came in contact with professor Boris Magnusson during Java development at Sony Ericsson; and as operational developer in verification methodology I cooperated with professor Per Runesson.
This is my brother, who has a degree in civil and environmental engineering from Chalmers University of Technology. He is a full-fledged entrepreneur, and is the successful managing director of our large family transportation corporation. He has been indispensable during our Hungary wine production adventure.
I met this microbiologist in Badacsony in Hungary while setting up our own winery, called Villa Sandahl. He established his own oenology consulting company to assist us, and we have developed some of the best white dry wines produced in Hungary. He is a living lexicon and has answers to almost anything one may want to know. He is now replaced with the worthy successor Palkó Zsolt. We also had invaluable help from wine producer Fabien Stirn in Alsace.
In all development fields, large numbers of products are still being created which fail to satisfy end users. In some newer fields, such as programming, trouble looks to be the standard. For example, the editor I use to write this book has crashed over 200 times and caused me several weeks of extra work. And note, there is no conspiracy behind this — no supplier likes to disappoint an end user. So what is the problem?
Digging deeper into the development topic in order to find the root cause of why products fail to satisfy end users, reveals the most common reason to be an exploding number of technical possibilities, which in turn causes competency and growth problems when organizing development of such products, which in turn causes that this increased complexity of the product is not being enough understood and thereby has not product development process been enough managed.
There might be airplane crashes and medicines with severe side effects, but to travel by air or follow a doctor’s prescription is generally very safe. In these cases, the high complexity of developing aircraft or medicine is undoubtedly handled with success. Obviously, in these fields, the mastering of complexity has worked out very well, even if not totally free from disasters. One can object that a lot of money is behind the mastery of that complexity, but nevertheless, this complexity is, in fact, handled with success.
What can clearly be seen is that product development might often be very messy, and many of you are in the middle of this mess. If so, you have to back out of the mess, and get a chance to recover. I have been in the same mess, and have also seen a lot of development failures. Don’t copy them all; let me instead help you out, and save your time from a further mess. Start learning Cpdm and persuade your surroundings to use it. It is as simple as that!