Operational Analysis – A Thought Framework

One of the key tenets of Systems Engineering or Systemic Thinking is developing an understanding of how the system (or a product under development) is going to operate or behave under various scenarios. This leads to identification of the right set of functions, acceptance criteria’s, operational modes of the systems and constraints from the operational environment if any. These discoveries are then formulated in textual form as requirements. This skill of identifying the right dependencies, with operational environment, both which can be both spatial or temporal in nature often come by timeover a period of time, by living and breathing in the system domain. For example, an aerospace engineer who has been practicing the domain for decades might be an expert in the aerospace engineering, but if he/she is tasked to work in a medical device, it might be very difficult for them to even comprehend where to start! Another example to consider is that operational environments also change with time or with additional applications.

Apart from having the right domain expertise, frameworks can come handy. Frameworks or patterns are tools that allow one to think systematically and come up with all possible questions to be asked. Frameworks can act like a to do list. One of the frameworks we learned came across from MIT is “Get ready”, “Set” and Go. This is a simple phrase used in at the start of a race to synchronize timing, to command all the participants to start at the same time. However, it can be applied to a much larger context, and to almost anything really!

table 1

The figures above is a nXm matrix to capture all actions that are done to achieve a mission. It describes the overall lifecycle of the operation phase. Let’s take an example to better understand the framework. 


The table above is a ConOps for driving a vehicle to work or some destination. The whole lifecycle of operation can be further broken down by using the Ger Get Ready, set and go framework. It is important to note the difference between Getting Ready and Getting Set. The function of “getting set” part is executed just moments before the function “go” part. For Example herein the above mentioned scenario, before the driver starts driving the vehicle, he/she would enter the vehicle, get seated, put the seat belt on, turn the ignition on, and may be set the music and air conditioning.

The getting unset and unready functions concludes the operation. Once the whole operation is understood, it in is now easy to come up with establish required functions, identify stakeholders, identify risks, and come up with define associated requirements.



Each step in ConOps can further lead to identification of associated risks, which can then be used for Risk mitigation planning. The below table shows example of Get Ready phase where the identified risks are shown marked in purple colour purple. 


As can be seen with the example shared above, the ConOps is a pretty powerful tool to analyse a System of Interest and develop requirements for the further developing development and design ofing the system. 

If you are interested in understanding how to apply this within your organization, reach out to us at info@Blue-Kei.com. We specialize in systems engineering consulting, project executions, process adoptions, digital transformations and conducting workshops which are experiential and tailored to your needs. With systems engineering adoption you can address the complexity, manage evolving risks and bring transformation in communication within your organization through digitalization.