Many people – myself included – feel there is something a little unsavory about the whole concept of a defined organizational structure. After all, we’re responsible professionals, so why do we need to bother with establishing a pecking order? Why not just take the “let a thousand flowers bloom” approach and pick the best ideas from the available options that emerge? Some environments do lend themselves to this egalitarian approach, but large-scale system development isn’t one of them. And a defined organizational structure really isn’t about declaring that one person is more important or influential than another. It is about organizing the project team so the work can be accomplished efficiently and correctly. Here are a few specific reasons why I believe it is beneficial to spend time to define the project team’s organizational structure:
- There are too many tasks to be performed and issues to be resolved to just hope someone will take up the mantle for each one. The creation of an organizational structure is about much more than assigning job titles and arranging them in a hierarchy. Project responsibilities must be clearly defined and deconflicted. The development of a project’s organizational structure should be a direct outgrowth of the project planning process that defines tasks and establishes execution processes and schedules.
- Without clearly defined areas of responsibility, the customer interaction will be chaotic and confusing. The customer community will be asked the same set of questions by different members of the contractor’s staff and each is likely to present an incomplete and inconsistent vision of the system. This will ultimately undermine the customer’s confidence in the contractor.
- Authority and accountability must be commensurate with responsibility. A person should not be given a responsibility without control over the resources necessary to be successful. Similarly, the program staff are depending upon each other to fulfill their responsibilities and they should be held accountable if they fail to do so. A lack of accountability is a significant disincentive to others. Part of the process of defining an organizational structure is to establish authority over resources and supervisory chains of accountability.
- Organizational structures should be designed to prevent the emergence of some of the less-desirable aspects of human nature, such as information hoarding or a survival-of-the-fittest atmosphere where the most dominant personalities rule. Such environments often fill the vacuum left by a poorly-defined organizational structure.
- It can be chaotic and ultimately demoralizing to work on a project where responsibilities and authority are unclear. The organizational structure, along with defined roles and responsibilities, should be clearly communicated to the program staff.
Like all aspects of Program Management, the organizational structure should be assessed continuously and modified as necessary to meet the needs of the program.
Readers who are unfamiliar with the complexity of large-scale systems often procured by the Defense and Intelligence communities may be wondering why I’m placing so much emphasis on defining an org structure. On small software-only projects – such as developing a desktop application – it might be sufficient to toss a dozen programmers into a room and expect a software application to come together in a few months (although plenty of evidence suggests this too is naive thinking). But these large-scale systems can involve hundreds of staff with different engineering specialties across dozens of different companies and geographic locations. I’ve created the org chart below to illustrate the types of roles often required for large systems. This chart is based on a fictional satellite system. I’ve personally never worked on a satellite system but it serves as a close stand-in for some of my experiences and allows me to discuss aspects of the organizational structures I’ve seen without referencing actual projects.
I should emphasize that this org chart really only drills down to the lowest level of management. Under each of the terminal boxes is where one would find the dozens of engineers who build the various subsystems that integrate to become the overall system.
Here are descriptions of the responsibilities for each of the segments illustrated above:
Systems Engineering Integration & Test (SEIT) – Like the name implies, responsible for overall Systems Engineering and Testing activities along with facilitating cross-segment integration.
Ground Control Station Segment – Responsible for the command and control of the satellite, sensor command and control, ground processing of collected imagery, dissemination of sensor products to consumers and accepting and scheduling sensor collection tasks from distributed sources.
Launch Vehicle Segment – Responsible for getting the satellite into orbit, which involves guidance and control, propulsion and design of the rocket superstructure. This is segment is somewhat difficult to specify in generic terms. For example, some satellites are launched via the Space Shuttle and so this team would be primarily focused on integrating with the Shuttle’s payload bay. Other satellites are launched through an existing rocket program, usually sponsored by the DoD and, again, this team would be focused on integrating the satellite with that rocket and ensuring the rocket can be controlled appropriately to launch the satellite into the proper orbit.
Satellite Segment – Responsible for constructing the satellite superstructure and on-board systems for propulsion, power, heat dissipation (thermal) and guidance and control.
Payload Segment – Responsible for developing the sensors that reside on the satellite, such as electro-optical, infrared or radar sensors. This may involve the development of some of the ground processing equipment as well, since the design of the sensor hardware and the image processing algorithms are inextricably linked.
Communications Segment – Responsible for all communication links between the ground and the launch vehicle and satellite as well as the terrestrial links between the ground control station and external entities that will submit collection requests and receive imagery products.
Support Segment – Responsible for training ground personnel in the operation of the satellite and sensors and deploys software and hardware upgrades to the ground control station and to the satellite during the O&M (operations & maintenance) phase of the program.
Contracts and Accounting – Responsible for all of the programs business management, including financial oversight of subcontractors and the internal teams, and ensuring contractual obligations are met.
For those new to building such large systems, I’m hoping this example provides some insight into the challenges of organizing and managing the project team.
Here are a few of the issues I’d like to explore in future posts:
- Interaction across teams in large-scale projects can be difficult because of the diversity of specialize engineering disciplines that span the segments. From the example described in the graphic above, the Ground Control Station, Satellite and Payload Segment teams will need to agree on an interface between the satellite’s subsystems and the payload systems for the purposes of command and control, telemetry and sensor product download, among others. And this cannot be accomplished without the participation of the Communication segment. In my experience, the engineers in each of the corresponding disciplines speak different languages, which can make it difficult to truly represent all relevant issues and arrive at a consensus. What’s the best way to facilitate cross-segment, cross discipline coordination?
- How do we define responsibilities for Systems Engineers? Notice in the org chart the SEIT segment is devoted exclusively to Systems Engineering, but we also have Systems Engineering staff within most of the other segments. Typically the SEIT group will focus on defining the overall system concept of operations (conops) and in allocating system-level requirements down to the segment level, since the scope of a single system-level requirement may span multiple segments. The System Engineering teams within each segment must participate in the allocation of system-level requirements to the segments because of the specialized expertise involved in requirements analysis. These segment teams continue the work of deriving the segment-level requirements and writing Software Requirements Specifications (SRSs), which they feed to the software engineering team. This all seems straightforward, but how do we organize systems engineering activities across segments and what artifacts do we create (e.g. use cases) so that information is capture precisely and communicated effectively? I’ve found it to be harder than it seems.
- Can we define management processes, design and development methodologies and artifacts so that they are applicable across all segments or must the processes be unique for each depending on the nature of the work? Most of the literature with which I am familiar focuses on processes and design methodologies specific to application and system software development. Can these approaches be extended to these system-of-systems projects that include the development of hardware and embedded software?
- What are the pros/cons of special roles, like Chief Engineer or System Architect (depicted with the dashed boxes in the diagram)? I have concerns about the efficacy of such roles, given that they may have poorly-defined responsibilities and may not have clear authority over any resources. Some projects institute review processes, such as an Engineering Review Board chaired by the Chief Engineer, that give these roles decision authority over certain aspects of design and development. On large projects it does seem there is utility in these special roles, given they have reach across the segments, but I think their responsibilities have to be clearly defined and their authority over specific processes has to spelled out.
I will attempt to address some of these issues in future posts but I would also like to gather feedback from others. What are your experiences with organizing large technology projects?