The purpose of this page is to describe the workflow governing delivery for the different forms of professional service projects. GitLab professional services employs three different workflows that control projects for the following categories: standard professional services, education, and dedicated engineers. Each of these categories have unique attributes that warrant a different approach. The page also provides a section that describes workflow patterns that are common across all service delivery categories.
The Professional Services (PS) team scheduling is processed through the Sr. PS Project Coordinator (PC). Until we roll out our PSA tool (Mavenlink), we have a spreadsheet that is our single source of record. This spreadsheet will track all schedules of the PS team, which will include customer projects and internal work as well.
Follow these steps to schedule a customer engagement.
To request an assignment, comment to the Sr. Professional Services PC on the project/ issue with the following details:
The Sr. Professional Services PC will review the spreadsheet for availability and confirm when scheduled to the calendar. If there is a schedule conflict the Sr. Professional Services PC will provide another set of project dates.
Scheduling updates and changes will also follow this same process with a comment on the project/ issue to the Sr. PS PC.
If a customer project has not booked, but planning/ scheduling discussions need to take place, reach out to the Sr. PS PC to review.
Each PSE is required to add their own internal time to the spreadsheet, including the following details:
A weekly touch base call is held with the team to review schedules. This type of cadence and review of the schedule will help with utilization, planning and forecasting purposes.
See the details in the Project workflow section of the PS Project Management page.
During discovery or fact finding sessions with the customer, PSEs will often have a predefined list of questions that need to be answered to to ensure we're designing and building the appropriate solution given customer constraints and requirements. It is good practice to send these question to the customer prior to the discovery call so they can be prepared for the discussion.
During the call, take notes to ensure that things that have validated or invalidated your initial assumptions have been captured. At the end of the meeting, review the things you've learned to memorialize what will be designed and built. Reiterating back your understanding of the details of the agreement instills confidence in the customer representative that we understand their requirements and can deliver what was reviewed.
After the meeting, based on meeting notes, create issues in the gitlab.com customer collaboration project outlining the work. Include Consider using a simple template with
Acceptance Criteria. These can be helpful in further memorializing the scope of work with the csutomer and getting asynchronous feedback to open questions. Make sure the
overview is as detailed as possible, and the
tasks section has build-to level tasks (e.g. update congregate list() function to include data from CI sources).
PSEs who deliver GitLab Education Services instructor-led courses can use the following workflow to ensure smooth interactions with customers. In addition, PSEs should complete these GitLab Certified Trainer steps for each course they are scheduled to deliver.
The Project Coordinator will contact the customer with a "Welcome to PS Email". The email will include proposed training dates and training session planning meeting details, which will include the PSE trainer in the meeting. Trainer participation in this meeting is critical – please let the PC (Project Coordinator) know if you need the meeting to be rescheduled to ensure your attendance.
Use these email communication templates to ensure communication of the key details with the customer and training participants.
Add the confirmed date(s) and start/stop time(s) for each training session to the issue and @ mention the Education Practice Manager.
The Education Practice Manager or Project Coordinator will set up a Zoom Webinar session for each session using these set up instructions and add the registration link(s) to the issue. You will receive an email message with your unique link to join the Zoom Webinar session.
At least 3 business days prior to the training session, email the session registration link(s) to the customer, asking them to send the link(s) to each of the employees whom they want to attend the session(s). When each person registers they will receive an automated confirmation email with a Zoom Webinar join link unique to each person, along with a link to add the session to their calendar.
Contact the PS Instructional Designer to confirm you have the latest versions of course slides and other materials.
Review the train-the-trainer (T3) video for the course you are delivering
Review, practice, and use these PS Remote Training Tips and Tricks.
Complete the GitLab Training Lab set up steps below.
Starting in Q1FY21 PS is incorporating the GitLab Demo Cloud as the standard environment for hands-on course lab activities and hands-on certification assessments. Follow these steps to set up your course attendees for lab access.
Register your account
Self-register at gitlabdemo.com to create your credentials on the GitLab instance during the automated provisioning process. This will provide you with your own user account and organization group for your own projects. This step is not specific course session, but is a required step as a GitLab team member.
Credentials for your course attendees will be generated when they redeem an invitation code that you’d provide to them. In essence, we create a unique invitation code for each course session that attendees redeem on gitlabdemo.com on Day 1 of the course session, and their GitLab instance credentials are generated after they enter their code.
Add your class dates: When you have confirmed your course session dates, you will need to add them to this spreadsheet and assign the provision field to the Demo System Engineer to start the process of creating an invitation code (same day turn around before 12pm US Pacific).
Share the invitation code and access instructions with attendees: Once the invitation code is generated, a new Slack channel is automatically created for that class for demo systems support purposes. Here is an example of the message that’s posted in the channel with the instructions for you to share with course attendees.
Example lab instructions message
```Invitation Redemption Code - xxxxxx Course Title: ACME Company - CI/CD Course Date(s): 2020-04-08 Max Redemptions: 30 Redemption End Date: 2020-04-10 Days before account expiration: 14
Instructions: As an instructor or as a student, visit gitlabdemo.com Click the blue button for redeeming the code above. An anonymous user account and password will be created. Click on the red button to download your credentials (very important, don’t forget to do this since you will not be able to access this page again). Click the blue button to access your group and create your first project. ```
Download the session recordings and place them in a location where the customer can access them.
Create a PDF version of the slides and place it in the same location as the recording.
Obtain the Zoom attendee report and using the emails in the report, send a Next Steps email to all of the attendees using email template #3 located in the email communication templates.
For GitLab with Git Basics course instructors: When an attendee submits their certification assessment, review their work in the demo lab cloud within 7 days of the attendee's submission and manually release their results using the attendee's completed Google Form. Here are the detailed instructions for certifying customers.
Work in progress
At the conclusion of the Statement of Work the PSE will prepare a cost vs actual analysis. This analysis will be filed in SFDC. When filed in SFDC the Professional Services Engineer will "@ mention" the Controller and Finance Business Partner, Sales in SFDC Chatter. For details see the Project workflow section of the PS Project Management page.
If the project requirements exceed the current capacity of the available resources then the professional services team may employ a subcontractor to help deliver the project. The following provides a checklist of items to process before and during the use of a subcontracted resource:
Confirm that the terms and conditions agreed to with the customer enable the use of a subcontractor. In some cases, GitLab must first obtain written approval from the customer in order to employ a subcontractor.
Generate a list of potential subcontractors. GitLab has established relationships and signed Master Service Agreements with a collection of professional services firms. Review the list of firms and select ones that have pools of resources with the correct set of skills and certifications.
Contact the GitLab Channel Account Manager (CAM) who owns the relationship for the selected firms. Provide the CAM with a description of the services GitLab intends to subcontract along with the project start/end date and an estimate on the quantity of time GitLab intends to procure.
Contact the selected firms through an introduction by the CAM. GitLab should then submit the requirements to the partner firm and request resumes and rates for any resources the partner deems available and suitable for the project. Interview proposed resources. GitLab will meet with the proposed resources to determine if the person is a fit technically as well as from the perspective of fitting in with the project team that includes both GitLab and customer personnel.
Develop a Statement of Work between GitLab and the selected firm. The Statement of Work should employ best practices that we use when developing SOW’s for GitLab customers. The SOW should also align with terms and conditions that GitLab is obligated to follow.
Sign Statement of Work.
Onboard the resource. This includes procuring a GitLab email address for the selected partner personnel. It may also include procuring access to customer systems.
Accurate time tracking records of hours is essential to ensure revenue can be recognized based upon percentage completion of a project scope as outlined in a Statement of Work ("SOW"), and this data is used in the calculation of gross margin. Key points for time tracking include:
Billable hours represent work hours that a staff member reports as being aligned to a specific SOW. The format for daily time tracking for each team member is shown below, and should be reviewed by the PS leadership for approval and sign-off. Rounding to the nearest hour is acceptable, and please ensure data is recorded in numeric format without the use of text strings such as "hrs".
The PS Issue Board contains everything that the group is working on, from strategic initiatives to SOW writing.
Issues are created for all work by PS.
There are three types of project tracking labels
Packaged - Complete or incomplete
Custom or standard SOW (more than 4 working weeks) - Tracks completed percentage (25%, 50%, 75% or 100%), unless other milestones are specified in the SOW
Embedded Engineer (time and materials project) - Bill time and materials direct to customer