12 Integrating Modern Methods for Faster Systems Engineering

12.0 Introduction

In chapter 2 it was explained that the best model for system development is the “craftsman” model that was widely used before systems became so complex that a single chief engineer could no longer understand a system in sufficient detail to control all aspects of design. System engineers, design engineers and other specialty engineers became necessary to handle the complexity of modern systems. Although this new approach has enabled the development of very complex modern systems it takes much longer to develop a system now than it used to take when a chief engineer and his/her team could develop a new system in a few months.

One objective of this book is to introduce new methods that enable the systems engineering work on system development to be accomplished faster and more accurately. This book has an emphasis on systems engineering fundamentals, as described in the DoD SEF and the NASA SE handbook, and readers will note that it takes time and discipline to follow these fundamental processes. Complex systems cannot be developed cost effectively by shortcutting the systems engineering fundamentals; what is necessary is faster and more accurate methods for executing these fundamentals. Accuracy is required because any errors in systems documentation results in costly “find and fix” efforts later in design or in integration and test. Several methodologies for ensuring accuracy have been discussed including using graphical models in place of text as much as possible, employing redundant tools for developing documentation, using modeling and simulation to support requirements analysis as well as design and checking work at the three levels of worker checking his/her work, peer reviews and design reviews.

In chapter 5 pattern based systems engineering was introduced, which when properly implemented, can dramatically reduce the time to produce much of the top level systems engineering documentation and at the same time increase the accuracy of requirements definition. Similarly using validated system performance models and simulations throughout the development cycle aids in reducing development time and increases the accuracy of requirements and design concepts and the robustness of systems.

The objective of this chapter is to describe methods for reducing information latency and then to show how integrating modern methods can achieve greatly reduced time for systems engineering work without sacrificing any process fundamentals critical to the accuracy of this work. Information latency is the time between when information is generated and the time it is available to others who are depending on the information for the next steps in their work. Information latency was increased with the evolution from the craftsman model for product development to models with systems engineers; this is the primary reason modern systems take so long in development. Reducing information latency to levels near what it was for the craftsman model is a necessary step in achieving faster system development cycles.

12.1 Integrated Concurrent Engineering

In the 1990s a method emerged for reducing information latency for system development teams. This method is similar to methods used previously when teams of workers were brought together in a common work area to collaborate to quickly accomplish some project. Many organizations in the aerospace and defense industry use special work areas to collocate the people writing and publishing proposals, which are often highly time constrained projects. The use of proposal preparation rooms with personal dedicated to working in these rooms results in highly productive teams for the limited times involved in typical proposal efforts. A major part of the increased productivity is due to the reduction in information latency achieved by having workers so close they can ask questions of one another and get immediate answers. If teams tried to maintain such intense work over long periods productivity would taper off due to workers being unable to maintain the long hours and intense work without burnout.

The methods that evolved in the 1990s achieve the reduction in information latency and the associated productivity gains of the colocated teams and permit teams to work effectively for long periods without burnout. These methods became possible by exploiting new technology as well as new work management methods.

The availability of inexpensive large screen display projectors, n to one video switches and inter/intra nets makes it cost effective to set up special work rooms where teams of 10 to 25 knowledge workers can gather with their laptops and software tools. These teams can simultaneously work and share the work results with the entire team on the large screen displays as fast as the results are available. Many organizations now use such facilities for teams to gather for intense work and information sharing periods of three to four hours two or three times weekly. These sessions must be well planned and workers must come prepared to work and share results in real time. Planning, documenting work and time consuming tasks are performed in between the sessions in the special work rooms. This approach is called by a number of names but Integrated Concurrent Engineering (ICE) is a common name. This approach is effective because it reduces information latency from minutes to seconds or hours to minutes.

ICE is proven to reduce cost and schedule of complex projects by factors of three to ten ^{12-1, 12-2}. Neff & Presley ^12-3 reported that the Jet Propulsion Laboratory initially achieved an average of over 80% reduction in project costs and significantly improved the quality and speed of work. With more experience a 92% reduction in design time and a 66% reduction in cost was reported. Designs produced using ICE are of higher quality because they examine each option in greater detail earlier in the design process by sharing thousands of design variables in real time. Approaches that are proven to reduce cost and schedule by factors of three to ten and increase quality at the same time should not be dismissed by organizations that wish to remain competitive.

The benefits of ICE are better understood by examining the work space and the work process in more detail. There is no single best work space design or work process; each organization tailors both to their views and their business processes. Examples presented here are guidelines for understanding ICE and not necessarily the best for any specific organization.

12.1.1 The ICE Design Command Center- A schematic diagram of a small ICE work area is shown in Figure 12-1. The room has large screen displays located where they are visible to everyone in the room. Several displays are used so that several different types of information can be displayed simultaneously. Each skill cluster has workers with common specialties and each worker has computer equipment and the design, modeling and simulation tools associated with his/her specialty. Alternatively each cluster can be an IPT responsible for a segment of the system design. Each of the computers is connected to one of the large screen displays via a video switch so that the results of analysis, modeling or simulation can be shared with everyone in the room on one of the large screen displays. The facilitator, typically the lead systems engineer for the systems engineering phase of development, is responsible for maintaining the design baseline visible to all at all times and to lead the team through a preplanned sequence of analysis tasks that lead to design decisions in real time.

 Figure 12-1 A diagram of a small ICE work are showing six specialty skill clusters, five large screen displays and a facilitator/leader.

 Many developments take place in multiple locations and it isn't practical to bring teams from different locations together in a common work area for each ICE session. Modern technology enables teams working is several separately located ICE facilities to communicate with each other and to see each other’s work in real time; thereby achieving the benefits of ICE even though the teams are in different locations. Technology allows virtual collocation. Using ICE with a team that is fractionated into multiple locations and even diverse cultures has the benefit of facilitating the interactions necessary to the success of any system development.

12.1.2 The ICE Concept of Operations - Integrated Concurrent Engineering is a repeating series of planning sessions followed by team work sessions, followed by documentation and follow-up analysis in parallel with the planning for the next series of team work sessions. The times for each of the components of the ICE cycle are dependent on the type and complexity of the system being developed. Example times are given here to explain the concept of operations. Development teams are likely to find adopting this concept of operations to their systems development requires adjustments. A typical approach is illustrated in Figure 12-2 where a series of three plan/ meet/document sessions are shown and each of the meet or design sessions is comprised of three intense team sessions separated by a day or two. Individual design sessions may last from two to four hours.

 Figure 12-2 An example ICE concept of operations where A is planning, B is series of team work sessions and C is documentation and analysis.

The planning, indicated by A in Figure 12-2, is done by team leaders and might take a week to plan a series of three intense work sessions, indicated by B, over another week period. The series of work sessions is followed by perhaps two weeks of documenting work done in the design sessions and carrying out analyses that takes too much time to be done in design sessions. In the example shown in figure 12-2 nine intense design sessions are planned, executed and documented in a an eight week period. Note that since the design sessions are the only activities that require the ICE design command center such a center can support three or four ICE projects or separate IPTs of a large project concurrently.

12-1 The Integrated Concurrent Enterprise by David B. Stagney, MIT Department of Aeronautics and Astronautics, Sloan School of Management, August 13, 2003

12-2 Observation, Theory, and Simulation of Integrated Concurrent Engineering by John Chachere, John Kunz, and Raymond Levitt, Center For Integrated Facility Engineering, Working Paper #WP087, Stanford University, August 2004

12-3 Implementing a Collaborative Conceptual Design System

– The Human Element is the Most Powerful Part of the System by Jon Neff and Stephen P Presley, IEEE, 2000.

Processes and Tools for Planning a Program - 8

Modeling and Simulation Plan - Modeling and simulation should be an integral part of the development of complex systems. The DoD SEF handbook defines a model as a physical, mathematical, or logical representation of something and a simulation as the implementation of a model over time. The DoD SEF has an excellent discussion of modeling and simulation so there is no need to discuss it in detail here. But it is important to stress developing a modeling and simulation plan as part of the overall project planning process.

It can take considerable time to create or tailor models and simulations to a projects needs and to validate their performance. The robustness of requirements analysis, the first step in systems engineering after planning a project, is dependent on the quality of models and simulations available to aid in flowing down requirements to system functions. Thus it’s important to plan the modeling and simulations as early as possible. Decisions must be made up front on the scope of intended modeling and simulation so that work won’t be wasted on models or simulations that won’t be used. The following list can serve to aid in identifying potentially needed models and simulations:

·         System and subsystem performance analysis (typically using models initially)

·         System and subsystem trade studies

·         Design analyses

·         System performance simulation

·         Subsystem test support (hardware in loop testing)

·         System integration support

·         System test support

·         Support of integration and test with customer systems (If system is part of a larger system)

·         Support to training and/or logistics

·         Trouble shooting during the systems operational life

In general, the use of validated models and simulations is highly cost effective because of improving system performance and quality and reducing testing requirements. A case in point is the aerodynamic analysis that has dramatically reduced the cost formally associated with extensive wind tunnel testing of aircraft. Also, in some cases modeling or simulation is the only way to validate performance. An example is a system that supplies measurements that are input to a software algorithm developed by a customer or another supplier and the customer specifies system performance on the basis of the output of the algorithm. If the algorithm isn’t available to the system developer then modeling or simulation is the only way the customer’s performance specification can be verified.

Models and simulations are so important to the development of complex systems that an enterprise’s modeling and simulation capabilities have become competitive discriminators and therefore warrant investment like other potentially discriminating technologies. Some enterprises specialize in modeling and simulations that apply to many complex systems and thrive by being teammates or subcontractors on development programs. Examples include various phenomenologies like environmental backgrounds and atmospheric propagation for electromagnetic radiation that are involved in the development of modern optical and radio frequency sensors. 

Processes and Tools for Planning a Program - 3

Defining Tasks and Developing Schedules

Defining and Sequencing Tasks – The NASA Systems Engineering Handbook discusses in section 4.4 the use of work flow diagrams (WFD) for developing schedules. The WFD is a graphical representation of tasks, task precedencies or dependencies and “products or milestones” that occur as a result of one or more tasks. Using the WFD as defined can lead to scheduling problems due to not fully defining each task. It’s possible to expand the definition of the WFD so that tasks are fully defined. However, there is a simple tool for more completely defining and sequencing tasks that can be used in conjunction with or independently of the WFD before any schedule below the top level is developed.

A simple and effective tool for defining and sequencing detailed tasks is the N-Squared diagram.  N-Squared diagrams are traditionally used in defining software and hardware interfaces but are just as valuable for defining interfaces between tasks. N-Squared diagrams are constructed for tasks and subtasks as a nested set using spreadsheet tools. Tasks are listed in squares along the diagonal set of squares in an N x N matrix of squares. In addition to putting the task name in a diagonal square other information useful to the project team can be added; e.g. the Work Breakdown Structure (WBS) number of the task, or perhaps the task leader’s name, or a paragraph number in a proposal or task description document that describes the task.

N-Squared diagrams can be developed top down or bottoms up or using a mix of bottoms up and top down. Here it is described as a top down process but don’t be constrained by this description. Start with a list of N tasks of the same level in the order you think they need to be executed. Top level tasks often have multiple levels of subtasks. List each top level task in turn in one of the squares along the diagonal of the N x N matrix.  The N-Squared diagrams for the subtasks of each task are constructed as separate diagrams.

The next step is to write the external inputs to the tasks in the row above the diagram and above the square containing the task that the external inputs feed into. Then write the outputs of the first task in squares that are to the right of the first square in the first row of squares. Each output is to be in the square directly above the diagonal square containing the task that requires the output from the first task as an input.  Then continue this process for each diagonal square. Outputs that feed tasks in diagonal squares that are above the row go in boxes to the left of the diagonal square and outputs that feed tasks in diagonal squares that are below the row go in boxes to the right of the diagonal square. This process defines the tasks in that the inputs and outputs of each task are identified along with the sources of the inputs and the tasks that need the outputs.

After completing this listing of outputs for each diagonal square examine the form of the resulting N x N matrix. A simple example with six tasks, one external input to task 1 and two outputs from tasks five and six is shown in Figure 4-1. In this figure the tasks are labeled with numbers along the diagonal and the outputs from tasks are labels with letters. Arrows can be added to make it clear which task each output feeds, as shown in Figure 4-1.

Figure 4-1 An N-Square diagram is a useful tool for defining tasks and the relationships between tasks.

An ideal sequence of tasks for a perfectly sequential project has outputs only to the right side of the diagonal. Typical projects have some tasks with outputs on the left of the diagonal squares. These outputs represent feedbacks to earlier tasks. Typically in executing the tasks in the diagonal squares that have feedbacks from tasks in squares in lower level squares assumptions or estimates are made for the inputs needed from lower level tasks and the tasks are reviewed or repeated after the lower level tasks are completed. Thus the form of the N x N diagram defines how efficiently the tasks are ordered. If there are a lot of outputs on the left side of the diagonal it is necessary to see if reordering the tasks results in moving more outputs to the right of the diagonal and thereby reducing the number of feedback loops that must be executed. Executing feedback loops increases the time and cost for completing the work. Therefore sequencing the tasks for a minimum number of feedback loops usually means achieving a task sequence that leads to the least rework, the shortest schedule and the lowest cost.

Often it is easy to get the top level summery tasks in the most efficient order even without using an N x N diagram. The value of this tool comes in sequencing lower level tasks. Once the top level tasks are sequenced then prepare N-Squared diagrams for each of the top level tasks. For example, suppose one of the top level tasks is System Trade Studies. Complex systems can have a dozen to several dozen system trades that are highly interrelated. It takes only a few hours to define the best order for the trades using an N-Squared diagram. Having just one or two tasks out of order can increase the time for completing all trades by days or even weeks.

Figure 4-2 illustrates an N-Squared diagram for the tasks defined in Figure 4-1 with task 1 sequenced to follow tasks 2 and 3. In this figure only arrows are used to indicate outputs from tasks and where the outputs are needed to make it easier to see the effects of sequencing errors. The sequence in Figure 4-2 is obviously less desirable than that of Figure 4-1 because there are multiple feedbacks, which increases the time needed to execute these six tasks compared to the time for the sequence shown in Figure 4-1.

Figure 4-2 This sequence has three outputs to the left of the diagonal compared to one for the sequence shown in Figure 4-1 and therefore takes more time to execute all six tasks.

There is a second payoff from constructing an N-Squared diagram. The form of the diagram not only defines the most efficient sequence for tasks it also shows which tasks can be conducted in parallel.  For example, note that task four has externally available input data and requires no data from any of the first three tasks. Thus the fourth task can be started in parallel with the first task, or at any time such that its output is available at the start of task five. Obviously tasks can be started as soon as the necessary inputs from earlier tasks are available and staff is available to execute the task. For example, in Figure 4-1 if there was no output from task 3 feeding to task 6 then task 6 could be executed any time after task 2 and the repeat of task 2 with data from task 3 is complete. The form of the N-Square diagram reveals immediately all tasks that can be started in parallel. Starting tasks in parallel increases the flexibility in staffing. Achieving maximum schedule flexibility, i.e. maximum lead and lag times for tasks, should be one of the goals of scheduling tasks.

To avoid the rework resulting from too much detailed task planning and scheduling in the initial project planning effort prepare second and third level N-Squared diagrams for only those top level tasks that are likely to be executed in the first two to four months of the project. Second and third level diagrams for summary tasks that are to be executed later should be developed with sufficient lead time before these tasks are to begin to allow for planning the staffing of the upcoming tasks.

Finally, N-Squared diagrams are often a very useful visual aid to communicate to customers and managers the scope and status of project work. A skilled project manager on a satellite program posted a project N-Squared diagram where it could be easily reviewed by customers and team members. He colored tasks to show task completions so that status was communicated at a glance. This gave the customers increased confidence in the project team and project management compared to just seeing schedule charts.

Developing the Schedule – This discussion assumes that those responsible for developing the schedule are familiar with both the principles of network scheduling, such as Program Evaluation and Review Technique (PERT) or Critical Path Method (CPM), and are skilled in using modern scheduling software tools. This material is not intended to teach scheduling but systems engineers need to be aware of some pitfalls in scheduling complex projects. A recommendation for the inexperienced scheduler is to study a text book on scheduling projects. James B. Dilworth’s “Production and Operations Management” contains an excellent discussion of scheduling.  Particularly important is Dilworth’s discussion of PERT using probabilistic time estimates. An alternative view of probabilistic schedules is found on the web in a blog post by Glen B. Alleman and should be studied by anyone involved in scheduling complex projects. Finally read Eliyahu M. Goldratt’s book “Critical Chain” or search “Critical Chain” on the web and read about Critical Chain Project Management (CCPM). The NASA Systems Engineering Handbook has a description of a process to develop a network schedule after finishing work flow diagrams or N-Squared diagrams. This description isn’t repeated here but a couple of comments are needed.

First, the NASA process calls for a bottom up approach; lower level tasks for subsystems or other work products are scheduled and then these groups of tasks are integrated in the scheduling tool to form the complete detail schedule. This can lead to difficulties and a lot of rework. The rework process is described in the NASA Handbook but much of the rework can be avoided by developing the detail schedule top down.

Typically projects have schedule constraints and developing the schedule bottom up leaves to the end the work of making the complete schedule comply with the constraints where it becomes complex and error prone. It is recommended that when a project has schedule constraints or when the project team wants to meet fixed dates for major milestones and deliveries then include these constraint dates on the Master schedule. Then develop the detail schedule top down from the Master schedule. Scheduling tools can combine these two schedules into what truly can be called an integrated master schedule (IMS).

The top down approach works best if the persons developing the schedule meet with those knowledgeable of the work needed at lower levels and work out the details necessary to comply with the constraints. This is time consuming but actually takes less time than it does to fix a complete schedule that doesn’t meet constraints. Plus, the bottom up approach nearly always results in having to go back to those responsible for the lower level tasks and rework the task details. This is aggravating to workers and managers.

Second, the NASA process does not discuss the variability of task durations and probabilistic scheduling that accounts for this variability. Probabilistic scheduling is most important for accurately determining the critical path. Probabilistic scheduling is discussed in a later section on critical path analysis.

Processes and Tools for Planning a Program - 1,

The first activity for systems engineers on a new product development program is to assist in planning the program. Although planning a program is the responsibility of the program leadership a product development program cannot be properly planned without systems engineering work. Program planning involves defining the tasks to be performed, scheduling the tasks and developing the planning documentation needed to guide the work and the workers. One of the primary reasons product development programs fail to achieve the expectations of management and customers is poor planning. This chapter presents processes and tools that reduce the chances that a product development fails to meet expectations due to poor planning.

This chapter discusses the various plans and documentation making up a product development plan, scheduling the development and touches on the important program management issues of design reviews and supplier relationships that involve systems engineering. This chapter does not distinguish whether systems engineering or program management is responsible for any specific plan item. That decision is up to the development team management. Allocating budget for each task and assigned people to each task are additional planning functions that are not treated here as these activities usually don’t rely on systems engineering other than for estimating the cost of the systems engineering work.

Product development programs are called projects here even though the term projects refer to both product and service developments. The planning for a new product or service development is similar so there is no reason to restrict this chapter to products; besides project is a shorter term than product development program.

Planning Documentation

Documentation is an integral part of project planning. Although not many projects fail due to poor documentation good planning documentation makes a project easier to manage and easier for the workers assigned to the project. Four types of documentation that are typically used on complex projects are discussed. These are the Integrated Management Plan (IMP), the Schedules, the Systems Engineering Management Plan (SEMP) and the System Design Document (SDD). The first three comprise the top level planning documentation. Of course there is considerable documentation needed to back up these top level plans. The SDD is not strictly a planning document but it should be started during the planning phase.

There are two ways to produce poor documents and one way to produce good documents. Poor documents are either so brief or poorly written that there is little useful information for managers overseeing the project and new workers assigned to the project or the documents are so long and detailed that no manager and few workers will ever read them. Surprisingly, most bad documents are those that are far too long to be useful. This is because the project leaders have slavishly followed advice to include everything but the kitchen sink description in these documents.

In the an earlier post it was stated that where ever possible labeled graphical models should be used rather than textual documents. Plans are one of the areas that require a significant amount of text. However, the goal should be to make as much of the plans as possible graphic models such as diagrams and tables. (Tables are included as graphic models here because they are less ambiguous than pure text.)

The Integrated Management Plan - A concise IMP is preferred because the IMP should be viewed as a “contract” between the project team and their senior management. Therefore the document need only address issues at a summary level. This allows the team and management to focus on the important issues without getting mired in detail. Mature organizations have standard procedures and processes for items like configuration management and product assurance. Management needs to know if any tailoring is needed for standard processes but they don’t need to wade through the details of standard processes. Certainly documents like a Product Assurance Plan are necessary but hopefully the organization is mature enough that the plan for any specific project is a tailored version of a standard plan.  Summarizing how the plan is tailored to the specific project is sufficient for the IMP. Any manager or worker that needs to know the details can read the detailed plan.

A good IMP is about ten pages long or less. If it is any longer it won’t be read by managers who are expected to have oversight of the project or by few workers that are assigned to the project. It is quite difficult to cover all the items that are recommended for an IMP in ten pages but it is far better to put effort into a good ten page document than to put even more effort into 80 pages that are never read. A template is provided here for a ten page IMP. Many books and web sites advise far more material be included in an IMP but it’s not effective to produce such tomes and it costs precious time and money to produce them. If a project leader insists that all the detail is needed then include a seven to ten page Introduction and Summary for managers because that is all they are likely to read.

The table shown here is an outline for a seven to ten page IMP. Your project may not have the same required items but this outline illustrates that a useful IMP can be ten pages or less. The suggested number of pages in this table adds to ten pages if the maximum suggested amount is used for every item. The recommended topics provide managers a concise overview of a project and are sufficient to orient new workers assigned to the project. If the resulting IMP is well written then, together with the project schedules, it provides senior managers all the information they need to conduct oversight that ensures that the project is progressing adequately or that the project leaders need help. New workers do need additional information but that is better provided in the SEMP and SDD.

Topic	Number of pages
Program Overview (Milestones, Deliverables with quality level required, Fit with Strategic Goals and a one page Top Level Schedule)	1.5 to 3 pages
Technical Description of System (Intended function, hardware/software overview and any make/buy issues)	1 to 2 pages (Include a top level System Breakdown Structure (SBS) and link to more detailed breakdowns in the SEMP.)
Key Performance Characteristics	0.25 to 0.5 pages (Include links to a Specification document for those needing more detail.)
Work Breakdown Structure (WBS)	1 page of top level only (Put the detail, if needed, in an appendix or link to a separate document, e.g. the SEMP.)
Cost target, Preliminary budget & Sources of funding	0.25 page
Staffing Plan (Preliminary manning forecasts, any critical resources, & any teaming arrangements)	0.25 to 0.5 pages
Key Assumptions	0.25 to 0.5 pages
Summary of major risks and plans to mitigate	0.25 to 0.5 pages and reference a risk register in an appendix
Inter-project cross feeds and dependencies	0.25 page
Capital and facility requirements	0.25 to 0.5 page
Status of Preliminary Support Plans (Configuration Mgmt. Plan, Product Assurance Plan, Environmental Health and Safety Issues/Plans, Logistics and Field Support, etc.)	0.5 to 1 page (Which are standard and which are to be tailored. Say why tailoring is appropriate.)

If an enterprise accepts the definition of the IMP as a contract between the project team management and the enterprise management then there is no reason that the IMP always be a text document. It may be acceptable that the IMP is a set of briefing charts that the team presents to the management and receives acceptance or guidance from the management at the end of the briefing. Since most briefings today use electronic data projected on a screen it is easy to include links to the more detailed plans just in an electronic text document. Including appropriate links to more detailed planning documents makes the briefing charts as complete as any text document.

There are several advantages to this approach. First, it is easier to prepare a set of briefing charts covering the topics of an IMP than it is to write a high quality document. Second, if the team can get the management to set through a briefing then there is no question about whether the management has read the IMP and there should be no question about whether the IMP is approved or not. Also, a briefing allows any ambiguities to be resolved in real time. Finally, the 80 page tome is discouraged because senior management isn’t likely to sit through a briefing that long.

A last but important reminder is to prepare the IMP using an IMP from a previous project as a template and strive to make the new IMP an even better template for future IMPs. This advice isn’t limited to the IMP. Where ever possible look for opportunities to build on previous work and structure work so that the result makes future work easier and faster. This approach to fundamental to executing systems engineering rapidly and accurately.