Following formal processes, versus expediency and innovation

Space system development is a complex and challenging endeavor that requires careful planning, coordination, and execution of a multitude of activities and tasks. It involves multiple stakeholders, disciplines, and technologies, as well as elevated levels of uncertainty, risk, and innovation. To ensure the success of such a program, or indeed the business executing such a program, it is essential to adopt formal business and engineering processes to guide and control the project from inception to completion.

But what are formal processes, and what are their benefits and drawbacks for space system development? Is it possible to have too much process? Can a process-controlled program still result in failure of one sort or another? In this post, we will explore these questions and more, and discuss how these processes can affect the cost, schedule, and efficiency of your space system development program, and could ultimately lead to both the success or the failure of a space system development program.

What are Formal Processes?

What I mean by formal processes is the self-defined set of rules, procedures, best practices, and methods that a company adopts to govern how a business is run, and how a system or a project is designed, developed, tested, and delivered to a customer. Formal processes will cover the entirety of business processes, including Human Resources, Finance and bookkeeping, Communications, and of course, the many aspects of engineering and project management. Engineering and project management process examples include requirements derivation and mapping, electrical/mechanical design, system architecting, coding, testing, verification, validation, integration, safety, risk management, budgeting, and definitions for program lifecycle milestones.

The bottom line of what I’m talking about here is the written procedures for how a business conducts its business. Many small companies will not have documented formal processes or even standard operating procedures for what should happen at regular intervals to be successful. These firms may have some of the most experienced and cutting-edge minds in their field, be hugely successful (given their size), and produce valuable products at many levels. But it is an axiom that the larger a business becomes, and the larger the projects that business goes after, the more documented processes the business will need to adopt simply to be a functional organization.

Why have formal processes, what are they good for?

For many individuals and companies, this is not a rhetorical question. This is not to say that someone wouldn’t want to write down how to do something, so that someone else, someday can do it instead of that person. That kind of action is simply documentation, recording of instructions on how to perform day-to-day activities, run a machine, or even assemble a product for sale. The kind of documented formal processes I am talking about are the kind that guide how to create something for the first time and do so in compliance with legal, industry, or even an entity’s own standards for how well something should be done. Example processes might include how to create a product test plan, how to design a mechanical part to withstand extremely high temperatures, and how to design an electrical circuit to operate in a high-radiation environment. But looked at in a more cynical way, these same example processes could be characterized as; how to be a test engineer, how to be a mechanical design engineer, how to be an electrical engineer combined with how to be a radiation engineer.

One point of view is that formal processes are intended to help one perform a job quickly and correctly, the first time, taking advantage of the lessons learned from people who have performed the same kind of job before. Tell me how to be successful, sooner, yeah! The opposite and unfortunately more common point of view is that formal processes are useless papers created by people who don’t know what they are doing to show me, an expert, how to do something that I am already very well educated and trained to do. Tell me how to do my job, stifling my creativity, boo!

I have personally gone through the full circle of positions on process and process control, and systems engineering generally for that matter. Early in my engineering career, I worked for companies that were startups or “rapid prototype” kind of businesses. Places where the business model tended to be proof of concept technical demonstration of a machine or instrument, accelerated detailed design of a custom product, and one-off or low-rate production of a finished product over a year or so. In other words, professional environments where cutting-edge technology and speedy delivery are prioritized over meticulous design or large-scale producibility. Over time, as the companies I worked for started going after larger and more complex projects, and highly regulated government programs (and I matured as an engineer), I began to see more value in documented test planning, configuration-controlled assembly instructions, and carefully derived requirements with validation. This level of formal process control was suitable for more complex and high-value projects where customers required verification of requirements, and interface documentation between systems and subsystems. Eventually, I began working on large systems development programs, with multiple associate contractors, multiple-year development schedules, complex and challenging concepts of operations, etc. The kind of program where the customer might have hundreds of millions of dollars at stake, and/or failure of the system in the field might cause serious harm to people or the environment. These are the types of programs where it is essential to have robust, repeatable, and verifiable processes and configuration control, that not only help to ensure that a company continues to design and deliver quality products, but also provide the customer and associates contractors confidence that your company can consistently deliver quality engineering.

The key thing to understand is that it is critical to use the level of formality of process control that is appropriate to the work being performed. A company won’t necessarily want or need formal processes if its focus is on designing one-off components, technical demonstrations, or proof of concept research and development. A company might desire and need formal processes if they are manufacturing a substantial amount of product, their products are intended to interface into larger complex systems, or the requirements and environments are so stringent that meticulous design and testing are required before delivery and use of the product in the field. You must implement the right amount and the right kind of process in proportion to the work being performed.

What are the Benefits of Formal Processes?

The benefits of having formal processes in short are repeatability, quality, efficiency, and verification. The benefits obtained from each of these categories can be summarized as follows:

• Consistency of work performed: Formal processes can help to define and document the scope, objectives, requirements, and deliverables for work performed within a company or project. Ensuring work is performed in the same way and to the same expectations, despite being performed by multiple people, across multiple programs. This helps workers and customers alike, not to feel like they are changing companies from one project to the next and builds the expectation of repeatable performance from one program to the next.
• Quality and reliability: Formal processes can help to ensure that the system or the project meets the desired standards of performance, functionality, safety, security, and usability. Formal processes can also help to identify, prevent, and resolve defects, errors, and failures, and to verify and validate the system or the project against the requirements and specifications.
• Productivity and efficiency: Formal processes can help to optimize the use of resources, time, and budget, and to eliminate waste, redundancy, and rework. Formal processes can also help to streamline and automate the workflow and to monitor and measure the progress and performance of the system or the project.
• Verification of Requirements: Inherent to the implementation of formal processes is the documentation of how the work was planned and performed, and the results from the completed process. In most cases, the process itself provides the results, and when reviewed by a third party (internal or external) will serve as verification that the requirements and necessary quality of that work were met.

What are the Drawbacks of Formal Processes?

Implementation of formal processes can also have some drawbacks, for example, rigidity, technical stagnation, and bureaucracy:

• Complexity and rigidity: Formal processes can add more complexity and rigidity to the system or the project and make it harder to adapt to the changing needs, expectations, and environment. Formal processes can also create more bureaucracy, documentation, and overhead, and slow down the decision-making and delivery process.
• Reduced creativity and innovation: Formal processes can limit the creativity and innovation of the project team and stakeholders, and discourage them from exploring innovative ideas, solutions, and opportunities. Formal processes can also constrain the flexibility and autonomy of the project team and stakeholders, and prevent them from applying their expertise, intuition, and judgment.
• Frustration with bureaucracy: Formal processes can cause resistance and frustration among the project team and stakeholders, especially if they are imposed without proper consultation, justification, or training. Formal processes can also seem to be (or might actually be) so burdensome and costly, that people won’t want to follow the process, see no value in the process, or might even not want to perform the work because the paperwork is such a hassle.

How do Formal Processes Affect Space Program Cost, Schedule, and Efficiency?

You might have noticed when reading the two summary sections above that I skipped over perhaps the most important of categories: money! Formal process control can drastically affect program cost and schedule, either positively or negatively. On one hand, having formal processes can speed up task completion, minimize rework, enhance the quality of work, and overall reduce project cost and delivery time. On the other hand, having formal processes can slow down task execution, mandate unnecessary work, negate built-in reliability, and overall increase project cost and delivery time. This is one of those curious dualities in mission assurance and project management, where one must strike the right balance of something to maximize its benefits and minimize its drawbacks.

Developing and implementing processes costs time and money, and following a process including the necessary documentation of the results, also costs time and money. What is necessary is a Return on Investment (ROI) analysis to inform leadership where expending a little time and money in the present might lead to big returns later.  For example, having a formal documented process for qualifying a component through Thermal Vacuum Testing (TVAC) might cost a modest amount of overhead dollars to develop, configuration control, and implement into the workforce through training and process control. It might also take longer and cost more to follow the process and document the result, than it might if a trained test engineer and technicians simply set up and performed the test in the same manner they have many times before. However, by following the process, one minimizes the risk that a step might be missed, reduces the training time of new personnel, meticulously repeats a previously verified qualification campaign, and verifies and validates performance to a customer’s requirements. If a step in the process is missed, the component or test equipment might be damaged, or the entire test might need to be performed again. And by having a documented test process, a customer might have more confidence in your design and test campaign, leading to reduced verification requirements and inspections, and follow-on business. Conversely, if a company invests the time and capital to establish a formal non-conformance control program, but never follows it or doesn’t perform work where formal anomaly control is required, then they may have invested a lot of money in an unnecessary system and process. Companies and customers should carefully consider their business model, program constraints, and goals when designing and implementing formal processes.

Space System Development Formal Processes

As mentioned earlier, formal processes will cover the gambit of business functions. Still, for this post, the processes and command media I will be referring to will be those that cover how a business executes its programs and conducts design, integration, and test activities for the development of a space-based capability. For space systems development programs, it is impractical to consider circumstances where there is little to no formal process control. The space environment and technical performance requirements are simply too complex and too costly to just “wing it” through a development and manufacturing program. But formal processes can be streamlined, or right-sized in a manner that best benefits the company and the customers they serve.

There are many, many process control areas involved in the design of space technology, and I won’t list them all here. But in summary, the process areas germane to space system mission assurance include:

• Systems Engineering
• Risk Management
• Hardware/Software Design, Quality and Test
• Systems/Launch/and Personnel Safety
• Reliability Engineering
• EEE Part Engineering
• Radiation Analysis and Survivability
• Space System Environmental Test
• Supplier Oversight and Management

Again, the intent of this post is not to delve into the purpose and function of these individual process areas. But I do want to explore how a company might create processes to cover these technical areas, and where that company might source the information that goes into the process.

Where do internal processes and command media come from?

Formal processes can be derived from a variety of sources, such as industry best practices, regulations, standards, frameworks, models, methodologies, or tools. Some examples of industry and government sources for formal processes for space system development are (where possible, links are to organization publication sources):

• The Aerospace Corporation: (Aerospace) An independent, nonprofit corporation operating the only FFRDC for the space enterprise, The Aerospace Corporation performs objective technical analyses and assessments for a variety of government, civil, and commercial customers.
• The National Aeronautics and Space Administration: (NASA) Consisting of 20 centers and facilities across the country – and the only National Laboratory in space – NASA is a United States government institution that studies the Earth, the Sun, our solar system, and beyond. NASA develops and funds space technologies that enable exploration and discovery for the benefit of life on Earth.
• American Institute of Aeronautics and Astronautics: (AIAA) A non-profit professional society that exists to help aerospace professionals and their organizations succeed by providing information and documentation that serves as the technical authority for aerospace design, manufacture, and testing.
• Institute for Electrical and Electronics Engineers: (IEEE) The world’s largest technical professional organization dedicated to advancing technology for the benefit of humanity, and is the trusted voice for engineering, computing, and technology information around the globe.

There are many, many more agencies and organizations that provide information and knowledge designed to help organizations succeed in both Space and Business. Often, these standards serve as formal requirements flowed from Customers to Contractors for the development of their systems.

However, fundamentally, internal command media and formal processes should come from just that; internally. This is to say that the business itself should be in the best position to document how it should best build its products and run its business.

With all these wonderful industry guidelines and standards, why would a business ever want its own processes?

Great question! And there is a quite easy answer. Simply go to one of the sites above (I suggest NASA as the other sites may have pay barriers), download one of the standards, and give it a read-through. Try NASA Technical Handbook NASA-HDBK-4009A, Space Telecommunications Radio System (STRS) Architecture Standard Rationale. What you will find is a very thorough technical standard intended to be flowed to contractors and other developing agencies, to provide guidance and requirements for the design, construction, selection, management, support, or operation of systems, products, processes, or services to be provided to NASA. Specifically in this instance, for reconfigurable communication transceiver developments for NASA Missions. Assuming your company is in the business of providing such systems, the two hundred-plus requirements statements (Shall, Should, etc.) found in this document, along with all the guidance information, may or may not apply to your specific product. Furthermore, your product may already exceed these requirements or consist of innovative technologies for which these requirements are not applicable. Additionally, a technically dense document such as this will be extremely laborious to follow and refer to throughout the design, build, and test phases of a program, not to mention providing verification and validation evidence for meeting the requirements of the document. In other words, following this government standard, rather than your proprietary ways of working and internal requirements, will cost excessive time and money, while contributing only minimally to mission success.

As stated previously, a business and its workforce should know best how to design and build their products. And leveraging a company’s own documentation and formal process, rather than having unfamiliar and perhaps unnecessary directions levied, will save time, and money, and provide a greater opportunity for mission success. Having such formal processes will in some cases preclude government and industry standards from being contractually flown, obviously another benefit to having formal processes. However, it must be noted that customers will usually require a formal mapping and tailoring exercise to approve such proprietary processes in place of the flown requirements. This is a topic for another day.

How to Balance the Benefits and Drawbacks of Formal Processes?

Formal processes are not a one-size-fits-all solution for space system development. Depending on the context, scope, and nature of the system or the project, some formal processes may be more suitable, effective, and beneficial than others. Therefore, it is important to balance the benefits and drawbacks of formal processes and to tailor them to the specific needs, goals, and constraints of the system or the project.

Some tips for balancing the benefits and drawbacks of formal processes are:

• Assess the value and feasibility of formal processes: Before adopting or applying any formal process, it is important to assess its value and feasibility for the system or the project. This can be done by evaluating the benefits, costs, risks, and challenges of the formal process, and comparing it with other alternatives or options.
• Involve and engage the project team and stakeholders: The success of any formal process depends largely on the involvement and engagement of the project team and stakeholders. Therefore, it is important to consult, communicate, and collaborate with them throughout the project, and to solicit their feedback, input, and support for the formal process.
• Adapt and customize the formal process: Formal processes are not meant to be rigid and fixed, but rather flexible and adaptable. Therefore, it is important to adapt and customize the formal process to the changing requirements, specifications, and conditions of the system or the project, and to incorporate the lessons learned and best practices from previous or similar projects.
• Monitor and evaluate the formal process: Formal processes are not meant to be static and final, but rather dynamic and iterative. Therefore, it is important to monitor and evaluate the formal process regularly, and to measure its impact and effectiveness on the system or the project. This can help to identify and implement the improvements, adjustments, and refinements needed for the formal process.

Conclusion

Formal processes are essential for space system development, as they can help to ensure the quality, reliability, productivity, and efficiency of the system or the project. Furthermore, having documented and approved formal processes may be a requirement simply to do business with many customers, particularly the Government. However, formal processes can also have some drawbacks, such as increasing the complexity of performed work, reducing the creativity of engineers, and causing workforce resistance due to added bureaucracy. Formal processes, while intended to drive the efficiency and reliability of a company’s work product, may all unnecessarily drive added cost and schedule. Therefore, it is important to balance the benefits and drawbacks of formal processes by performing a Return-on-Investment analysis and to tailor them to the specific needs, goals, and constraints of the system, project, and customer.