Lessons Learned about Blueprint Courses: Getting Buy-In

lindalee · ‎11-13-2017

NB: This is the second post in a series on what we learned in our Fall 2017 Blueprint Course pilot. The previous post provides an overview of our experience (Lessons Learned about Blueprint Courses: Introduction), and later posts consider our "failed" Blueprint pilot course (Lessons Learned about Blueprint: When Blueprint Wasn't the Solution) and replacing a course copy workflow with Blueprint (Lessons Learned about Blueprint Courses: Replacing Course Copy Workflows).

In my previous blog post,Lessons Learned about Blueprint Courses: Introduction, I provided an overview of our experience using Blueprint Courses (Canvas Release: Blueprint Courses) in Fall 2017. That post focused on our selection of four use cases for the initial pilot and some of the considerations (that is, course needs) in selecting these courses. Here I'm going to discuss one of the early steps: getting buy-in from teaching and administrative teams.

It's important to acknowledge that there are various types of buy-in that may be necessary. First, securing buy-in from teaching teams and other stakeholders for using consistent course content that faculty may (or may not) be able to change. Second, getting buy-in for using Canvas Blueprint Courses as a tech solution for providing this functionality.

Although I recognize that there is interest in the former (indeed, during the Fall Community Showcase (2017-11-1)‌, where I discussed our use of Blueprint Courses, someone asked a question about this issue), here I'm really talking about the latter. Indeed, I strongly believe that requiring a common starting point for a course -- or common content throughout the course -- is a decision most appropriately made at the program or course level. As an instructional designer and Canvas admin/support, this program/course-specific requirement is not my call to make.

That caveat out of the way, if there is a course or program need to deliver consistency in Canvas content -- either as a starting point or maintained throughout the semester -- then we can and should recommend the best technology to meet that need.

Selling Blueprint Courses to Teaching Teams

We had a relatively easy time convincing our target teaching and administrative teams to participate in our Blueprint pilot. This was partially because our Courseware Team has a generally excellent relationship with the faculty and programs we support. They trust our team to make appropriate recommendations. But it's also because Blueprint offers functionality that solves problems for them.

That being said, it can be a risk to be first to try something new -- so you want to make sure that the benefits gained will outweigh the risks. Knowledge of course and program needs is crucial!

So here are some of the selling points we used to promote Blueprint to our target pilot courses. They fall broadly into two categories: features that the teaching teams want and productivity enhancements (either for our Courseware Team and/or for the teaching teams):

Consistent starting point for course content: Certainly, a consistent starting point can also be accomplished by importing content from another course. But Blueprint is faster and easier, as content is replicated across all associated courses at the same time.
Ability to update content at a later date: When teaching teams are tweaking courses until the last minute, that can create an unfortunate bottleneck just before the semester begins -- because we wouldn't want to manually import content in numerous sites after we've already set it up. Because Blueprint can sync updates after the initial course sync (How do I sync course content in a blueprint course as an instructor? ), it's no longer necessary to delay Canvas site replication until the template content is finalized. If an assignment needs to be added or changed at a later point, that's no problem! Blueprint can make it practical to create Canvas sites much earlier in the process, giving teaching teams (and possibly students) access to their sites much sooner.
Ability to replicate some LTI tools: For multi-section, large-enrollment courses (like our communications courses that run in 56 sections in each quarter) with the same course readings, we often had to wait until the Certified Partner - Study.net course pack was made available to students before creating and replicating content across sites. We wanted to make sure that the course pack (provided through a course-level Study.Net LTI integration) was part of any content import. Again, this often meant creating and replicating sites later than the teaching team wanted in order to minimize avoidable extra work. The ability sync some LTI tools with Blueprint made it easy.
Maintain content consistency after Canvas site creation: For courses where content in Canvas sites really has to be the same, Canvas previously had a limited ability to deliver this functionality, beyond an initial course copy. The only guaranteed way to ensure consistency in content was to enroll all course sections into the same section. (This, of course, raises FERPA concerns, though different institutions interpret these requirements in different ways, see New FERPA requirements for cross-listed courses! for more.) Enrolling multiple sections (with multiple teachers and TAs, all with editing privileges within a Canvas site) can create it's own problems. With the ability to lock content (How do I lock course objects in a blueprint course as an instructor? ) of various types -- assignments, files, discussions, pages, and quizzes -- Blueprint becomes an easier sell when this is a requirement. Three of the four courses in pilot needed this functionality.
Limit the people who can change content: If one of the previous workarounds for content consistency had been to have a multi-section Canvas site, this can increase the number of people with editing capabilities. Blueprint removes this potential problem by allowing only people enrolled in the Blueprint template site to be able to change locked items. Problem solved!
Ability to update content across multiple courses at the same time: Of course, the biggest benefit that Blueprint Courses offer is being able to automatically update or add new content across multiple associated Canvas sites at the same time. If a large-enrollment, multi-section course needs this capability, then this is all it might take to sell Blueprint to a teaching team.
Post announcements to all Canvas sites at the same time: Lastly, several of our courses needed the ability to be able to post an announcement to multiple Canvas sites at the same time. Teaching teams found it frustrating to copy-and-paste the announcement content across site -- and if those announcements included links to files, pages, assignments, etc., the links need to be updated if the content is copy-and-pasted. But those links updated automatically when synced using Blueprint! For two of our pilot courses, this ability was a significant benefit.

Acknowledging where there might be Challenges

But Blueprint is a newly introduced feature, and it will mean new processes for teaching and administrative teams. Like any new feature, there can be a learning curve. So it's best to be upfront about where the challenges might be.

Communication issues among teaching team members, and communicating when a Blueprint synches changes to associated courses: Ken Black addresses issues of communication and planning in Tips for Designing and Maintaining Blueprint Courses.
Need to train teaching and administrative teams in a new technology: It will be important to set aside time to meet with faculty, TAs, course coordinators, and other admin folks to make sure that everyone knows what they're doing. In our experience, the course that had the least satisfaction with Blueprint also had the largest number of faculty and TAs -- and not all of them participated in training sessions.
New technology/tool means there might be unexpected issues: This one is hard to predict! We encountered many, many issues where the Blueprint documentation wasn't detailed enough, or the documentation didn't match the behavior we observed. We opened lots of Service Cloud cases and new feature ideas. Over time, such problems should become fewer and further between, we hope. But it's best to acknowledge up front that there might be unexpected behaviors, and to agree on a plan for how you'll address them.