Professional Services Project Management

Learn about the processes that the GitLab Project Management team uses to deliver successful engagements with Customers.

Customer success = GitLab product implementation, on time, on budget delivery of agreed upon scope, faster time to value that leads to satisfied customers that see the added value of GitLab products and PS

<PS Delivery Customer Journey Flow - Page 1 (10).png>

SOW Close

Given the close collaboration between the PS Project Management and PS Operations team functions, please refer to the PS Operations Wiki for details on processes related to scheduling, reporting, billing, partner processes, and more. *Review our list of PS Offerings here

Project Initiate & Plan

  1. After obtaining Legal approval, PS Quote triggers an Epic in GitLab.com around the recently sold Professional Services Project, at the Professional Services Group level. This Customer Epic is labeled as SOW# + Customer and includes links to relevant Customer & contract information
  2. Once a prosepctive Services deal reaches “Stage 6” (closing) in the PS Customer Journey, the PSOps team refers to the Customer Epic to find the “Scheduling Intake” issue. From this issue, the Resource Scheduling team works to gather the initial information needed to assign the PS Resources (PM, PSE, TA)
    • To find the right resources required, the PSOPs team will refer back to the Customer Epic to find the “Scope Engagement and Write SoW” issue (managed by the Engagement Managment Team). This is where the scheduling team confirm skillsets needed, timing of the project, Project type (Time & Materials or Fixed Fee), etc.
    • This scoping issue this is where the PM’s, TA’s, and PSE’s work to gather the initial project information, scoping breakdown, and estimated schedule
    • The PS Ops team works to ensure all detail in the above template is populated before assigning Delivery resources
    • For Consulting Blocks please see below
  3. Once assigned by the PS Ops team, the PM reviews follows the Kantata steps outlined below, to ensure access to Kantata
  4. The PM then reviews the Scheduling intake and begins to work through the Sales to Delivery Transition issue, also tied to the Customer Epic

Customer Project Space Guidelines

  1. We use GitLab as our primary Project Management tool for Service Deivery with our Customers. We use CP (Customer Project) automation configured by the PS Practice team to convert the SOW activities into trackable issues within GitLab
  2. For adehring to best practices, reference the “Professional Services Delivery Methodology” below and be sure to reference the Delivery Kits for guidance around managing our porfolio, by Service Offering

For Consulting Blocks and Dedicated Engineer Projects

  1. The DoW is used to add additional detail to a Consulting Block SKU that has been sold. A DoW is created by the Engagement Management team and confirmed by the Customer. The DOW should be attached to the Customer Epic prior to the Sales to Delivery Transition call
  2. Template for a DoW can be found here

Forecasting Process for PMO Team

PS/PMO Cadence Schedule
  • Pinned to the ps_pmo Slack channel for weekly update requirements and the ps-operations slack channel for Month End timelines (billing period dates)
  • The purpose of this schedule is to reference and understand the relationship between PMO updates to Projects (health, forecasts, timecards) and PS Operations (reports, resource scheduling). Goal is to ensure Project and Program Managers are updating Project forecast in a consistent and symbiotic way to support both our PS Ops teams, as well as communicate our PS Project Portfolio review across the GitLab organization
Kantata

Kantata is our primary Resource Management software. From here the PMO team reviews and manages the Delivery team hours against the Project scope in order to effectively report on Project progress with the Customer. This is also the primary mechanism for PS revenue forecasting. To ensure resources are allocated appropriatly & our forecast is as accurate as possible, it’s important to adhere to the schedule outlined above.

  1. Once assigned to a project, make sure you, as the PM are assigned as the lead of the project in Kantata
  2. Go to Kantata > Resourcing > Resource Center > Projects and filter by Project Lead = you to review the allocations for your projects
  3. Go to Kantata > Resourcing > Resource Center > Team Members to see a specific resource(s) availability in case you need to change or increase allocations
  4. There are 2 types of bookings:
    • Soft bookings are non-confirmed allocations for team members (displayed as striped cells). This must be added by the PM
    • Hard bookings ate confirmed allocations (displayed as colored cells). This also, must be added by the PM
  5. To create a new resource request, navigate to the Resource Center > Projects. Under the list of assigned team members, you can click “Add Team Member” or “Add unnamed Resource”, fill-in the information at the top of the pop-up and click “Submit Request”. NB: Clicking “Post” will not submit the request.
  6. Allocations’ review:
    • You can request your soft bookings to become hard bookings and hours to be adjusted as needed and agreed with the Customer. You can do that from the Resource Center by clicking the resource row under the project and entering your request as a message for your assigned OPS person under Activity. Don’t forget to click “Post” once ready

Billable vs NonBillable information, please refer to Team Metrics page

Reporting Project Health

The PMO team ensures our forecast & upside is updated by Monday, 11am EST, as the PS Ops team prepares the weekly reports per the PS Reporting schedule. The Top Customer is provided to the PM team by PS Ops by 12pm EST on Tuesdays, and the PM team is expected to update the notes (as outlined below) by The PS Reporting Schedule, Weekly Revenue Forecast Reports, and Kantata information pinned to the ps_PMO Slack channel

  • Time & Materials (T&M) projects are invoiced according to time submitted at the Project level
  • Fixed Fee projects (FF or FP) are invoiced at a Milestone schedule. So it’s vital to ensure anticipated dates are added to Milestones within FF projects, and we get customer signoff before the billing period ends
Forecasting Time and Materials (T&M) and Fixed Fee (FF)

Forecast allocations impact PS revenue forecast and team members availability, utilization and planning

  • Soft allocations are used when final schedule is not known yet, for visibility and planning. Soft allocation will not promise team member availability for a project, and will be considered upside forecast (assuming 40% accuracy)

  • Hard allocations will promise team member availability, for the requested hours, once approved by the project coordinator. The allocated hours will also project into the revenue forecast (assuming 90-95% accuracy)

  • For T&M and FF projects, it is the responsibility of the PM to forecast (hard-book) the PM, PSE, and TA time for the project 2 months out in Kantata. Our goal is to be able to be accurate within +/- 5% of our estimated forecast.

  • For Consulting Blocks and Dedicated Engineer Services, we sometimes enter these engagements knowing very little about the project (as it is generally purchased as a SKU). Therefore, our goal is to be within +/- 10% of our estimated forecast after we have our initial EM>PS Transition Meeting

  • To ensure forecast revenue is accurate go under Resource Center in Kantata:

    1. Select “Project Tab” and filter via “My Projects”
    2. Expand project you are allocating for so you can see all PS Engineers and yourself
    3. Click on each team member’s name and submit RR request via the “activity” window opened and assign to Project Coordinator as recipient

  • If it’s a FF project, we need to update the dates on the Milestones in order for it to reflect in our forecast:

    1. Open your project and open the “Task Tracker” tab
    2. Expand milestones
    3. Update sign off date

  • It is helpful to call out forecast that “pushes” in the Top Customer report

How to Track Upside
  • Upside is reviewed on a weekly, monthly and quarterly basis. There are four scenarios around when we need to track upside within our weekly revenue tracking sheet (which is pinned to our ps-pmo channel)
  • If we are unable to confidently forecast the project resources 2 months out, we need to soft-book PSE/PM/TA time in Katata
  • If we have a pending CO that is not yet reflected in Katata, add it to Upside if the work in the CO will be completed this quarter
  • If we anticipate a Milestone date will be adjusted to complete in the quarter, but it has not yet been confirmed/verified, add it to the Upside
  • It is helpful to call upside out in the customer report. ex: can only soft-forecast “x” amount because of “y” restraints
Top Customer Report
  • Updated by 4pm est Tuesday
  • Pinned to ps_pmo Slack channel
  • Update the following in the Notes section
  • 1-lined progress update
  • If there is an issue, what is the proposed action + timing of fix.
  • If there is assistance needed
  • DRI & contributors
  • Internal temperature (R-Y-G) | Customer temperature (R-Y-G)
  • Link to RAID & Internal Customer Epic if Y/R (to review WE, CO, WaR)
Forecast call prep (to be complete by 10am est Mondays)
  1. Run “Remaining Funds to Forecast” report   a. Select project status b. Sort by project lead/PM
  2. Ensure that you have start/complete dates in for ALL of your project tasks
  3. Run your Forecast report and ensure it’s accurate
  4. Add upside added to forecast sheet (daily/weekly):
  5. Run the “Task Audit Report”
  6. a. Sort by PM b. NOTE: Donita will create a Loom recording to walk through the details of this new report
  7. Run the Allocation report a. Review all soft & hard bookings and look at all team members in light blue b. Help to find work for these team members as they are under allocated!
  8. Review all soft-bookings Allocation report a. Select All roles b. Select Full quarter c. There should be no soft allocations for the current month unless the project has just kicked off d. Ensure hard bookings are in place for all projects post kick-off

Deliver, Train, and Monitor

Please reference the PSDM (Professional Services Delivery Methodology) page for more information.

*this also includes information on how we track/report on risk and escalated projects (via RAID), internal retrospective guidelines, tracking lessons learned, and capturing Customer and Project wins

Iterate and Validate

Managing to Project Scope Changes

Project scope for Professional Services is the outline of the work required to deliver a Service against the Customer use case. This includes an overview of the work to be delivered (scope definitions), duration, and resources (cost). All of which is included in the Statement of Work (SOW). If there is a change in project scope, the Project/Program Manager will follow the guidelines below to ensure we properly capture

  1. Change Order

    • Change orders (CO) are common elements of Professional Services engagements that can modify the scope definitions, duration, or cost of an ongoing project. A change order issue and a change order template is created by the Project/Program Manager and communicated with the Engagement Manager and Account Team. It is always attached to the Internal Customer Epic Issue.

    • Common project scope change scenarios:

      • Does need a CO:
      • Change of scope definitions where the project budget requires additional funds. The PM should work with the EM/Account Team to fill out the Change Order template. From here, the EM will create a new PS opportunity for the amount required to fulfill the scope change. A new Kantata project will then be created by the PSOps team.
      • If an existing project is requested to be pushed out two months, with similar project activities and deliverables as the original scope, and the customer agrees to use the original SOW, a change order must be created and associated with a new PS opportunity that reflects the extension.
      • If the Project moves from T&M to FF (or vice versa)
      • If you feel the Project needs a CO (especially on FF projects)

    • Does not need a CO:

      • If there is a change of project scope definitions within the SOW duration and budget, no change order is needed. The PM must get written confirmation with the Customer on the change of Scope definitions. This written confirmation must be screenshot & attached to the associated Project Epic.
      • For extensions less than 2 months past the SOW expiration, the PM should capture written confirmation (from email or Slack) and attach the confirmation to the “Scope Engagement and Write SoW” issue found within the customer Epic.

  2. Work at Risk (WaR)

    • A WaR issue serves as a means to gain approval from PS leadership to commence project staffing or initiation before all paperwork is finalized. This approval is necessary whenever there’s a requirement to commit to project start dates before the opportunity is completely closed. It’s essential for both consulting and training projects. The responsibility for initiating WaR lies with the assigned Project or Program Manager with the EM/AE teams. This will enable the Delivery team to start staffing the project promptly. When seeking approval for Work at Risk, please follow the steps outlined in the WaR template above.
    • A WaR is not billed to the customer until after the contract is signed
    • Common scenarios:
      • Kicking off a project before SOW is signed by the Customer
      • Resuming work before the CO is signed by the Customer, or the change is captured in writing

  3. Work Exception (WE)

    • A Work Exception is used by a PM when seeking approval for a project to exceed the hours/budget originally allotted. Use the Work Exception issue template to gain approvals from PS leadership. It can be used independently or including a CO.
    • Ensuring we include labels as a PM is crucial, as this is how we will better track and improve our transition process from Sales to PS.

    Work Exception Report - callouts for reasonings behind additional PS effort without a CO request. This includes Product challenges, scoping definition misalignment, insufficient PS hours, or other PS related items.

Deploy & Close

  1. Project Closure Meeting

    Schedule a 30-minute meeting with the customer’s point of contact (POC) to review the external project retrospective. It’s recommended that the retrospective be maintained as a living document or issue throughout the project, allowing both teams to collaborate and update it regularly. During the closure meeting, this retrospective will serve as the primary agenda and a reliable source for capturing customer feedback. The meeting should cover key successes, challenges, and areas for improvement.

  2. CSAT Survey

    Before the project closure meeting, send the Customer Satisfaction (CSAT) Engagement Survey to gather formal feedback. A template or example communication for this can be found here. The CSAT survey provides insights into customer satisfaction and highlights areas for future improvement.

  3. 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 acceptance or upon the completion of passive acceptance (according to the SOW terms).
    • The PM sends a formal request for acceptance to the customer, copying the Operations Manager and Project Coordinator. The PM then updates the Billing/Revenue Milestone in Kantata.
    • If passive acceptance is applicable, Day 1 is counted as the day the notification is sent, and business days are calculated from this date to determine when passive acceptance is complete.

    Key Updates for Kantata

    • 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 acceptance scenarios, attach the acceptance email or milestone document to the milestone.

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

  4. Internal Project Retrospective

    Schedule an internal project retrospective meeting with the GitLab Account Team, GitLab PS Project Team, Engagement Manager, and Delivery Leads as applicable. The internal retrospective is essential for documenting lessons learned, scoping insights, and opportunities for continuous improvement.

    Note: The retrospective runs most effectively when it is prepared in advance, with relevant sections updated throughout the project lifecycle. This ensures the meeting is focused and productive.

    The internal retrospective serves several key purposes:

    • Tracking Scoping Efforts: Evaluate how well the project was scoped, including any scope changes or challenges.
    • Celebrating Success: Highlight key customer milestones and wins.
    • Promoting Continuous Improvement: Encourage feedback loops to improve both processes and outcomes.

    Additionally, labels should be used strategically within the retrospective documentation. These labels make it easier to filter and search for specific types of feedback across projects, enabling the organization to implement changes more effectively.

    The Project Manager (PM) is encouraged to celebrate project accomplishments by posting a shout-out in the PS-Internal Slack channel. This not only acknowledges the team’s hard work but also enhances visibility and transparency of the project’s success across the organization, fostering a culture of recognition and collaboration.

  5. Kantata Updates

    Once the project is fully completed, with all hours submitted and accounted for, and milestone acceptance confirmed (for fixed-price projects), update the project status in Kantata to “Completed.”

Last modified November 7, 2024: Fix formatting for project closure section (1fe31b0b)
View page source - Edit this page - please contribute. Creative Commons License