Applying The Systems Engineering Process to Small and Medium Sized Businesses
Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems.
It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design and validation, all while considering the complete problem. The Systems Engineering Process (SEP) is the application of this discipline; a comprehensive, iterative, and recursive problem solving process that transforms the problem statement into needs and requirements, then on to a set of system product and process descriptions, and then developed and tested systems. The process is scalable, iterating into additional levels of detail and definition as needed, with corresponding levels of development and tests.
The Systems Engineering Process came out of lessons learned from World War II where industries were rapidly developing complex systems, such as aircraft, ships, radar, and the atom bomb. It can be applied to anything, from producing ice cream to developing a civil jetliner. I use the Systems Engineering Process to help small and medium sized businesses improve their operations, enabling accelerated growth and the transition into scalability. The Systems Engineering Process is best shown visually, in the form of a “V” — the Systems Engineering V.
What is the Systems Engineering V?
The Systems Engineering V is a graphical representation of a system’s development lifecycle. It summarizes the main steps to be taken, in conjunction with the corresponding deliverables, in executing the Systems Engineering Process. It describes the activities to be performed and the results that have to be produced during product (system) development. While the “V” exists in multiple forms and with varying levels of detail, the one I most prefer was published by the United States Federal Highway Administration in 2005, which can be seen below.
Moving down through the left side of the “V” identifies the problem and defines the system that resolves it. It starts with determining the concept of operations (CONOPS): What problems are you trying to solve with the operation of this system? What is the system supposed to do? Who is going to be operating it? How is it going to be operated? Why is it being operated? What benefits do you see it offering up in its full operation? Keeping in mind that a system is hardware, software, people, and processes, it pays off to address all four of these aspects and how they interplay.
Next you define your requirements. Specification requirements (SRs) are factual statements about what the system is to do (functions) and how “fast” (performance). Verification requirements (VRs) state the means to be used to ensure that the SR is met. This is also when you develop the architecture; think of it as a picture of the system, outlining the hardware, software, people, and processes, and the role (function) each one plays. As SRs are allocated to functions, one will know what each component of the architecture is supposed to do, and how “fast”. Part of the “to do” is communications between components/functions; there are SRs that capture these communications, primarily as interfaces between architecture components. The architecture and requirements are built simultaneously, ensuring that the architecture is in alignment with the requirements, and vice versa.
The left side of the “V” is where you also do prototyping. Prototyping is a risk mitigator (Technical feasibility? Affordability? Achievability?) and helps to validate the CONOPS, aspects of the architecture, and is an input to requirements development.
Based on your requirements and architecture, which are founded on your CONOPS, you move on to a detailed design. Software coders start developing software, hardware is manufactured and/or purchased, processes are written, training materials are developed, plans for integration, test, and deployment are written, and more. The various speciality engineering teams are designing and building components, subsystems, interfaces, and the system itself.
At the bottom of the V, you move on to the implementation stage. This is when you take your design, which has been created per the requirements and architecture to fulfill your CONOPS, and which you then built at the component, subsystem, and system levels, and integrate it. For the first time, hardware, software, people, and processes come together. You now have a system!
Moving up the right side of the “V” you enter integrated test and verification. This step is vital as this is the first time the system exists as a whole and can be tested as a whole. You will find aspects that need to be fixed, adjusted, tweaked, and so on. The components of the design can be collectively subject to verification; are the components meeting requirements as they operate in an integrated manner? Are functions performing to specification, at the specified performance level?
Following that, you come to verification and validation at the system level. Validation is “are we building the right system?” Verification is “are we building the system right?” The distinction between the two terms is largely due to the role of CONOPS and requirements; validation is the process of checking whether the system meets the customer’s needs as captured in the CONOPS while verification is the process of checking that the system meets requirements.
As you advance through verification and validation the point will be reached where you can start fielding the system. You now have to support it, provide maintenance updates, and so on. Once stabilized in the field and receiving feedback from the user base, you can start investigating CONOPS refinements and requirements revisions, iterating the SEP to further refine and improve the system, to the benefit of your business. This happens continuously until you eventually retire the system.
How do you make it work for small and medium sized businesses?
This methodology applied to normal industrial practices generally does not provide a solution until you get to the end. For small businesses, especially in today’s world, this is not efficient. The solution is to iterate the SEP, a step-wise approach, to incrementally make available an increasingly larger solution to the problem. The SEP is iterated, starting with a solid CONOPS and initial requirement set, taking on “low hanging fruit” (easy to achieve enhancements) within the existing business infrastructure. You move onto minimal viable product (MVP — https://en.wikipedia.org/wiki/Minimum_viable_product), and then iterations on the MVP to fill out the system functions. There can be interim steps as well, such as adapting existing cloud computing services/applications as a prelude to moving to an MVP. Essentially, instead of doing one big V, you do numerous little Vs, each incrementally layering on a functional solution set that addresses a percentage of the problem identified in the CONOPS. Each iteration is guided by the CONOPS, the system architecture, and the requirements; these need to be well defined up front, but can, and should, be refined from lessons, experience, and user feedback gained in each iteration.
For a large government project, which are typically very complex and valued at billions of dollars, the “Big V” SEP can take upwards of 15 years. However a small business first implementing the SEP, achieving an MVP is typically 9 to 12 months, with the following “refinement” Vs taking anywhere from one to three months. The length of any particular iteration depends on complexity, volume and scope of feedback from the prior iteration (which can change CONOPS, architecture, and requirements), and availability of funds and resources. If the business is only updating their business practices and procedures (typically “low hanging fruit”), an iteration could be completed in 4 to 6 weeks. On the other hand, if the solution space is technological and fairly detailed, with integration and verification testing, an iteration is measured in months.
Have you used this method before for small or medium sized businesses? Having now read about it, do you plan to? Leave your thoughts in the comments!
