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. Categories: Currently Professional Services offers two major categories of services: Education and Consulting.
2. 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 Advisory are examples of types of services in the Consulting category. Custom and Standard are types of services in the Education Category.
3. 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 readiness assessment and general implementation services in the Consulting Category and Implementation Type.

Offering Maturity Model

The services maturity framework provides for 5 maturity levels for offerings: planned, minimal, viable, complete and lovable.

• Planned: A future planned offering
• Minimal: The offering is defined, a vision for moving to complete exists
• Viable: We have delivered the offering at least once, feeding lessons learned into the completion plan. At least some marketing materials and execution plans from Complete
• Complete: An offering that can be consistently delivered: predictability in timing, results, and margin.
• Lovable: The offering is at full maturity, positive NPS & impact on customer’s adoption of GitLab product

Service Offering Framework

In general, you can find our publicly marketed services on our service catalog page and the delivery kits at: Consulting and Education

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 T&M 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 and TAs and practice update the build sheet, which includes updating the COGS (Cost of Goods Sold).

Tooling and Automation

• Tooling/Automation: Technical Architects create any necessary resuable tooling or automation as part of the engagement.
• Create Delivery Kit: Technical Architects document 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
• Review and Approval: Practice team reviews and merges delivery kit.
• Track Contributions and Progress: Staff Program Manager tracks delivery kit contributions and progress during delivery.

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

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 Hub 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 (if needed, 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.

Delivery Kit Creation and Contribution

• Indicate Need for Delivery Kit: During the Engagement Manager → Transition call, indicate the need for a delivery kit to be created. This will be tracked with labels Delivery-Kit-Update, and Practice-Management in the Retro Issue
• Schedule Time for Contributions: Ops schedules additional time for delivery kit contributions.
• Initial Delivery Kit Creation: Architect builds the initial delivery kit as part of the delivery process.
• Review and Approval: Practice team reviews and approves the delivery kit.

Grooming and Maturity Matrix

• Groom Current Delivery Kits: Practice and Delivery regularly grooms delivery kits.
• Create Maturity Matrix/Score: Practice and Delivery maintain a maturity matrix to evaluate the quality and completeness of delivery kits.

View page source - Edit this page - please contribute.