Though many schools claim to be familiar with the piloting of new technologies, it turns out that many in practice do not have established and documented processes for how to approach such a task. We know what you’re thinking...we were shocked, too. Therefore, we want to begin by providing our definition of what a pilot is, and just as importantly, what it is not.
What a Pilot IS
A pilot is small scale evaluation of the Concourse platform. This evaluation is critical to the decision-making process about not only continuing the service, but it provides the preliminary framework for implementing Concourse across additional departments, schools, or the entire institution.
A pilot answers questions about how Concourse might be used in the future, by whom, and with what integration touchpoints. It helps determine which feature extensions make the most sense for your institution, and gives participants an opportunity to explore Concourse and provide their feedback on not only the technology itself, but what policies and procedures need to be developed to ensure its long-term success.
For these reasons, a pilot should mimic as closely as it can the way that you expect Concourse might be used in the future. This does not necessarily mean that the same people will maintain the same roles, but more importantly that the workflow is well understood. For example, if you plan on providing instructors with a syllabus template for their course, this is what an instructor should begin with in the pilot setting.
Finally, the pilot should be viewed as a “playground.” In other words, users should be provided with guidelines about what you’d like them to play with (e.g. try the file upload feature), but beyond this, they should be free to explore. The more flexible and open you are with the pilot environment, the more you will come to understand what it is users are looking for or expecting to do with the technology.
What a Pilot is NOT
Most importantly, a pilot is not the “final” implementation. While time should be spent considering the policies and procedures that will ultimately impact its use, we do not recommend you attempt to formalize these prior to start of the pilot. For example, instead of seeking consensus and approval from the faculty senate on the exact wording of the Academic Integrity policy for use in your institutional template, you could enter something reasonable and give instructors the ability to modify it through Concourse. This way you will not only be able to get the pilot off the ground before the end of the century, but you will also be able to observe post-pilot what instructors were expecting the policy to be.
Next, a pilot is not the place to stress the technology to the limits, or more specifically, try and break its capabilities. A pilot is intended to be a “real world” example of use. Your sandbox system is available for this type of “abuse,” where users can see what happens if they try to change the background of the syllabus from white to hot pink. The pilot is more about understanding how users react to the experience and the identification of challenges inherent to your selected design, training, and approach.
Given the limited size and complexity of most pilots, they may or may not require integration. If the focus is on faculty experimentation and confined to a small group (only a few courses), full integration may not be necessary. However, if one of the objectives of your pilot is to work with your IT department to get their processes in place, integration at this point can be very helpful.
Typical Concourse Pilot Objectives
Designing templates, integrating with other systems, and administration of your Concourse system are the primary objectives of a typical Concourse pilot. The following outlines some specific goals of each of the primary objectives.
Planning- Determine implementation task responsibility and the sequencing and timing of activities.
- Formulate a pilot implementation plan
- Become familiar with your Concourse sandbox
- Utilize Concourse Support Center
Templates- Determine the overall architecture for data organization, source, flow, and access.
- Determine the appropriate balance of flexibility and structure (e.g. which items should instructors be able to edit, verses which items should be maintained by an administrator?)
- Identify “trouble spots” (e.g. unclear instructions, misleading icons)
- Learn what extensions (e.g. files) should be made available in Concourse
- Determine source of content
- Gain insight into reporting needs
Administration- Determine how high-level roles and responsibilities will be distributed throughout the system.
- Determine what a public syllabus should expose.Identify process responsibility (e.g. template management, reporting, training, etc.)
- Establish the workflow related to course/template creation
Integration- Determine how Concourse will be accessed and how it will consume and produce data to and from other systems.
- Determine and configure access points
- Construct and process feeds
Deployment- Determine what remaining elements are needed for go-live and bring together decisions made in previous phases.
- Assess the degree of training required
- Explore the level of user support needed
Maintenance- Determine the ongoing activities post initial deployment.
- Plan for post-pilot expansion of Concourse
- Discuss how Concourse issues will be handled
In the end, every pilot is different, and you will likely draw upon elements from each of these suggestions and the underlying approaches. However, we strongly suggest sticking to a few clear and precise goals so as to make your pilot not only manageable, but also to give it clear purpose and a way to accurately and reasonably evaluate its results.
Don’t bite off more than you can chew. Consider a small number of measurable and attainable objectives among a small group of individuals. Keep the scope contained, not only in terms of task, but who performs the task as well. Good luck!
Visit our Community Forum to share best practices, lessons learned, or to just say hi! We want to hear from you!