Recently I learned that an EBook on Amazon.com titled “Austerity, Greece’s Debt Crisis and the Theft of Democracy” included a chapter titled “The Information Technology Problem” that discussed my articles on Naked Capitalism and those of Australian economist Billy Mitchell who has an unrealistic take on the amount of work required to modify Greek computer systems to handle a return to the drachma.
Joseph Firestone, the author of the EBook, has a PhD in Political Science from Michigan State, over 150 articles to his name, and an extensive background in IT but mostly at the management level. Right now he is the Chief Knowledge Officer of a company called Executive Information Systems, a title that most likely has something to do with Knowledge Management, his area of expertise. This is apparently a field that has emerged since 1991 but one that somehow managed to elude Columbia University where I worked from that year until my retirement in 2012. There will be something about it later in this article by another expert in the field.
Firestone tries to reconcile Mitchell’s views and my own, probably something that irritated the economist emeritus much more than it does me given his irascible reaction to my first article on Naked Capitalism. His tone reminded me of the one I take on issues such as when the Russian Revolution went off the rails but let’s leave that aside and move on to the substantive IT issues.
From Firestone I learned that Mitchell had a short follow-up article that somehow escaped my attention. Using the authority of a friend who appears to be as high-powered as Firestone, a man who “owns a significant private firm in Europe which is at the forefront of delivering innovative card payment services to banks and corporations throughout the Eurozone”, Mitchell sought once again to buttress his “its not rocket science” understanding of the IT issues.
The friend confided to him that since “the Euro was integrated ‘on-top’ of the existing legacy IT payment systems”, ‘switching’ the Drachma back on would not be such a major task.” He added:
the Grexit should be accomplished by stealth. He would leave everything in place as it is for now. Then establish, in secret, a public bank (like the German KfW), procure the banking software out-of-the-box, sign a contract with a major card-scheme to use its network for transactions and hook the bank up with the official Bank of Greece, the nation’s central bank.
I wonder if this plagiarized or at least conveyed the madcap spirit of Varoufakis’s “Plan B”. If they ever made a movie about such a scheme, I’d cast Steve Carell in the leading role (only because Peter Sellers is dead.)
In terms of the Euro being integrated on top of the legacy systems, I have no way of assessing this. As someone who has taken part in at least a dozen feasibility studies over the years, I have learned that it is best to be cautious. Apparently the higher up you are in the IT food chain, the easier it is to throw caution to the wind.
In the late 90s I advised IT management at Columbia to avoid purchasing a Facilities Management System from American Management Systems (AMS). This was an outfit that Robert McNamara’s aides in the Pentagon founded in 1970. That should have been a warning from the outset to steer clear. Within six months after the system was implemented at the cost of millions of dollars, the users decided it did not meet their needs and dumped it. Just a few years later AMS went under, no doubt partly a result of Mississippi terminating an $11.2 million contract to modernize the state’s tax system. It would go on to sue the company for $985 million. Wikipedia states: “a jury awarded the state $474.5 million in actual and punitive damages in August 2000, causing a drop in stock price from 44 3/8 to 14. The company subsequently settled the suit for $185 million.” You can bet that if Greece ever needed consulting help to get them back into the drachma, there would be latter-day versions of AMS knocking at its doors.
Furthermore, with all due respect to Mitchell and his friend who “delivers innovative card payment services to banks and corporations throughout the Eurozone”, there is more to IT in Greece than banking and credit card processing. Greece has hospitals, universities, wholesale and retail companies selling furniture, yogurt, olive oil, tourist accommodations, and Zeus knows what else. Many of these companies do not have in-house staffs. Getting them up and running on a drachma will not be a piece of cake—trust me on that.
For Firestone to bridge the gap between Mitchell and myself, he invokes his own particular areas of expertise that supposedly get us closer to “it’s not rocket science”. Naturally this require some critical commentary.
In a section titled “Web-oriented Architecture Approach to a Drachma-based Transaction System”, he advises “web-enabling a legacy system”, something that might take a “few days, if that long”. Well, gosh, why hadn’t he brought that to Varoufakis’s attention? That would have saved him from the trouble of lining up his pal at Columbia University to program a stealth-based “Plan B”. Firestone even offers up the names of some products that could be off-the-shelf solutions such as the one marketed by the slyly named Kapow Software. While this software no doubt works as advertised in terms of integrating different systems under a web-based front end, it has little to do with the complexities of batch processing—the meat and potatoes of all banking applications for which there is no user interface. Kapow might be of some use to a bank officer evaluating a loan application from a nervous customer sitting opposite him or her, but it is totally irrelevant to a stream of programs run at 3am in the morning that pump out customer statements. A customer statement like the kind that you receive from your friendly banker at the end of the month with a listing of your debits and credits followed by an account total. It is exactly programs such as these that will require onerous and time-consuming attention—nothing that Kapow can address.
Finally, returning to Firestone’s Knowledge Management, he starts off by wisely acknowledging that “people avoided mainframe applications wherever they could, because the chances of failure were so high”. He includes himself in that group. That being said, he regards the Kapow approach as an interim solution and concludes that a “better solution” would be to develop a new system written for the mainframe from scratch “using modern programming tools and techniques”—no doubt drawn from the Knowledge Management toolbox.
All I can say is that ever since the mid 1970s, I have heard about one new technique or another that would finally make developing large-scale systems more averse to failure. They were put forward either as management, systems analysis, database or programming technologies in trade journals such as Datamation or Computerworld:
—programmerless programming: Languages such as MarkIV would allow an end user to build a system by using to specify parameters that satisfied business requirements. In fact I automated Salomon Brothers in London (SBIL) when I reported to Michael Bloomberg in 1977. Trust me, Michael couldn’t have done anything in MarkIV if his life depended on it.
—goto less programming: The less said the better. I stopped using the “go to” in 1978 or so but deadlines were still missed because the user kept changing his or her mind—the real explanation for most software delays.
—structured design methodologies: I worked for a consulting company that employed SDM for a phone company project that would evaluate whether a customer would be charged for a phone call that they claimed that they didn’t make. When the consulting company demanded new funding because the project was delayed, negotiations broke down and we were escorted out of the building by security guards. SDM did not address user indecision, the cause of cost overruns.
—relational databases: This was a huge breakthrough supposedly because it organized data into rows and columns just like a spreadsheet that could be accessed through SQL and best when it was based on normalized data structures, which meant avoiding redundancies through a data analysis of the firm. I can only say that I have worked with VSAM flat files, IBM’s IMS hierarchical database, Cullinet’s IDMS network database before finally becoming a Sybase support person on my project team at Columbia University. All of them work just fine even though Sybase (and Oracle) are best suited for client-server or web-based applications. But in the final analysis, it is the problem of nailing down user requirements that will always bite you in the ass. Given the economic chaos in Greece, this will be a thousand times worse than the normal chaotic situation.
–Object orientation: I spent about five years developing Java programs in the STRUTS framework for Columbia University’s financial system. Anybody who sells OO as some kind of silver bullet should get one in the head.
Since I have never gone near Knowledge Management, I won’t say a word about it although I would be remiss if I did not refer you to this:
Wall Street Journal, Jun 24, 2015
Whatever Happened to Knowledge Management?
By Thomas H. Davenport
I would never claim to have invented knowledge management, but I confess to an intimate involvement with it. I co-authored (with my friend Larry Prusak) one of the best selling books on the topic (in case you are into the classics, it was Working Knowledge: How Organizations Manage What They Know) and am supposedly the second-most cited researcher in the field (after the Japanese scholar Ikujiro Nonaka).
So I should know whereof I speak when I say that knowledge management isn’t dead, but it’s gasping for breath. First, the ongoing evidence of a pulse: academics still write about it, and some organizations (most notably APQC—a nonprofit research organization of which I am a board member and respect a lot) sells out its knowledge management conference every year. Professional services firms are still quite active and successful with the idea.
But there is plenty of evidence that it’s gasping as well. Google Trends suggests that “knowledge management” is a term rarely searched for anymore. Bain’s Management Tools and Trends survey doesn’t list it in the top 25 tools for the 2015 or 2013 surveys; it was included before that. More subjectively, although I am supposedly an expert on the topic, hardly anybody ever asks me to speak or consult about it.
What happened to this idea for improving organizations? I’m pretty sure that knowledge itself hasn’t become less important to companies and societies, so why did many organizations give up on managing it? Is there any chance it will return? And what does its near-demise tell us about the attributes of successful business ideas?
Although it’s impossible to know for sure why something rises or declines in popularity, here are some of my ideas for why knowledge management (KM) has faded:
- It was too hard to change behavior. Some employees weren’t that interested in acquiring knowledge, others weren’t interested in sharing what they knew. Knowledge is tied up in politics and ego and culture. There were methods to improve its flow within organizations, but most didn’t bother to adopt them. Perhaps for this reason, the Bain survey (for example, the one from 2005) suggests that corporate satisfaction with KM was relatively low compared to some other management concepts.
- Everything devolved to technology. KM is a complex idea, but most organizations just wanted to put in a system to manage knowledge, and that wasn’t enough to make knowledge flow and be applied.
- The technology that organizations wanted to employ was Microsoft’s SharePoint. There were several generations of KM technology—remember Lotus Notes, for example?—but over time the dominant system became SharePoint. It’s not a bad technology by any means, but Microsoft didn’t market it very effectively and didn’t market KM at all.
- It was too time-consuming to search for and digest stored knowledge. Even in organizations where a lot of knowledge was contributed to KM systems—consulting firms like Deloitte and Accenture come to mind—there was often too much knowledge to sort through. Many people didn’t have the patience or time to find everything they needed. Ironically, the greater the amount of knowledge, the more difficult it was to find and use.
- Google also helped kill KM. When people saw how easy it was to search external knowledge, they were no longer interested in the more difficult process for searching out internal knowledge.
- KM never incorporated knowledge derived from data and analytics. I tried to get my knowledge management friends to incorporate analytical insights into their worlds, but most had an antipathy to that topic. It seems that in this world you either like text or you like numbers, and few people like both. I shifted into focusing on analytics and Big Data, but few of the KM crowd joined me.
Any chance that this idea will come back? I don’t think so. The focus of knowledge-oriented projects has shifted to incorporating it into automated decision systems. The hot technology for managing knowledge is now IBM Corp.IBM -0.28%’s Watson—very different from the traditional KM model. Big Data and analytics are also much more a focus than KM within organizations. These concepts may be declining a bit in popularity too, but companies are still very focused on making them work.
If you believe in knowledge management—and you should—perhaps in your organization you can avoid the pitfalls I have listed and allow the idea to thrive. And if you favor a different idea and want it to survive over the long term, don’t hitch a complicated set of behaviors to technology alone. Don’t embrace a vendor for your concept that doesn’t care much about your idea. And if another notion that’s related to yours comes along and gains popularity, don’t shun it, embrace it.
Thomas H. Davenport is a Distinguished Professor at Babson College, a Research Fellow at the Center for Digital Business, Director of Research at the International Institute for Analytics, and a Senior Advisor to Deloitte Analytics.