Literature and experience suggest that while structures fail on a technical basis, the actual root cause of that failure is not solely a technical matter. This learning is common, and therefore systemic, within the practice of engineering. The corrective actions noted below suggest, in no intended order, those nontechnical matters that have driven a structure’s success or failure. Failure may be defined as a project not meeting the objectives of its major stakeholders. Whether new or retrofitted, a structure will be the outcome of a system of management. Structural engineering is one and only one part of that system. Perhaps the most unaddressed part of the system of management is the human side. Human Systems EngineeringTM recognizes and includes, with the same attention to detail as applications dealing with the technical side, anticipatable people-driven issues at the project, organizational, and individual level. The role of each component of the system of management is not to optimize its part but to focus on the intended outcome for that system. The specifics that follow are translatable, fundamental parts of the system of management derived from the application of Forensic Management. 1. Prepare, update, and apply at the executive level, an accept/ reject proposal checklist using the issues that follow. If you hear anyone on the proposal team use the words, “hope,” “try our best,” or “should,” reject the proposal. It may be the best work you never get. 2. Confirm the level of owner/user planned participation in the design and construction phases of the work. Document the name of the individual who will speak for the client in project-related matters. 3. Consider the potential for parts of the structure to be used in unintended ways. 4. Validate the owners/users understanding of, and budget for redundant systems. 5. Identify those parts of the applicable codes that are not sufficient for the intended design. Obtain the owner/users agreement to include above minimum code parameters in the budget. 6. Establish an Engineering Review Panel ERP to validate the design interpretation of the architect’s concept/schematic as well as critical points in the design and construction process. Examples might be for ERPs from Type 1 to Type 3, with Type 1 requiring a multidisciplinary review and travel to Type 3 requiring the review of appropriate documents and no travel. 7. Develop guidelines for a structural peer review for specific categories of structures e.g., buildings under or over 3 stories . 8. Work with geotechnical engineers who have long-term expe-