Process Improvement – Systems Engineering Principles and Practices

Why Do We Need a Process?

What is it about the word process that makes some very creative and talented engineers, scientists, artists and others cringe? The fact is that even if you are not following a clear documented process, you are still following some sort of process, or steps, to achieve results. Webster defines a process as a natural progressively continuing operation or development marked by a series of gradual changes that succeed one another in a relatively fixed way and lead toward a particular result (Merriam-Webster). If there is already a set of steps in place that lead to results, what is the purpose in documenting and analyzing these steps may be the next logical question.

There are a number of reasons for why a process is needed and it is usually evident in some type of problem that needs to be addressed. Maybe steps are being bypassed unintentionally causing expensive defects. Perhaps there is a problem with predictability and scheduling resulting in missed milestones and delayed product availability. Maybe everything looks good but there is waste that could be eliminated in order to increase profitability. Sooner or later every system or product gets to a point where doing things on the fly becomes ineffective and causes problems for the company. For this reason, a number of industry standards have been established to address some of the issues mentioned. These standards are very helpful in giving structure and consistency to the systems engineering process (Massachusetts Institute of Technology). It is helpful to not get caught up on the systems engineering terminology and to realize that these process steps can be used in a variety of projects both technical and non-technical.

Using Systems Engineering Principles and Practices

Simply stated, a system is and integrated composite of people, products and processes that provide a capability to satisfy a stated need or objective (Systems Engineering Fundamentals). The process of managing a technical project starts with the process input(s) which feed into the standard systems engineering steps and result in the process output(s). The process inputs can come from any number of sources and include things such as requests, customer requirements, needs, objectives and corrective actions. All of these inputs must be captured and controlled using a formal change management system. (note: will be discussed in a future blog) Once the inputs are captured, the Project Manager and necessary stakeholders, will analyze them to define the basic scope for the project at hand. Humans are indeed an integral part of these systems as designers, operators, passengers and maintainers and the term “stakeholders” is used to identify people and organizations that have a stake in the system (Massachusetts Institute of Technology).

These processes have been defined for the engineering community but the same principles can be used in other areas of business as well. Regardless of the product, service or solution being offered, there will be certain steps that must be followed. There will most certainly still be a business case or operational concept that will define the requirements for the project. These processes have been tailored successfully for the development of numerous projects such as business proposals. With proposals, there is a need that is analyzed, addressed at a high-level (management plan), detailed at the lower levels (communications plan, marketing plan, etc.), integrated, assembled and delivered as a complete package (system). Good principles and practices can be tailored and adjusted for use in any number of environments.

Process “V” Model

There are a number of variations of the Systems Engineering “V” such as the MIT model in Figure 1. This is a very thorough and detailed standard systems design approach that is used regularly by engineers in practically every industry. For an engineering intensive project, such as an aircraft upgrade in the aerospace industry, this model makes sense and each of these phases would have its own individual steps and processes. Depending on the size of the project, there may be large teams and lead engineers for each of these phases. This is obviously a very expensive model to integrate and may be overkill for many projects at the small to medium sized business level. Government programs and certain commercial projects are required to follow standards as defined in the contract. Small businesses that focus on being quick to market and agility have some flexibility in the model that they chose for their projects.

Figure 1. The Systems Engineering “V” model.

(Image by MIT OpenCourseWare)

 

Waterfall – A Simpler Model?

A simpler model that can be tailored to projects of any size is what is typically referred to as a “waterfall” development cycle. As seen in Figure 2, the basic steps in this process are planning analysis/requirements definition, high-level systems design, low-level components design, systems development/implementation, integration verification/testing and installation, maintenance/support. Again, this process can be tailored for a specific project, but the basic structure ensures that a logical sequence of steps is used to transform an operational need into a complete system.

Figure 2 A Typical Waterfall Development Cycle

By looking at each of the steps in the process, the basic steps and reasons behind them can be understood.

 

Planning Analysis and Requirements Definition

The first step in this process is defined by the old adage Proper Planning Prevents Poor Performance. During this phase, the business case and operational concept is defined into the overall project scope. How the scope is defined is where the requirements come into the process. In order for a project to be successful, everyone must be aware of what it is they are trying to accomplish. The requirements are the specific who, what, where and when for the system. They are as detailed as necessary, are not ambiguous and must be verifiable.

High-Level Systems Design

            Once the scope of the project is established and the requirements are defined, the next step is to design the high-level system. The system may have any number of lower level components and they work together because of the system level design. I have worked on projects where this high-level design is in the form of a Process and Instrumentation Diagram (P&ID). From the P&ID, the mechanical, electrical, software, test and quality groups define their scope. Many times this is a simpler structure where there is a hardware and software component to the system. In this case, the system design defines the interconnecting functionality of the overall solution.

Low-Level Components Design

The next phase is where the design starts to take shape and the details of how the requirements are going to be met are addressed. The specific disciplines (hardware, software, etc.) design their parts of the puzzle that complete the system. Through a series of peer-reviews, these designs transform the system requirements into detailed HW/SW specifications. Many times, teams may be anxious to start work on development and bypass this step, but ultimately the project will suffer if the design phase is not complete.

Systems Development and Implementation

This is where the rubber meets the road and this is where the detailed design is transferred into the actual work products. The work products should be broken down and defined so that proper tracking of progress, risks, issues and problems can be addressed appropriately. It is a good idea for the Project Manager to establish interim milestones for this phase as this is a common area for schedule issues. There will be a tendency to extend this phase and make up for in reduced time for verification and testing. Despite the push to move the development phase to the right on the schedule, the Project Manager must be aware that reduced time for testing and verification increases risk for the overall project drastically. It is good practice to add some schedule reserve to plan for the expected delays in the development phase.

Integration Verification, Testing and Installation

This phase includes the complete system integration of the low-level components to produce the functional capability and the formal testing verification of the system against the requirements. If the project is planned out correctly, there is a Requirements Traceability Verification Matrix (RTVM) that maps the individual requirements to the specific test steps that will be used for validation. This avoids the unnecessary steps associated with testing functionality that may not even be part of the requirements. For proper testing, the steps must be completed from beginning to end with and all changes ultimately part of a regression test of the complete system.

Maintenance and Support

For some projects, this may be the largest and longest lasting phase of the project. Support contracts can last for years and this should be considered through the other phases of the project. The best-case scenario is where the maintenance team is a part of the design peer reviews. Sometimes very small design changes can reduce maintenance efforts significantly. I once worked on a project for the USMC where we were able to re-design a very complicated system for maintenance using the standard Marine field tool set so maintenance could be performed in the field by the users rather than making a costly, and possibly deadly, trip to the depot. It is critical that the maintenance and support team members have established plan for communication with the design team. Field problems may require the assistance of the design team and the future enhancements and corrective actions for the inputs of the next version of the system will most likely originate from the field in one way or another.

Conclusion

These processes are considered the ideal and are the basis for major large-scale projects. The Project Manager must decide the method of tailoring the process in the Project Plan for each particular effort. No process of Project Plan is a one-size-fits-all solution and it is critical to have team members that have experience with a number of variations to work with the subject matter experts for that particular product.

References

 Massachusetts Institute of Technology (2009) MIT OpenCourseWare Principles and Methods of Systems Engineering. Retrieved May 23, 2012 from: http://ocw.mit.edu

Meridian-Webster (2012) Process Definition. Retrieved May 23, 2012 from: http://www.merriam-webster.com

Systems Engineering Fundamentals (1999) Published by Defense Management College Press.