Processes and Tools for Planning a Program - 2

Project Schedules - There are two types of schedules defined in IEEE 1220 and DoD nomenclature. One schedule is called the Master Schedule in IEEE 1220 nomenclature and the Systems Engineering Master Schedule (SEMS) or Integrated Master Schedule (IMS) in DoD nomenclature.  It is an event driven schedule and is not an executable schedule; it is used by the program management for communicating status and to guide the development of detailed executable schedules. The Master Schedule maps to the WBS, identifies major milestones and deliverables.

The second type is executable, tied to calendar dates and is called the calendar schedule. The calendar schedule is also called the detail schedule or systems engineering detail schedule (SEDS). This schedule is used to develop earned value metrics for government contracts. The NASA Systems Engineering Handbook refers only to one schedule; called the network schedule, which is the same as the detail or calendar schedule. The NASA Systems Engineering Handbook provides instructions for planning and developing the schedule whereas the DoD and IEEE 1220 documents for systems engineering only discuss the planning that systems engineers must do to enable schedules to be developed.

Three schedules are necessary to achieving effective project control and communication with management and customers. First there is the Master schedule as defined by IEEE and DoD. Some slight modifications to the DoD definition are desirable. First, limit the Master schedule to about two levels for most projects. The Master schedule can then include the major phases of the planned work, the management reviews that typically gate the initiation of the next phase and the deliverables, including any long lead items that are on the critical path, and other selected items that drive the schedule. This usually permits a Master schedule to be displayed on a single page, which greatly simplifies communications with senior management.

Second tie the events to calendar dates since most customers for new product developments specify delivery dates. The reality is that product development teams typically must plan a project that meets some schedule constraints. Customers may claim they want an event driven rather than calendar driven program but it’s rare that they actually do. Also the team has less incentive to develop work arounds to hold schedule and cost if the project is truly managed as event driven. These constraints are clear to everyone if they are included in the Master schedule. Finally, use the term Master Schedule and not the terms Integrated Master Schedule (IMS) or SEMS or SEDS. The detail schedule, or network schedule as NASA calls it, is the integrated schedule and both the Master schedule and the detail schedule apply to more than the systems engineering work.

The second schedule is the detail schedule; it is an executable schedule that is calendar driven and is used by the project management, task leaders and workers. It contains all task levels and should have measureable milestones about every one to two weeks to facilitate tracking progress. It is resource loaded, should identify critical resources and allow for contingencies, i.e. lead and lag times (float in NASA nomenclature) should be maximized as much as schedule constraints allow and the critical path should be identified.

The third schedule is a weekly task schedule prepared by each worker and used by the worker to schedule his/her work in order to meet the milestones on the detail schedule. The schedule can be on a 3 x 5 card or any other tool that the worker finds effective. This schedule must be more than a list of tasks. Workers should schedule their time hourly for an entire week at a time and with contingencies to account for the unexpected interruptions that will happen. Many experienced engineers do this automatically but young or inexperienced engineers may need mentoring before they develop the habit of scheduling by the week.

The detail schedule is a critical document to get right because it is the primary tool used to assign budgets and workers to the project and to track the work compared to planned schedule and budget. Both the Master schedule and the detail schedule must map to the Work Breakdown Structure (WBS) that assigns tracking codes to each task for the financial management system in use. The WBS should be based on the hierarchical structure of the product and processes, i.e. the Product Breakdown Structure (PBS) in NASA nomenclature, or System Breakdown Structure (SBS) in IEEE 1220 nomenclature, so that it is tied as much as possible to physical products rather than functions. Readers are referred to section 4.3 of the NASA Systems Engineering Handbook (down load from http://nen.nasa.gov/nasa_nas/ops/systems_community/NASA_SP-2007-6105_Rev_1_Final_31Dec2007.pdf) for a discussion of how to structure the PBS and WBS.

The detail schedule must have all the links and precedent relationships between tasks identified. Fortunately there are software tools, like MicroSoft Project, that facilitate preparing a detail schedule. Such tools are sophisticated and considerable experience is needed to utilize them properly. This often results in persons with skills in the scheduling tool being assigned to prepare or assist in the preparation of the schedules, which can lead to problems, as described next.

 A big mistake inexperienced project leaders make is scheduling the project before the tasks are defined. It’s ok to develop the Master schedule before defining and structuring lower level tasks that belong in the detail schedule because often Master schedules contain project constraints that must be accommodated. Inexperienced project leaders sometimes try to combine two planning steps by listing the tasks to be performed and working out a detail schedule for the list or even developing the task list on the fly using the scheduling tool. Defining tasks should be done first, at least for complex projects, because it’s not obvious how tasks should be sequenced and structured until tasks are fully defined. Defining tasks means defining the inputs, the tasks that are the sources of the inputs, the outputs and the tasks the outputs support. Defining tasks is work that requires analysis by systems engineers, design engineers and operations personnel. Just having a list of tasks does not mean that the inputs, outputs and the work needed to turn inputs into outputs are understood. It should be obvious that schedules constructed without such understanding are not likely to be executable without numerous corrections.

Another big mistake inexperienced project leaders often make is requiring detailed schedules for entire projects as part of the beginning planning. This is a mistake because there is insufficient information to construct such detailed schedules so that a detailed schedule becomes useless within a month or two and re-planning is required.  A rolling wave scheduling process that avoids this needless rework is described after discussing tools for defining tasks.

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.

System Engineers in the Organization

Let’s assume a product development organization practices concurrent engineering and organizes in a set of interlocking teams. The top level team is often called the core team. A core team for a medium to large development program is composed of representatives from the major contributing functional organizations in the enterprise and might look like Figure 3-6.

Figure 3-6 A typical core team for a medium to large product development program has representatives from all the contributing functions.

A circle structure rather than a tree is used for the organization because each member of the core team is functionally independent and has responsibilities both to the product development or core team and to his/her functional organization. This means for example that the contracts representative operates within the team in the best interests of the product development program but is also constrained to follow the policies and procedures the parent organization defines for the contracts function. Similar rules apply to the other members of the core team. Each member of the core team is a leader of a support team, e.g. the engineering member of the core team is the lead engineer for the engineering team.

Now we can look at how the engineering work is organized and how its organization fits with the core team. This is shown in Figure 3-7.

Figure 3-7 The engineering integrated product team (IPT) is typically organized with a Systems Engineering and Integration Team (SEIT) and a number of teams responsible for the various systems or engineering functions such as software or test.

In Figure 3-7 SE stands for a systems engineer and DE stands for an engineering specialist other than a systems engineer. The engineering leader is called the project engineer, as in this figure, or chief engineer, or lead engineer. The leader of the System Engineering and Integration Team (SEIT) is usually called the lead systems engineer. The engineering IPT is thus composed of a number of subordinate IPTs, here labeled A through N, which are responsible for subsystems or for specialty functions like test or software. The systems engineers shown under the subordinate teams in Figure 3-7, or the subordinate team leaders, are members of the SEIT as well as their respective IPTs. If the system being developed is large and complex than there are likely many more layers of IPTs. Think of each of the DE blocks being an IPT with the SE block being a lower level SEIT.

Not explicitly shown in Figure 3-7 is how members of the operations team, the product assurance team and key suppliers support the engineering team and vice versa. In some cases it may be sufficient to only have the structure shown in Figures 3-7 and 3-8 but in most cases an operations engineer and a quality engineer should be a member of the SEIT and a member of the SEIT should be a member of the operations IPT and possibly the product assurance IPT. Usually an engineer knowledgeable about a supplier’s product is responsible for coordinating with the supplier and bringing the expertise of the supplier into the design process at each phase of the design work.

The principle to be followed in organizing the engineering team is to break down work so that at the lowest level IPT the craftsman model applies. This is the work assigned to each of the lowest level IPTs can be thoroughly understood by the team leader. Thus the team leader is a “chief engineer” for the work assigned to his/her team.

The nesting of interlocking IPTs can continue as necessary to handle the size and complexity of any large system. This nesting of teams reduces the time non managers spend in communications meetings. In the three tier example shown in Figures 3-7 only the lead engineer, here called the project engineer, needs to attend core team meetings although sometimes the lead systems engineer may attend. Engineering coordination meetings are held at two levels. The project engineer meets with all the team leaders and then the team leaders meet with their respective teams. This approach limits the amount of time workers spend in coordination meetings and limits the meeting topics to just those items of interest to each team. Few things are more frustrating to working engineers than having to sit through meetings on topics that are of little or no interest to them; plus it’s a waste of time and money to have working engineers sitting in nonproductive meetings.

Product development programs usually have documentation called a work breakdown structure (WBS) that assigns code numbers to various elements and  phases of the  work so that budgets can be generated and managed. The WBS can map to the organization to facilitate cost management although this is not a strict constraint.

Figure 3-7 shows that there is systems engineering specialty work to be done in each of the subordinate IPTs even if the person doing the work is called a design engineer rather than a systems engineer. Some design engineers think that they don’t have to do systems engineering work, which just isn’t true. They do systems engineering work even if they don’t use all of the tools used by systems engineering specialists. Since a system is always part of a larger system then there is systems engineering work in all product development at all levels of “systems”. Even though an engineer is developing the design for an assembly or component of a system there is systems engineering work required. Of course this systems engineering work must be tailored to the level of complexity of the design element.

Systems engineers can perform a variety of roles on IPTs, from lead systems engineer to contributing engineer or analyst on one or more other teams. Since the IPTs are multidisciplinary, it is critical that the systems engineers understand their roles and responsibilities on each team. A good practice is to hold roles and responsibilities meetings with all members of an IPT as soon as the team is staffed.

The engineering team for a small product development program can be simplified from that shown in Figure 3-7. An example of an engineering IPT for a small project is shown in Figure 3-8.

Figure 3-8 The engineering IPT for a small development program can be simple with the engineers having responsibility for both systems engineering and design engineering.

Figure 3-8 shows an engineering IPT with just seven engineers; a project engineer (PE), a system engineer (SE), an electrical engineer (EE), a mechanical engineer (ME), a quality engineer (QE), an operations engineer (OE) and a test engineer (TE). This organization might be sufficient for developing the design of a small electrical or electro-mechanical system. Note that this organization clearly illustrates the multidisciplinary nature of IPTs and is what might also be used on one of the subordinate IPTs of a large development program.

Definitions of Systems and Systems Engineering

Now that we have taken what is hopefully is a fresh look at what systems engineers do let’s back up and look at some traditional definitions of a system and systems engineering. I have used these definitions for so long that I have forgotten their original sources and I apologize. There are almost as many definitions of a system and of systems engineering as there are systems engineers so I prefer not to put much emphasis on these definitions but include them for completeness and to make a critical point about defining things with text based definitions.

One source says a system is a collection of objects working together to produce something greater. A system can be tangible, like a rocket or a communications network, or intangible like a computer software program or any combination of tangible and intangible. A system is composed of unique elements and the relationships between these elements. The elements in a system can be highly hierarchical or essentially flat like a network, or again any combination of hierarchical and flat. A system has the further property that it can be unbounded; each system is invariably a part of a still larger system. This characteristic of a system leads to a complication in definitions. Some systems engineers use names like “system of systems” to account for certain types of systems; often those involving complex interactions with humans. From a semantics point of view a term like “system of systems” makes no sense as it’s equivalent to saying a “universe of universes”; but if such terms communicate something important to those working on the development of certain types of systems then the terms serve a useful purpose. Also we have to remember that sometimes customers invent new terms and we have to use them even if we don’t agree. It usually isn’t worth trying to be “virtuous and pure” over such issues.

One pragmatic way to define a system is that it is the design element at the top of the hierarchy being developed by a systems engineer’s team. Thus it’s the collective name of that design element. The system being developed may be part of a larger system but the development team only has to be concerned with the requirements for their system and the interfaces of their system with the larger system, not with what to call the larger system.

Eberhardt Rechtin, in his book “Systems Architecting: Creating & Building Complex Systems”, says the essence of systems engineering is structuring. Structuring means bringing form to function or converting the partially formed ideas of a customer into a workable model. The key techniques are balancing the needs, fitting the interfaces and compromising among the extremes.

Others describe systems engineering as both a technical and management process. One source says “it is a discipline that ties together all aspects of a program to assure that individual parts, assemblies, subsystems, support equipment, and associated operational equipment will effectively function as intended in the operational environment”. One of my favorite definitions is from a U.S. Navy web site.  It says systems engineering “is a logical sequence of highly interactive and iterative activities and decisions transforming operational needs into a description of system performance parameters as well as a preferred system configuration.”  This definition is amusing because it is exactly correct in saying systems engineering is highly interactive and iterative but the reality is that it is logical only to a highly experienced system engineer. Something that is highly interactive and iterative hardly appears logical to someone not intimately familiar with it.

Comparing these definitions with the four tasks for systems engineers defined in Figure 3-3 of the previous post shows that the definitions do not capture all that is implied in the four tasks. From the definitions would a young engineer realize that a system engineer has a role in planning and scheduling a development program; or in verifying the performance of a system design? If this chapter started with the standard definitions of a system and systems engineering would a logical path to the four systems engineering tasks have been easily found? If just the five text words had been used to define the product development cycle instead of the labeled graphical model would it have raised the question of whether the four tasks are rigidly sequential or allowed to overlap in time? Perhaps, but not as easily as it is starting with the graphical model of product development as the five simple sequential tasks or phases of define, design, build, test and produce.

Graphical Models vs. Textual Models

There is a profound principle in the last paragraph above. Textual descriptions of complex ideas are often incomplete and very often lead to different readers having different understandings of the ideas. Labeled graphical models of complex ideas are less ambiguous. This is a critical point for systems engineers to remember and use in their work. Look back at the second figure in the previous post. The thin solid arrows indicate that the outputs of a task are the inputs to the next task. In the development of complex systems each task typically involves different teams. Therefore it is critical that the outputs of one task be easily understood and unambiguous to the teams working on the following tasks. Labeled graphical models are much easier to understand and less ambiguous than textual descriptions for most engineers.

Think back to the “Craftsman” model of product development defined earlier that was successfully used for centuries for simple products. The output documentation from the chief engineer and his/her team was engineering drawings. The workers and managers in the factories responsible for producing the products could clearly understand and use these engineering drawings. Imagine if the chief engineer and his team submitted textual descriptions of their product design to the factories.

Another example of a labeled graphical model being superior to textual descriptions is maps. Imagine going on a driving vacation through your country using just a textual description of the location of towns and the roads connecting them. Just keeping track of where you are with respect to the textual descriptions would become a time consuming task. This is why maps became the standard model for describing geography centuries ago.

One of the reasons development of complex systems often failed to achieve the planned schedule and budget after systems engineering was introduced in the 1950s and 1960s to address  the complexity of modern systems was that some of the documentation produced by systems engineers and passed to design engineers was textual descriptions rather than labeled graphical models. Unfortunately this practice continued when concurrent engineering was introduced and continues today for many organizations. One of the primary objectives of this book is to convince systems engineers to use labeled graphical models wherever possible and avoid textual models wherever a graphical model can be used instead. This is one of the keys to achieving faster and lower cost systems engineering, as will be explained in a later article.

System Engineering and Design Engineering

Accompanying the introduction of systems engineering was the practice of distinguishing between systems engineers and design engineers. It was natural to label the engineers doing the systems engineering work as system engineers. Since functional engineering organizations were typically broken down into mechanical departments, electrical departments or some similar differentiation it was natural to set up systems engineering departments for the systems engineers. This is unfortunate because all engineers do some systems engineering work and all engineers do some design engineering work.  It is true that systems engineering has become a specialty just like other specialties of design engineering and that systems engineers use some processes that are fundamentally different than design engineers. We must keep the various specialties but perhaps we could change the term design engineer. This might help remove some of the undesirable barriers that creep into our organizations that inhibit effective communications. However, using the term design engineer helps define the different rolls of system engineers and the various specialties. Let’s use the diagram from Figure 3-4 to help define the traditional roles and responsibilities of systems engineers and design engineers. The result is shown in Figure 3-5.

Figure 3-5 The traditional roles of system engineers and design engineers involve responsibilities within each development phase.

 From Figure 3-5 and the description of what takes place during each task or phase we can further define the traditional differentiation between systems engineers and design engineers in simple terms as follows:

·         Systems Engineers Determine

o   What’s to be built

o   How it’s supposed to function

o   Whether it meets its requirements

·         Design Engineers

o   Determine how it’s to be built

o   Make it  operate (integration & test)

It is critical to understand that both systems engineers and design engineers are involved in all five phases as shown in Figure 3-5. To further define the role of systems engineers it helps to look at how they are integrated into a typical organization. That is the subject of the next article.

Introduction to Systems Engineering

Systems engineering is defined in many texts. Rather than repeat the standard definitions at this time it is helpful to define these terms in the simplest possible manner. The reason is that having very simple definitions helps us to consider things from a fundamental point of view, which makes it easier to come up with new insights. Later traditional definitions are presented and comparing the two may give new insights. New insights are needed in order to understand new methods and, eventually, to develop improved methods. This chapter, presented in several articles, defines four fundamental tasks that systems engineers perform, provides definitions of systems engineering, compares the rolls of systems and design engineers and shows how systems engineers fit in a modern product development organization. The four systems engineering tasks are deliberately defined before defining systems engineering or systems engineering processes. Although this seems out of order it helps take a fresh look at systems engineering methods. To set the stage for defining the four tasks of systems engineering we look at the overall product development process or development cycle as it is usually called.

The Product Development Cycle

In the exercises at the end of the last post the reader was asked to define the product development cycle in simple terms a grandmother would understand, assuming the grandmother is not a systems engineer. The purpose of this question is to make the reader think about the fundamental tasks that comprise product development. Sometimes people get into the detail of their work to the point they lose sight of the fundamentals of what they are doing. Figure 3-1 illustrates what the reader might have said.

Figure 3-1 Product development consists of five tasks, or phases, at a fundamental level.

Product development organizations typically define the product development cycle in a much more complex diagram, or set of diagrams, that describe the tasks to be performed in much more detail than shown in Figure 3-1. However, it is important to step back and look at the fundamental tasks, or phases if you prefer, in as simple of terms as possible if we intend to improve the overall process. Starting with the simple flow chart in Figure 3-1 we define the work that systems engineering encompasses, again in simple terms, because our objective is to seek better methods for systems engineering. Note that Figure 3-1 leaves out the object of the verbs. This forces us to think about what it is that we are defining, designing, etc. For example, it’s necessary to define both the product and the program for developing the product. Decisions must be made about what will be designed, what will be tested and what will be produced. These decisions are product dependent and involve systems engineers if only as advisors. We can add some of the top level inputs and outputs of each step in Figure 3-1 as we think about what it is that we are defining, designing, etc. A result for one type of product might look like Figure 3-2.

The tasks shown are performed by a variety of managers, technicians, and engineers; systems engineers, design engineers, test engineers, etc. We seek to define just the tasks performed by systems engineers. Actually systems engineers are involved in all five tasks to some extent. Typically systems engineers are responsible for the specifications and plans that are produced in the “Define” task and contribute to or oversee work in the other four tasks. With these roles in mind we can think about the tasks the systems engineers perform. Recall that here nontraditional terminology is used at to describe the systems engineering work.

Figure 3-2 The outputs of a fundamental product development task are the inputs of the next task

Four Fundamental Tasks for Systems Engineers

A simple but useful terminology for defining systems engineering work is shown in Figure 3-3.

Figure 3-3 Four fundamental tasks performed by systems engineers during the product development cycle.

The four tasks listed in Figure 3-3 are not the only way to define systems engineering tasks, or are these are a complete description, but these four tasks help us understand the fundamentals, if we allow for some flexibility in our definitions. This becomes apparent as we examine in more detail the four tasks in later chapters.

Notice that the first three systems engineering tasks are shown as overlapping in time rather than being sequential in time. This is because these tasks should overlap in time. This is a good point to introduce one complexity in the fundamental task list shown in Figure 3-1, then we can return to defining systems engineering.

Progressive Freeze of Product Development

The product development tasks should not be rigidly sequential but should allow for some overlap in time, as indicated in Figure 3-4.

Figure 3-4   The fundamental product development tasks should be allowed to overlap in time.

Often major product development tasks, or phases, are gated by milestone reviews. This implies that all work must be completed on one phase of the product development before work can start on the next phase. It is not good practice to demand rigid adherence to the gating process. A better approach is to allow some work to begin as soon as the information needed for initiating the task is available. This is called progressive freeze, as discussed in previous  articles, and it adds flexibility to the work that offers benefits that outweigh the small additional risks incurred.

Progressive freeze is practiced by freezing an element of the engineering work, when the risk of freezing the work is acceptable and allowing work on the next phase to begin before the next milestone review. Engineering judgment is used to determine when the risk is acceptable that the continuing work on other elements of the development work won’t change the results of the frozen work element.

A couple of examples help understand the progressive freeze concept. Consider a radio frequency (RF) sensor. Freeze the antenna architecture when the gain, antenna configuration and interfaces are determined; initiate the antenna design in parallel with other subsystem architecture trades. Hold a system design review (SDR) or architecture review, if required, when all subsystem architectures are frozen. Second, consider an infrared sensor. The telescope architecture can be frozen when the aperture size, the form, the optical subsystem f/# and interfaces are determined. The telescope design can then proceed while the focal plane, electronics and cooling architecture trades continue.

There are several benefits from beginning the design early for the RF antenna or the telescope in these two examples. The biggest is the flexibility in scheduling the skilled antenna and telescope designers. Critical skills such as these are often in high demand on several programs. By enabling early starts of the design work involving critical skills it increases the total time period for the design work to be accomplished without impacting the program schedule and helps avoid program delays due to the unavailability of critical skills.

A second benefit is that progressive freeze facilitates sequencing design decisions throughout a design phase. Product development involves thousands of decisions in each phase of the work. Delaying decisions until just before major design reviews complicates decision management to the point that the quality of the work can be threatened. Making decisions as soon as risk allows spreads the decisions throughout a development phase and makes decision management easier. We will return to this issue in a later chapter where we explore design decision management in more detail.

 Another benefit is that should a problem arise in the design that impacts other architecture the architecture changes can be made easily if these trades are still underway. For example, suppose the RF antenna designer discovers that the desired gain margin cannot be achieved within the constraints defined in the architecture trades. If the other trades are still underway it is much easier to decide how to accommodate the problem. It may be that a larger envelope is available or it may be that the lower gain is acceptable with tighter control of noise figure in the amplifier electronics. Finally, allowing more time for the designers to work on a design element may result in a better design. Sometimes engineers need to set work aside for a short period while they mull over a difficult design issue. Sometimes unforeseen difficulties arise in design and having extra time to work out these difficulties helps avoid program delays.

Review of Fundamental Principles for Product Development

Examination of the “lessons learned” from over 50 years of evolving product design methods suggest that there are some basic principles that should be considered when examining new methods or tools for product development. Some are evident in the examples given in the previous posts and others derive from the experience of successful systems engineering teams. I suggest we can summarize these into 12 principles that underlie modern product development methods:

1. The best model for a simple product development is a “Craftsman” model, i.e. a Chief Engineer with total project visibility and responsibility. 
2. Complex products should be decomposed into simpler pieces so that the craftsman model can be applied to each piece.
3. All activities in a product’s development must become one integrated effort.  (Otherwise, #2 cannot be implemented successfully.)
4. Trade-off within single disciplines must be subordinated to trade-offs across disciplines. (Necessary to achieve a “balanced” design.)
5. Authority must be shared among members of a collaborative, multi-disciplined team.
6. Product complexity will continue to increase, leading to the need for more engineering specialization.  (And the need for better systems engineering tools)
7. The complexity of system engineering tools should be matched to the complexity of the product
8. Continuous Process Improvement of product design methods is essential to compete successfully in a global market.
9. A competitive advantage is realized from technology and tools that provide all team members complete visibility of evolving designs, support in identifying and resolving conflicts, and the ability to equally influence decisions.
10. Modern methods are essential to shorting the time to prevent design errors; rather than to find and fix design errors, and thereby facilitate achieving minimum product development cost and schedule.
11. Functional managers must collaborate, share responsibility in measuring team performance, and foster unity of purpose within and among teams.
12. Product development schedules must account for resource contentions within the team and among teams.

The reason the Craftsman model is the best for simple products or simple portions of complex products is that all the information necessary to guide the design is available in the mind of the experienced leader or chief engineer. This is best because it reduces information latency to an absolute minimum. If information latency is minimized then the conditions for minimizing cost and schedule are in place. This means that cost and schedule will be minimized assuming the other principles are also fulfilled. (The principles could be summarized in a shorter list if the principle of minimizing information latency is invoked. However, decomposing this fundamental principle into subordinate principles makes it easier for systems engineers and product development managers to see how the principle should be implemented on their projects.)

The second principle derives from the first and tells us part of how a product development team should be organized to minimize information latency. It says to decompose the product into pieces (subsystems, assemblies, etc.) to the point that a single lead engineer can be knowledgeable enough to guide the development of the piece. This lead engineer must be supported by the needed specialty engineers and must work with other team leaders to achieve a balanced design but the individual should be capable of being responsible for all design decisions on the piece assigned. How all these small teams are organized into an overall integrated team is the subject of principle 3 and the core organizational issue of IPD.

Principle 4 says that one of the responsibilities of systems engineering is to manage the tradeoffs between different disciplines (and teams) so that a balanced design is achieved. For example, compromises are often needed between electrical design and thermal design or between mechanical design and optical design. If the systems engineers allow one discipline to dominate then that discipline will make their portion of the design optimum at the expense of other disciplines; resulting in an unbalanced design which is usually not robust to the variability of use. Principle 5 is a necessary condition for successfully implementing principle 4.

Principles 6 should be self-evident and principles 7 and 8 follow from 6. Principle 9 is derived from examining the question of how we achieve the benefits of the craftsman model for the development of modern complex products with many engineering specialties. For a number of years I used this principle in training systems engineers and had to admit that I did not know how to achieve the goals listed in this principle. New methods emerged in the late 1990s that now enable teams to achieve the goals of principle 9 and these new methods are addressed in Part II of this training material.

Principle 10 says that teams must use methods like peer reviews, progressive freeze, quality function deployment (QFD) and risk management to achieve minimum cost and schedule. This list is meant to be illustrative and is definitely not a complete list of modern methods and communication tools needed for effective systems engineering and product development. None of these methods is difficult but teams must exhibit good discipline to maintain effective use of these tools and inexperienced managers sometimes fail to maintain the necessary discipline.

Principles 11 and 12 are “housekeeping” principles and perhaps could be left off this list but they are added as reminders.

Exercises

Before proceeding to the next series of posts take a few minutes and consider the following questions:

1. Review the product development processes in your organization and rate them against the list of 12 principles stated above on a scale of 1 to 5, with 5 being full satisfaction of the principle. If your organization achieves a score of 50 or above it’s likely that it’s competitive with most of its competitors. If the score is below 50 then there is work to do even before trying to implement the 21^st century methods that will be introduced later.

2. Describe the end to end product development process in simple terms your grandmother could understand (assuming she is not a systems engineer) if she asked “what are the steps in product development”?

Systems Engineering for Defense Acquisition

This guest article by Mike Gangl explains how Government acquisition agencies use modern systems engineering to define new systems. If you are not familiar with some of the DoDAF terminology later articles will explain concepts like Operational Views in more  detail.

Whereas systems engineering is needed to develop any new system or improve on existing products, there are unique activities and nomenclature for those engineers who are supporting US Department of Defense (DoD) acquisition programs. DoD has recognized that the systems they procure are much too complicated to not address quality systems engineering practices. Additionally, if these procured systems do not perform as required or fail in operation, then the consequences may be severe including failed US policies or even injury or death to our military men and women. Therefore, it is important that engineers and program managers who are working on government projects understand the system engineering processes defined by the DoD and how these relate to their own product development SE processes.

The standard by which the DoD acquires new systems, from planes to ships to radios and beyond, is Department of Defense Instruction (DoDI) 5000.02, Operation of the Defense Acquisition System. The latest version is dated December 8, 2008 and a copy can be found at http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf. Figure 1 of the “5000” process shows the primary stages of the acquisition cycle, which include pre-system acquisition, system acquisition and sustainment. The DoD acquisition community has statutory and regulatory requirements to follow this process to procure new military systems. But there are two important exceptions.

The first exception is for research and development. Government organizations such as the Defense Advanced Research Projects Agency (DARPA) and the military laboratories issue research and technology development contracts to other government agencies and industry contractors. These contracts do not follow the 5000 process. Typically, the systems engineers will receive a Statement of Objectives (SOO) and perhaps a set of target performance requirements. In some cases, such as DARPA with their go-no go criteria, further funds are predicated on achieved performance. This is good since no program manager or systems engineer should sign up to meet hard, budget linked requirements for technologies that are not yet demonstrated. Of course, companies are frequently tempted to do so to win the contract. So it is important that the engineers, even on these technology development projects, follow some form of a systems engineering process and ensure all stakeholders understand risks and mitigation tasks. A company’s profit and reputation depend on it.

The second exception is a more recently popular acquisition approach called Quick Reaction Capability, or QRC. For these types of contracts, the system developer is provided with a set of requirements the military need to satisfy to field an operational capability. A QRC is typically justified to either demonstrate the utility of a new technology or mission, or to satisfy an immediate need of the warfighter. This is especially important in times of war. The largest, most recent example is fielding technologies to defeat improvised explosive devices (IEDs). With a QRC program, the government elects to forgo the 5000 process and have the contractor build and field the equipment on a best effort basis.

Of course, the degree to which the requirements are met still have a significant impact on whether the customer is satisfied. Here, it is extremely important that the engineers maintain some level of systems engineering discipline in a highly accelerated schedule. Managing performance and expectations are even more critical when you are working “under the gun.” A big issue for many DoD acquisition programs in today’s environment is having the Pentagon leverage a 5000 process while imposing a QRC schedule. Everyone wants the latest and best capability. And in time of war, this is amplified. These competing requirements, full acquisition process vs. schedule, are not easily solved and will require continued systems improvements to the acquisition process.

Back on the subject of the 5000 process, it is important to point out some of the key systems engineering products the government is required to produce and how they relate to engineers and their programs. This article does not cover the whole DoDI 5000.02 process since that is a separate, extensive topic. Training can be found through the Defense Acquisition University (www.dau.mil).  Typically, this training is only necessary for government systems engineers. There are three important items for engineers who work on government contracts to develop systems.

The first is the flow of requirements. It is important that a contractor systems engineer understand the way the program requirements have flowed down through the government process. For a typical military acquisition program, the primary requirements are captured in a Capability Development Document (CDD). The CDD contains the government agency’s Key Performance Parameters (KPPs), Key System Attributes (KSAs) and any additional attributes they believe are necessary to have the system satisfy their objectives. The CDD is usually worded in language from the user community rather than from technical personnel. The government organization that is responsible for the acquisition then must procure a system that satisfies these KPPs and KSAs. The systems engineers of the government acquisition organization must translate these CDD requirements into technical and operational requirements. These are documented in a System Requirements Document (SRD). Many government systems engineers now use software tools such as DOORS™ to track the linkage of the CDD to the SRD. Typically, the government may release either a top-level SRD or a complete SRD. The difference is the amount of engineering maturation that occurred to derive the SRD requirements. If the agency doesn’t have all the expertise and time at their disposal they may elect to go with a top-level SRD and work with the contractor to mature the requirements. Prior to entering the Engineering and Manufacturing Development phase of the program, the SRD will be worked into a final System Specification (sometimes called a Weapon Systems Spec, or WSS). The WSS is intended to resolve all To Be Determined (TBDs), To Be Reviewed (TBRs), and no longer contain Threshold (T) and Objective (O) requirements. It is expected that the WSS contains the specific requirements that the government and contractor will comply with during fabrication and test.

The second important DoDI 5000.02 document to understand is the Systems Engineering Plan (SEP). Like Systems Engineering Management Plans (SEMPs) that many contractor companies create, the SEP describes the engineering processes, tools, plans and schedules as determined by the government acquisition engineers. The SEP may be reviewed as high as the Pentagon, depending on the program’s acquisition category. It is considered a living document that changes as the program matures. It takes on different information as the program progresses through development maturity. Although the government continues to own and maintain the SEP they expect the contractor’s program management and engineers to not only contribute to the maintenance of the document but to synchronize any of their own SE processes and plans with it as well. It should be noted that the SEP must be updated and provided at key milestones throughout the acquisition process.

The third important item to reference is the DoD Architecture Framework (DoDAF). This is a series of pictorial and graphical representations of the system being developed. It can be thought of as the documentation of the functional and physical architectures. The top level diagram of the DoDAF is the Operational View -1 (OV-1). This is typically a concept type picture that shows how the system may be operated. Essential elements are shown in the OV-1 along with external elements that the system is expected to interface with. There are additional Operational View documents to further describe these system and external elements and how they are intended to operate.

Additionally, the DoDAF has other diagrams and documents under the major categories of Systems and Services View (SV-x) and Technical Standards View (TV-x). The SV articles should be closely watched since it typically contains specifics on interfaces to external entities and is used to derive Interface Control Documents. Note: there is also a higher level All View (AV) but systems engineers may not find those as beneficial.

The DoDAF is started by the government operational agency to denote what the system is and how they intend to use it. Their most important contribution is the Operational Views. After the government acquisition agency begins their program they will most likely take over the DoDAF and work out the details with the contractor(s) and external entities that include users and interfaces. They may even elect to have the contractor take over the maintenance of the DoDAF, but the government retains responsibility. There are several tools for developing a DoDAF including IBM’s Rational System Architect^©. Vitech’s CORE^© software tool allows the engineer to capture functional and physical architectures in traditional systems engineering methods and has a DoDAF output it can generate. As a minimum a contractor’s system engineers are expected to understand and work with a government generated DoDAF document for their program. They may also be involved with generating and maintaining the DoDAF at some point in the program. It is important to learn and understand the various aspects of this visualization method.

In summary, for the engineer who is working on government acquisition programs, there are specific rules and requirements he/she must follow to ensure compliance with the DoDI 5000.02 development process. The process and documents the government requires are in general good systems engineering practices. The biggest challenge to the systems engineer on a government program is to follow the right systems processes under very challenging schedules. In this aspect, working government programs is no different than commercial.