Professional Services Delivery Methodology

What is the Professional Services Delivery Methodology (PSDM)

The Professional Services Delivery Methodology (PSDM) is the guiding light for Program and Project Delivery within GitLab. The goal is to ensure the PS Delivery team operates within a predictable time slice against the Project scope while ensuring we’re focused on Customer Success. This is done through GitLab.com as the SSOT, label guidelines for managing and reporting against progress, risk, iterations needed against our processes and enablement material, and fundamental Agile best practices.

Iteration 0

Iteration 0 includes the initial discovery and planning between the GitLab & Customer Project Team(s). This includes:

• EM>PS Delivery Transition
• Stakeholder Planning
• Customer Kickoff
• Discovery sessions with the Customer

To prepare and deliver Iteration 0, the PM will work with the GitLab Project team to review the timeline against the agreed upon scope and dependencies. This ensures we are gathering the right information and understanding the potential risks. Allowing us to show up to Iteration 0 more aligned with our Customers and prepared to deliver against a more predictable schedule.

Proper Iteration 0 preparedness allows us to address risk early and instills confidence with our Customers.

Managing a Project in GitLab

GitLab will be used as a project management and collaboration platform. We will be using the following features/terminology in GitLab defined below.

Please reference the following tips for GitLab best practices when navigating GitLab.

How to initially configure GitLab as a Project Management tool can be found here.

NOTE: any issues marked as “internal” are still visible to anyone who has “developer” access into the Gitlab Collaboration project. This includes anyone outside of Gitlab. It it recommended to use the Projects “Internal Epic” for confidential communications.

Project Management Mapping in GitLab

Reference here for additional clarity around mapping Agile terminology to GitLab.

Label Guidelines

Labels are the best way to generate reports around our Projects and sort according to the Project teams’ needs. The team is free to make labels as they see fit for Project reporting, but there are also current guidelines around label generation for internal use.

Currently, our CP (Customer Project) automation includes the following labels:

• SOW-# or PO# - helps the GitLab team search for Projects within the Professional service Group
• PM name - helps the GitLab team sort by PM name
• PSD workflow (for issue board management)

Labels used for Internal retro & RAID tracking/reporting can be found in “Reporting throughout the Iteration” below.

Iteration Scheduling

The iteration schedule and cadence is first introduced in Iteration 0, and is part of the Communication Plan that lives within the GitLab Customer Project (Group). It is important the Customer agrees to an Iteration Schedule as an output of the Customer Kickoff, but should be introduced & collaborated with the Customer as part of our Stakeholder Planning meeting.

There are five components within an Iteration schedule:

1. Iteration Planning
2. Iteration Review
3. Daily Standup
4. Backlog Refinement
5. Retrospective

Iteration Planning & Review

The Program Manager / Project Manager provides strategy and direction for the project, which means he/she is responsible for providing the vision, product roadmap, release goals, and iteration goal. The Program Manager / Project Manager is expected to insert, re-prioritize, refine, or delete items from the product backlog; this can happen any time until the iteration scope is defined and committed to by the development team.

Please reference Backlog Management for guidance around estimation, backlog grooming, and other Iteration Planning preparation tips.

Reporting within the Iteration Schedule and Project

Who Updates What?

While the PM is expected to prepare for the various ceremonies, report on status, and work within Issues, the GitLab PSE (Professional Services Engineer) & TA (Technical Architect), along with the team members on the Customer side, are also expected to work within the planned issues (tasks) within the Project board.

Working asynchronously & remotely can be challenging. Ensuring the DRI within the issue is actively contributing to is crucial to the project’s velocity. It’s the best way the PM can protect the technical teams from distractions as well as make sure there is an effective status roll-up.

RAID & Internal/Customer Retrospective

The RAID, Internal Retrospective, and Customer Retrospective not only assist with the progression of a Project, but these records act as a mechanism to feed back into our Business Development, Customer Success tracking, and Team celebrations. Please reference here for more guidelines on how to manage these reports once a Project begins.

The Customer Retrospective guidelines can be found here.

Guidelines for PSDM

Applying the suggested PSDM with a full Iteration schedule is needed only when the Project exceeds 5 Iterations or when the engagement plans to exceed two months.

Please review the archetype definitions around what a “large” Customer looks like.

Please use the below as a guide, when planning for Iteration 0.

View page source - Edit this page - please contribute.