The Ice-Cream is Melting

A few months back, I blogged about a project in which the goal was to use an API to grab data from our LMS about which students had completed a particular course, and "reward" completion by means of a free ice cream in the form of credit on their student account. I had written a proof-of-concept Python script to grab the data, which I passed on to others on the project, but not being a software developer or data engineer, I assumed that the project team would put together a more robust solution. Early emails back and forth suggested that everyone had what they needed, so I assumed everything was under control.

Fast-forward to a few days ago (many weeks since the original meetings). Once again, people seemed to be talking about the need to grab LMS data to assess course completion. I had been under the impression that we were already more than a month into a working solution. 

What happened? I don't have any particular insight into who was doing what during the interim, but I can venture as to the general challenge. (I think I first heard these ideas in a presentation years ago by Johanna Rothman.)

Information about a new project is lowest before the project has begun. All we have are assumptions about how long things will take, who will be available to do the work, where the bottlenecks will be (if we even recognize that there will be some), which systems require special permissions, etc. (An exception to this is projects very similar to current or previous work, which can serve as initial estimates of resource requirements and probable timelines.) Our assumptions of how long something will take can easily be off by orders of magnitude if we start from a blank slate. Not just "I thought I could do it in three hours, but it looks like it will take four or five", but rather, "I thought I could do this in an afternoon, but now I realize that it might take several weeks to get it working." 

Because the project scope seemed to be rather small (extract data from a single class), there was likely a shared (and unvoiced) assumption that it should be a relatively trivial task, and there would certainly be no need to prioritize it over the many other, "obviously higher priority" tasks that folks had on their respective plates. By the time people rolled up their sleeves and got to work, unforeseen challenges emerged. 

I would also posit that these assumptions were not just on the IT side, but also on the original concept side. I don't know who was involved in discussions and on what level, but my guess is that IT was not consulted (or the people who might actually be responsible for doing the work were not consulted) before the project was given the green light. 

The moral of the story is that, in a room full of "sure, we can do thats," there is also a need for "has anyone thought abouts?".