The good stuff is in the PDF: https://www.gao.gov/assets/700/694913.pdf - Running a port scan caused the weapons system to fail - One admin password for a system was guessed in nine seconds - "Nearly all major acquisition programs that were operationally tested between 2012 and 2017 had mission-critical cyber vulnerabilities that adversaries could compromise." - Taking over systems was pretty much playing on easy mod…
> Test reports we reviewed make it clear that simply having cybersecurity controls does not mean a system is secure. How the controls are implemented can significantly affect cybersecurity. For example, one test report we reviewed indicated that the system had implemented rolebased access control, but internal system communications were unencrypted. Because the system’s internal communications were unencrypted, a reg…
Since then, however, there has been the constant desire to deskill workers. That is, they want explicit operating/work instructions that mean even a trained monkey could do the job. This is useful for some things (got a broken down Jeep? Pull out the manual and even your Lt can fix it!), but for development, acquisitions, and sustainment this is actually a horrible idea.
The infection of deskilling spread to the office. They've removed the office managers (among others) and left the work (critical, but time consuming and secondary to the mission) with the highly educated and trained staff. This diminishes their ability to focus on real work (see [0] from yesterday). From there, they continued to try to document precisely how engineering work is done. Believing that the process of the work is the same as the work. So if only my engineers knew how to properly fill out SF-1234 it wouldn't matter how educated they are, magically the work would be done.
Of course, we all know this is bullshit. Knowledge work is called that for a reason. The capacity for work is based on the knowledge of the workers. You cannot deskill computer science or aerospace engineering. You can deskill aspects of it, or really the workflow, but not the science and engineering work itself. I can eliminate or largely reduce the need for a classical configuration manager by establishing a (automated) peer review and version control workflow. But the creative act producing content that enters the workflow will always require skilled, competent, knowledgeable engineers and scientists.
[0] https://news.ycombinator.com/item?id=18157885
EDIT: I will not change the above, but I will make a note. After re-reading the Wikipedia page on Scientific Management [1] I see that some people consider Lean and others to also be extensions of it. So read the above as describing Fordism and Taylorism, not scientific management in general. Any management largely based on, or influenced by, statistics, models, and experimentantion could be argued to be "scientific management", that doesn't mean it's bad. It's when it's taken to an extreme. Like, in Taylor's case, where workers are treated with contempt. The purpose of the management being to make them fully expendable. They had no unique knowledge or skills that could really contribute to the business beyond their physical presence and ability to follow directions. His goal was to disempower workers, whereas other examples (Lean particularly) work to empower workers.