KEY: Structured Communication and Formal Risk Management
Open and honest communications up and down the chain of command as well as across the various development stakeholders and organizations is critical for success. Program leaders must create a culture where all team members are empowered and encouraged to identify and proactively communicate risks and associated mitigation techniques and plans. Leaders must not “shoot the messenger” when emergent high severity risks are identified.
Effective communication often suffers due to poor project estimation. Team members are behind schedule from day one and therefore “do not have time” to communicate on a regular basis with their peers, stakeholders and leaders. Lack of communication and miscommunication due to over-allocated engineers often results in requirements, design and interface problems detected very late in the development cycle which are very costly.
Project teams must establish a set of hierarchical and linked cost, schedule, technical performance indicators and quality measures. Cross discipline and team delivery interdependencies must be identified and closely tracked. All development teams must establish timely regular data-driven reviews to proactively assess and mitigate cost, schedule, technical, and quality performance risks.
A formal risk and opportunities board and process must be established and executed with discipline. The process must facilitate risks being identified and communicated on a frequent, regular interval and at the appropriate levels of leadership. All risks must always be addressed from the three perspectives of cost, schedule and technical performance impact. Risks must be formally documented via the standard 5×5 risk cubes; and each risk must have a documented mitigation plan with assigned individual(s) responsible for driving the risk to closure.
All status and risk reviews must have an assigned leader and well defined agenda and required participants. The discussions must be supported by objective data (planned vs actual cost and schedules, technical performance, and quality indicators, open versus closed risks over time, etc.) rather than subjective “red, yellow, green stoplight” type indicators.
One strength of Agile based development approaches is the requirement for key stakeholders to communicate on a daily basis. The project/product owners and leaders from the key engineering disciplines (requirements, design, code, test, safety, security, end-user, etc.) frequently communicate and stay in synch using efficient and well-structured meetings. This philosophy of frequent multi-stakeholder continuous communication can be adopted by waterfall based development teams by establishing regular multi-discipline and multi-stakeholder reviews. Projects must resist the temptation to frequently delay or cancel periodic risk and status reviews due to schedule pressure. Projects must establish the tools and processes to formally capture action items resulting from the frequent project control communication events and ensure that all actions are appropriately assigned and tracked to closure.
KEY: Early Defect Detection and Removal
It is well known that detecting and fixing defects late in the development cycle is very costly. However, many projects fail to make the investment in the tools, techniques, and methods that may cost a bit more in the short run, but provide for significant reduction in the program’s total ownership cost. As illustrated in the diagram above; models, simulations, tools, and test-drivers should be utilized throughout the development cycle to identify and remove defects as early as possible. But note that this requires projects to fund and account for the time and resources to develop and maintain these testing products and processes.
Automation of testing requires a steady investment and applied resources. Automated testing must be implemented at the unit and CSCI level as much as possible and not just at the later and higher level system integration activities. Investment must also be made in implementing a Data-Extraction and Data-Reduction capability. At a minimum, all data that is exchanged between the CSCIs and external systems must be extracted and time-tagged. In addition, key data elements, state changes, and system performance data should be recorded as well. The associated Data-Reduction system and tools must provide for automated detection of data out-of-sequence, out-of-range, and other processing not in accordance with requirements and design intent. The reduction tools must also enable the users to sort and search for specific extraction elements.
KEY: Architecting Multi-Mission and Multi-Platform Capable Software
It is not inherently natural for a profit based organization to provide Modular Open System Architecture (MOSA) approaches resulting in common system and software architectures that can be easily reused or quickly tailored to support multiple warfare missions on various multiple platforms. Government software teams are more apt to provide non-proprietary architectures and designs that are modular, scalable, portable, configurable, and with standardized interfaces that lead to higher system quality while also reducing cost and schedule.
Program Offices should address MOSA from both business and technical aspects in order to avoid “vendor lock” where they must rely on the original developer for all fixes and upgrades. The government and industry software development approach discussed in later sections facilitates:
- Increased: Competition, Innovation, Protection of government data rights
- Increased: System and Software Modularity, Scalability, Commonality, Maintainability, Reliability, Usability, Security, and Quality
- Decreased: Proprietary components, Duplication of design and implementation
The root cause for lack of well-architected MOSA systems is due to poor project estimation and the emphasis on rapid prototyping and speed to fleet. Rapid prototyping by definition prevents teams from investing the time required to establish a sound foundational architecture. They are focused on creating a “one off or 80%” solution as quickly as possible. While this approach may be required to address emergent critical threats; it is not a sound approach for significantly reducing DoD software acquisition cost and development timelines in the long run.
The vast majority of software engineers understand how to architect, design and implement MOSA systems (i.e. abstraction of the software application layer from the hardware, utilization of Virtualization, separation of the user-interface and application layers, utilization of Object Oriented Design (OOD) to abstract and make common the communication, sensor, weapon, engagement, and other interfaces; establishment of open standardized interfaces, etc.). The simple key is to allocate a bit more time and resources up front for sound architecture and design efforts.