U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590

Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

4.8 Systems Engineering Organization



This chapter describes typical systems engineering organizations and the role these organizations play in the development of ITS.

What makes an effective organization?

Effective systems engineering requires an integrated organizational structure with the following characteristics:

  • is flexible to support a range of project types
  • facilitates clear communications
  • has defined roles and responsibilities
  • can be scaled to small or large project teams
  • related activities are together as a team [organizational entity]

Because a system is being developed, the various disciplines that make up these teams, [For example hardware, software, or human-machine interface] are not independent of one another. Cross-coordination must be ongoing throughout project development. Continuing communication across disciplines is an essential function of the project organization for successful system development.

Specifically, the key criteria for an effective system management organization as adapted from Wilton P. Chase’s Management of Systems Engineering are:

  • facilitate communications
  • streamline controls
  • simplify the paper work
  • types of organizational structures
  • relationships to consultants and vendors

The following is an explanation of each.

Facilitate communications

Few of the problems that arise in developing a system can be solved by a single discipline. Each provides a way of looking at the system. Complete understanding requires integrating these perspectives. This system view is an ongoing need. Therefore, the various team members must coordinate as the system is being developed. They must understand the viewpoint of the others and communicate in a language understandable to all.

Streamline controls

A clear statement and understanding of the level of detail to be controlled at the project level makes management more efficient. It keeps the managers from slipping into too much detail emanating from their respective backgrounds. The process steps in Chapter 4.10 give guidance on how to tailor the process appropriately.

Simplify the paperwork

Standardized documentation is essential for efficient system management to record and transmit analyses, plans, and designs. During much of the systems engineering process, documentation is the only product. The system design is described only by specification. The following chapters of the Guidebook provide guidelines for developing documents appropriate to the scale and complexity of the project at hand.

Types of organizational structures

Functional          One common approach is a functional configuration. Here each functional specialty or discipline is assigned to individual organizational entities. As an example, consider a systems engineering team who performs all systems engineering across all projects. This works best for small projects, where the team members may be working on several projects at once. Communications problems can occur for larger projects when sub-system teams are created. The risk is the sub-system teams may optimize for the sub-systems, not the system. Also, integration may be difficult since the pieces have been developed independently. This means that frequent cross-disciplinary communication and consideration of the system-level issues are essential.

Project The other approach is centered on projects, not disciplines. All those working on a project, no matter what their specialty, will report [possibly indirectly] to the project manager. This works only if the project is so large and long-term that the specialists can devote themselves to it for an extended period.

Matrix A hybrid approach, the matrix management structure, exists when team members report to both project and functional management. This approach is effective for large, long-term projects.

The Project Office approach, calls for project management, systems engineering, and design teams to be organized by project, and request project support from the functional staff as needed. This works for a moderate sized project, when only the key individuals devote full time to the project. The specialists work on multiple projects.

Integrated Product Team [IPT] this team consists of both agency and contractor representatives. They work together to develop the system that meets the project’s needs. In a large project, there are often mirror functions in the agency and contractor teams. For example, each has a program manager and a systems engineer. They work closely with their counterpart in the IPT. Further, representatives of each of the disciplines are a part of the IPT to ensure essential cross-discipline communication. Additionally, IPT’s may be formed to address key cross-discipline issues, such as cost of ownership, overall system performance, or configuration management.

Example organizational roles

Figure 4‑7 is an example of roles that are generally required for a successful systems engineering organization [adapted from Chase]. This may appear frighteningly complex, especially for an agency that typically does small projects. The important thing is that each box represents a role, not a department or an individual. A simple project may only require two people: a project manager and a systems engineer. Administrative functions assist on an as-needed basis. For larger organizations that manage more complex projects, this is a template for structuring groups with like activities together while maintaining system-level oversight and coordination.

There are three major activities in the organization: project management, systems engineering, and project control. Project management is concerned with planning and execution. Project control tracks the effort relative to performance, cost, and schedule goals. The same person may assume these two roles. Systems engineering is responsible for design, implementation, and verification.

Relationship to consultants and vendors

There is no single, correct, organizational structure. It needs to be tailored for each team based on existing structures and capabilities within the agency. It should take effective advantage of in-house expertise, existing working relationships, and communication paths. There are no standard roles for agencies and contractors. Agencies can [and often will] develop their own software, for example. Similarly, an agency may choose to outsource oversight activities. The only caveat is that there are certain activities which can only be performed by the agency. These key activities are listed for each step in the process throughout Chapter 3. The keys to a successful team that includes consultants are: appropriate roles and frequent, frank communications.

Shows an example hierarchical organization structure for a systems engineering organization.

Figure ‑7 Example Organization


Return to top
Page last modified on September 20, 2016
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000