Question Carefully

So LinkedIn invited me to view a "collaborative article," where the topic was: "Your external vendor misses a crucial deadline. How can you ensure program delivery stays on track?" The feedback request says: "We created this article with the help of AI. What do you think of it?" And the options are "It's great," or "It's not so great."

"It's not so great," is actually intended to mean "It's actively bad," because the reasons you have to choose from are things like "It’s not on a professional topic" or "It contains stereotypes or bias." But I thought the question was "not so great," not because it was actively bad, but because it's the wrong question. (And it is a bit unclear; what "on track" means, for instance, is left to the reader.)

By the time an external vendor actually misses a crucial deadline, the remediation plan should likely have already been initiated. Because: "The external vendor providing Deliverable X will miss their delivery date," is a foreseeable risk. The number of things that can blow up a delivery is infinite. And the vendor's project plan should have the reasonable ones noted, and the vendor PM should be communicating status of active risks with in-house program management. Especially when an entire program is riding on that delivery. The missed deadline may be a disappointment, but it shouldn't be a surprise, especially if it's "crucial."

These sorts of questions, that ask about recovering from problems rather than preventing or mitigating them, are common. I encountered one when I took my first manager training class, about a quarter century ago (and I still remember it quite clearly). So I'm not surprised that an LLM trained on the contents of the Internet would ask one. And, to be sure, there's value in knowing what to do when the unexpected happens. But the quick recap of advice that is presented covers things that should have already been done, like "Assess the impact and scope of the delay" and "Develop contingency plans." And activities like "Communicate with the vendor to understand the reasons for the miss" should be part of the postmortem/lessons learned, not the immediate risk response (what I would want to know in the moment are what obstacles to delivery they still face). It was advice that indicated that this wasn't something that had been planned for, as opposed to something that hadn't gone according to plan.

I don't know who looked at the question before it was put out there. But this goes back to one of the problems with LLMs; if one doesn't know the subject matter, it's often difficult to assess an LLM's output. The question, as asked, is reasonable on its face, but strikes me as wonky, because the LLM has simulated expertise in language, but not so much in Program Management. It can't ask questions about questions in the same way that people can.