The Systems Engineering Mindset, Problem Solving and Critical Thinking

By James Lackey

For people who know me, I would suspect one common observance is that I tend to look at issues in the context of a systems engineering mindset.  Before this article title turns off those who are not engineers by background, please bear with me for a second and read onward.

What do I mean about having a “systems engineering mindset”? -- At the most fundamental level, it’s about taking an issue, assignment, task, and/or challenge and breaking it down systematically to produce a workable result.  In basic form, systems engineering is a process where one takes top level requirements, determines how they are defined in lower levels of detail, functionally allocate them, and derive a detailed design.  The next stage of the process is where one ensures a design works by verifying and validating it operates in accordance to requirements from which it was originally founded upon.  Throughout this entire process, use of metrics, risk analysis, configuration management, and trades helps bound the activity effort to produce an optimal end product solution.

Ok; so what, you’re not a Systems Engineer – how does this relate to you?  - My “food for thought proposal” is that we all really use basic components of the systems engineering mindset in our daily routines without actually realizing it.  For broad workforce consideration, it’s more of a systematic approach philosophy than engineering discipline.  At even a larger level, it’s a critical thinking activity that can be applied to both technical and non-technical things in everyday life. 

Ok…Why does this matter? - Because the more we can refine our critical thinking skills, the more we either directly or indirectly apply the systems engineering mindset, the better off we are in terms of problem solving and producing optimal products and services for our Customers.

Take any issue, assignment, task and/or challenge.  Understanding what is driving it and what is the expected outcome is your top level requirement.  Addressing the problem-set from a functional perspective (break it down by components - what makes it up for what reason) and ultimately synthesizing a lower level “detailed design” (aka – solution) is the basic process at-hand.  Understanding the solution implications, Stakeholders, inter-relationships and second order effects in realizing the solution is fundamentally risk analysis and either direct or indirect use of metrics and trades to compliment the overall process.  Tracking potential versions of the solution from initial to final “design” is configuration management.  Taking the solution, either testing, piloting, or outright applying it and gaining feedback on what worked and what didn’t and why – is verification and validation of the originating top level set of requirements.

That’s having a systems engineering mindset; use of systematic problem solving and critical thinking.  You don’t have to be an engineer to do this.  Taking things systematically and logically in due process are skills we should continually refine upon to help us deftly maneuver through the complex world known as Defense Systems Lifecycle Acquisition.  We already do an excellent job here.  However the more we refine, the better we collectively perform and thus the even more increased excellence we provide our Customers and War-fighters.