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.
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):
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.