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.

Agile and Lean product development management principles (see Figure 1) were combined with standard project management processes and tools in order to develop the ConOps document. Notably, the ConOps project team took the approach of delivering incremental versions of the ConOps document to the client at the end of each ‘sprint’ period (in accordance with the Agile product development methodology). This deviated from the traditional, sequential product development process in which each stage of the project development lifecycle has to be completed before proceeding to the next and the product is released at the final stage of the lifecycle.

The advantages of the incremental approach in the Agile development process were that the project team was able to incorporate client and stakeholder feedback continuously throughout the project and avoid the typical late surprises common to the sequential project lifecycle approaches.

As an output of project planning and risk management activities, the following project objectives were identified:

• satisfy the client through early and often delivery of ConOps increments (‘sprints’);
• implement changes from ConOps reviews and walk-throughs (sprint reviews), incorporating comments into each new revision of the ConOps before next release;
• deliver ‘shippable’ versions of the ConOps frequently, with an average of three weeks between sprints, keeping the team focused and the client apprised of the progress;
• work together with the client in frequent stakeholder meetings throughout the project and meet in person whenever possible;
• bring in experienced and highly motivated team-members;
• use the released versions of the ConOps as a measure of progress (demonstrating earned value);
• provide continuous attention to technical excellence, using best practices and building trust with the client; and
• deliver the ConOps to the client’s satisfaction within the project budget.

Based on the 14 week timeline it was decided that the ConOps would be delivered over the following five sprint reviews.

• Annotated Outline: The purpose was to agree on the ConOps ‘system’ requirements (i.e., the stakeholders’ needs), and define the architecture (the boundary and structure of the ConOps document).
• In-Progress ConOps: The objective was to define the boundary of the PCS system-of-interest (SoI) and to understand and describe the ‘as-is’ system architecture, users, functions, and capability. This was undertaken over an intensive three week period during which a number of site visits and structured stakeholder interviews were held alongside a comprehensive review of technical/operational reference material.
• Draft ConOps: The objective was to develop a concept for the ‘to-be’ system (or future state) jointly with users, stakeholders, and engineering staff, to identify and evaluate the gaps between the ‘as-is’ and ‘to-be’ states, and to brief decision-makers on the ConOps and gain acceptance of the principles and requirements captured within it.
• Pre-Final ConOps: The objective was to evaluate the gaps between the ‘as-is’ and ‘to-be’ systems, and develop a migration strategy for seamless deployment of the upgraded power control system, and to provide a complete set of system and process requirements for inclusion in the PCS specification. The outcome of this sprint was the pre-final ConOps, effectively the completed ConOps document subject to final review, update, and approval.
• Signed ConOps: The purpose was to distribute the updated pre-final version of the ConOps to the key decision makers (identified from the stakeholder management planning stage in the 1st sprint) for their approval as confirmed by their signatures on the final ConOps document.

The ‘annotated outline’ sprint review was due after two weeks, with each of the other sprints being scheduled at regular three week intervals.

Despite a demanding 14 week timeline during the summer season, a large and diverse stakeholder group, a geographically distributed team working across two continents and 8 time-zones, and a fixed scope and budget, the ConOps was delivered on time and under budget, meeting and exceeding the expectations of our client and resulting in a successful project delivery.

The project combined and tailored elements of the following into an integrated project management approach: Project Management Institute’s PMBOK (Project Management Body of Knowledge) Guide, International Council on Systems Engineering (INCOSE) Systems Engineering Handbook (SEH), ‘Scrum’ as the Agile Product Development Framework, and the Lean Product Development Flow Method (Figure 1).

Operating in a fixed scope, cost, and time environment required the use of the traditional project management tools and techniques following the PMBOK, and thorough project planning contributed significantly to the project success. The detailed work breakdown structure with clearly identified work packages, responsibilities, and due dates served as a strong communication tool and as the basis for project monitoring, control, and progress reporting to the client.

Applying the INCOSE SEH technical processes within the project management process framework (PMBOK) helped in the selection of the right ConOps ‘system architecture’ and in identifying the ConOps ‘system elements’. Both served as inputs in the traditional project management activities (Figure 2), such as the work breakdown structure (WBS), cost, and time management and risk management.

Agile and Lean methodologies contributed to keeping the stakeholders engaged in getting feedback early and often and incorporating it into the next ConOps increment. The approach encouraged the team to stay focused in a constant work effort towards achieving project success.

Systems Engineering Approach

The main systems engineering deliverable of this project was the ConOps for the power control system. Two major industry-recognized standards exist that outline the ConOps structure: ANSI/AIAA Guide to the Preparation of Operational Concept Documents (ANSI/AIAA-G-043) and the IEEE Guide for Information Technology-System Definition-Concept of Operations Document (IEEE-1362) (see Figure 3). The latter is widely recognized as lending itself more to upgrades of existing systems, and was therefore preferred over the ANSI/AIAA standard for the PCS ConOps structure.

Figure 4 provides an overview of the ConOps structure, which had been tailored to the needs of this project during the first sprint. While the IEE standard was adopted, a notable variation to the ConOps was the inclusion of an Alternative System Review section to address the client’s specific requirement for an international best practices review.

Conclusion

While this article describes the integrated project management approach for a specific project - the upgrade of the power control system (PCS) for a large transit agency - the authors are convinced that it can be successfully applied to any other product development. The application of the project management and systems engineering processes described in the paper resulted in the project being delivered on time, within budget, and meeting the expectations of the client.

Conway’s law was avoided through the application of Agile and Lean approaches and many of the common challenges that ‘waterfall’ (sequential) project lifecycles incur at the end stages were also avoided by seeking early agreement on the client’s requirements and continuous review/feedback at the completion of each ‘sprint’. This enabled the completed ConOps to be delivered, including sign-off approvals, within a timescales of 14 weeks; considerably shorter than typical ConOps production.

This project also demonstrated the successful collaboration between the Rail and Transit Global Technical Excellence (GTE) Center of WSP in the UK and the US.

The full version (15 pages) of this article was cowritten with Steven Turner from the London office and was accepted for the INCOSE International Symposium in July 2016 in Edinburgh, Scotland, UK.