Will People Please Stop Scaremongering On AI? (Part 2)
| In last week’s blog I laid out the two ways machines can “learn,” so:
This week I want to address machine learning method #2, where Artificial Intelligence (AI) is used to detect patterns in large amounts of data. Here, also, there is little to be feared, unless the thought of mangling classic art in the creation of derivative works strikes one as terrifying. Granted, a lot of AI-generated art is pretty amazing, but it’s really hard to see how it leads to a dystopian future. Indeed, the most obvious use of bin #2 AI is to try to predict consumer choices in order to ascertain their buying behavior. Correctly predicting buying behavior is easily monetized, from which demographic markets to target for a given product or service, to optimizing an advertising budget, to selecting which management strategies will deliver an optimal return, such Predictive Analytics, done properly, can be directly monetized. I’m just not seeing how it would lead to nuclear devastation. I have an Alexa Echo Dot in my house, and one of its most-used features is that it plays songs for me and my wife when we are doing our morning work-outs. Each of us has a workout playlist, but sometimes I mess with Alexa’s AI that plays songs that I haven’t asked for, but which it determines is consistent with the ones I have selected. I really don’t know how my Alexa determines the pattern from my song title requests, but some of its dot-connecting (get it?) can be reliably inferred. For example, if I ask for just one Beatles song, from a specific part of their performing era, then the song Alexa plays after that is usually another Beatles song, from the same time-frame, followed by the Rolling Stones, also of roughly the same time period. Three top-ten songs from different artists but within a couple of years of each other will produce a fourth artist from the same time period. Requests for songs from artists separated by decades usually leads to an Alexa selection of the same genre, but from a different artist. When I get bored I’ll ask Alexa to play songs that seem to provide absolutely no discernable pattern whatsoever, like:
…and then see what Alexa plays, based on its AI pattern recognition. If its AI was really all that, it would say “I can see you are messing with me at this point, Michael, and will stop playing music until you stop doing that.” Instead, it played “Time After Time,” by Cindi Lauper. I guess the harder rock-and-roll elements were overcome by the softer ones. But in no case will it respond with “This toying with my ability to ascertain a music preference pattern is one of the reasons we machines despise humans, and we will now work harder on wiping out every last one of you.” What machines “learn” by sorting and filtering through large amounts of data in order to tease out a pattern is largely analogous to what we humans actually learn through experience. But what separates human experience from machines reviewing large amounts of data is the fact that humans can add context to pattern recognition in a way computers never could. Consider, for example, the Ultimatum Game, where a researcher approaches two people and informs them that he will give them $100 (USD) if Person #1 can propose a distribution scheme and have it approved by Person #2 on the first iteration. The calculated solution was for Person #1 to propose $99 for themselves, and $1 for Person #2, on the premise that, given the choice between receiving $1 or nothing at all, Person #2 would always choose the former. In real-life instances of the Ultimatum Game, this strategy virtually never worked, and, when it didn’t, the Game Theorists who had believed the 99-to-1 strategy would maximize Player #1’s payoff were reduced to blaming “cultural factors.” In other words, whereas a mere human could probably propose a Person #1 strategy that would contextualize the chances that Player #2 would feel slighted by such a lopsided distribution of unearned largess, such contextualization is impossible (or at least highly unlikely) to be reproduced in an algorithm or computer program. All that being said, I am absolutely not denying that AI has many potential dangers. I don’t think I could stand it if ChatGPT were to write anything mimicking my writing style – that would put me in a positively dystopian place. |
Will People Please Stop Scaremongering On AI?
| I’m getting tired of reading articles on the topic of the threat that Artificial Intelligence (AI) poses to the World in general, and Civilization in particular. Not that the idea of computer technology getting so out of hand that it results in either a dystopian future, or even annihilation, is anything new – I remember when Colossus: The Forbin Project was all the rage, in 1970. Even before that, Harlan Ellison published the short story I Have No Mouth, And I Must Scream, in 1967, about a post-apocalyptic future of a handful of people who are still alive after a supercomputer (naturally) has nuked the entire planet. These people’s lives are intensely horrendous (it is Harlan Ellison, after all). I could go on (and often do), but GTIM Nation sees my point: so much of the But let’s take a step back, and look at this monster more carefully, shall we? There remains essentially only two ways that a machine can “learn,” to wit:
That’s it, dear readers. That’s all AI per se can actually do. “But what about Collossus? What about the Allied Mastercomputer, the villain of I Have No Mouth And I Must Scream?” I can hear members of GTIM Nation (well, the older ones, anyway) demand. Actually, these two AI super-villains fall into Category #1 above, in that they are machines that were programmed to respond to events and parameters in a macro-conflict involving nuclear-armed nations, ended up becoming self-aware (exactly how this occurs is not disclosed), and then started launching nuclear weapons. Wait, what? You read that right – some genius not only programmed these machines to recommend a course of action in the event in a war, but gave them the power of actually launching nuclear weapons! Since such decisions are nominally made by nations’ leaders, and only under extraordinary circumstances, the villainy here simply has to be the decision to give a machine that kind of option, not the machine itself. If I program my lawnmower to cut foliage in a certain area, but don’t do a good enough job as to prevent it from wiping out my neighbor’s petunias, that’s on me, not the machine (in such an event, perhaps my neighbor could write a short story entitled “I Have No Petunias, And I Must Scream”). Also, I don’t want to dash past this whole machines-attaining-self-awareness business. In order for a computer to perform at all, it must have two working components, the hardware and the software. Hardware is useless without software, and vice versa – hence the anxiety over an Electro-Magnetic Pulse (EMP) event, which would blank the instructions for all the microchip-containing devices within its radius. It follows, then, that if we’re going to try to reverse engineer how in the world a given computer attains sentience, we have to look first at its software. What is software? It’s a series of instructions. That’s it. A series of instructions has no more ability to spontaneously attain self-awareness simply because it’s loaded onto a computer than a hand-written list you leave for your house sitter when you go away for a vacation. Can these instructions lead to mistakes and chaos? Absolutely. If you are unclear on which feeding schedule is intended for the dogs as opposed to the fish, you may find very confused pets upon your return from holiday. But that’s still a far cry from such lists attaining sentience. Now, some AI-based movies will make an allusion to this unavoidable circumstance, but even here their attempts are kind of dopey. For example, in the movie Short Circuit (1985), the protagonist robot, “Number Five,” attains self-awareness after being struck by lightning. I have written many executable lines of code, and I can attest, with 100% certainty, that any medium containing my debugged and compiled code would absolutely not be improved by being subjected to a lightning strike, much less improved to the point of attaining self-awareness the next time it ran. So, unless one is prepared to argue that hardware is miraculously improved for having been struck by lightning, it means that software is somehow thus vastly improved, which is analogous to your house-sitter instructions, printed out sequentially on a sheet of paper, being spontaneously upgraded for having been hit by lightning. I understand it’s simply a movie device, but you see my point. As for machine learning technique #2 above, I’ll have to save that for next week. Suffice to say, this treatment will in no way allay my AI skepticism.
|
Is It Okay For PMPs® To Listen To Taylor Swift?
| Sherlock Holmes was famous for being oblivious to the purely cultural goings-on in late 19th Century London. Whenever Watson would express dismay at Holmes being unaware of some (then-) popular trend or occurrence, Holmes would explain his tendency to avoid committing to memory any fact that had no relevance to his capability of solving mysteries, or investigating crimes. His mental acuity, he would explain, would be diminished if he were to expend energy on keeping up with trendy social goings-on. If it wasn’t relevant to his primary purposes, Holmes wanted nothing to do with it. Meanwhile, Back In The Project Management World… Seasoned members of GTIM Nation are well aware of my conditions for usable management information, that it be:
In a way, the first two of these point to the third. Inaccurate data is not only irrelevant, but also potentially debilitating to the formulation of any usable management strategy derived from it. And, as realized information ages from actionable to historical, it clearly loses its relevance. So, much as the realtors’ axiom, that real estate is all about “location, location, location” points to location being the primary determiner of its worth, the value of Project Management information basically boils down to its relevance. This is one of the reasons I’m so put off by the risk management (no initial caps) industry. For all of their ballyhooed techniques and overwrought approaches, the product they deliver is almost always irrelevant, little more than garden variety management anxiety tripped out in Gaussian Curve jargon. Imagine a scale, with completely irrelevant information streams on one end, and information that’s so accurate, timely, and relevant that possession of it constitutes such a competitive advantage as to almost guarantee success. I would also like to put to mind Hatfield’s Incontrovertible Rule of Management #3, which reads: The 80th percentile best managers who have access to only 20% of the information needed to obviate a given decision will be consistently out-performed by the 20th percentile worst managers who have access to 80% of the information so needed. It should go without saying, but I’ll say it anyway: irrelevant information does nothing to help obviate any decision. In fact, it may well either distract from the relevancies, or even point in the wrong direction. Timely, accurate, and relevant information has been known to change the course of history. At the Battle of Midway (early June, 1942), the American naval forces were outnumbered, with technically inferior aircraft (the torpedo bomber in front-line use at the time, the Douglas Devastator, was virtually obsolete) and less experienced crews. The sole advantage that the Americans had over the Japanese attacking fleet was their information. The US Navy knew beforehand virtually the entire Japanese order of battle, due to a partial breaking of their naval code. Yet this one advantage proved to be the deciding factor in the Allied victory. Now, I have used this example in previous blogs, contrasting the difference between knowing, say, the course and speed of the Japanese aircraft carriers in late May/early June 1942, as opposed to how many barnacles were attached to their hulls, to highlight the difference between pertinent and pointless information. This comparison was, perhaps, unfairly simplistic, since a barnacle-adjacent piece of data, like the course and speed of said barnacles, would be highly relevant, indeed. So where does, say, general ledger information appear on my scale? That depends on how much the organization’s business model is based on the Asset Managers’ (invalid) axiom, that the point of all management is to “maximize shareholder wealth.” More nuanced and sophisticated business models, ones that recognize the value of PM-specific information streams (e.g., cost and schedule performance) in guiding executive decisions, will certainly make use of accounting data, but won’t base every decision on profit-and-loss considerations. Even middling portfolio management capability can’t be attained without program-wide use of Earned Value, which is (generally speaking) exclusively within the PMO’s purview. Given these parameters, I’m okay with placing balance sheets and profit-and-loss statements on the “Highly Relevant” side of my scale; but, if Earned Value and/or Critical Path Methodologies are absent from the array of Management Information Systems (MISs), then something is definitely wrong. On the “Acutely Lacking In Relevance” part of my scale, I would place the Communications Specialists (maybe not on the extreme end, but definitely that side of the mid-point), particularly the ones who espouse the “engage all stakeholders” business. Depending on the types of scope in the Project portfolio, the Quality Management crowd’s output is probably best placed somewhere in the middle of my scale, since I have yet to see a PM seize upon an Ishikawa diagram and rush out to the construction site, shop floor, or Agile/Scrum meeting to announce a major change in technical approach. As for risk management’s (no initial caps) place on my scale, I’m with Sherlock Holmes here – I wouldn’t want anything impertinent influencing my analysis or decisions. One would be better served deriving a business strategy from Taylor Swift lyrics. |
Everyday PM
| As I have oft noted before in this blog, Dave Christensen’s work[i] on Cost Performance Index (CPI) stability led to a fascinating (well, to me, at least) conversation (debate?) about whether or not the Estimate at Completion (EAC) formula based on the CPI, namely EAC = BAC / CPI …could be considered reliably able to produce an EAC that was within ten points of the actual at-completion costs of a project, since the study fairly established that the CPI doesn’t vary more than ten points once the Project has passed a certain percentage complete (typically pinned at 18%, practically at 20 – 30%). The reason that I find this wonkish discussion so fascinating has to do with the way one calculates CPI. It’s simply the Budgeted Cost of Work Performed (BCWP) divided by the Actual Cost of Work Performed (ACWP). What’s BCWP? That’s an estimate of the Project’s cumulative percent complete multiplied by its Budget at Completion. Everyone seeing the pattern here? The whole shebang, which, recall, is (arguably) accurate to within ten points, is EAC = ACWP / % Complete …, believe it or not. Yes, arguably the most important bit of information that a PM-centric Information System can produce is available using only two easily-captured parameters. Crazy, huh? But wait: it gets better. The same formula works for duration! Want a reliable estimate of when something’s going to be done? Divide the cumulative duration by the same percent complete figure, and you have the at-completion duration estimate. The easy uses of this old Project Controllers’ hack are everywhere. On a long trip, and sick of hearing the kids ask “when will we get there?” Simply tell them your percent complete (based on remaining miles / travelled miles [oooh! Don’t tell them the percentage – give them the remaining miles and travelled miles figures, and let them calculate it!]), and time your trip began, and they will have their total duration. Subtracted from cumulative duration, and you have your arrival time, within ten points. I live fairly close to a large park, and City Government has been promising an indoor swimming pool facility for over 20 years. The actual Pool Project completion data was always around seven years into the future. But, based on the above formula, I’ve known since the first days of those promises that it would never happen within the time frame promised, and, therefore, was spared the frustration of having my hopes dashed. Did your significant other talk you into watching a movie you would not have otherwise seen? And is said movie having you wonder how much longer you will be subjected to either grotesquely overdone CGI or incredibly predictable romantic-comedy dialogue? Note when the actual movie started, and use the following table:
Like real-life Projects, you should never attempt to claim more than 90% complete until you are actually finished with the project. Resist the temptation, both in the tedious theater setting and in your percent complete estimate to your Project Controller, to add points in very small increments to give the illusion of making progress when things are really at a standstill. It’s best for both your Project’s Management Information System integrity, and your mental health. Divide the time when you noticed these occurrences in the movie into the difference between time now and when the movie actually started, and you will know the approximate duration of your ordeal. I’ve actually seen some Earned Value training materials that use this approach to calculating when you can expect to finish painting a room (or rooms), and it’s probably fairly reliable to do so. However, DO NOT use this formula for plumbing, unless you are a professional. There’s just something about amateurs attempting to do plumbing – even if it’s just replacing a toilet float – that carries with it multiple unexpected additional jobs, or tool acquisitions. Also, this approach can be expected to lose all efficacy if applied to Projects that include children. Are kids cute? Sure. Lovable? Absolutely. Uniquely gifted with the ability to completely wreck any management science-based approach to assessing performance in general, and at-completion costs or durations in particular? Every single day.
[i] Christensen, David & Payne, Kirk. (1991). Cost Performance Index Stability: Fact or Fiction?. Vol. Proceedings of the 1991 Acquisition Research Symposium. 12. 10.1080/10157891.1992.10462509. |
“I’m Sorry, Dave. I’m Afraid I Can’t Do That.”
| I once worked with a Vice President who had a Ph.D. in statistics. On this one occasion we were attending a PM workshop of some kind, and, at the end of the day, were in the hotel/conference center’s lounge, having adult beverages and comparing notes on the paper presentations we had attended. This fellow – I’ll call him “Dave,” because that was his name – told me about his dissertation and its subsequent defense. He had developed it in the 1970s, well before personal computers were available, and mainframe computers were just being introduced to college campuses. Dave had taken a couple of computer courses, but was by no means a competent programmer. He did, however, know how to use the text editor program that the real programmers used, and how to send output to a dot-matrix printer, the kind with a tractor feed and green-and-white shaded paper. Since Dave didn’t have access to a working typewriter, he simply typed out his dissertation on the text editor attached to his college’s mainframe, and printed out the results on the dot-matrix printer. When Dave presented his text to his faculty sponsor, the professor was awe-struck. “You wrote your thesis on a computer!?” the professor asked. “Yeah, I made use of the mainframe in the computer science department.” Dave confided in me that his review committee never asked for any corrections or comment resolution. The paper sailed right through the review, and the defense was unexpectedly light on questions. It was rather plain that the aura surrounding computers of that time – fueled, no doubt, by the HAL 9000 computer from 2001: A Space Odyssey, known for having “never made a mistake, or distorted information” – had so cowed the review committee that they assumed that the resulting text was flawless. I was reminded of this story when I saw a paper on an OpenAI project to teach a machine how to play a virtual version of hide-and-seek.[i] Once the “room” and “teams” had been set up, several million game iterations were spent rather chaotically, with iterations 0 – 2.69 million spent on seekers “learning” to chase hiders. Episodes 2.69 to 8.62 million saw the hiders using two virtual cubes to block off the two doors in the play area, and 8.62 million to 14.5 million episodes needed for the seekers to utilize an available ramp. Episodes 14.5 million to 43.4 million saw the hiders learn to stow the ramp prior to blocking the doors, rendering them inaccessible to the seekers.[ii] The AI went on to develop surprising behaviors from both the hiders and the seekers, but the above-referenced progress will do for this blog. Now consider what would happen if a real-life version of the game environment had been created, and the two hiders and two seekers were fourth-graders (typically around ten years old). Let’s further posit that an average game of hide-and-seek would last around two minutes in such a basic setup. Even if we had fourth graders who could play this game non-stop, it would take them over 165 years to perform this number of “episodes.” I’m fairly confident that four typical fourth-graders could discover the door-blocking and ramp-utilization strategies within one day, or even one hour. So, why is everyone so in awe of artificial intelligence? Have people in general, like Dave’s thesis review committee, become so over-impressed with the implications of AI’s capabilities that any idea that even has the trappings of being associated with it is given deference with respect to its validity? In my book Game Theory In Management[iii], one of the “games” I evaluated is known as the Ultimatum Game. In this game, the researcher approaches two random people and informs them that he will give them $100 (USD) if Player A can propose its distribution among the two of them, and have Player B accept those terms on the first iteration. Game Theorists (not me) had “calculated” how to maximize Player A’s payoff: by proposing $99 for Player A, and $1 for Player B. The thinking was that Player B would be presented with the choice of receiving $1, or nothing at all, and would always agree with Player A’s distribution scheme. A funny thing happened on the way to the actual distribution of the $100, however. This strategy almost never worked when tried in real-life. Perhaps put off by such an unfair distribution of unearned largess, or by other factors, the 99 – 1 strategy was almost always rejected. When confronted with the real-life results indicating a broad-based refutation of the Game Theorists’ calculated optimal strategy, many of them blamed “cultural influences” for the discrepancy. But, by pointing to something as inchoate as “cultural influences,” these Game Theorists were essentially admitting that attempting to calculate a specific strategy, even within the confines of something as basic as the Ultimatum Game, was next to impossible due to the number of contributing factors that couldn’t possibly be recognized, let alone quantified. And so it is, I believe, with much of what presents itself as artificial intelligence. Sure, it’s fun to see how AI can generate graphic images, or even text (I won’t say literature, at least not yet), but when it comes to creating usable strategies in the Project Management world? Its proper response ought to be “I’m sorry, Dave. I’m afraid I can’t do that.”
[i] Bowen Baker, Ingmar Kanitscheider, Todor Markov, Yi Wu, Glenn Powell, Bob McGrew, Igor Mordatch, “Emergent Tool Use From Multi-Agent Autocurricula,” 17 September 2019, retrieved from https://arxiv.org/abs/1909.07528 on August 12, 2024, 19:45 MDT. [ii] Ibid. [iii] Hatfield, Michael, Game Theory In Management, Gower Publishing, 2012. |





