Conway’s law suggests that: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of those organizations.” (Conway, 1968). This often results in stovepipe (silo-engineered) designs that run into significant challenges during integration, verification and validation, transitioning into operation, and client acceptance. This presents a significant risk of project delays, necessitates rework resulting in cost increases, unsatisfied stakeholders, and consequently reflects poorly on the performance of the project manager and the responsible organization.
This case study describes how project management and systems engineering approaches were combined to produce a concept of operations (ConOps) document for the replacement power control system (PCS) for a large rail transit agency in the US. The PCS monitors and controls the remote electrical plant located in traction power substations (TPSS) and circuit breaker houses (CBH) that supply traction power to the railway. The purpose of a ConOps document is to describe the functional characteristics of the to-be delivered system from the user’s viewpoint.
An innovative approach was used that treated the ConOps document as a ‘system’ in its own right. The ConOps document was developed incrementally and in a highly flexible and interactive manner, thereby avoiding Conway’s law.
Concept of Operations (ConOps) Document
The client, a large transit agency in the US, was seeking consultant systems engineering services to facilitate and support the development of a concept of operations (ConOps) for the upgrade of a power control system (PCS).
The ConOps ensures a common understanding between the end users of the system (including operators and maintainers) and the designers/implementers as to the purpose and functionality of the future PCS:
- what it will do,
- how it will be used, and
- who will be using it.
It also serves as an agreement between the stakeholders as to:
- the high-level system functionality and capability that will be delivered, and
- the resources that will be needed to operate and maintain it.
For this project, the ConOps document was considered as a ‘system’ and delivered in increments (referred to as ‘sprints’). The ConOps ‘system’ was delivered early and often over a number of sprints, each increment providing a valuable and ‘shippable’ product (the ConOps document) to the client. Risk was reduced significantly by integrating all ‘system elements’ in regular intervals and presenting them for buy-in to the client.