System Development: It’s a Circle, not a Line
“Doing Things Better” is part of the Lessons Learned series.
Ever wondered how you can create something? And after that, make it better? And after that, make that process the foundation of improving your business, advancing your career and even improving your life? It’s been given a name. We see it everyday, we benefit from it in almost everything we touch.
When I look back at my career and consider lessons learned, you would think the greatest lessons learned would revolve around the greatest disaster or the greatest achievement. Yet what came to mind first was something that I encountered almost every day. It is called system development. If that does not betray a boring, technical existence, I don’t know what does. Was I a real-world Dilbert? And if you are reading this far, you have exhibited a remarkable level of patience.
For the first decade of my professional life, I never employed the term “system development”. But once I read the literature I realized I had been doing system development most of my career. In fact, my first encounters with so-called “system development” were two manifestations of the Deming model. W. Edwards Deming introduced to Japanese manufacturers fourteen principles that would enable the Japanese to dominate several market sectors in the coming decades. My experience was the car I purchased: a 1978 Toyota Celica Coupe. The car was substantially of better quality than American cars. It ran smoother, was far more reliable, and had features that customers had been asking of American manufacturers for years. Even the Germans were getting outflanked as a friend asked if he could exchange cars for a day so he could listen to a cassette tape on his way to a meeting. He left me with his new Mercedes 450SL convertible! Go figure.
A second example was my stereo system. The Japanese once again totally swamped the American manufacturers for the same reasons: quality, affordable technology that people wanted. Unlike the car, however, the customer participated in the system development process. The customer could choose specific components, a sharp departure from the all-in-one packages that American manufacturers were prone to make. My father bought one of those classic American packages in the late 60’s, featuring speakers built into an attractive, long cabinet, with a turntable in the middle and a radio console on the side (see video below). As I experimented with sound, I realized there was more to this technology. The speakers could be better. The turntable needle could be enhanced. The tuner could be more powerful. But, alas, it was all or nothing. When I graduated from college I had the good fortune of working in a discount store in the electronics department. Before long I was assembling my own arrangement of audio technology, far more advanced than what had inhabited my father’s living room ten years before. What amazed me was the quality and, eventually, the durability. The receiver lasted for over 20 years. The turntable,cassette player and speakers lasted for over fifteen years.
We often see the system development model without knowing it is there. It is a process that moves from the original idea toward a thorough review of how it fits into the corporate mission. A team is formed and the design stage commences. A test product is presented, the bugs exposed, prior assumptions debunked and you go through the process again. Eventually, a final product emerges and it is implemented. If staying true to the concept, the final phase can circle around to any of the previous stages for product improvement.
System development is a cycle. In fact, it is really cycles within cycles. Like the Deming model, each phase of development interacts with the previous phase. Ultimately, when the final product rolls out, it is not the end but a new beginning. At that point the product is evaluated. Customer service is taken seriously and the information is used to cycle back and improve on the product and the methods of production.
The 80’s were a wild time to be in IT. I ran a consulting business and I spent many hours sitting with business managers charting out strategies for introducing the new and exciting technologies that were emerging. I witnessed first hand the transformation of tasks that took days down to only hours, hours to minutes. Yet I also saw the rough edges of a technology that was promising too much, of users expecting too much and a complex array of unexpected technical issues. I quickly realized that there were two types of managers. There were the ones who thought technology was something you bought off the shelf like you were grocery shopping. Then there were the ones who understood that technology had to be strategic, and its implementation well thought-out. It had to be developed.
I saw some real train wrecks as well. All of them were the result of not following a system development model. It was frequently reported how IT was actually doubling the work load of office staff, and I saw that first hand. It made no sense. Rollouts too often incurred production loss or even shutdowns. The classic case was when a network specialist said they were only going to do “one” thing the coming weekend: upgrade a switch. He listed four changes. I pointed out to him that he was changing four things. If something goes wrong, how will we know which of the changes is the cause? Well, after three weeks of intermittent crashes to a high-production network they discovered it was the backplane they had replaced. I witnessed a network card driver patch deployment that brought down an entire floor of a building. Those were fun times. Common in all the train wrecks was the total absence of a test stage and a failure to identify risk potential, both important elements of the system development cycle.
I would eventually migrate to Alaska and teach IT courses at the University of Alaska Southeast. One of the subjects I taught was Information Management. The text I was handed revolved around the system development model. This was my first formal use of the knowledge. My students were largely young adults who worked for the state and federal government. It all now made sense to me and I really enjoyed working with the students who dealt with real-world challenges. Most of the students were not IT geeks. They were managers, business owners and military officers. The system development model was a tool they could use to provide a framework for cost-effective, reliable advancements in technology.
I was hired by the US Forest Service and was introduced to a very large enterprise network. Over the years I was routinely working within the system development process. But what I observed consistently was that the model was implemented as a line, rather than a cycle. As a result, once a solution was rolled out, it was usually forgotten. The developers were assigned different projects. Managers focused on different objectives. As a performance analyst, I had to gather the evidence that some applications were in need of serious repair. Many of these issues were addressed, but in many cases it was apparent that no one was listening. The fundamental flaw was that management treated IT projects as a line with a period at the end of it. IT, intrinsically, will not treat you well if that is your view of the technology.
Not to say the “line” approach did not work. By and large, the IT professionals at the USFS did a pretty good job designing and implementing solutions. It was not the most perfect solution, but applications were rolled out with few interruptions. By the time an upgrade reached the production level, there were few surprises. Yet as a software developer in the private sector, I could attest that the major difference was that software development was a cycle in the private sector, a line in the government. It goes back to Dr. Deming. It was the difference between my Toyota and the Chevy Vega.
Closing Thoughts
My article above may imply that only foreigners understand the system development model. Nothing could be further from the truth. Folks like Henry Ford and Edgar Kaiser transformed the modern world by using system development. Today we have Elon Musk. And he is joined by thousands, if not millions, who work at doing things better in a systematic fashion. Almost everything we buy in the store is to a large degree the result of system development.
Resources
© Copyright 2025 to Eric Niewoehner