Learning about systems

I was interested in the Educational Systems Theory, Analysis, Planning, and Evaluation course because, since I work with systems engineers at Link, I see education and training programs as systems. That is, they have a complexity of interfaces and changes often result in impacts to other elements of the system, or other systems. I find a systems approach to be a logical way to analyze, design, and develop training and this course topic seems to be extremely relevant to what I want to do as a doctoral student.

Our first three synchronous sessions have been interesting in that I’ve been exposed to alternate perspectives in systems. An example is how I approached my last blog assignment and how my own perspective changed as a consequence of our most recent synchronous class session. In the blog assignment we were asked to describe an educational or training system with which we are familiar. I have worked on a number during my 13 years with L3 Link, so I gave a generalized description, incorporating my observations about the systems engineering that takes place in typical training programs. However, as a result of my participation in the synchronous session which followed, I found myself thinking more about a specific training system and thinking about how each of my activities were planned and implemented according to a specific system plan. To be honest, I wanted to go back and edit my blog to include detail that I had not thought to include previously.

Currently I’m working as a project manager for our Gray Eagle training system program. Our efforts for the past two weeks have been focused on conducting test activities with our customer. These test activities included two types of tests: software evaluation testing and regression testing. The evaluation testing followed strict testing protocols in order to determine if software changes accomplished the stated, contractual performance goals. In other words, does the software have the required functionality. If there are errors discovered, they are documented in a discrepancy report. The discrepancy report (DR) is reviewed by a systems engineer to determine: 1) what specification requirement is the identified software component supposed to address, 2) does the DR fall within the scope of the contract, 3) what sub-system is affected by the DR, 4) what is the priority of the DR, and 5) which software engineer needs to be assigned.

The second kind of test is a regression test. This type of test is conducted on a subset of the existing software in order to determine if any of the unmodified system elements were adversely impacted by changes to other elements of the training system. This is critical because without regression testing, we may find out that our system updates broke other aspects of the training system, requiring additional time and resources to fix, leading to cost overruns and delays.

These tests are critical because all changes have the potential to affect the training system in a variety of ways, thus the complexity. A systems engineer generally has the overall vision of the entire system and is able to evaluate impacts of changes to each part of the system. I recognized the need to think about the training system in more detail as Dr. Warren was diagramming the systems related to the plumbing problems in his home. Perhaps I’m too used to thinking about systems in general terms. I think our synchronous meetings have begun to influence me to consider training systems in more detail.

I also appreciate that our synchronous discussions have focused on what might be “non-traditional” systems. The house plumbing example is a good one. I hadn’t considered the plumbing, the electronics, the municipal permitting process, etc. as systems, per se. Certainly I can see how they qualify, but I’m not used to thinking about them like that. In addition, I hadn’t thought about my own Ph.D. program as a system. I can see that there are a number of “systems” of my own that have an impact on my life and work.

Of course, as mentioned, I’m involved in the LTEC Ph.D. program. At this point I’m a student only. My involvement is fairly passive in that my role in the system is one of inputs. Ultimately I hope to expand my role to be more of a contributor in the system.

In addition to my role in the LTEC Ph.D. system, I’m also a senior instructional designer and a project manager at work. Both of these roles have functions in broader systems, including engineering systems, personnel systems, training systems, business development systems, and so forth. Again, I’m principally a passive actor in these systems; a tactical participant if you will. I don’t generally contribute beyond the work I’m expected to do to satisfy system requirements. One reason I’m involved in a Ph.D. program is to prepare myself to contribute on a more strategic level in one or more internal and customer-facing systems within my company.