The purpose of this issue is to discuss and document the structure of the bootcamp sessions.
A high-level outline of the bootcamp curriculum is available here.
What are the bootcamp sessions?
The bootcamps are working sessions conducted by EdCast in which GitLab implementation team members are invited to learn the product and collaborate on the design decisions associated with each topic. Rather than sit-and-learn style presentations, these are active sessions in which GitLab team members will be working to align and decide upon several configurations associated with the product, ranging from site branding, to learning pathways, and everything in-between.
It should be noted that EdCast has not provided a specified instructional timeframe for each content area. This is because the bootcamps often move at the client's pace, based upon their specific requirements for each area. (As an example, the User Authentication section is expected to be more brief than usual, as our IT team is already working with their Solutions Architect to structure and deliver our SSO specifications.) Their usual style is to schedule out working time blocks, and complete each topic area in succession until no further bootcamp sessions need to be held. This presents a barrier to coordinating around specifically which team member needs to be involved with which session for an implementation team of our size and scope.
Ordinarily, EdCast has these bootcamp sessions divided into two audiences: Curators and Administrators. However, since several different teams at GitLab will be utilizing EdCast for different audiences, key members of each team will require participation in both bootcamp curriculums. As such, we will need to work with EdCast on how their bootcamp structure can be best differentiated to accommodate our needs in an efficient manner.
To this end, the following structures are under discussion:
Structure 1: Standard EdCast structure.
- What it looks like: 2-3 90-minute sessions per-week, per-audience.
- Advantages: EdCast's usual working style around which the bootcamps were devised. Least likely to negatively affect implementation go-live target.
- Risks: High level of difficulty in accommodating all team members. For those who will be attending both curricula (most team members), this will result in roughly 9 hours/week of necessary scheduling.
Structure 2: Friday structure.
- What it looks like: 1 90-minute session every Friday, per-audience.
- Advantages: Most likely for all team members to attend without conflict. This will result in a total of 3 hours of scheduling each Friday for team members who will be attending both.
- Risks: Most likely to negatively affect implementation go-live target. Some of these sessions are prerequisites for later implementation tasks, likely cascading the implementation schedule to later than expected.
Structure 3: Intensives.
- What it looks like: 1 or 2 all day sessions.
- Advantages: Most easily accommodates needs for team members to attend and contribute to both bootcamp working sessions.
- Risks: Not a professional service best practice. Consuming all of this content in intensive all-day sessions is not ideal from a learning perspective, and having only 1 day to make the majority of decisions which will affect our utilization of the product is likely to cause further issues.
Structure 4: Structured differentiation.
- What it looks like: Several sessions explicitly divided out by content type and necessary personnel. For an example of how GitLab has done this with other product implementations, see this issue.
- Advantages: Provides the granular curriculum detail necessary to efficiently and effectively schedule each team member's necessary bootcamp involvement.
- Risks: Logistical complexity. Would require EdCast to provide a great deal more up-front detail regarding the bootcamps, and force specified timeframes for each working session (which may preclude synchronous task completion in some cases). Aggregate length of time for the completion of all bootcamps in this instance is currently unclear, and thus, the degree to which this would affect the implementation timeline is unclear.
In our October 2nd meeting with the EdCast team, we will be looking to discuss these options between EdCast and GitLab team members to reach a consensus on the best path forward. Will subsequently update the issue with further details, if possible.
We will need to reach a decision on the structure which will best accommodate implementation team members by October 8th, and ideally, as quickly as possible.