Professional Services Offerings Framework

What is a Services Offering Framework?

Its a way of organizing the collection of services we offer into a way that can be understood and managed by many different people involved in the selling and delivery of professional services at GitLab.

Why do we need to categorize services using a taxonomy?

The short answer is that it helps us manage the business and eases the selling process to use standard and universally-understood language.

We need a way to determine market trends using bookings and revenue data. We categorize the services we sell into the below taxonomy to measure bookings and revenue to identify market trends. This will help us make data driven investment prioritization decisions rather than judgement calls. Additionally, we need a way to understand the delivery forecast by specific service category and type to ensure we have the staffing and/or partnerships in place to be able to deliver.

There are many people involved in the selling and delivery of services: the customer, the account team (SA, CSM, SAE), the PS engagement manager, the PS project coordinator, the PS project manager, the PS Engineer (and as we introduce partner selling motions, there could be many more). Its important for everyone to use the same universally-understood language to minimize ambiguity. This will help improve our scoping accuracy, reduce overages, improve predictability, and increase overall Customer Satisfaction.

Services Taxonomy

1. Customer GitLab Adoption Journey: Professional Services organizes its services to cater towards the Customer GitLab journey, with the following service pillars: Source Code Management (SCM) Consolidation, CI/CD Modernization, DevSecOps Transformation, and Value Stream Management. Some services can span across multiple pillars (e.g. Onboarding, Education, Duo).
2. Categories: Currently Professional Services offers two major categories of services: Education and Consulting.
3. Types: Further classifying types of services help us analyze business trends, prioritize investments, and schedule delivery. Types of services are broken out for each Category of services. These service types use ubiquitous language. They should mean the same thing to the customer buyer, the account team, the Engagement Manager and the delivery team. Migration, Implementation, and CI/CD, and Security are examples of types of services in the Consulting category. Custom and Standard are types of services in the Education Category.
4. Offerings: There can be multiple offerings in each service type. As we identify market trends, we accumulate and build more offerings per service type. For example, we have a self-managed health check and other general implementation services in the Consulting Category and Implementation Type.

Service Offering Framework

In general, you can find our publicly marketed services on our service catalog page and more information at: Consulting Delivery Kits and Education Service Info

New Service Process

The process in which Technical Architects, Engagement Managers, and Practice Management collaborate in order to bring a new service or offering to market when identified by Engagement Managers.

Identification of New Offering Needs

• Identify Need: Engagement Managers, Technical Architects, and Practice Management identify the need for a new service or offering, often based on opportunities with customers.
  • Every new service will begin as a SOW to allow for iteration and scope/price/LOE rightsizing. Once the service becomes cookie cutter, repeatable, and delivered often, we will create a SKU as a last step.
• Review/Update Slide Decks: Engagement Managers and Practice Managers Review/Update as needed the:
  • FY25 GitLab Global Services deck for considerations and methodology.
  • PS Proposal Deck Templates for individual service pre-sales pitches.
• Custom Scope Service: Engagement Manager coordinates with a Technical Architect to create a custom SOW or DOW that scopes the services including any tool enhancements involved, runbooks and documentation.

Initial Documentation and Planning

• Write Data Sheet: Practice Management creates a draft data sheet following a template in this folder, creating a google slide and then saving as a pdf.
• Create Template SOW (DOW only if necessary): Engagement Manager coordinates with TA and practice team to create google docs and pdf versions of these documents. See examples here.
• Create Estimate Breakdown: Engagement Managers outline cost estimates with TAs and practice update the build sheet, which includes updating the COGS (Cost of Goods Sold) to show a breakdown of hours per resource role and project margin.

Tooling and Automation

• Tooling/Automation: Practice and TAs collaborate to create any necessary resuable tooling or automation as part of the engagement.
• Create Delivery Kit: Practice creates the first iteration of the delivery kit during the engagement that includes:
  • Documentation
  • Runbook(s) with delivery steps
  • High-level delivery document template for PS with delivery artifacts for Customer
  • Links out to tooling used to assist with the delivery of this engagement
  • PM methodology and delivery guides
• Review and Approval: Practice team reviews and merges delivery kit. Afterwards, a combination of Practice and Delivery team members become designated CODEOWNERS to incentivize high quality contributions and assist in the review triage process.
• Retro and Contributions: Post-engagement, the delivery and practice team conduct a retro on the engagement to analyze improvements in tooling, delivery kits, collateral, estimation, and processes that can be made.

Documentation and Updates

• Update Qualification Questions: Engagement Managers & Technical Architects update the qualification questions as needed.
  • These are discovery questions to help EMs gather the inputs to the build sheet scope estimate.
• Update PSQ Offerings: Practice Management updates the PSQ offering language based on the template SOW.
• Perform Initial Enablement Sessions: Practice works with Technical Architects and Engagement Managers to perform initial enablement sessions.
  • Engagement Management
  • Delivery
  • Training & Education
  • Recordings

Marketing and Sales

• Update Marketing Pages: Practice updates the marketing pages as needed.
  • Service catalog
  • Update about.gitlab.com/services page in Contentful
  • Update Professional Services Resources Page in HighSpot.

Ongoing Enablement Sessions

• Daily PS Offering Working Sessions: Lead by Practice Management
• Friday PS Enablement Session: Led by Professional Service Engineers and Technical Architects

Additional Steps for SKUs

• Update Zuora by creating a systems issue.
  • The SKU process typically takes anywhere from a few weeks to a few months depending on request urgency and how fast all the necessary leadership approvals can be attained.
• Create SKU service description (examples here).
  • SKU service descriptions are the equivalent of SOWs for SKUs purchased through Zuora. Because these are transacted via an Order Form and are fixed price, the service descriptions omit hours requirements and authorization requirements.

View page source - Edit this page - please contribute.