Professional Services Project Management

1. You are here:
2. Customer Success
3. Professional Services Team Handbook
4. Professional Services Project Management

On this page

• Project plan
• Project workflow
  • Pre-Project Prep
  • Initiate
  • Plan
  • Monitor/Control, Develop, Configure, Integrate, Train
  • Validate
  • Deploy & Close
• Project Management Process Templates
  • Work Exception
  • Change Order
  • Work At Risk
  • Description of Work

GitLab takes our customer's success very seriously. In Professional Services (PS) we strive to provide a first class experience for all engagements.

• Process Flow - trim (above)
• Process Flow - full

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.

Project plan

Each PS Engagement will include a Project Plan based on the activities outlined in the Statement of Work (SOW). The Project Plan starts in Kantata but may be supplemented by a more detailed Gantt chart, tasks list, or another form of documented plan. This plan will follow the process diagram listed above.

Project workflow

Pre-Project Prep

1. PS Operations: Once a project has moved into SFDC Phase 5 – “Negotiating”, SOW is reviewed and a PS team member is identified for the project, working with Sr. PSE and/or Technical Architect. Choice is based on several criteria:
   • Technical skillset/experience
   • Personality match with the customer
   • Technical growth path opportunity
   • Time zone
   • Availability
2. PS Operations: Reviews team member availability, consulting with Regional Delivery Managers as needed, and adds a soft-allocation to the Kantata project schedule.
   • This puts a temporary hold on the resources intended to work the project
3. PS Operations: Research an appropriate Partner if it is determined that a GitLab team member is not available to work the project.
   • See the PS Ops Partner Process
4. PS Engagement Manager: Introduces the Project manager to the customer.
5. PS Project Manager: Schedules and conducts Project Prep meeting with the customer. The intention of this meeting is to explain HOW we work so that the customer understands how to best tsupport the successful progression of the project.
   • Project Preparation call includes the PM and customer Project Lead counterpart (Engagement Managers and account team are optional)
   • NOTE: Technical discussions are held for the customer project kick-off meeting

Initiate

1. PS Operations: Once a project has moved to Closed/Won in Salesforce, a project is updated to “in set-up” status in Kantata
   • A Project Lead is assigned: this can be a Project Manager, or Professional Services staff member
2. PS Operations: If the Project Manager has not yet had the Project Prep meeting, then PS Ops will send Welcome email and existing customer initiation email
3. Project Lead: Begins planning the project
   • Conducts an internal Account Team to Professional Services Transition meeting which includes EM, PSE, TA, and opitionally the Project Coordinator, Regional Manager, AE, and/or CSM
   • Completes the Account Team to PS Transition issue template, located in the customer Epic
   • Project Preparation call (PM, PSE and/or Technical Architect and customer Project Lead counterpart)
   • If a CSM is assigned, follow these steps outlining the engagement guidelines, throughout the customer project
   • Submit resource request via Kantata to match the mutually agreed upon customer project schedule

Plan

1. Project Lead:
   • External Customer Project Kickoff: Actions and meeting minutes are added directly to the Project Definition Template (attendees include the entire project teams on both sides)
   • Submit resource request via Kantata to match the customer-confirmed project schedule
   • Weekly project check-in meeting: Notes documented in the Project Definition or customer collaboration project
   • Provide Weekly Status Report: Using the template in the Project Definition or other agreed upon method

Monitor/Control, Develop, Configure, Integrate, Train

1. PS Engineer: Complete work per the SOW
2. Project Lead:
   • Keep Kantata up to date: project schedule, project health/pulse report, milestone acceptance, update project tasks via task-tracker, timesheet approvals
   • Provide Weekly Status Report to customer using the template in the Project Definition using the template in the Project Definition
     • Kantata schedule snapshot of the schedule (or other alternative view)
     • Kantata hours burn-down report (for T&M only)
     • Open Action Items Project Definition or customer collaboration project in GitLab
     • Issues & Escalations Project Definition or customer collaboration project in GitLab
     • Planned Out of Office Project Definition or customer collaboration project in GitLab

Validate

1. Project Lead:
   • Inform the customer prior to an activity completion letting them know that they will be asked to approve/sign-off
   • Send activity-based acceptance requests to the customer for approval upon complete of each milestone
2. Customer:
   • Approves completion for each activity, deliverable, or milestone via email or Slack

Deploy & Close

1. Project Owner:
   • Complete this sign off workflow
   • Schedule Project closure meeting
   • Schedule Project Retrospective
   • Regional Manager to provide a closeout report including estimated hours, actual hours, deliverable documents, and lessons learned to broader team. Post this in #ps-project-leadership and make sure to mention the Engagement Manager team @em.

Project Management Process Templates

Work Exception

A Work Exception is used by a PM when seeking approval for a project to go over the alloted time/budget. Use the Work Exception issue template to gain approvals from PS leadership.

Change Order

Change orders are common elements of Professional Services engagements that can modify the scope, duration, or cost of an ongoing project. A change order is typically created by the PM, with assistance of the EM when there is a change in scope. Common scenarios for change orders are:

• The start and end dates of a project are different than what's reflected in the SOW - a $0 change order reflects the new project estimated start and end dates
• Part of the scope of the project changes - the scope change might be handled within the original SOW duration and budget, in which case a $0 change order is created, or it might increase the original scope, and the customer will pay for the additional work. The change order in the latter case would be associated with a new PS opportunity for the amount of the increase in scope. A new Kantata project will then be created to work through the additional scope.
• An existing project will be extended, with similar project activities and deliverables as the original scope, and the customer agrees to use the original SOW as the contract vehicle for the added work. In this case, a change order is created and associated to a new PS opportunity that refects the amount of the PS extension. Note: if the extension of work is for a different project, i.e. has different activities and deliverables, is not contiguously delivered with the original project, and/or will be staffed with different people, then in most cases, a new SOW should be used rather than creating a change order against the original SOW. The new SOW will have its own scoping issue, be linked to the appropriate PS opportunity, and will create a new project in Kantata for staffing and tracking the engagement process.

Apply the following steps to create a change order issue for tracking and approval purposes

• Note the engagement Epic number and the scoping issue number
• Create a Change Order type issue in PS Plan
  • Use this Change Order document template and attach to the Change Order Issue
• Replace <!-- ADD CUSTOMER EPIC NUMBER HERE, e.g. &65--> at the bottom of the description under Quick Actions with the epic number e.g. &65
• Replace <!-- ADD SCOPING ISSUE NUMBER HERE, e.g. #1234--> at the bottom of the description under Quick Actions with the scoping issue number e.g. #1234

Work At Risk

Work at Risk (WAR) is used when seeking approval from PS leadership to staff or start work on a project proior to paperwork being fully executed. Work at risk approvals should be sought in all cases where we need to commit to project start dates for a project (consulting or training) before we have a fully closed opportunity, whether or not the project work actually starts before the opportunity closes. The WAR should be created by an EM, Regional Manager, or Project Coordinator at the appropriate time in the pre-sales process to effectively manage the staffing of the project. When work at risk is sought, apply the following steps to create a work at risk issue, which describes the work at risk process.

• Note the engagement Epic number and the scoping issue number (for new SOW not yet closed) or change order number (for scope change/addition)
• Create a Work at Risk type issue in PS Plan
• Replace <!-- ADD CUSTOMER EPIC NUMBER HERE, e.g. &65--> at the bottom of the description under Quick Actions with the epic number e.g. &65
• Replace <!-- ADD ISSUE NUMBER OF SCOPING OR CO ISSUE HERE, e.g. #1234--> at the bottom of the description under Quick Actions with the scoping/change order issue number e.g. #1234

Description of Work

Description of Work (DoW) is used when a scope discrepancy is identified in the SoW and both GitLab and the customer agrees that the scope change does not impact the project budget (zero dollar), project duration, project financial or legal terms The DoW can also be used to add additional detail to a SKU that has been sold (e.g. Rapid Results), but the description does not quite meet the needs of the customer. Unlike the Change Order process, for the DoW, the GitLab signee will be the RDM or the PS Director.

Create a DoW Issue create a DoW using this template