Professional Services Delivery Methodology

• What is the Professional Services Delivery Methodology (PSDM)
• Managing a Project in GitLab
• Project Velocity and Iteration Scheduling
• Status Planning
• Status and Burndown Reporting
• Mitigating Risk via RAID Board
• Internal Retrospective Guidelines
• Customer Retrospective Guidelines
• Guidelines for Iteration based PSDM

What is the Professional Services Delivery Methodology (PSDM)

The Professional Services Delivery Methodology (PSDM) is the guiding framework for Program and Project Delivery within GitLab. The goal is to ensure the PS Delivery team operates within a predictable timeframe against the Project scope while prioritizing Customer Success. This is achieved through:

• Using GitLab.com as the Single Source of Truth (SSOT)
• Following label guidelines for managing and reporting progress
• Identifying and mitigating risks
• Actioning/tracking improvements internally
• Implementing iterations based for Sprint/Iteration-based SOWs
• Utilizing enablement materials
• Applying fundamental Agile best practices

Managing a Project in GitLab

GitLab serves as both a project management and collaboration platform for all Professional Services engagements. We utilize the following features/terminology within GitLab for project management:

Please reference the GitLab best practices when navigating GitLab.

For initial configuration of GitLab as a Project Management tool, see the configuration guide.

NOTE: Any issues marked as “internal” are still visible to anyone who has “developer” access into the GitLab Collaboration project. This includes people outside of GitLab. It is recommended to use the Project’s “Internal Epic” for confidential communications.

Project Management Mapping in GitLab

For additional clarity on mapping Agile terminology to GitLab, reference this guide.

Label Guidelines

Labels are the most effective way to generate reports around Projects and organize information according to the Project team’s needs. While teams have flexibility to create labels that meet their specific project reporting requirements, there are established guidelines for label generation for internal use.

Our CP (Customer Project) automation includes the following default 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 retrospectives & RAID tracking/reporting can be found in the “Reporting throughout the Iteration” section below.

Project Velocity and Iteration Scheduling

The iteration schedule and cadence is first introduced in Iteration 0 and becomes part of the Engagement Charter within the GitLab Customer Project (Group). It is crucial that the Customer agrees to an Iteration Schedule as an output of the Customer Kickoff. However, this should be initially introduced and collaboratively developed with the Customer during the Stakeholder Planning meeting.

When working within an Iteration/Sprint schedule, there are five key components:

1. Iteration Planning - Setting goals and selecting work items for the iteration
2. Daily Standup - Brief synchronization meetings to share progress and identify blockers
3. Backlog Refinement - Clarifying, estimating, and prioritizing upcoming work
4. Iteration Review - Demonstrating completed work and collecting feedback
5. Retrospective - Reflecting on the process and identifying improvements

When not working within Iterations, it’s still important to clearly communicate the project velocity to ensure consistent resource alignment. For example: “We anticipate working 40 hours/week for 5 weeks to perform a successful upgrade and seamless migration of 1000 users and 2000 projects from GitLab SaaS to Self-Managed for FedRAMP compliance.” This is validated during the Stakeholder Planning meeting and Customer Kickoff.

Status Planning

For Agile SOWs, the Program Manager / Project Manager provides strategic direction for the project, including the vision, product roadmap, release goals, and iteration objectives. The Program Manager / Project Manager is responsible for managing the product backlog by inserting, re-prioritizing, refining, or removing items as needed. This can occur at any time until the iteration scope is defined and committed to by the development team.

Please reference Backlog Management for guidance on estimation, backlog grooming, and preparation for Iteration Planning.

If the scope of work is more strictly defined within the SOW, the PM is expected to assess the impact of any changes and work with the Customer to either reprioritize or initiate the Change Order process.

Status and Burndown Reporting

Who Updates What?

While the PM is responsible for preparing ceremonies, reporting status, and managing Issues, the GitLab PSE (Professional Services Engineer), TA (Technical Architect), and Customer team members are all expected to contribute to and update their assigned issues (tasks) within the Project board. This highlights the importance of establishing effective Working Agreements during Iteration 0.

Working asynchronously and remotely presents unique challenges. Ensuring that the Directly Responsible Individual (DRI) actively contributes to their assigned issues is vital to maintaining project velocity. This approach allows the PM to shield technical teams from distractions while enabling effective status roll-up.

Not every Project will follow a Sprint or Iteration cadence. However, status updates should be documented within GitLab and reported to the Customer on a weekly basis. It is recommended to use an Engagement Charter to direct stakeholders to weekly status updates, RAID logs, and other relevant project documentation.

Status Report Examples:

• Engagement Charter Example
• Status Update Example 1
• Status Update Example 2
• While the GitLab CP is the recommended platform for status reporting, if the Customer prefers a presentation format, please reference this template.

Project Burndown

While Kantata is the single source of truth for our Financial Management, we recommend PMs track the hourly and finanical burn seperately for additional auditing and progress against the progression of the Project. Templates can be found here. It is required to track hourly/financial progress within the weekly status report

Mitigating Risk via RAID Board

The RAID (Risks, Actions, Issues, and Decisions) framework serves as our single source of truth for project risk identification, management, and resolution. It provides several key benefits:

• Creates transparency for project stakeholders and leadership
• Enables proactive monitoring of projects with Yellow/Red health status
• Centralizes risk documentation and mitigation strategies

Setting Up RAID

• The RAID board is automatically created when the PM initializes the CP template
• Rename the template to “RAID - [Customer Name] - [SOW/PO#]”
• While the PM is responsible for creating and managing the RAID, both internal team members and Customer representatives are encouraged to update it as challenges and mitigations evolve
• View an Example RAID Log

Reporting on Risk via RAID

When documenting a risk, follow these guidelines:

1. Apply appropriate labels:

   • “PS RAID Log”
   • “PS Risk”
   • “PSD Workflow::Not Started”

2. Define severity using priority labels:

   • “PS:: Priority High”
   • “PS:: Priority Medium”
   • “PS:: Priority Low”

3. Quantify impact in terms of:

   • Timeline effects
   • Scope changes
   • Quality implications
   • Budget consequences

4. Assign ownership:

   • Designate a person responsible for accepting, mitigating, or resolving the Risk

5. Detail mitigation plan:

   • Document specific actions to lessen or eliminate the Risk

6. Escalation process:

   • Use the “Escalated” label for risks requiring immediate attention that impact project progress
   • Escalated items should be surfaced in the Professional Services Portfolio report

Internal Retrospective Guidelines

The Internal Retrospective issue serves as an ongoing reflection mechanism throughout the project lifecycle, focusing on:

• Capturing team accomplishments and celebrations
• Documenting technical challenges and solutions
• Identifying process improvements
• Recording business development opportunities
• Building institutional knowledge for future engagements

Unlike the Customer Retrospective which occurs at project milestones and reviewed with the Customer, the Internal Retrospective serves as a way to capture improvements needed to improve our proceses and celebrate team wins

Setting Up the Internal Retrospective

The Internal Retrospective is automatically created when the Customer EPIC is established:

1. Location:

   • The issue lives within the internal Customer EPIC
   • It should be linked in the internal Project Slack channel for easy access

2. Template:

   • Use the latest template to ensure standardization
   • The PM should ensure the template is properly populated with project information

3. Access:

   • This is an internal-only issue - no customer access should be granted
   • All GitLab team members working on the project should have access

Contributing to the Internal Retrospective

Team members should contribute to the Internal Retrospective throughout the project:

What to Document

1. Project Wins and Celebrations:

   • Technical achievements
   • Customer praise and positive feedback
   • Team collaboration successes
   • Innovative solutions

2. Lessons Learned:

   • Technical challenges and how they were overcome
   • Process gaps and workarounds
   • Communication improvements
   • Tools and techniques that proved effective

3. Opportunities for Improvement:

   • Areas where processes could be streamlined
   • Documentation gaps
   • Training needs identified
   • Tool limitations

4. Assets Created:

   • Scripts and code snippets
   • Documentation templates
   • Configuration guidelines
   • Customer-specific solutions with reuse potential
   • Any Delivery Kit related updates

How to Contribute

• Ongoing Basis: Team members should add comments to the issue as noteworthy events occur
• Weekly Check: The PM should encourage updates during weekly team meetings
• Phase Transitions: Special attention should be given to capturing learnings at the end of each project phase

Finalizing the Internal Retrospective

At project completion, the PM should:

1. Conduct a Final Session:

   • Schedule a 30-60 minute Gitlab team retrospective call, inviting PS Practice team members
   • Review contributions and synthesize key learnings
   • Identify patterns and major takeaways

2. Categorize Learnings:

   • Apply appropriate labels to facilitate future searching:

3. Create Follow-up Issues:

   • Generate specific issues for action items
   • Assign owners for implementation
   • Set realistic timelines for completion

An example Internal Retrospective can be found here]. The list of inflight and completed internal retros can be found in the “PS-Plan” Gitlab Project by searching within “Titles” and the text “Internal Retro”.

Knowledge Sharing

PS leadership regularly reviews retrospective data to:

• Identify common challenges across projects
• Recognize exceptional team performance
• Inform training and enablement priorities
• Update delivery kits and methodologies
• Shape future service offerings

Best Practices

• Keep entries objective and solution-focused
• Include specific examples rather than generalizations
• Maintain a balance of positive observations and improvement opportunities
• Focus on systems and processes rather than individuals
• Quantify impact where possible (time saved, problems avoided, etc.)
• Suggest specific, actionable improvements

Customer Retrospective Guidelines

The Customer Retrospective is a critical component of the Professional Services Delivery Methodology that provides structured feedback on the engagement alondside our Customers. It serves to:

• Capture the customer’s perspective on the engagement
• Identify what went well and areas for improvement
• Document successes and challenges for future reference
• Strengthen the customer relationship through collaborative reflection
• Generate insights that can inform future engagements
• Encourage CSAT particpiation

Setting Up the Customer Retrospective

The Customer Retrospective issue is automatically created when setting up the collaboration project:

1. Initial Setup:

   • Rename the template to “[Customer Name], [SOW/PO#]” when setting up the project CPR
   • The issue serves as a living document that both GitLab and Customer teams can contribute to throughout the engagement

2. Ongoing Documentation:

   • Much like the internal retrospective, encourage Customers to document feedback throughout the engagement
   • Regular updates help capture insights while they’re fresh and relevant

Conducting the Customer Retrospective

Preparation

1. Schedule the session:

   • Plan a closure/retrospective meeting with the customer at the end of the PS engagement
   • Share the retrospective issue in the meeting agenda for team members to pre-fill before the session

2. Encourage participation:

   • Ask team members to add their initials before their feedback under each main section
   • If someone agrees with existing feedback, they should add their initials alongside the original contributor

During the Session

The retrospective meeting should cover these key sections which are found in the issue template:

1. Attendees and Date
2. Summary of Services & Value Delivered
3. Final Burn Down Report
4. Retrospective Discussion
   • What went well
   • What could be improved
   • Lessons Learned
5. Feedback on PS processes or Methodology
6. Voice of the Customer

Documenting and Following Up

After the retrospective session:

1. Finalize the document
2. Apply appropriate labels
3. Create action items
4. Share insights within #ps-internal

Best Practices for Customer Retrospectives

• Keep the tone collaborative and constructive
• Focus on specific, actionable feedback
• Balance discussion of challenges with celebration of accomplishments
• Capture both technical and process-related insights
• Ensure customer’s voice is prominently featured
• Document quotes and testimonials (with appropriate permissions)
• Use the retrospective to strengthen the customer relationship

Additional Resources

• Retrospective Facilitation Issue/Guide
• Customer Survey Template

Guidelines for Iteration based PSDM

The full PSDM implementation with a complete Iteration schedule is required only when the Agile-specific SOW

• Exceeds 5 Iterations, or
• The engagement is planned to exceed two months

Please review the archetype definitions to understand what constitutes a “large” Customer engagement.

Use the following guide when planning for Iteration 0:

View page source - Edit this page - please contribute.