Purpose

This project represents a library of tips, tricks, and best practices to gain efficiencies, using repeatable practices, artifacts, and tooling.

By leveraging these resources, project managers can streamline their workflows, reduce redundant efforts, and deliver consistent results across projects.

All of this information is backed by a comprehensive GitLab PMO Delivery Kit Project.

Directory Structure

The repository follows standard and GitLab project management phases, with each directory containing specific documentation and resources:

• Project Start (first 2 weeks)/: Project charter, stakeholder identification, scope definition
• Planning/: Project plans, resource allocation, risk assessment
• Project Delivery/: Task management, status reporting, change control
• Escalations/: Performance tracking, issue management, stakeholder communication
• Project Launch/: Launch, support, and transiction activiites
• Closure/: Deliverable finalization, lessons learned, knowledge transfer
• Examples/: Sample documents from past projects
• Resources/: Additional tools, checklists, and reference materials
  • Templates/: Reusable document templates for each project phase
  • Using AI/: Some example prompts and knowledge base artifacts

Special Notes

• Each directory contains specific instructions for its respective project phase
• Some directories may link to other relevant project resources
• Always check with the respective DRIs before making significant changes to any section
• Use the examples as reference, but customize templates to fit your specific project needs

Overview

The Pre-Sales phase for our PS PMO team includes the SOW validation and information gathering steps before the contract is signed. During this phase we work to get ahead of risk as well as get a kick start into our Project Start and Planning phases. It is encouraged to work closely with the PS Engagement Manager and Technical Architect during this phase.

Pre-Sales

• Identify assumptions, risks, and areas needing clarification
  • Review Standard Risk List
• Ensure realistic timelines, deliverables, and acceptance criteria
• build out intitial resource allocation (by role type) and associated budgets with PS Ops team
• Review and provide feedback on SOWs to the EM, before finalizing (when possible)
• Customer Homework (via Customer Epic, scoping issue, transition issue, Account & EM team context)
  • Provide project specific artifacts for the customer to familiarize themselves with established processes and required items on their side.
• If agreed by the Customer, work through the WaR (work at risk) to begin Project Setup & Planning so we can effectively bill to the Project.

Overview

The Initiation phase is the foundation of successful project management. This critical first stage establishes the project's purpose, direction, and boundaries while securing stakeholder alignment and commitment.

A well-executed initiation phase significantly increases the likelihood of project success by ensuring clear understanding and agreement on fundamentals before resources are committed.

Project Start (first 2 weeks) - Iteration 0

This page will outline steps to complete all of the following project tasks.

• Set up project financials and resource scheduling
• Conduct stakeholder planning, kickoffs, dependency mapping, risk mapping, timeline planning
• Establish working agreements, deliverable acceptance criteria

Resource Allocation planning

1. If not yet done, review associated Kantata Project, SOW, and scoping issue attached to the Customer Epic -note the scoping issue helpss formulate baseline project understanding needed to formulate project plannning, resource scheduling, and risk
2. For Consulting Block SKUs: Review the DoW (should be attached to Customer Epic)
3. Work with Resource Scheduling team to align the appropriate resources
4. Use Burndown templates to build the intial resource/plan schedule

Conduct Sales > Delivery Transition

1. Invite Engagement Manager, Technical Architect, Professional Services Engineer, Account Managers, and Customer Success Managers (if assigned)
2. Use Sales to Delivery Transition Issue (attached to Customer Epic) to guide your meeting, update in real time. Focus the meeting on:
   • Business drivers and context
   • Timelines
   • SOW validation and clarification
   • Technical requirements overview
   • Schedule planning for Stakeholder Planning and Kickoff
   • Review initial resource plan/schedule
   • Risks and dependencies
   • Review Working Agreements and determine needs for a SteerCo
   • Review the need for a RACI

Project Setup Step

Before diving into the formal project initiation activities, follow these practical setup steps to establish the project infrastructure:

1. Review the Customer Epic and Child Stories

• Thoroughly review all customer requirements
• Identify key deliverables and expectations
• Note any questions or clarifications needed
• Understand dependencies and constraints

2. Create the initial Collaboration Project

• Use Claude to assist in setting up the GitLab project structure
• Set up appropriate project visibility and access permissions

3. Import Project Issues into the CP

• Standard PMO Issues
• Creating Issues from SOW

4. Update the initial Project Charter within the CP

• Charter Example

5. Create an Internal Project Slack Channel

• Establish a dedicated communication channel for the project team
• Invite all relevant team members
• Pin important documents and links
• Create a Slack Project Charter Canvas (Optional)

6. Create a Project Canvas

• Use Claude to help develop a comprehensive project canvas
• Include project vision, objectives, key stakeholders, and constraints
• Outline high-level timeline and milestones

Stakeholder Planning Meeting

Leverage this meeting to identify and address any expectation misalignment between GitLab and the Customer team before the broader kickoff meeting

Schedule a dedicated meeting with Customer PM & key stakeholders from both GitLab and Customer teams. Use the Stakeholder Planning Template to guide the discussion Focus on mutual understanding of project parameters

• Confirm Project Stakeholders

  • Identify all key participants and their roles
  • Confirm availability and communication channels
  • Project Objectives

• Validate business drivers and success criteria

  • Align on use cases and expected outcomes
  • Project Velocity and Timeline

• Set expectations on pace and milestone dates

  • Discuss sprint/iteration cadence preferences
  • Project Prerequisites

• Review technical and organizational readiness

  • Identify any blockers to starting work
  • Kickoff Preparation

• Determine agenda and participants for the full kickoff

  • Set expectations for the kickoff meeting
  • Onboarding Validations

• Ensure all access and permissions are in place

  • Verify environments and tooling availability

• Next Steps

  • Document action items with owners and deadlines
  • Plan for Customer Kickoff and Discovery sessions

• Key Outputs

  • Validated stakeholder list and roles
  • Aligned expectations on timeline and velocity
  • Documented prerequisites and dependencies
  • Prepared agenda for Customer Kickoff
  • Action items with clear ownership
  • Create Customer Slack channel and invite Customer & Internal Project team members. You can you use this AR as template
  • Create a Support Ticket to be reviewed at kickoff

Customer Kickoff

1. Consolidate insights from EM>PS Transition and Stakeholder Planning
2. Prepare the presentation using the Kickoff deck template
3. For projects where we recommend a steering committee meeting, also prepare the SteerCO template
4. Ensure all key (driving and leading) stakeholders are invited

Present a comprehensive overview of:

• Project objectives and success criteria
• Team structure and roles
• Project approach and methodology
• Timeline and milestone plan
• Communication and reporting cadence
• Next steps and immediate actions

Key Outputs:

• Confirmed understanding of project objectives, approach, and dependancies that will drive progress
• Scheduled Discovery & Planning sessions
• Confirmed Iteration Cadences
• Confirmed SteerCO needs
• Confirmed RACI needs
• Create Customer Slack Channel and invite Customer Project team members. You can you use this AR issue as a template within the access-reuests Project
• Documented action items with clear ownership
• CSAT shared
• Support ticket created & shared with the Customer

Subject: [Your Company] Professional Services - [Project Name] Introduction

Hello [Customer Contact],

Thank you for [EM for the context/introduction]. I look forward to working with you on the [Project Name].

In terms of next steps, I would like to set up two meetings with you and your team:

Meeting 1 - Stakeholder Introduction Call (30 minutes)

I consider this a virtual handshake and project planning call in which we will align on the services included, proposed schedule, any onboarding requirements you may have for us, and how we will communicate during the engagement (meetings, chat platform, etc.).

May I ask for your availability for the week of [Date Range]? Requested attendees: Project Lead/Project Manager.

Meeting 2 - Kick off meeting (1 hour)

During this meeting, we will officially kick off our project together. The typical agenda includes introductions, project scope, schedule and timeline expectations, communication plan, meeting cadence, access requests, project closure, and a review of action items. Time permitting, we will begin the initial discovery conversations during this call.

Requested attendees: Project Lead/Project Manager/Full Project team.

Please let me know if you have any questions.

Regards,

[Your Name] [Your Title] [Your Contact Information]

With this meeting, I hope to kick off our partnership by learning a little about our mutual ways of working.

• Document team composition.
• Discuss customer availability requirements.
• Agree to communication approach, overall project plan, and overall goals.

Outcome of Project Planning Meeting: We are aligned on scope and ways of working, allowing us to move forward for a full project kickoff.

[Customer Name] Project Kickoff Meeting

Purpose: To formally bring project teams together and kick off the [Project Name].

Outcomes: All team members are:

• Aligned on scope and expectations
• Clear on their roles and responsibilities
• Prepared to move forward effectively

Agenda

Part 1: Project Management Overview (~30 minutes)

• Introductions
• Project scope review
• Timeline and milestones
• Communication plan
• Working agreements

Part 2: Technical Discovery (~30 minutes)

• Current state assessment
• Technical requirements discussion
• Next steps and action items
• Open Q&A

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.

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.

What is CP?

The CP or "Collaboration Proejct" is the framework for how we would like to manage delivering engagements in a standardized, repeatable manner all within GitLab. Each customer will have their own group in GitLab and that group will contain a project for each SOW we deliver for that customer. These groups and projects will house all the information around the project delivery to easily track the progress and health of a project as well as provide a paper trail for all the work we have done during the project.

A list of our Projects can be found here: GitLab Professional Services Group if staffed internally or GitLab Partner Collaboration Group if staffed fully or partially with partners.

Project Management Mapping in GitLab

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

How does an SOW flow into CP?

A PSQuote quote contains one to many quote lines. Those quote lines map 1:1 to epics within a customer group on gitlab.com and each epic is then treated as a workstream. That customer group will contain one to many projects depending on how many SOWs we deliver for that customer. For each epic, the PM will create various issues tracking specific work towards the completion of each workstream.

What are the common components?

• A customer group: This group will house all the work we do for a specific customer.
• An SOW/PO project: These projects will reside within the customer group and house all the work we do within that specific SOW or PO.
• Workstream epics at the customer group label: These are what tie directly to the activities in the SOW.
• A standard library of issue templates.
• A standard library of comment templates.
• A standard series of boards covering the status of each task/issue per workstream.
• Any specific documentation from our delivery kits.

How will all this get created?

We have a project called CPR_GitOps that handles the process of automatically creating the foundation of groups, projects, epics, etc per Customer Project. This automation is triggered by our Quilt API through PSQuote. We are currently using a merge request as the staging area to provide all the necessary details CPR_GitOps needs to properly scaffold out a project to deliver.

Converting a Statement of Work to TOML for GitLab Collaboration Projects

Overview

This guide provides instructions for converting an uploaded Statement of Work (SOW) document into a properly formatted TOML file for use with the GitLab Collaboration Project template.

Step-by-Step Process

Step 1: Upload Your SOW Document

1. Tell Claude that you will upload an example TOML file for a collaboration project, then upload the exmple teamplate found here: Collaboration Project Template
2. Upload your Statement of Work document to a Claude chat.
3. Ask Claude to convert the SOW into a TOML file using a request like:

   Please convert this Statement of Work into a TOML file for a GitLab Collaboration Project. 
   The customer name is [CUSTOMER NAME], the Kantata workspace URL is [URL], 
   the epic ID is [ID NUMBER], and the project manager username is [USERNAME].
   

Step 2: Provide Required Metadata

Ensure you include these key pieces of information in your request:

• Customer name (exact legal name of the organization)
• Kantata workspace URL (formerly Mavenlink URL)
• Epic ID (numerical ID for the project epic)
• Project manager's GitLab username

Step 3: Review and Save the TOML File

1. Claude will analyze the SOW document and generate a structured TOML file containing:

   • Project metadata (customer name, URLs, IDs, etc.)
   • Default labels
   • Formatted activities with titles, descriptions, actions, assumptions, and deliverables

2. Copy the complete TOML output from Claude's response

3. Follow the steps within the CPR_GitOps to create the new Collaboration Project

Example Request

I've uploaded our Statement of Work for Acme Corporation. Please convert this SOW into 
a TOML file for a GitLab Collaboration Project. The customer name is "Acme Corporation", 
the Kantata workspace URL is "https://gitlab.mavenlink.com/workspaces/12345678", 
the epic ID is 5678, and the project manager username is "jsmith".

Expected Output Structure

The generated TOML file will follow this structure:

customer_name = "Customer Name"
kantata_url = "https://gitlab.mavenlink.com/workspaces/XXXXXXXX"
epic_id = XXXX
project_manager = "gitlab_username"
project_members = []

labels = [
    "PSD Workflow::Not Started"
]

[[activities]]
title = "Activity 1: Activity Title"
description = """
Activity description.

**Actions**
- Action item 1
- Action item 2
- Action item 3

**Assumptions**
- Assumption 1
- Assumption 2
- Assumption 3

**Deliverables**
- Deliverable 1
- Deliverable 2
- Deliverable 3
"""

# Additional activities will follow the same format

Tips for Optimal Results

1. Review the generated TOML: Verify that all activities have been correctly extracted and formatted. Pay special attention to:

   • Activity titles and numbering
   • Complete extraction of all actions, assumptions, and deliverables
   • Proper Markdown formatting in descriptions

2. Make minor adjustments if needed: You may need to make small formatting adjustments to the TOML file if your SOW has unusual formatting or structure.

3. Special formatting requirements: If your SOW has specific formatting requirements that weren't captured correctly, you can request adjustments in a follow-up message to Claude.

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)

CP assistance/help

Send a note within the #cx-engineering slack channel for assitance

Creating a Project Canvas for Slack Using Claude

Overview

This guide will help you use Claude to create a formatted Project Canvas based on your Statement of Work (SOW) and project information. The resulting content can be pasted into a Slack Canvas for your project team.

Some may find a project Canvas to be repetetive, and by no means is this an edict to create one for every project. Creating a project Canvas is another way to gather all relevant information in tooling that is used on a daily basis. The time to set it up is worth the time saved when I quickly need to reference project information.

Note - A project Canvas is subject to the same Slack retention policies, so if not updated within a rolling 90 day window, it will be deleted

Step-by-Step Instructions

Step 1: Prepare Your Materials

Before starting with Claude, gather:

• Your customer's Statement of Work (SOW)
• Any additional project information you want to include
• Upload the Project Canvas template to the Claude project knowledgebase

Step 2: Start a Conversation with Claude

1. Open Claude through your preferred method (web browser at claude.ai or application)
2. Start a new conversation

Step 3: Upload Your Statement of Work

1. Click the attachment/upload icon in the Claude interface
2. Select and upload your customer's SOW document
3. Wait for the upload to complete

Step 4: Request Canvas Creation

Ask Claude to create a Canvas using language similar to:

Can you create a Canvas using the Canvas template and information I am going to provide? 
I've uploaded our customer's Statement of Work. 

Please extract the following from the SOW:
- Project scope for the overview section
- Activities and deliverables for the goals section
- Professional Services hours allocation

Format the output with appropriate emoji headers (🎯 for Goals, 👥 for Teams, 🔑 for Resources, etc.) 
and ensure it follows standard markdown formatting that will work in Slack Canvas.

Step 5: Provide Additional Context (If Needed)

If Claude needs more information, provide it:

• Team member details
• Specific milestones or target dates
• Any customizations you want for the Canvas
• All Key Resource urls

For example:

Here are the GitLab team members to include:
- Jane Smith, Program Manager, EST
- John Doe, Technical Architect, PST
- Amy Johnson, PSE, CST

The customer team includes:
- Michael Brown, Project Sponsor, EST
- Sarah Wilson, Technical Lead, EST

Step 6: Review and Refine

1. Review the Canvas content Claude generates
2. Ask for specific changes if needed
3. Continue refining until you're satisfied with the output

Example refinement request:

The Canvas looks good, but could you:
1. Update the hours section to match the SOW more precisely
2. Add more bullet points under Activity 2 based on page 3 of the SOW
3. Format the Team section to include timezone abbreviations

Step 7: Copy the Final Canvas Content

1. Once you're satisfied with the Canvas, select all the content in Claude's response
2. Copy it to your clipboard (Ctrl+C or Cmd+C)

Step 8: Create a Slack Canvas

1. Go to your project's Slack channel
2. Create a new Canvas:
   • Click the + icon next to the message field
   • Select "Canvas" from the options (or use the /canvas command)
   • A new Canvas editor will open

Step 9: Paste and Format in Slack

1. Paste the copied content into the Slack Canvas (Ctrl+V or Cmd+V)
2. Give your Canvas a title (e.g., "[Customer Name] Project Canvas")
3. Make any final formatting adjustments if needed
4. Click "Create" or "Save" to publish the Canvas

Step 10: Share and Update

1. Share the Canvas with your team by pointing them to it in the Slack channel
2. Pin the Canvas for easy access if desired
3. Update the Canvas as the project progresses

Example Prompt for Claude

Here's a complete example of how to request a Canvas from Claude:

Can you create a Canvas using the Canvas template and information I am going to provide?

I've uploaded our customer's Statement of Work for Acme Corporation. Please extract:
- Project scope for the overview section
- All activities and deliverables for the goals section
- Professional Services hours allocation (found on page 7)

Please include these team members:
- GitLab Team:
  - Cale Dancho, Sr. Program Manager, MST
  - Chris Childers, Technical Architect, EST
  - Mark Foster, Engagement Manager, CST

- Acme Corporation Team:
  - John Smith, Project Sponsor, PST
  - Jane Doe, Technical Lead, PST
  - Bob Johnson, DevOps Engineer, CST

Format the output with appropriate emoji headers (🎯 for Goals, 👥 for Teams, 🔑 for Resources, etc.)
and ensure it follows standard markdown formatting that will work in Slack Canvas.

Include sections for:
- Project Overview
- Goals (with activities from SOW)
- Team Members
- Key Resources
- Hours
- Target Dates
- Working Agreements

Project Planning Phase

The Planning Phase confirms and validates how the project will be executed, monitored, controlled, and closed. While it begins once you're engaged with your Project, it is generally validated within the first 2 weeks and through the initial Discovery Sessions. Planning is when we re-iterate the impact of known risks to the Project scope and/or timeline as well as ensure our communication plans are effective.

1. Develop or Validate Project Management Plan

While we at GitLab have a preference to perform all planning within GitLab, we must adjust to customers needs. Delivery of a Plan can come in the form of a fleshed out timeline using GitLab Epics and Issues, it can be a Work Breakdown Structure based backlog, or it can be housed within a customer project management tool.

• Review and incorporate impact of potential risks
• Update comprehensive project plan according to new findings
• Recommunicate scope, schedule, and cost baselines

inputs:

• Initial Resource Planning

2. Validate & Agree on Scope Management

• Communicate any changes to scope control & change management procedures
• Confirm scope statement with acceptance criteria
• Iterate WBS with work packages

3. Confirm Schedule Alignment

• Reference Date Management Guidance for Kantata
• Validate required activities (Definition of Done)
• Establish activity relationships & owners
• Iterate on schedule as critical paths evolve
• Review Project Launch Plan strategy (timing, risks, etc.)
• Update Milestone dates as needed

4. Iterate the Resource Plan & Management

• Update roles and responsibilities as you learn more about the project
• Iterate & Communicate RACI matrix
• Determine if there are any new resource requirements

5. Evolve the Communications Management as Needed

A customer communication plan is to be developed and shared along with the Project Charter. The linked Communication Plan Template provides a starting point to create a communication plan that works for your stakeholders.

• Update stakeholder communication needs as changes arise
• Update communication matrix (ReadMe)
• Confirm stakeholder management approach is visible
• Ensure Communicate plan & schedule is updated and always visible

6. Risk Management

Mitigating Risk via RAID Board

• The RAID, Risks, Actions, Issues, and Decisions dashboard is our way to ensure a single source of truth for project risk & resolution
• It is where our internal project stakeholders and leadership can reference the latest project information when the project is trending or sitting in a Y/R health status
• The RAID is automatically created when the PM creates the CP template. First step is to rename template “RAID - Customer - SOW/PO#
• While the RAID is created, managed, and reported by the PM, the internal & Customer team is encouraged to update the RAID as we work through Project challenges and mitigations.
• The Risk Management Process can be found here.

During Project Delivery

The following framework outlines key activities for successful project delivery. Not all projects will require every element listed here; the scope, size, and nature of each project will determine which activities are essential. Project managers should use this as a flexible guideline rather than a rigid checklist, adapting the approach to meet specific project needs while maintaining best practices for delivery excellence.

Be sure to refer to the following to ensure understanding thoughout the Delivery lifecycle:

• MVP PM activities and PM Time Tracking for MVP PM delivery & PM time tracking by Project size
• PS Reporting schedule to understand when to complete the following items
• Resources and templates to make our lives easier

1. Manage Project Financials & Reporting

   • Track actual vs. budgeted hours weekly
   • Forecast remaining costs and potential overruns
   • Prepare financial status/burndown reports for stakeholders
   • Produce weekly status reports for stakeholders
   • Update executive dashboards with key metrics
   • Document and distribute meeting minutes
   • Create ad-hoc reports as requested by stakeholders

   Resources:

   • Burndown reporting templates
   • Kantata Forecasting and Resource Management
   • Weekly Status reporting
   • Project Charter

2. Oversee Backlog Management & Team Reviews

   • Facilitate backlog refinement sessions
   • Ensure proper prioritization of work items
   • Maintain alignment between backlog and project objectives
   • Track backlog health metrics (size, aging, clarity)
   • Facilitate sprint/iteration reviews

   Resources:

   • Professional Services Delivery Methodology

3. Conduct/Document Retrospectives

   • Lead team retrospectives to identify improvements
   • Document lessons learned throughout the project
   • Implement process improvements based on feedback

   Resources:

   • Internal Retro
   • Customer Retro

4. Manage Customer Communication

   • Maintain regular cadence of customer updates
   • Document and track customer feedback
   • Manage customer expectations proactively
   • Prepare and deliver customer presentations

5. Facilitate Team Ceremonies

   • Lead daily standups to maintain alignment
   • Conduct effective sprint planning sessions
   • Facilitate issue refinement to ensure readiness
   • Manage demos and review sessions

   Resources:

   • Professional Services Delivery Methodology

6. Coordinate Resource Updates

   • Monitor resource utilization and performance
   • Adjust resource allocations as needed
   • Onboard new team members effectively
   • Manage resource conflicts with other projects
   • Review and approve/deny team time entries
   • Reconcile time records with project activities & predicted forecast
   • Address time tracking discrepancies with team member before approving

   Resources:

   • Kantata Forecasting and Resource Management

7. Execute Risk Mitigation

   • Monitor identified risks regularly
   • Implement mitigation strategies as needed
   • Identify and document new risks as they emerge
   • Escalate high-impact risks appropriately

   Resources:

   • Risk Management Process

8. Handle Scope Management

   • Document and evaluate all change requests
   • Assess impact of proposed changes on schedule and budget
   • Maintain the change control log
   • Secure appropriate approvals for scope changes
   • Change Orders
   • WaR (Work at Risk) - beginning a project prior to SOW signature
   • WE (Work Exceptions) - accounting for project overages

   Resources:

   • CO/WaR/WE

9. Monitor Team Velocity

   • Track and report team velocity metrics
   • Identify trends in productivity and quality
   • Address impediments affecting velocity
   • Forecast completion dates based on actual velocity

Resources:

• Professional Services Delivery Methodology

13. Nurture Customer Relationship

    • Build trust through transparent communication
    • Address customer concerns promptly
    • Identify opportunities to exceed expectations
    • Manage difficult conversations professionally

14. Coordinate & Report Across Departments

    • Facilitate cross-functional collaboration (PS Ops, CS, Sales, Support, etc)
    • Ensure alignment on shared objectives
    • Communicate project needs to supporting departments

Resources:

• Leveraging Slack(Canvas) to surface statuses across departments

15. Initiate Launch Planning
    • Begin early launch planning discussions
    • Identify launch prerequisites and dependencies
    • Document initial launch strategy
    • Engage stakeholders in launch readiness assessment

[TOC]

PM Escalation Tracking Process

ESCALATION TRIGGERS

When a program reaches Red status, the type and severity of escalation should be clearly identified to ensure appropriate response and documentation.

🚨 SEV 1 - CUSTOMER ESCALATION PATH

This enhanced tracking process must be initiated when ANY of the following occurs:

• Customer formally escalates to account manager, CSM, and/or PS leadership regarding performance of the PS engagement
• Customer expresses dissatisfaction with project progress, quality, or communication
• Customer threatens contract cancellation or withholding payment
• Customer requests executive-level involvement
• Leadership escalates a Sev 2 to Sev 1 for heightened visibility

Definition: Issues that directly impact customers or have the potential to affect customer experience, revenue, or satisfaction.

PHASE 1: ESCALATION INITIATION (Complete within 24 hours)

Step 1: Create Escalation Framework

• Create dedicated escalation tracking issue on the customer's collaboration project
• Assign escalation severity level (Critical, High, Medium) and follow the reporting expectations covered in the TRACKING REQUIREMENTS BY ESCALATION TYPE section below.
• Document escalation timeline and key milestones
• Identify DRI (Directly Responsible Individual) for escalation communication
• If escalation is outside PS scope: Coordinate with account CSM or work with AE to determine CSM

Step 2: Establish Communication Channels

- Begin escalation thread in #ps-project-leadership and pin to channel

• Ensure progress is also tracked within the internal project & Customer slack channels
• Include AE, CSM, Direct Manager and Director PS in communication loop
• Attach escalation tracking document/issue to channel
• Provide links to all relevant tracking documents and dashboards

Step 3: Set Up Monitoring and Reporting

• Update portfolio status in Kantata with "path to green"
• Schedule daily internal escalation check-ins with stakeholders
• Set escalation review for next Y/R Portfolio call (or arrange immediate sync if critical)
• Create RACI matrix for escalation resolution activities

PHASE 2: ACTIVE ESCALATION MANAGEMENT (Daily activities)

Step 4: Implement Daily Tracking (Every Day)

• Morning: Review overnight developments and update status
• Midday: Conduct internal stakeholder check-in
• Evening: Update escalation thread in #ps-project-leadership, internal, and Customer Slack channels
• Document progress in centralized escalation tracking document

Step 5: Manage Requirements and Changes (As needed)

• Record detailed escalation requirements in centralized location
• Create requirement validation checklist with sign-off tracking
• Log any requirement changes with date stamps and approvers
• Create formal change order and execute the documented approval process
• Update project artifacts with version control and change history

Step 6: Monitor Resources and Impact (Daily)

• Track resource assignments and availability in Kantata
• Monitor individual workload impacts and notify resourcing channel and and PMs if other projects will be impacted
• Assess budget and timeline impacts from changes
• Update financial forecasts and communicate impacts to PMO Manager
• Maintain risk register (RAID) with escalation-related entries

PHASE 3: RESOLUTION TRACKING (Until closure)

Step 7: Track Resolution Progress

• Create detailed resolution action plan with measurable milestones
• Define success criteria with completion status tracking
• Monitor progress against milestones (percentage complete)
  • For example, if it's resource availibility, then the milestone would be "new team member added to project," with composite tasks of:
    • Meet with resourcing team and engineering leader, due tomorrow
    • Identify and assign new team member, due tomorrow
    • Complete internal meeting to detail project scope and escalation scenario, due tomorrow +1
    • Introduce new team member to customer team, due tomorrow +1
• Log blockers and dependencies preventing progress
• Document and maintain alternative approaches to resolving the escalated issue, including pros, cons, and additional risks that may be introduced with alternate approaches

Step 8: Escalation Closure and Lessons Learned

• Document final resolution and obtain customer sign-off
• Complete lessons learned capture in internal retrospective issue
• Implement and document process improvements
• Share learnings with PMO team
• Update all project artifacts with final changes
• Complete financial impact reconciliation
• Remove pin from #ps-project-leadership channel

⚠️ SEV 2 - INTERNAL PROJECT HEALTH PATH

This monitoring process is initiated when ANY of the following occurs:

Project Performance Issues

• Timeline: Project is >2 weeks behind critical milestones without approved change request
• Budget: Project is >10% over budget or trending toward significant overrun
• Scope: Major scope changes that impact timeline/budget by >15%
• Quality: Deliverables fail acceptance criteria multiple times or have critical defects

Resource/Operational Issues

• Key team member unavailability threatens project delivery
• Technical blockers that cannot be resolved within 5 business days
• Vendor/third-party dependencies causing critical delays
• Resource conflicts preventing adequate staffing

Communication/Relationship Issues

• Breakdown in stakeholder communication or decision-making
• Conflicting requirements from multiple customer stakeholders
• Legal, compliance, or security issues arise
• Customer requests escalation due to perceived lack of responsiveness

SEV 2 WORKFLOW

Step 1: Update Project Health in Kantata

• Update portfolio status to Red with detailed "path to green" explanation
• Document specific issues, risks, and proposed mitigation strategies
• Include timeline estimates for resolution
• Identify resource needs or blockers

Step 2: Attend Y/R/Blocked Portfolio Review Call

• Present project's current state to PS leadership
• Discuss mitigation strategies and resource requirements
• Receive guidance on course correction approaches
• Leadership Decision Point:
  • Escalate to Sev 1: If customer impact is imminent or significant
  • Remain in Monitoring: Continue Sev 2 process with leadership awareness

Step 3A: If Remaining in Sev 2 Monitoring

• Continue weekly updates in Kantata with progress toward green
• Implement agreed-upon course correction strategies
• Attend subsequent Y/R calls until status improves to Green/Yellow
• Escalate to Sev 1 if customer impact occurs or situation deteriorates

Step 3B: If Escalated to Sev 1

• Follow complete Sev 1 Customer Escalation Path process above
• Maintain all Sev 1 documentation and communication requirements

TRACKING REQUIREMENTS BY ESCALATION TYPE

SEV 1 - DAILY REQUIREMENTS

• Escalation status update in Slack
• Progress assessment against milestones
• Blocker identification and resolution tracking
• Customer communication (daily or every other day)

SEV 1 - WEEKLY REQUIREMENTS

• Stakeholder communication summary
• Budget and timeline impact assessment
• Resource allocation review in Kantata
• Risk register (RAID) updates
• PMO Manager briefing with updated forecasts

SEV 2 - WEEKLY REQUIREMENTS

• Kantata status update with path to green
• Y/R Portfolio call attendance and reporting
• Internal mitigation strategy implementation
• Resource needs assessment

Project Launch

Ensure a successful transition to production through these structured launch activities:

1. Develop Customer Success Plan

   • Create detailed customer roadmap for adoption
   • Document success metrics and measurement approach
   • Establish ongoing support model
   • Define knowledge transfer requirements

2. Create Remediation Plan

   • Identify known issues and limitations
   • Develop remediation timeline for outstanding items
   • Document workarounds for unresolved issues
   • Secure customer agreement on remediation approach

3. Define Hypercare Expectations

   • Document hypercare duration and coverage
   • Establish hypercare team composition
   • Create escalation paths during hypercare
   • Set response time expectations

4. Prepare Testing Documentation

   • Develop comprehensive test plans
   • Create test scripts and scenarios
   • Document test data requirements
   • Establish defect tracking and resolution process

5. Create Go-Live Documentation

   • Develop detailed go-live checklist
   • Document go/no-go criteria
   • Create deployment sequence
   • Establish communication plan for go-live

6. Develop Rollback Plan

   • Document detailed rollback procedures
   • Establish rollback triggers and decision points
   • Assign rollback responsibilities
   • Test rollback procedures prior to launch

7. Secure Final Customer Acceptance

   • Conduct formal acceptance review meetings
   • Document acceptance of deliverables
   • Address any conditional acceptance items
   • Obtain signed acceptance documentation

8. Manage Technical Launch via RACI

   • Define detailed RACI for launch activities
   • Conduct pre-launch readiness reviews
   • Coordinate launch day activities
   • Facilitate post-launch verification

9. Conduct Launch Retrospective

   • Facilitate launch retrospective session
   • Document what went well and improvement areas
   • Identify lessons for future launches
   • Share retrospective findings with leadership

Project Close

Formally conclude the project with these closing activities:

1. Conduct Project Retrospective with the Customer

   • Begin summary of project to prepare for Project Close and Retro meetings
   • Document project successes and challenges
   • Identify process improvement opportunities
   • Facilitate Customer Retrospective sessions
   • Distribute CSAT survey to stakeholders

2. Conduct Executive Close-out

   • Update/send executive summary of project and obtain signoff of completion by the Customer
   • Document final results within internal retro issue
   • Be sure to include:
     • Strategic outcomes achieved
     • Opportunities for future business

3. Conduct Internal Retrospective Meeting

   • Review summary of the project and add details to the Internal retro issue
   • Conduct Internal Retro meeting
   • Update delivery kits with new templates
   • Transfer Organize all project documentation within the Customer Folder

4. Close Out Project Systems

   • Within Kantata:
     • For Fixed Fee Proejcts and all respective Milestone tasks, complete the following:
       • Sign-Off Sent: Update this custom field when the acceptance request email is sent.
       • Sign-Off Received: Update this custom field when customer acceptance is received or passive acceptance is achieved. Attach the acceptance email (in PDF form) to the milestone.
     • Passive Acceptance Utilized: If passive acceptance is used, update this field accordingly
     • For both FF & T&M scenarios, attach the acceptance email or milestone document to the milestone
     • Update actual start/kickoff/end dates
     • Once the internal retro documentation and meeting is complete, set the Project to "Completed"

   Note: Only top-level milestone fields should be updated. Sub-activities within the milestone remain unchanged.

   • Slack
     • Archive Customer and internal Slack channels

5. Notes on Revenue Sign Off

   Revenue Release T&M Projects

   • Revenue is recognized and released at the end of each month.
   • Project hours must be logged weekly via the time sheet function in Kantata. Professional Services Engineers (PSEs) or Project Managers (PMs) log time against the project, and the Project Lead or PM approves these entries weekly.
   • At the end of each month, the Project Coordinator (PC) compiles all approved timesheets and submits the consolidated report to Finance for review and revenue release.

   Revenue Release FP Projects

   • Revenue is recognized upon receipt of customer milestone acceptance or upon the completion of passive acceptance (according to the SOW terms).
   • The PM updates set the Milestone in Kantata to "complete" when the Customer signs off on the closure document
   • If passive acceptance is applicable per the SOW, the Customer has 5 business days to approve or deny before we can set the milestone to "complete". Day 1 is counted as the day the notification is sent.

Using Claude to Generate Project Closure Documents

This guide will walk you through using Claude to create comprehensive project closure documents by leveraging your project status history and the Project Closure Template.

Purpose

• Create a formal project closure artifact for documentation
• Refresh team members on the project's timeline and accomplishments
• Synthesize project information from multiple status reports into a cohesive summary
• Save time by automating the compilation of project history

Prerequisites

• Project Closure Template (uploaded to Claude)
• Core Project Documentation
  • Status Reports: Collect all periodic status reports (weekly/bi-weekly updates)
  • Meeting Recordings: Compile links to all session recordings with passcodes
  • Session Notes: Obtain links to detailed documentation (like the Google Doc with session notes)
  • Risk Registers: Include any formal risk documentation with dates, mitigation plans, and outcomes
  • Final Project Burn Down Report: Include the actual hours, estimated hours, and total hours.

Step-by-Step Process

Step 1: Gather Project Status Reports from GitLab

1. Log in to GitLab and navigate to your project

2. Use the search feature to find all status reports:

   • Click on "Issues" in the left sidebar
   • In the search bar, enter: label:status (or your project's specific status label)
   • Alternatively, search for: "Status Report" in the title
   • Ensure the search scope is set to your project or group

3. Export the search results to CSV:

   • From the issues list view, look for the "Export as CSV" option (usually an icon or in a dropdown menu)
   • Click to download the CSV file

4. Review the CSV file to ensure it contains:

   • Status report titles with dates
   • Status content or descriptions

Step 2: Upload Materials to Claude

1. Start a new conversation in Claude or use your existing project conversation

2. Upload the Project Closure Template:

   • Click the upload/paperclip icon
   • Select your Project Closure Template file
   • Add a brief description: "This is our Project Closure Template that we use for formally closing projects"

3. Upload the CSV file containing status reports:

   • Click the upload/paperclip icon again
   • Select the CSV file with your exported status reports
   • Add context: "This CSV contains all status reports from our project, exported from GitLab issues"

Step 3: Ask Claude to Generate the Closure Document

Use this prompt template to ask Claude to create your project closure document:

Using the Project Closure Template I've uploaded and the status reports in the CSV file, please create a comprehensive project closure document for [Project Name]. 

Please include:

1. A concise executive summary of the project (1-2 paragraphs)
2. Project background and initial objectives
3. A detailed timeline of key milestones and events, synthesized from the status reports
4. Major accomplishments and deliverables completed
5. Challenges encountered and how they were overcome
6. Budget summary (final vs. planned if available in the status reports)
7. Lessons learned and best practices identified
8. Any outstanding items or follow-up actions

Format the document according to our Project Closure Template structure while incorporating the historical information from the status reports. 

The primary audience for this document is [internal team/customer/stakeholders] and it will be used for [formal sign-off/knowledge transfer/archive purposes].

Step 4: Review and Refine the Output

1. Review the generated document for:

   • Accuracy of timeline and events
   • Completeness of major milestones
   • Proper formatting according to the template
   • Any gaps or inconsistencies in the narrative

2. If needed, ask Claude to make specific revisions:

   Please make the following adjustments to the project closure document:
   1. Expand the section on [specific area]
   2. Add more detail about [particular milestone or challenge]
   3. Reformat the timeline section to be more [chronological/concise/detailed]
   4. Include information about [any missing element]
   

3. You can also ask Claude to focus on specific aspects:

   Based on the status reports, please provide a more detailed analysis of the challenges we faced during [specific time period] and how they impacted our timeline and budget.
   

Step 5: Finalize and Format the Document

1. Once you're satisfied with the content, ask Claude to format it for your intended use:

   Please format this document for [presentation to stakeholders/internal documentation/customer handoff]. Make sure all sections are properly structured and the document follows our organizational styling.
   

2. For formal documents, consider asking Claude to add:

   • Table of contents
   • Executive summary at the beginning
   • Signature/approval sections if needed
   • Appropriate appendices for detailed information

3. Save the final document from Claude:

   • Copy the formatted content
   • Paste into your preferred document editor
   • Save with an appropriate filename: "[Project Name] - Closure Document - [Date]"

Tips for Getting the Best Results

Improving Status Report Analysis

• If status reports are lengthy, consider asking Claude to focus on specific aspects first:

  First, please extract just the major milestones and their dates from the status reports to create a timeline.
  

• For complex projects, break down the analysis:

  Before creating the full document, please identify the key phases of this project based on the status reports, and summarize each phase separately.
  

Handling Incomplete Information

If your status reports lack certain information needed for the closure document:

• Ask Claude to identify gaps:

  After reviewing the status reports, what information appears to be missing that would be important for a comprehensive closure document?
  

• Provide additional context where needed:

  The status reports don't contain detailed budget information. Please use this summary instead: [provide budget summary]
  

Creating Different Versions for Different Audiences

You can ask Claude to create multiple versions of the closure document:

• Executive summary for leadership:

  Using the full closure document you created, please generate a 1-page executive summary highlighting only the most critical information for senior leadership.
  

• Technical summary for team members:

  Please create a technical version of this closure document that includes more details about the implementation challenges and solutions for our development team.
  

• Customer-facing version:

  Please adapt this closure document to be appropriate for customer delivery, focusing on value delivered and removing internal details.
  

Example: Project Closure for a GitLab Migration Project

Here's an example prompt for a GitLab migration project:

Using the Project Closure Template I've uploaded and the status reports in the CSV file, please create a comprehensive project closure document for "Acme Corp GitLab Migration Project."

Please include:

1. A concise executive summary of the migration project
2. Initial project scope and goals (from early status reports)
3. A detailed timeline showing the progression through different migration waves
4. Technical challenges encountered during the migration and how they were resolved
5. Statistics on number of repositories migrated, users onboarded, etc.
6. Budget summary showing planned vs actual hours used
7. Lessons learned that could benefit future migration projects
8. Any post-migration support arrangements or outstanding items

Format the document according to our Project Closure Template while incorporating the detailed history from our weekly status reports.

The primary audience is both our internal delivery team and the customer's IT leadership.

By following this process, you'll be able to quickly generate comprehensive project closure documents that accurately reflect the project history while saving significant time compared to manual compilation.

CSAT Survey

Resources

Overview

This section contains a comprehensive collection of templates, guides, and tools designed to support project delivery throughout the entire project lifecycle. These resources have been developed and refined through practical application across multiple professional services engagements.

Each resource is designed to be adaptable to different project types, client environments, and delivery methodologies. While organized by project phase for easy reference, many of these resources can be utilized across multiple phases as needed.

Pre-Sales

Project Start - First 2 Weeks

Planning

Project Delivery

Escalations

Project Launch

Closure

Cross-Phase Resources

Additional Resources

For specialized tools and integrations:

• Using AI Resources - Artificial intelligence tools and templates for project management
• Navigation Salesforce Invoicing - Guide for managing invoicing through Salesforce integration

[TOC]

GitLab Professional Services Products - A Simple Guide

Introduction

GitLab Professional Services help organizations maximize the value of their GitLab investment through expert guidance, targeted solutions, and enhanced user education. As part of GitLab's Customer Success department, these services accelerate adoption and support customers in achieving their business goals more efficiently. This page presents a high level overview of each of our services offerings, for education purposes.

Core Service Categories

1. Implementation Services

What it is: Expert assistance to set up and configure GitLab for your organization's specific needs.

Self-Managed Implementation

What it is: This is when GitLab is installed and hosted on your own infrastructure (servers) that your company manages, rather than using GitLab's cloud service.

In simple terms: Think of this like buying software and installing it on your own computer, rather than using a web-based version. Your company takes full responsibility for maintaining the servers, handling backups, and performing upgrades.

Key benefits:

• Complete control over your GitLab environment
• Ability to customize settings extensively
• Data stays within your own infrastructure (good for strict compliance requirements)
• No dependence on GitLab's cloud availability

Best for: Organizations with regulatory requirements to keep data on-premises, companies with strong IT infrastructure teams, or businesses that need extensive customization.

Single-Node Implementation

What it is: A specific type of self-managed GitLab deployment where all GitLab components run on a single server (or "node").

In simple terms: Imagine having all parts of GitLab running on one computer rather than spreading it across multiple machines. It's the simplest way to deploy GitLab in a self-managed environment.

Key benefits:

• Easier to set up compared to multi-node deployments
• Lower infrastructure costs (just one server)
• Simpler maintenance and troubleshooting
• Good for smaller teams or test environments

Best for: Small to medium-sized teams with moderate workloads, organizations just starting with GitLab, or development environments where high availability isn't critical.

GitLab.com Implementation

What it is: Using GitLab's cloud-hosted service (GitLab.com) rather than installing GitLab on your own infrastructure.

In simple terms: This is like using Gmail instead of setting up your own email server. GitLab handles all the infrastructure, maintenance, backups, and upgrades while you just use the service through your web browser.

Key benefits:

• No infrastructure to maintain
• Automatic updates to the latest GitLab version
• No hardware costs or setup required
• Quick to get started (immediate access)
• GitLab handles all backup and availability concerns

Best for: Teams that want to focus on their work rather than maintaining infrastructure, companies without dedicated server operations staff, or organizations that prefer subscription-based pricing models.

Implementation services for GitLab.com typically involve:

• Setting up organizational structure
• Configuring user permissions and access controls
• Migrating existing projects from other systems
• Integrating with other tools in your workflow
• Training on GitLab.com features and best practices

2. Migration Services

What it is: Expert assistance to move your existing code, workflows, and data to GitLab from other systems.

Below, we present some of the ways in which data can be moved from SCM systems to GitLab.

Direct Transfer

What it is: A newer migration method specifically for GitLab-to-GitLab transfers that moves data directly between instances without requiring file exports.

In simple terms: Think of this like directly transferring files between two computers over a network connection, rather than having to download files from one computer and then upload them to another.

Key benefits:

• No admin token required
• Streamlined process with fewer steps
• Reduces potential for file corruption during transfer
• More efficient for larger projects

Best for: Organizations moving between GitLab instances that want a simpler migration process with less manual intervention.

File-based Export/Import

What it is: The traditional method for migrating projects or groups by exporting data to files and then importing those files into the target GitLab instance.

In simple terms: Similar to downloading all your data as files from one system, then uploading those files to another system. Like backing up your photos to an external drive and then restoring them on a new computer.

Key benefits:

• Works across different versions of GitLab
• Well-established with predictable results
• Still the primary method used by most migration tools
• Provides a backup copy during the migration process

Best for: Cross-version migrations, organizations that want a backup copy of data during migration, or when Direct Transfer isn't available.

GitLab Importers - Internal

What it is: Built-in tools within GitLab designed specifically to import from particular external systems (like GitHub, Bitbucket).

In simple terms: These are like specialized adapters that know exactly how to read data from other systems and properly convert it to GitLab's format.

Key benefits:

• Purpose-built for specific source systems
• Handles the peculiarities of each source system
• Built directly into GitLab's interface
• Often simpler than manual export/import processes

Best for: Organizations migrating from specific supported platforms who want a straightforward migration path with minimal tooling.

Congregate

What it is: A GitLab Professional Services automation tool that wraps around various import methods to enhance their capabilities and address limitations.

In simple terms: Think of this as a Swiss Army knife for migrations. It's a tool that can use multiple migration methods and adds extra features to make migrations smoother.

Key benefits:

• Works with multiple migration methods (File-based, Direct Transfer, GitHub importers, etc.)
• Compensates for limitations in the individual methods
• Provides additional features beyond standard importers
• Offers a consistent interface regardless of source system

Best for: Complex migrations, especially those involving multiple source systems or requiring features not available in standard importers.

GEO

What it is: A GitLab feature that continuously replicates data between GitLab instances, primarily designed for disaster recovery and distributed teams.

In simple terms: Rather than a one-time migration, GEO creates an ongoing mirror of your GitLab data. It's like having a backup server that's always kept in sync with your main server.

Key benefits:

• Continuous replication rather than one-time migration
• Can migrate data while users continue working
• Provides a disaster recovery solution after migration
• Useful for distributed teams after migration

Key limitations:

• Only works for GitLab-to-GitLab under specific conditions
• Not available for GitLab.com (as source or destination)
• Can be complex to set up

Best for: Self-managed GitLab instances that need both migration and ongoing replication, especially for disaster recovery purposes.

Omnibus Backup/Restore

What it is: A complete backup and restore of an entire GitLab instance, including all data, configurations, and settings.

In simple terms: This is like taking a complete snapshot of your entire GitLab system—not just projects and data, but all settings and configurations too. Then restoring that complete snapshot to a new system.

Key benefits:

• Most comprehensive migration method
• Includes all instance configurations
• Preserves all relationships between data
• Maintains system settings and customizations

Key limitations:

• Not available for GitLab.com
• Requires compatible GitLab versions
• Currently won't backup remote object storage data

Best for: Complete system migrations between self-managed instances where you want to preserve all aspects of the original system.

Chart Backup/Restore (K8s/Cloud-native Hybrid)

What it is: A backup and restore method specifically designed for GitLab installations running on Kubernetes.

In simple terms: Similar to Omnibus Backup/Restore, but specifically designed for modern cloud environments. It's like taking a snapshot of a cloud-based system that can be restored to another cloud environment.

Key benefits:

• Designed for modern cloud-native architectures
• Works with Kubernetes environments
• Provides complete system migration
• Suitable for containerized GitLab deployments

Key limitations:

• Not for GitLab.com (either side)
• Can have constraints based on Kubernetes limitations
• Requires Kubernetes expertise to implement

Best for: Organizations running GitLab on Kubernetes or cloud-native infrastructure who need to migrate their entire instance to a new environment.

3. Consulting Services

What it is: Strategic advice and guidance to help you optimize your DevOps practices using GitLab.

Examples:

• DevOps Assessment: Evaluate current practices and recommend improvements
• CI/CD Optimization: Design efficient pipelines for faster, more reliable builds and deployments
• Security Integration: Implement DevSecOps practices with GitLab's security features

Real-world scenario: An e-commerce company was experiencing slow release cycles. GitLab consultants analyzed their development workflow, identified bottlenecks, and helped them implement automated testing and deployment pipelines that reduced release time from weeks to days.

4. Education Services

What it is: Training programs to help your team master GitLab capabilities.

Examples:

• GitLab Fundamentals: Basic training on repositories, merge requests, and issues
• CI/CD Mastery: Advanced pipeline configuration, testing, and deployment strategies
• Administrator Training: System maintenance, security, and performance optimization

Real-world scenario: A software development company transitioning from multiple tools to GitLab needed to quickly upskill 200 developers. GitLab provided customized training sessions covering basic Git workflows, CI/CD pipelines, and security scanning, resulting in rapid adoption and productivity gains.

5. Managed Services

What it is: Ongoing operational support and maintenance of your GitLab environment.

Examples:

• Standard Support: Day-to-day management and routine maintenance
• Premium Support: 24/7 monitoring, incident response, and optimization
• Full Managed Service: Complete GitLab infrastructure management in the cloud

Real-world scenario: A manufacturing company with limited DevOps expertise needed to focus on application development rather than platform maintenance. GitLab partners provided fully managed GitLab services, handling upgrades, security patches, backup verification, and performance tuning.

GitLab Professional Services Training Videos

GitLab Tech Stack: Simplified Deep Dive

Ruby on Rails: The Core

What it is: The main framework GitLab is built on.

How it works simply:

• Handles web requests when you click around in GitLab
• Manages the database connections
• Renders the web pages you see
• Processes form submissions

Why it matters: Rails lets GitLab developers build features quickly. It's like LEGO blocks for web apps - pieces fit together in standard ways, making development faster.

Real-world impact: When you create a new issue or merge request, Rails handles the entire process from saving your data to showing you the updated page.

Go (Golang): The Performance Booster

What it is: A faster programming language used for specific parts of GitLab.

How it works simply:

• Handles Git operations (like clones and merges)
• Runs in separate services outside the main Rails app
• Processes the heavy lifting that would slow down Rails

Why it matters: Some operations would make GitLab slow if done in Ruby. Go is like adding a turbocharger to specific parts of the system.

Real-world impact: When you push code or clone a large repository, Go-powered services handle it, making these operations much faster than if they were done in Ruby.

PostgreSQL: The Data Storage

What it is: The database where all GitLab data is permanently stored.

How it works simply:

• Stores all your projects, issues, user accounts, etc.
• Organizes data in tables with relationships
• Handles complex queries efficiently
• Ensures your data stays consistent

Why it matters: Without PostgreSQL, GitLab would lose all your data when servers restart. It's like the filing cabinet that keeps everything organized.

Real-world impact: Every time you search for issues or filter merge requests, PostgreSQL is finding that information for you.

Redis: The Speed Layer

What it is: A super-fast temporary data store.

How it works simply:

• Stores data in memory (much faster than disk)
• Keeps track of background jobs
• Caches frequently accessed information
• Handles real-time features

Why it matters: Redis makes GitLab faster by storing frequently-used data in a format that can be accessed quickly. It's like having important papers on your desk instead of filing them away.

Real-world impact: When you see real-time updates in the UI or when background jobs process (like CI pipelines), Redis is coordinating this behind the scenes.

Sidekiq: The Background Worker

What it is: The system that processes work outside of web requests.

How it works simply:

• Takes jobs that would make the website slow
• Processes them in the background
• Handles retries if something fails
• Manages job priorities

Why it matters: Without Sidekiq, GitLab would feel sluggish because you'd have to wait for everything to finish processing before getting a response. It's like having assistants who handle paperwork while you keep helping customers.

Real-world impact: When you push code and a CI pipeline starts, Sidekiq is managing those jobs. When you get an email notification, Sidekiq sent it.

Vue.js: The Interactive UI

What it is: The JavaScript framework that makes GitLab's interface interactive.

How it works simply:

• Creates responsive UI components
• Updates the page without full reloads
• Manages user interface state
• Handles user interactions

Why it matters: Vue makes GitLab feel like a modern app instead of a series of page loads. It's like the difference between digital controls and manual knobs.

Real-world impact: The merge request interface uses Vue to update in real-time, showing comments and changes without refreshing the page.

NGINX: The Front Door

What it is: The web server that first receives all web traffic to GitLab.

How it works simply:

• Receives all incoming web requests
• Routes them to the right internal service
• Serves static files directly
• Handles SSL encryption

Why it matters: NGINX efficiently manages connections so GitLab can handle many users at once. It's like a receptionist directing visitors to the right department.

Real-world impact: NGINX is why GitLab can serve thousands of users without crashing under the load of connections.

GitLab Workhorse: The Smart Router

What it is: A component that handles certain types of requests more efficiently.

How it works simply:

• Intercepts large file uploads/downloads
• Routes requests to the right backend service
• Bypasses the Rails app when possible
• Handles long-running connections

Why it matters: Workhorse prevents the main application from getting bogged down with certain types of requests. It's like having a shipping department handle packages so the sales team doesn't have to.

Real-world impact: When you upload large files or clone repositories, Workhorse manages these operations efficiently.

Gitaly: The Git Manager

What it is: A specialized service that handles all Git operations.

How it works simply:

• Manages Git repositories on disk
• Processes Git commands (clone, push, pull)
• Optimizes Git operations for performance
• Handles repository access control

Why it matters: Git operations are resource-intensive and would overwhelm the main application. Gitaly is like having a dedicated team just for handling source code.

Real-world impact: Every time you browse code, commit history, or push changes, Gitaly is doing the heavy lifting behind the scenes.

CI/CD Runner: The Pipeline Executor

What it is: The component that runs your continuous integration jobs.

How it works simply:

• Picks up jobs from the queue
• Creates isolated environments for each job
• Runs the commands in your .gitlab-ci.yml file
• Reports results back to GitLab

Why it matters: Runners let GitLab execute code in secure, isolated environments. It's like having testing labs separate from your main facility.

Real-world impact: When your tests run after a commit or your application deploys automatically, Runners are executing those processes.

Each of these components fits together to create a complete system that handles everything from storing your code to testing and deploying your applications. The beauty of GitLab's architecture is how these specialized components work together while each focusing on what they do best.

Simplied Archtecture Diagram

graph TB
    %% External access points
    HTTP((HTTP/HTTPS<br>Web & API Access))
    SSH((SSH<br>Git Access))
    
    %% Front-end components
    NGINX[NGINX Web Server<br>Routes all incoming traffic]
    GitLabWorkhorse[GitLab Workhorse<br>Smart proxy & file handling]
    GitLabShell[GitLab Shell<br>Handles SSH Git operations]
    
    %% Core applications
    Puma["Puma (GitLab Rails)<br>Main application server<br>Ruby on Rails"]
    Sidekiq["Sidekiq<br>Background job processor<br>CI/CD, emails, hooks"]
    
    %% Data storage
    PostgreSQL[(PostgreSQL<br>Main database<br>Users, projects, issues)]
    Redis[(Redis<br>Queue & cache service<br>Temporary data store)]
    Gitaly[Gitaly<br>Git repository service<br>Written in Go]
    
    %% Extensions
    GitLabPages[GitLab Pages<br>Static website hosting]
    Registry[Container Registry<br>Docker image storage]
    
    %% Web Request Path
    HTTP -- "1. TCP 80/443" --> NGINX
    NGINX -- "2." --> GitLabWorkhorse
    GitLabWorkhorse -- "3." --> Puma
    Puma -- "4." --> PostgreSQL
    
    %% Git SSH Path
    SSH -- "1. TCP 22" --> GitLabShell
    GitLabShell -- "2." --> Gitaly
    
    %% Background Job Path
    Puma -- "1. Queue job" --> Redis
    Redis -- "2. Process job" --> Sidekiq
    Sidekiq -- "3. Update results" --> PostgreSQL
    
    %% Other connections
    NGINX -- "TCP 8090" --> GitLabPages
    NGINX --> Registry
    GitLabShell --> GitLabWorkhorse
    GitLabWorkhorse --> Gitaly
    GitLabWorkhorse --> Redis
    Puma --> Redis
    Puma --> Gitaly
    Sidekiq --> Redis
    Sidekiq --> Gitaly
    
    %% Legend
    LegendBox[Legend:<br>Pink = External Access Points<br>Blue = Frontend Components<br>Green = Core Applications<br>Orange = Data Storage<br>Purple = Extension Services]
    
    %% Styling with improved contrast
    classDef external fill:#ff99cc,stroke:#000,stroke-width:3px,color:#000,font-weight:bold
    classDef frontend fill:#99ccff,stroke:#000,stroke-width:2px,color:#000,font-weight:bold
    classDef core fill:#99ff99,stroke:#000,stroke-width:2px,color:#000,font-weight:bold
    classDef storage fill:#ffcc99,stroke:#000,stroke-width:2px,color:#000,font-weight:bold
    classDef extension fill:#cc99ff,stroke:#000,stroke-width:2px,color:#000,font-weight:bold
    classDef legend fill:#f8f8f8,stroke:#000,stroke-width:2px,color:#000,font-weight:bold
    
    %% Apply styling
    class HTTP,SSH external
    class NGINX,GitLabWorkhorse,GitLabShell frontend
    class Puma,Sidekiq core
    class PostgreSQL,Redis,Gitaly storage
    class GitLabPages,Registry extension
    class LegendBox legend
    
    %% Title as a note at the top
    title[GitLab Tech Stack - Component Architecture]
    class title legend

Project Templates

The repository includes the following templates:

[TOC]

Standard Risks

This purpose of this page is to provide a menu of risks that me be relevant to your project. The structure is less important than the content in helping provide insight into risks.

Instructions for Use

• This risk register contains common risks encountered in GitLab Professional Services engagements
• For each project, review all applicable categories and identify relevant risks
• Copy relevant risks to your project risk register and customize as needed

Risk Rating Matrix

The levels provided below and subsequent risk score calculation help to visualize severity of risks.

Impact Levels

• Critical (5): Major project failure, contractual breach, significant financial/reputational damage
• High (4): Serious delay to critical path, major scope compromise, significant cost overrun
• Medium (3): Moderate delay, noticeable impact to deliverables, budget impact
• Low (2): Minor delay, small adjustments to scope, minimal budget impact
• Negligible (1): Barely noticeable impact to timeline, scope, or budget

Probability Levels

• Very Likely (5): 80-100% chance of occurrence
• Likely (4): 60-80% chance of occurrence
• Possible (3): 40-60% chance of occurrence
• Unlikely (2): 20-40% chance of occurrence
• Rare (1): 0-20% chance of occurrence

Risk Score Calculation

• Risk Score = Impact × Probability
• High Risk: 15-25
• Medium Risk: 8-14
• Low Risk: 1-7

1. Product-Specific Risks

1.1 GitLab Migration Projects

1.2 GitLab Geo Implementation

1.3 GitLab Upgrade Projects

1.4 CI/CD Pipeline Implementation

1.5 GitLab Implementation/Onboarding

2. General Project Risks

2.1 Resource and Staffing Risks

2.2 Schedule and Timeline Risks

2.3 Technical and Implementation Risks

2.4 Customer and Stakeholder Risks

2.5 Commercial and Contractual Risks

2.6 Organizational and Environmental Risks

POC Migration Strategy and Expectations

Purpose of the POC Phase

The Proof of Concept (POC) migration phase is a critical discovery period designed to:

• Validate the migration approach in the customer's specific environment
• Identify unique technical challenges before full-scale migration
• Test customized migration scripts with representative data
• Establish baseline metrics for planning larger migration waves

Setting Proper Customer Expectations

When communicating about the POC phase with customers, emphasize these key points:

• Exploratory Nature: The POC is intentionally designed to uncover issues early when they're easier and less costly to address. Issues found during POC should be viewed as valuable discoveries rather than failures.

• Custom Solutions: Each migration requires engineering teams to build customer-specific solutions based on unique requirements and environments. This customization process may require multiple iterations.

• Anticipated Challenges: During the POC migration phase, engineering teams must build customized solutions based on each customer's unique project requirements and environment. While we anticipate encountering customer-specific challenges, the variable nature of these issues may lead to unexpected complexities that could potentially delay the migration start date.

• Timeline Flexibility: The POC is a test and isn't always intended to be smooth. We want to see what issues may arise so we can be proactive in resolving them before moving into the migration waves. Schedule buffer should be incorporated after the POC phase.

Kantata Project Management Guide

Overview

Kantata is our primary Resource Management software where the PMO team reviews and manages Delivery team hours against project scope to effectively report on project progress and forecast PS revenue.

Our team does leverage google sheet templates to ensure forecast & resource allocation accuracy.

• Initial Resource Planning templates
• Burndown Report templates

Project Types & Billing Models

Time & Materials (T&M) Projects

• Billing: Invoiced according to time submitted at the project level (bucket of hours)
• Revenue Recognition: Released monthly based on approved timesheets
• Tracking: While SKUs are one transaction, we track against hourly billings (e.g., Consulting Blocks & Dedicated Engineer Projects)

Fixed Fee (FF/FP) Projects

• Billing: Invoiced at milestone schedule
• Revenue Recognition: Upon customer milestone acceptance or passive acceptance completion
• Critical: Ensure anticipated dates are added to milestones and customer sign-off is obtained before billing period ends

Initial Project Setup

Project Lead Assignment

1. Ensure you (as PM) are assigned as the project lead in Kantata
2. Navigate to Kantata > Resourcing > Resource Center > Projects
3. Filter by Project Lead = you to review allocations for your projects

Resource Allocation Types

• Soft Bookings: Non-confirmed allocations (displayed as striped cells) - used when final schedule isn't known yet
• Hard Bookings: Confirmed allocations (displayed as colored cells) - promises team member availability

Time Tracking Guidelines

• refer here for a complete breakdown of non-billable vs billable time
• be sure to review with your project team members independent or in conjunction with the Working Agreement

Resource Management & Forecasting

Creating Resource Requests

1. Navigate to Resource Center > Projects
2. Under assigned team members, click "Add Team Member" or "Add unnamed Resource"
3. Fill in information and click "Submit Request" (Note: "Post" will not submit the request)
4. If too early for specific resource but you have rough schedule, hard schedule with "unnamed resource" for capacity planning

Allocation Guidelines

All active projects must be fully allocated on a rolling 12-week basis and should have a combination of Hard and Soft allocations that account for the full 12-week window.

• Hard Allocations (Hard Forecast):
  • Hours where we have confirmed client commitment (90%+ confidence)
  • Examples: scheduled meetings, project plans, and confirmed upcoming deliverables
  • Promises team member availability for requested hours
  • Projects into revenue forecast (90-95% accuracy)
  • Requires approval by project coordinator
• Soft Allocations (Soft Forecast):
  • The PM's best assumption of likely project revenue based on current trajectory, scope, and client engagement — an informed estimate, not a guarantee
  • Used for visibility and planning when schedule is uncertain
  • Will not promise team member availability
  • Considered upside forecast (40% accuracy)

What's expected of every PM:

• Confirm Hard allocations reflect only work with strong client confirmation
• Fill remaining weeks with your best Soft forecast assumptions
• Ensure no active project is left unallocated across the 12-week horizon

Blocked or missing information? If you're waiting on client confirmation, missing project details, or have any blockers, loop in your PMO Manager first and escalate any outstanding issues to PS leadership. Do not leave projects unallocated while waiting — use Soft allocations to capture your best current estimate.

Forecast Management Process

1. Go to Resource Center > Project Tab and filter via "My Projects"
2. Expand your project to see all PS Engineers and yourself
3. Click on each team member's name and submit Resource Request via the "activity" window
4. Assign to Project Coordinator as recipient

Team Member Availability

• Navigate to Kantata > Resourcing > Resource Center > Team Members
• View specific resource availability when changing or increasing allocations

Upside Tracking

Upside is reviewed weekly, monthly, and quarterly. Track upside in the weekly revenue tracking sheet (pinned to ps-pmo channel) for these scenarios:

1. Uncertain Forecasting: Cannot confidently forecast project resources 2 months out → soft-book PSE/PM/TA time
2. Pending Change Orders: CO not yet reflected in Kantata → review details with PMO Manager
3. Milestone Date Adjustments: Anticipated completion in quarter but not yet confirmed/verified
4. Customer Reporting: Call out upside in customer reports (e.g., "can only soft-forecast 'x' amount because of 'y' constraints")

Fixed Fee Project Management

Milestone Date Updates

1. Open your project and select "Task Tracker" tab
2. Expand milestones
3. Update sign-off dates to reflect in forecast

Revenue Recognition & Project Closure

T&M Project Revenue Release

• Timing: Revenue recognized monthly
• Process:
  • PSEs/PMs log time weekly via Kantata timesheets
  • Project Lead/PM approves entries weekly
  • Month-end: Project Coordinator compiles approved timesheets and submits to Finance

Fixed Fee Project Revenue Release

• Timing: Upon customer milestone acceptance or passive acceptance completion
• Process:
  1. PM copies Project Milestone/Closure document
  2. Attach document to customer for closure, copying Operations coordinator
  3. Customer signs document or replies "approved"
  4. PM sets milestone in Kantata to "complete"

Passive Acceptance

• Timeline: Customer has 5 business days to approve/deny (Day 1 = notification sent day)
• Action: If no response within timeframe, milestone can be set to "complete"

Required Kantata Updates for Milestones

Update these custom fields in respective milestone tasks:

• Sign-Off Sent: When acceptance request email is sent
• Sign-Off Received: When customer acceptance received or passive acceptance achieved
• Passive Acceptance Utilized: If passive acceptance is used
• Attachments: Acceptance email (PDF format) or milestone document
• Dates: Update actual start/kickoff/end dates

Important: Only update top-level milestone fields; sub-activities remain unchanged.

Key Reminders

• Adhere to scheduling guidelines for accurate resource allocation and revenue forecasting
• Weekly timesheet submissions are critical for T&M revenue recognition
• Milestone management is crucial for FF project revenue recognition
• Regular upside tracking ensures accurate quarterly forecasting

This is a folder to house guidance for the Planning phase

Kantata Date Entry Guidance for Program Managers

Date Fields

Planned Start Date

Enter during initial project planning or when a task/milestone is created. This is your baseline — reflect the originally scheduled start date and do not update it once work begins.

Planned Due Date

Enter at the same time as Planned Start Date. For client-facing milestones, this should align with any contractual or SOW commitments. Like Planned Start, do not update.

Start Date

Enter on the day work begins (no later than the next business day). Only log when work has genuinely started — do not enter speculatively.

Due Date

Enter on the day completion is confirmed. For milestones requiring client acceptance, use the acceptance date, not the submission date. Do not pre-populate as a target.

Variance Reason Fields

Start Variance Reason

Document the root cause, who or what drove the variance (internal team, client, third party, scope change), and any impact on downstream tasks.

Format: [Early/Late] by [# days] — [Root cause]. [Downstream impact or mitigation, if applicable.]

Examples:

• Late by 5 days — Client did not provide access credentials by the scheduled onboarding date. Downstream environment setup shifted accordingly.
• Early by 2 days — Predecessor task completed ahead of schedule; team capacity was available.

End Variance Reason

Document the root cause, whether it was within the team's control, and any corrective action taken or planned.

Format: [Early/Late] by [# days] — [Root cause]. [Corrective action or lessons learned, if applicable.]

Examples:

• Late by 8 days — Mid-task scope expansion added unanticipated complexity. Change order submitted and approved; schedule formally updated.
• Early by 3 days — Team identified an automation opportunity that reduced manual effort. No downstream impact.

Quick Reference

FAQ

Q: Sometimes the start date gets populated when the first time card has been submitted; is it ok if the start dates are after the first time card submission, especially if the PM starts doing pre-planning before the kickoff?

A: Yes, using the first timesheet was an approach used by operations when there is no start date entered. Please use the date fields as described above and there will be no issue with timesheets being submitted before the project official start date.

[TOC]

GitLab Project Management AI Best Practices

Introduction

Welcome to the GitLab Project Management AI Knowledge Base! This collaborative resource shares approaches for using artificial intelligence to streamline project management processes, enhance collaboration, and improve delivery outcomes within GitLab projects.

This guide presents various techniques for integrating AI with existing templates and processes. Contributors have discovered significant opportunities to automate routine tasks, generate valuable insights, and support decision-making.

Some key value and efficiency successes reported by users include:

• Streamlined status reports with enhanced accuracy based on data inputs
• Fast Collaboration Project setup
• Easy generation of project data for analytical purposes
• Efficient data aggregation to easily find project information
• Improved data transformation processes
• Reduced context switching by using AI as an information cache
• Leveraging meeting transcripts to form content
• Expanding technical capabilities to create mockups, make API calls, and build simple apps

How to Use AI to Enhance GitLab Projects

Before getting into specifics, here are some general approaches to best use AI:

• Record Everything: Using audio transcripts has been one of the most valuable tools to help build accurate narratives.
• Copy & Paste all the things: Grabbing conversations from email, slack messages, or GitLab issues provides good information to summarize long discussions and associated timelines.
• Be aware of GitLab's data use policies
  • Some relevant handbook pages
    • (External) Data Classification Standard
    • (Internal) Data Classification Index
    • (Internal) AI at GitLab

AI-Enhanced Project Management Techniques

1. Status Report Generation and Analysis

Status Reports follow a consistent structure that's ideal for AI assistance:

Technique: Automated Draft Creation

• Use AI to generate initial status report drafts by analyzing project data, recent activities, and previous reports
• Ensure consistency by having AI check that all required sections (Project Scope, Overall Status, What's Next, Budget, RAID items) are completed with appropriate detail
• Leverage AI to suggest appropriate status indicators (🟢/🟡/🔴) based on project metrics and narrative content
• Calculate and highlight remaining hours and burn rates automatically
• Analyze status narratives to proactively identify potential risks not explicitly listed

2. Project Planning and Template Customization

Templates (Status Template, Canvas Template, Collaboration Project Template, etc.) can be enhanced with AI:

Technique: Custom Template Generation

• Create tailored versions of templates to match specific project needs
• Break down SOW activities into structured GitLab issues (as outlined in "Directions to make issues from a sow")
• Generate realistic project timelines based on activity dependencies and resource availability

3. Project Documentation Enhancement

AI can improve Charter Templates, Collaboration Projects, and Kickoff Meeting materials:

Technique: Documentation Standardization

• Ensure all project documents follow GitLab's formatting and content standards
• Create project-specific content for wikis, charters, and kickoff materials
• Generate comprehensive team member lists with roles and responsibilities
• Organize bookmarks based on project type and stage
• Draft detailed agendas for kickoffs and status meetings based on project context

4. RAID Management and Risk Mitigation

RAID tracking can be enhanced through AI analysis:

Technique: Comprehensive Risk Creation

• Generate risks that include Risk Description, Background, Specific Technical Concerns, Current Customer Questions, Risk Impact, Mitigation Strategy, Ownership, and Status

5. Project Closure and Milestone Documentation

For project closure (using templates like TEMPLATE_Project Milestone_Closure Document, AI can:

Technique: Project Closure Assistance

• Compare completed deliverables against SOW requirements to ensure completeness
• Analyze project data to identify strengths and improvement opportunities
• Generate draft acceptance documentation for customer review
• Evaluate project outcomes against initial goals and KPIs
• Identify key learnings to be shared with the broader team

Getting Started with AI in Project Management

Implementation Approach

Here's how to integrate AI into your workflow:

1. Data Preparation: Ensure project data is well-structured and accessible
2. Template Selection: Choose appropriate templates from the project knowledge base
3. Prompt Engineering: Develop effective prompts that generate valuable outputs
4. Review and Refinement: Always review AI-generated content before sharing with stakeholders

Best Practices

• Maintain Human Oversight: Use AI as an assistant, not a replacement for judgment
• Focus on High-Value Activities: Prioritize AI use for repetitive, time-consuming tasks
• Iterate and Improve: Continuously refine prompts and processes based on results
• Respect Confidentiality: Ensure AI tools are used in compliance with data privacy requirements
• Share Successes: Document effective AI use cases that might help colleagues

AI Application Examples with Specific Artifacts

Status Reports

• Generate draft status updates by analyzing GitLab issues, milestones, and previous reports
• Suggest appropriate status indicators based on progress metrics and narrative content
• Identify missing information in draft reports before they're shared with stakeholders

Canvas Templates

• Auto-populate team member information from project directories
• Generate initial goal statements based on SOW activities
• Create comprehensive key resources lists based on project type

Collaboration Projects

• Translate SOW activities into structured GitLab epics and issues
• Generate detailed descriptions for each activity based on SOW language
• Create relevant labels based on project characteristics

Charter Templates

• Populate DRI tables with appropriate team members
• Generate project-specific dashboard links

Canned Actions

• Use the Project Knowledge base to store pre-planning agendas, kickoff agendas, and welcome emails

CONTRIBUTE: How have you applied AI to specific GitLab artifacts? Share your examples!

Contribution Template

When adding your own AI techniques to this knowledge base, please use the following format:

### [Technique Name]

**Problem It Solves**: 
[Describe the challenge or inefficiency this technique addresses]

**Implementation Method**:
[Step-by-step process for implementing this technique]

**Results/Benefits**:
[Describe the outcomes and improvements achieved]

**Tools Used**:
[List specific AI tools or models that work well for this technique]

**Contributor**: 
[Optional: Your name/handle]

Closing Thoughts

This knowledge base is evolving as AI technology develops. These strategies are shared not as prescriptive guidance but as potential inspiration for those interested in exploring similar productivity enhancements.

Have you found other helpful ways to integrate AI into your project management workflow? Please contribute your experiences by following the contribution guidelines above. Together, we can build a comprehensive resource of AI-enhanced project management techniques for the GitLab community.

This README MAY have been created with heavy AI assistance. Contributors are encouraged to discuss, add, or amend these approaches in more detail at any time.

[TOC]

Kantata Dashboard Configuration Guide for GitLab Professional Services

Overview

This guide will help you set up a powerful at-a-glance project portfolio dashboard in Kantata that displays the most critical project information for effective management and reporting.

Accessing the Dashboard Configuration

1. Log into Kantata
2. Click on Projects in the main navigation
3. From the "Show" dropdown menu, select Your Projects
4. Click the Configure button (usually represented by a gear icon)

Selecting and Ordering Columns

Select the following columns in this specific order for optimal visibility of critical project information:

• Start Date
• Due Date
• Budget Burn
• Hours Logged
• Hours Estimated
• Hours Approved
• Status
• % Done
• Technical Account Manager
• Opportunity Owner
• Provider Lead
• Tasks Done
• Next Due Milestone
• Time Entry Notes Required
• Task Status Set
• Stage
• Time Tracking
• Last Updated
• Project Color
• Paid

Save this configuration as your default view for quick access

Kantana Hours Compare Report Quick Guide

What Is It?

A report showing week-by-week comparison of actual vs. allocated hours against capacity. Helps track resources and monitor project progress.

Key Information

• Purpose: Compare actual hours worked vs. forecasted hours for all project contributors
• Main View: Weekly breakdown of hours (actual, allocated, capacity)
• Billable Analysis: Use "Billable Project Default" and "Billable Actuals Only" filters together for billable-specific comparisons
• Results: Reflect your specific project execution approach

How To Use

1. Review weekly to spot resource utilization issues
2. Identify over/under-allocated team members
3. Compare billable allocated hours vs. actual billable hours
4. Make resource adjustments based on findings

Benefits

• Holistic view of all contributors' hours
• Early warning for project overruns
• Better capacity planning
• Improved resource allocation

Active and Completed Project Report Guide

Purpose

This report is used for understanding which projects are in progress and completed by project leads (PMs). It's particularly helpful when closing out the month/quarter to ensure internal retrospective data is collected and populated.

Who Should Use This Guide

• Project Managers (PMs)
• Managers
• Anyone responsible for project oversight and quarterly/monthly closures

Step-by-Step Instructions

1. Access the Report Navigate to the Month End Reporting-Free Services Report in Kantata

2. Set Date Range

• Choose your desired date range for the reporting period
• Consider aligning with your monthly or quarterly closure timeline

1. PS Type

• Select all

1. PS Category

• Select all (filter out Edu Services if needed)

1. User Type

• Select all

1. Filter by Project Lead

• Filter by Project Lead = PM Assigned to review only your assigned projects
• Managers can filter by specific team members or leave unfiltered to see all projects

1. Configure Project Status Filters Uncheck the following Project Status options:

• Cancelled
• Estimate
• Prospect
• Backlog
• NA

Keep checked:

• Active
• At Risk
• Blocked
• Cancelled
• Closed
• Completed
• In Setup
• Not Started
• Okay to Start
• On Hold

1. Configure Free Services Filter

• Select all

1. Opp Owner & SA

• Select all

1. Project Components

• Select all (filter out Edu Services if needed)

1. Generate and Review

• Run the report to see all relevant started, Due, and Completed projects within the date filter
• Use this data for retrospective analysis and internal data collection

Best Practices

• Run this report regularly during month-end and quarter-end processes
• Ensure all project data is up-to-date before generating the report (start/end date, kickoff date, updated project status)
• Use the results to verify project completion status and gather insights for retrospectives within the internal retro issue
• Coordinate with your Project Coordinator (PC) if you have any questions around project closure activities