There’s a lot to be said for learning from difficulties and challenges, so as to head off future problems or to improve ways of dealing. It’s even better to learn from a near-miss, or it’s at least less costly. Recently, we had a confluence of events that could have been problematic except for some mad scrambling at the last minute. I’ll leave the details alone here. What was learned from this effort was the importance of building resilience. “Resilience” refers to the ability to return to a former position and to recover from adversity.

Technological Resilience

Course resilience may suggest that it is portable and playable, with its elements loosely coupled enough to be disaggregated but also tightly coupled enough for coherence and clear learning paths ad trajectories. This means building with stable software authoring tools, so the code doesn’t corrupt (well…) or need excess attention.

Having a back-up is mission-critical for those courses that have multiple-user access and that are relatively “high value.”

Human Resilience

Then there’s the resilience in having back-up instructors for substituting for a course. The human resilience also means having ways for team members to switch in and out with relative ease and to integrate various expertise positively.

Process Resilience

Process resilience comes from the project leadership, so fresh directions may be transitioned to and through without undue difficulty. This also comes from having a coherent and fitting stylebook to define the expected work, the processes, the technological and pedagogical standards, and the project deadlines.

Personal Resilience

This last piece is pretty critical, too. This means coming back from (the rare) bruising days with stress and miscommunications and people’s incorrect attributions. This also means sort of letting all that slough off in order to be at one’s best in a new day.