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