Systems Analysis and Control

A collection of activities designed to provide controls (as we call them in the automo-tive industry) exists to support the systems engineering function. A scrum team can accomplish this objective by analyzing the systems and subsystems using a process

failure mode and effects analysis (PFMEA) approach. The use of a scrum team in this application makes a lot of sense because PFMEA development is nearly always team based.

9.3.4.1 Trade-Off Studies

Trade-off studies involve comparisons of contractors, products, components, sub-systems, and systems in general. One of the best-known methods of developing a trade-off study is to use an approach called Pugh concept development. The process occurs as follows:

1. Develop a set of—potentially weighted—criteria based on customer’s require-ments, whether those are wants or needs.

2. Develop a group of design concepts, contractors, products, or other items aimed at satisfying the criteria we developed already.

3. Use as simple a matrix as possible and list criteria on the left and the concepts (products, contractors, etc.) across the top.

4. Select one of the concepts as a baseline, usually an existing product, contractor, or other.

5. Evaluate each concept (column heading) against the datum for each of the criteria (row heading). If an item is better, assign a ‘+’; if the same, assign a ‘0’;

or if it is worse than the baseline, assign a ‘−’. If we have a plethora of options we can add ‘+ +’ and ‘− −’ or assign numerical values. Do not make it more complicated as long as the array is working.

6. Record the decisions made by the team on a paper or spreadsheet.

7. For each column, we calculate the number of pluses, minuses, and sames or we can take the sum of the alternate score multiplied by weight of the criterion in much the same way as used during a quality function deployment.

8. Iterate the process of developing concepts.

More complex techniques exist; for example, the analytical hierarchy process. It is not so important what techniques we use, but rather that we achieve an equitable selection in what we are aiming to use. We recommend the Pugh approach because it is easy to use, simple to explain, and reasonably powerful. If the team understands the rationale behind the choices they make, they are more likely to support the choice than when management imposes the decision on them without their input.

9.3.4.2 System/Cost-Effectiveness Analysis

The system and cost-effectiveness analysis on a large project for the government will most likely be performed by a function dedicated to financial analysis; for example, the accounting department. Because budget and schedule reporting are central to the government approach, especially on military projects, we do not expect scrum teams to participate in this particular activity. That does not mean that an accounting department cannot use some kind of scrum approach for their own

Risk Identification

Risk Analysis

Risk Mitigation Planning

Risk Mitigation Plan Execution

Risk Monitoring

Figure 9.1 DoD and risk.

internal projects—instead, the regulatory requirements of a government project really expect a dedicated department. In general, the contract or contracts will spell out the reporting formats, the reporting intervals, and the functions that need to submit these cost status/cost reporting documents.

9.3.4.3 Risk Management

The plan for managing risk is an integral part of any government contract, regardless of the agency involved (see Figure 9.1). We have discussed risk management in other parts of this book and those rules will apply in this section as well. However, on large programs, a more formal level of documentation will be necessary to meet stan-dardized requirements. In other words, the format and reporting frequency for risk management will already be spelled out in the contract documents. It is possible that the scrum teams will participate in failure mode and effects analyses. A failure mode and effects analysis is a tool for anticipating failures and managing them before they occur. The failure mode and effects analysis is not specifically a scrum-based activity, but we see no good reason why the scrum teams should not perform this analysis.

9.3.4.4 Configuration Management

Configuration management is a requirement for any project (see Figure 9.2). Config-uration management per se is not a scrum activity—it is a repeated action performed by members of scrum teams to protect the intellectual property of the enterprise.

That means the scrum teams, the conventional teams, and any other contractor or developer will participate in configuration identification, configuration control, configuration status accounting, and configuration auditing. Note that a physical configuration audit is a typical part of a government contract and will involve veri-fying that the required documentation has been produced by all teams—including

Software Release NotesSoftware Release NotesSoftware Release Notes 1/12/20087/12/2008

2/1/20083/1/20084/1/20085/1/20086/1/20087/1/2008

Configuration Management Plan Software Release Schedule Hardware Release Schedule Software Planned Features Content (revision) Hardware Planned Features Content (revision) 1/31/2008 SW rev. 0.2 Scrum Hardware Release Notes

Conventional Hardware Release NotesConventional Hardware Release Notes

Scrum Work Package 1Conventional Work Package 1Conventional Work Package 2 1/24/2008 HW rev. 0.3

2/19/2008 SW rev. 0.1 2/29/2008 HW rev. 1.3

Integration Verification Work Package 1 5/17/2008 SW rev. 1.1 5/24/2008 HW rev. 2.4 Figure9.2Configurationmanagement.

the scrum teams. The functional configuration audit is a means by which the gov-ernment agency or department can verify that the product or process functions as required in the product specification.

9.3.4.5 Interface Management

Interface management becomes important when the government function uses a col-lection of contractors to deliver the final product. If the interfaces are not well-defined from the start of the project, it is unlikely the completed system will function as ex-pected. If the program is extremely large, the systems engineering function for the program managers will have to manage interfaces composed of various contractors.

That is interface management at the human level as opposed to the physical design of the product. Once the human resources are under control, we also need to manage the interfaces in the software and interfaces in the hardware, particularly if we are dealing with a significant number of subsystems (think “aircraft carrier”).

9.3.4.6 Data Management

If substantial data management hardware will be needed for the program, we will not use the scrum approach for that part of the activity. Scrum teams will generally protect their intellectual property by using some kind of formal configuration management system. In large government contracts, we may find a regulatory requirement that forces us to use substantial hardware resources in order to manage data. If we are dealing with the military, they may have pre-existing data requirements that will not change because we are using a scrum team for development.

9.3.4.7 Systems Engineering Master Schedule (SEMS)

The systems engineering master schedule is sometimes called the Integrated Master Plan. This planning document sits atop all other schedules and coordinates the pro-gram. Individual contractors develop their own schedules, which will be subordinate to the Integrated Master Plan. The goal of the Integrated Master Plan is to ensure that all phases and contributors to the project are synchronized. The existence of this plan does not agitate against the use of the scrum approach. If the plan is naive, it may lead to a simplistic waterfall method and we have already discussed the defects of this approach. Once again, we may be constrained by the requirements of the government agency, especially if we are dealing with the military.

9.3.4.8 Response to Change

We have already discussed how the scrum approach helps the enterprise to manage change. Although the government agencies generally require formal configuration management in order to protect the intellectual investment from the development work as well as to ensure delivery of the proper product, the scrum approach will fit into this formality as well as any other technique.

As usual, the short planning horizon and the rapid tempo will allow the scrum teams to flex with requirements changes. The use of configuration management or product data management software reduces the pain for all parties and provides an audit trail for the documentation.

9.4 Systems Engineering Output