In my first and second blog post I show that there appear to be differences in the way that government defines and applies strategic sourcing and category management as compared with Industry practice of the same. With this post I argue that federal government-wide information technology acquisition initiatives have historically been based on three false premises: the Fallacy of Enterprise Government, the Fallacy of Commodity IT, and the Fallacy of Equivalency between different government-wide acquisition vehicles. These fallacies are the assumed underpinning of federal strategic sourcing and category management as they have been enacted to date, but it isn't a view shared by most federal CIO offices, federal buying commands, or in the industry communities that serve the federal marketplace.
Enterprise Government
Argument - If the Federal Government were a company it would be among the largest, therefore we should receive enterprise pricing for the whole of government as if we were a Government-as-one.
Counterpoint – The government is not built like Citibank or other singular enterprise that is assumed comparable when this analogy is used. A better analogy would be Berkshire Hathaway: an entity with varied interests in a very diverse fields. After all, Berkshire Hathaway does not require that McDonalds and GEICO have the same IT assets, bought in the same way and under common and coordinated conditions, between separate entities.
This argument also does not consider different architectures, different agency missions, different funding cadences, different acquisition rules, different terms constructed for different government-wide vehicles, different writing systems, and different standards for security. The government does not function as it would a single enterprise. Enterprise Government is fine to say for a rallying cry, but activities and analysis should not be conducted as if this were true.
Again, Berkshire Hathaway's interests involve stakes in very different companies. Just like Dairy Queen, GIECO, Duracell, and BNSF Railways (all current Berkshire holdings) don’t share the same purchasing departments because of the types of business they are in, neither does the FDA, Bureau of Land Management, US Army Corp of Engineers and the Department of Education. Particularly for information technology, they don’t buy the same way, for the same reasons, under the same conditions, for the same purposes, with the same architecture, or under the same rules. This is why a single vehicle approach has lacked adoption for federal IT.
Commodity IT
Argument – Commercial IT should be akin to a commodity such as electricity, pork bellies, paper and pens, or window cleaner.
Counterpoint – The pace of change involving the IT sector will never logically fit the IT as a commodity view. A commodity cannot be used in a strategic manner to improve an agency’s performance, allow for experimentation, create actionable knowledge, surface new information that allows for innovations, or help improve business processes. A commodity, like a pencil, cannot accomplish these goals. We may reject the commoditization of information technology.
Commodity IT was introduced initially as an early aspiration associated with Cloud Computing. It was envisioned by some that a utility model of compute would emerge as a commodity market just had been done for electricity. Although cloud computing has become the standard delivery mechanism for industry, utility like compute has yet to emerge due to technical variations between providers.
Commodity IT was also associated with early strategic sourcing efforts as some wanted to view IT as they would pencils, pens, and paper (with little variation between brands or capabilities). This was a way for some to make easy comparisons between like items and simplify buying as a result. This would be closer to how a traditional commodity on the Chicago exchange would act, and it is self-evidently suspect to equate IT with pork bellies.
Lastly, Category Management as an initiative may have confused the term “commodity”. When a manufacturing or retail environment engaging in Category Management refers to something as a “commodity” they are referencing the buckets and categories of data based on attributes of items for the purpose of analysis and insights. That is very different from considering IT an item that would be akin to pork bellies or electricity, where no attributable differentiation exists.
False Equivalency
Argument – Schedules and GWACs can standardize their terms and pricing between and among the vehicles because they are all similar in scope.
Counterpoint – Although the scope of these vehicles may be very similar, unfortunately equivalency is not the case. The argument assumes that all vehicles were created in the same way, for the same purpose, and are structured similarly. Some vehicles are used closer than others to the point-of-sale, and the data fields, standards, and capture process are not identical between vehicles. OEMs, resellers, and distributors have different relationships, under different terms, with different vehicles.
The unique operational framework of each vehicle empowers the agencies to map their unique technical requirements and agency terms with the most compatible vehicle. Standardizing the terms and conditions and/or pricing among vehicles effectively reduces value to the agencies.
Conclusion/Recommendation
Just because you call a ham sandwich a banana doesn’t make it a fruit.
The desire for cross-vehicle comparisons is rooted in the false premises of “Government-as-One”. “Commodity IT”, and a “False Equivalency”. It causes government to ask the wrong questions, make the wrong comparisons, and draw the wrong (or uninformed) conclusions when it comes to assessing items or pricing data to understand what is happening in the federal marketplace. Data analytics that merely identify the range and means does not help agencies understand the conditions by which a price is achieved.
Previous efforts at analytics focused heavily on the left side tail of pricing and asked "How come all agencies cannot buy this IT Widget for $X?" Never has anyone asked, "Why is there variance to begin with?" Pricing is often a contingent function, and drawing out these contingencies via a contextual data analysis and then using that insight to outline these conditions would be very informative to federal buying commands so that they can understand and plan in accordance to their circumstances.
For example we can start by asking: What goes into a price? How does volume affect pricing? How does total vendor obligation affect unit pricing with the same vendor? How does bundling affect unit pricing? How does time/when an item was bought affect pricing? Are there significant variance in terms that affect pricing? A sun-setting product? A new release?
Doing this kind of data analysis across vehicles will not be workable because, unfortunately, not every vehicle captures the data needed to ask these kinds of questions. Some government-wide vehicles can tell you what happened under their platform yesterday (what was bought, by whom, along with what, for what amount), while others are required to back into their information via multi-source data sets and conduct data gymnastics just to achieve anything similar. Regardless, this is the type of information that would be most beneficial to buying commands as they plan and execute their IT purchasing in accordance with the conditions that suit their needs.