innovationchampion
commented
8 years ago I concur with utopia27; this plan is likely to do more harm than good.
The argument from my experience I'm an engineer at a Navy R&D lab. The Navy has an enterprise-wide software inventory management system called DADMS, which appears to have similar goals to the proposed software policy (http://www.doncio.navy.mil/TagResults.aspx?ID=22). DADMS has dramatically increased our cycle times and decreased our agility, with devastating effects on our innovation. We have an expensive standing bureaucracy to administer DADMS, and PhD scientists spending hours filling out multi-page forms with scores of fields to acquire free or low cost ($100s) state of the art software that has been developed by the national labs or leading universities, only to be told after several months of waiting that they can't have the software. I know of one case in which the scientist had to reinvent the software just to get job done. The best people don't put up with this, and we lose the best and the brightest to the private sector.
Mr. Frank Kendall, current Under Secretary of Defense for Acquisition, Technology and Logistics, together with Mr. Ashton Carter when he held that position, started an initiative they call Better Buying Power. To quote Mr. Kendall (http://dau.dodlive.mil/files/2015/12/DATL_JanFeb_2016.pdf):
Our technological superiority is at risk, and we must respond. This fact is the reason for BBP 3.0. The combination of cutting-edge, strategic and increasing investments made by potential adversaries, coupled with our own budgetary stress and global commitments, are causes for alarm. ... BBP 3.0 also includes the increased use of experimental prototypes and other measures designed to spur innovation—such as early concept definition by industry and monetary incentives to industry to develop and offer higher-than-threshold performance levels. We need to reduce cycle time, eliminate unproductive bureaucracy, and increase our agility by accepting more risk when it is warranted. All of these measures are BBP initiatives." (emphasis mine).
How big a problem does our R&D workforce think that DADMS is, and how contrary to the innovation our leaders are calling for? We have an internal suggestion system to further Better Buying Power. Of the hundreds of suggestions in that system, a suggestion that R&D work be exempted from DADMS received the second most votes, and by far the most number of comments. Yet our management tells us they can't do anything about it. Apparently it was imposed at too high a level in the organization.
In summary, the proposed software policy is completely inappropriate for R&D enterprises. I agree with utopia27 that it is also likely to cost more than it saves and interfere with mission effectiveness for the government as a whole.
The argument from best practices I have a graduate degree from a leading Industrial Engineering school, with a focus on management. I am also an avid follower of technology trends. It is from these perspectives that I offer the following observations that indicate that the proposed policy appears contrary to best practices:
- The proposed approach appears to be a classic example of "suboptimization". Organizations are complex systems (especially ones as vast as the US Government), and all aspects of the system tend to be interrelated. Optimizing one aspect in isolation usually leads to less than optimal performance of the organization as a whole. The process of managing all aspects of an organization at the same time, and thereby maximizing mission effectiveness and efficiency, needs to be done at a low enough level that the manager(s) understand the unique mission of the organization and the various tradeoffs that need to be made (http://blog.deming.org/2014/09/dr-deming-video-managing-the-organization-as-a-system/). This concept of sub optimization may be what utopia27 is referring to in mentioning the software management office not being mission focused.
- Attempting to fix a problem without systematically analyzing and addressing the root causes of the problem almost always leads to failure. While I don't doubt that there is waste in procurement of software in the US Government, have you thoroughly investigated the reasons for the waste, even through as simple a process as "the 5 whys"? (http://www.isixsigma.com/tools-templates/cause-effect/determine-root-cause-5-whys/). This may be a rather lame example, since I don't know the root causes of the waste, but assume for the sake of argument that some organizations are wasting money on software because they have excess money at the end of the fiscal year, and need to spend it to prevent a reduction in next year's budget. The root cause of the waste is the perverse incentives to spend all the money. If you attempt to control software waste without identifying and correcting the root cause, the organization will either find a way to circumvent your regulations and waste money on software anyway, or will find something else to waste the money on.
- Centralizing decision-making at the highest level, which the proposed policy appears to do, is contrary to the widely accepted principle that decisions need to be pushed down to the lowest possible level.
- If everyone in the government uses the same software in the same way, there will be no way to experiment with the most effective way of doing things. Google, arguably the best company of our time, continually runs numerous simultaneous experiments and collects data to determine what works best. The proposed policy appears diametrically opposed to this best practice of continual experimentation.
- Standardizing on one or a few software configurations across the government reduces diversity and inhibits innovation. The resulting monoculture favors one or a few companies, perhaps at the expense of the most innovative startups. Monocultures are also less robust against security breaches, where one undiscovered (by the government) security vulnerability exposes all government computers.
- The proposed policy appears to assume that software is an expensive commodity, and will remain so. The trend I see is that software is becoming cheaper and in many cases free, and the value is be derived from data aggregation and support services.
- One example is comments I saw on an article regarding your proposed software policy. Some government statisticians were complaining about the fact that they were forced to use very expensive commercial statistics software, and that they had no control over the queries they could perform, and had to wait a long time to get the results of the query back. What they wanted to do, but weren't allowed to, was use the free R statistics software that is used for the vast majority of statistics research. Not only would they save the government the very large licensing fees, they would be able to work interactively and get immediate feedback from the data they were working with.
- A second example of the "software is cheap" trend is the recent announcement by Google that they were releasing their state-of-the-art TensorFlow system as open source. That made no sense from the perspective that software is expensive. Apparently Google sees their real competitive advantage is the data they have collected, and believe that it is to their advantage to give away the software to build an ecosystem around their products.
- Bureaucracies tend to take on a life of their own, and to become self justifying. If the "software is cheap" trend is real and continues, any organization you set up now will become increasingly irrelevant. If software is free, there is no money for the organization to save, yet people will attempt to keep their jobs and will attempt to find ways of controlling thing they shouldn't be controlling. I believe it would be wise to design mechanisms for the obsolescence of the organization from the outset.
It is my hope that these comments are helpful.
My experience with enterprise-wide software license management has been constant and consistent failure. Contracts are allowed to lapse. Technical support is not adequately supported (particularly accounts/POC lines for technical personnel that actually execute the technical interface). Important elements of software lines are not included (or better, 'dropped' with no notice) and then are impossible to re-license. Changes to line item (or bundle) by vendors are not properly tracked, no notification to license holders is given, Allocation of costs is unreliable and unpredictable ("How much do I need to budget to renew my program's licenses for ABC software?" "Pricing isn't final yet, and we haven't finalized next year's buy. We'll send you a bill" "But that doesn't help my program budget development."). Oh - and my favorite - periodic recompetition of software fundamental to technical solutions ("a database is a database, why do you care if it's MS SQL, Oracle, or MySQL?", "Because you're about to break mission critical systems, and drive them onto expensive, high-risk rearchitecting. They are NOT form-fit compatible").
I have seen these issues re-appear in every organization that I have seen pursue centralized software licensing management - private sector, public sector - DoD, DHS. The incentive structure is entirely misaligned for the software management office - they are (uniformly) understaffed, overwhelmed, and not knowledgeable on the products they are managing. Software management offices are evaluated on compliance with reporting, and on meeting fiscal targets. At the extreme, every software management office I have seen would get better evaluations if they reduced all software expenditure to zero, and successfully filed weekly reports showing no cost growth, and 100% licensing compliance - i.e. if they turned off all the computers. Because the goals of the office are not mission-focused, but are administratively derived.
If you really want this to work, require that the position of software manager (and deputy) be filled on a rotating basis (temp not to exceed 18 mos) from an interior hire that has no less than 3 yrs program management experience (along with the requisite DAWIA certifications). Provide them with adequate staff and funding, and measure them on the ability of the organization to deliver to mission. Until that happens, software management offices will continue to be an albatross and a bureaucratic mire.
Oh - did I mention that the office won't be cheap? If you're looking for cost savings from enterprise licensure, please keep in the forefront of all planning that all cost savings (and much more) will be consumed by management and overhead.