Introduction
In the previous article (The Crucial Foundation: Why Business and Mission Analysis is Vital in Systems Engineering (Draft)), we discussed the importance of Business and Mission Analysis (BMA), primarily discussing the peril of no doing BMA. Before we dive into the “How, Who, When, What,” and other critical questions regarding BMA, I want to address a common misconception. Consider this article as a rant against how sometime the capabilities of systems engineers are miss-perceived.
Systems Engineering: Pandora’s Box of Paradoxes
All knowing systems engineer
A quick glance at the Systems Engineering Handbook might make you think that systems engineering covers everything related to systems (It really does but that’s not the point). The broad scope of systems engineering lead to the unrealistic expectation that systems engineers need to know everything. This misconception is often made worse by a lack of understanding from management, leading to the flawed idea: if systems engineering covers everything, then systems engineers must know everything.
Systems engineer, the bureaucrat
On the other extreme there is different problem: limiting SE for compliance. This problem is particularly noticeable when managers with a specific domain or business background fail to understand what systems engineering is all about. They might see it merely as a compliance task, making systems engineers responsible for documentation to meet certain standards. This narrow view diminishes the strategic value of systems engineering, reducing it to just a paperwork exercise instead of a collaborative and integrative discipline.
The reality: Systems Engineers Aren’t All-Knowing
The truth is, systems engineers are not, and should not be, expected to know everything. Let’s take BMA as an example. According to the SE Handbook, the purpose of BMA is to define the overall strategic problem or opportunity, understand the possible solutions, and figure out potential solution types. This involves knowing the market, users, and other factors to define problems or opportunities, solution features, and potential solutions. It also includes developing value propositions, business models, revenue streams, strategic decisions, and turning these into requirement specifications.
The Fallacy of Knowing Everything
Expecting a systems engineer to have deep business knowledge, interest, and the power to make big business decisions is unrealistic. This is where the role of a business analyst becomes crucial. Business analysts specialize in many of these areas, having the expertise needed to analyze complex business contexts. They play a vital role during BMA by providing crucial insights to decision-makers who use those insights to make important business decisions.
The solution
Understanding Systems Engineering’s Scope
BMA is just one process in the SE Handbook. Even within requirements processes, BMA is one of three key processes (Business and Mission Analysis, Stakeholders Needs and Requirements Analysis, and System Requirements Definition). Besides business analysis, requirements engineering is itself a specialization, evidenced by certifications like the CPRE. Beyond that, there are other specialized processes in systems engineering such as Architecture Definition, Design Definition, Verification and Validation all of which need specialized knowledge of the process and industry.
Embrace Collaboration
The answer lies in collaboration. Systems engineers must excel in bringing together various specialists to achieve complete solutions that are desirable, viable, and feasible. They must work closely with business analysts, decision-makers, and requirements specialists, among others. While these professionals may have limited systems engineering knowledge, their expertise is essential for specific processes.
Working Together in BMA
For BMA, systems engineers must gather inputs from business stakeholders (owners, decision-makers, analysts) and turn these into technical specifications. These specifications guide engineers in developing solutions that meet the user’s needs while ensuring business viability. At the same time, systems engineers must communicate technical insights from engineers to business stakeholders to make sure the solution is technically feasible. This does not mean that systems engineers should not know anything about business aspects. As a matter of practicality, it is obvious that we will pick up knowledge and skills if we work on BMA for a long time. Some of us might even become specialists in it. But my key argument is that we as humans have limits. We certainly cannot have deep knowledge of each and every systems engineering process (anyone who saying that is lying or just doing PR). The skill of collaboration, accepting limitations, and being okay with them is essential. My message for leaders and management is the same.
Key Takeaway
The takeaway from this discussion is clear: systems engineering is not about being all-knowing. It’s about being a collaborative leader who integrates diverse expertise to achieve the best outcomes. As we move forward in our exploration of BMA and other systems engineering processes, let this principle of collaboration guide our approach, ensuring that we create solutions that are not only compliant but also innovative and effective.
Disclaimer: Generative AI has been utilized for proofreading and linguistic refinement. I firmly believe that generative AI is a valuable tool that enhances efficiency.
Prafull Kasture 