Skip to content
Snippets Groups Projects
Commit f59391d4 authored by Bryan May's avatar Bryan May
Browse files

Merge branch 'vponnapalli-presales-methodology-ps' into 'main'

take 2 on adding back pre-sales methodology for PS

See merge request !11296
parents 522061d3 81552e73
No related branches found
No related tags found
1 merge request!11296take 2 on adding back pre-sales methodology for PS
Pipeline #1640295534 passed
Showing
with 197 additions and 73 deletions
......@@ -12,7 +12,7 @@ Here are links to the most popular Professional Services topics.
* [Marketed Offerings](https://about.gitlab.com/services/)
* [Offerings Framework & Delivery Kits](framework/)
* [Positioning](positioning/)
* [Professional Services Methodology](processes/)
* [Professional Services Methodology](professional-services-delivery-methodology/)
* [Selling](selling/)
* [Working with PS](working-with/)
* [SKUs](SKUs/)
......@@ -29,7 +29,7 @@ The Professional Services team is organized according to specialized functions a
| Function | Responsibilities |
|---|---|
| [Delivery](processes/) | Service delivery planning and execution through specialized engineering team members |
| [Delivery](professional-services-delivery-methodology/) | Service delivery planning and execution through specialized engineering team members |
| [Engagement Management](engagement-mgmt/) | Opportunity and SOW scoping and closing in collaboration with GitLab Sales team members |
| [Instructional Design and Development](instruct-dev/) | Educational content creation, deployment, and maintenance |
| [Practice Management](practice-mgmt/) | Definition, planning, go-to-market, and performance for specific categories of professional services offerings |
......
......@@ -79,30 +79,25 @@ To get your customer the most [value](/handbook/customer-success/customer-succes
Some customers have a team of git ninjas who can manage migration and setup quickly, but the rest of the engineers might not be as skilled. Its always a good idea to suggest education services because the customer end users will be more likely to push for later stage adoption. This type of grassroots motivation will go a long way when investigating conversion opportunities.
For these customers consider our [Education Services](/services/education/) (Basics, CI/CD, DevOps Fundamentals)
For these customers consider our [Education Services](/services/education/)
## Sales Collateral
### Internal Testimonials
The PS team has been building maturity and repeatability to its services over the later part of 2019 and early part of 2020. We have captured some recent wins with internal testimonials in [this internal document](https://docs.google.com/document/d/1TMZe6yNbvdz9Sfq4pz-i0DHMLnai2Kjqw7HKkqzwpSo/edit?usp=sharing).
The PS team has been building maturity and repeatability to its services over the later part of 2019 and early part of 2020. We have captured some recent wins with internal testimonials in [[this highspot page](https://gitlab.highspot.com/items/65047cc5d2ccf775a19de0f6)
### Pitch Deck
To discuss our services offerings with prospects, it is often helpful to have a few slides to describe the role of the professional services team. Feel free to use this deck directly - however if you'd like to modify it please first make a copy.
To discuss our services offerings with prospects, it is often helpful to have a few slides to describe the role of the professional services team. If you need slides for our SKU services feel free to pull from the below deck. If you are thinking this is a larger engagement, please contact [your Engagement Manager](https://docs.google.com/document/d/1sdehii3Eqp_CiYsGT3dDb0nKbbtwpxKQlni7t3ZgfCs/edit?tab=t.0#heading=h.1er41qhhpoj5)
[Professional Services Pitch Deck](https://bit.ly/psslides)
[Professional Services Proposal Deck](https://docs.google.com/presentation/d/1M-7aA7f9S6dULvzuKuTJs4j3A4V1z2DtMsoN0T0SMZg/edit#slide=id.g277ce56021a_0_2036)
### Data Sheets
Professional Services Data Sheets are available as subpages to the marketing site. You can find them through the [Professional Services portal](/services/).
### Services Calculator
The goal of the services calculator is to provide the sales team a starting point to scope more complex services requests with the PS Engagement manager. You can get access to the service calculator [here](https://services-calculator.gitlab.io/).
### Other Collateral
- Check other collateral documentation in the [Professional Services Sales Enablement folder](https://drive.google.com/drive/u/0/folders/1vLhSdmlwClou_16I1SU9d3X0oG1EtBHv) on Google Drive.
- [How to sell professional services](/handbook/customer-success/professional-services-engineering/selling/)
- General Guidelines for [working with professional services](/handbook/customer-success/professional-services-engineering/working-with/)
......@@ -9,7 +9,7 @@ The Professional Services Delivery Methodology (PSDM) is the guiding light for P
## Iteration 0
[Iteration 0](professional-services-delivery-methodology/iteration-0/_index.md) includes the initial discovery and planning between the GitLab & Customer Project Team(s). This includes:
[Iteration 0](./iteration-0/_index.md) includes the initial discovery and planning between the GitLab & Customer Project Team(s). This includes:
- EM>PS Delivery Transition
- Stakeholder Planning
......@@ -24,9 +24,9 @@ Proper Iteration 0 preparedness allows us to address risk early and instills con
GitLab will be used as a project management and collaboration platform. We will be using the following features/terminology in GitLab defined below.
Please reference the following tips for [GitLab best practices](professional-services-delivery-methodology/gitlab-best-practices/_index.md) when navigating GitLab.
Please reference the following tips for [GitLab best practices](./gitlab-best-practices/_index.md) when navigating GitLab.
How to initially configure GitLab as a Project Management tool can be found [here](professional-services-delivery-methodology/cp/_index.md).
How to initially configure GitLab as a Project Management tool can be found [here](./cp/_index.md).
NOTE: any issues marked as "internal" are still visible to anyone who has "developer" access into the Gitlab Collaboration project. This includes anyone outside of Gitlab. It it recommended to use the Projects "Internal Epic" for confidential communications.
......@@ -42,15 +42,15 @@ NOTE: any issues marked as "internal" are still visible to anyone who has "devel
| Iterations | Time-boxed (generally) two-week events, that are reviewed during the Agile ceremonies. |
| Milestones | How we can track against the Project Phase |
| Labels | We use these in a variety of ways, but the most important ones are: </br> <ul><li>To manage progress during delivery using a left-to-right flow</li><li>To manage prioritization</li><li>To organize specific sub-categories of work to keep the team organized.</li><li>To manage risk and mitigation</li></ul> |
| Weight | Size or level of effort of the issue. See [Good Estimation Techniques](./professional-services-delivery-methodology/good-estimation-techniques/_index.md) for assigning weight |
| Weight | Size or level of effort of the issue. See [Good Estimation Techniques](./good-estimation-techniques/_index.md) for assigning weight |
Reference [here](professional-services-delivery-methodology/agile-to-gitlab-terminology/_index.md) for additional clarity around mapping Agile terminology to GitLab.
Reference [here](./agile-to-gitlab-terminology/_index.md) for additional clarity around mapping Agile terminology to GitLab.
## Label Guidelines
Labels are the best way to generate reports around our Projects and sort according to the Project teams’ needs. The team is free to make labels as they see fit for Project reporting, but there are also current guidelines around label generation for internal use.
Currently, our [CP (Customer Project) automation](professional-services-delivery-methodology/cp/_index.md) includes the following labels:
Currently, our [CP (Customer Project) automation](./cp/_index.md) includes the following 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
......@@ -60,7 +60,7 @@ Labels used for *Internal retro & RAID tracking/reporting* can be found in “Re
## Iteration Scheduling
The [iteration schedule and cadence](professional-services-delivery-methodology/iteration-scheduling/_index.md) is first introduced in Iteration 0, and is part of the Communication Plan that lives within the GitLab Customer Project (Group). It is important the Customer agrees to an Iteration Schedule as an output of the Customer Kickoff, but should be introduced & collaborated with the Customer as part of our Stakeholder Planning meeting.
The [iteration schedule and cadence](./iteration-scheduling/_index.md) is first introduced in Iteration 0, and is part of the Communication Plan that lives within the GitLab Customer Project (Group). It is important the Customer agrees to an Iteration Schedule as an output of the Customer Kickoff, but should be introduced & collaborated with the Customer as part of our Stakeholder Planning meeting.
There are five components within an Iteration schedule:
......@@ -74,7 +74,7 @@ There are five components within an Iteration schedule:
The Program Manager / Project Manager provides strategy and direction for the project, which means he/she is responsible for providing the vision, product roadmap, release goals, and iteration goal. The Program Manager / Project Manager is expected to insert, re-prioritize, refine, or delete items from the product backlog; this can happen any time until the iteration scope is defined and committed to by the development team.
Please reference [Backlog Management](professional-services-delivery-methodology/backlog-management/_index.md) for guidance around estimation, backlog grooming, and other Iteration Planning preparation tips.
Please reference [Backlog Management](./backlog-management/_index.md) for guidance around estimation, backlog grooming, and other Iteration Planning preparation tips.
## Reporting within the Iteration Schedule and Project
......@@ -86,15 +86,15 @@ Working asynchronously & remotely can be challenging. Ensuring the DRI within th
### RAID & Internal/Customer Retrospective
The RAID, Internal Retrospective, and Customer Retrospective not only assist with the progression of a Project, but these records act as a mechanism to feed back into our Business Development, Customer Success tracking, and Team celebrations. [Please reference here](professional-services-delivery-methodology/manage-risk/_index.md) for more guidelines on how to manage these reports once a Project begins.
The RAID, Internal Retrospective, and Customer Retrospective not only assist with the progression of a Project, but these records act as a mechanism to feed back into our Business Development, Customer Success tracking, and Team celebrations. [Please reference here](./manage-risk/_index.md) for more guidelines on how to manage these reports once a Project begins.
The Customer Retrospective guidelines can be [found here](professional-services-delivery-methodology/retrospectives/_index.md).
The Customer Retrospective guidelines can be [found here](./retrospectives/_index.md).
## Guidelines for PSDM
Applying the suggested PSDM with a full Iteration schedule is needed only when the Project exceeds 5 Iterations or when the engagement plans to exceed two months.
Please review the [archetype definitions](professional-services-delivery-methodology/archetype-definition/_index.md) around what a “large” Customer looks like.
Please review the [archetype definitions](./archetype-definition/_index.md) around what a “large” Customer looks like.
Please use the below as a guide, when planning for Iteration 0.
......
......@@ -7,7 +7,7 @@ description: "Learn about the key charateristics to classify the different Custo
Most Fortune 500 companies are interested in **Scaling.** The business goals are usually focused on gaining efficiencies by scaling from **teams** to **programs** and ultimately across a set of complex **portfolios** with a strong incentive to realize cost savings through standardization.
Some Fortune 500 companies are interested in [digital transformations](../digital-transformation/_index.md).
Some Fortune 500 companies are interested in digital transformations.
What are key characteristics?
......@@ -25,9 +25,9 @@ What are key characteristics?
* Black Friday
* 4th of July Sales Event
![ScalingCharacteristics.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/archetype-definition/ScalingCharacteristics.jpg)
![ScalingCharacteristics.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/archetype-definition/ScalingCharacteristics.jpg)
![ScalingTeamCompositions.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/archetype-definition/ScalingTeamCompositions.jpg)
![ScalingTeamCompositions.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/archetype-definition/ScalingTeamCompositions.jpg)
### Scaling Considerations
......
......@@ -17,7 +17,7 @@ The problem arises from a combination of issues such as:
The following picture shows how these things are strongly related:
![IntegrateBizAndIT.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/backlog-management/IntegrateBizAndIT.jpg)refi
![IntegrateBizAndIT.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/backlog-management/IntegrateBizAndIT.jpg)refi
## Prerequisites
......@@ -27,13 +27,13 @@ To reiterate some of the basic preconditions that have to be met in order to eff
2. [Good estimation techniques](../good-estimation-techniques/_index.md)
3. 1 and 2 result in the ability to perform [effective release planning](../release-and-engagement-planning/_index.md)
3. 1 and 2 result in the ability to perform effective release planning.
**_Without good user stories and applying good estimation techniques, the product and sprint backlogs become less useful and will ultimately prevent the Agile / Scrum process from becoming predictable._**
The Program Manager / Project Manager provides strategy and direction for the project, which means he/she is responsible for providing the vision, product roadmap, release goals, sprint goal. The Program Manager / Project Manager is expected to insert, re-prioritize, refine, or delete items from the product backlog; this can happen any time until the sprint scope is defined and committed to by the development team.
![Backlog Change](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/backlog-management/refine-backlog.png)
![Backlog Change](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/backlog-management/refine-backlog.png)
[Sizing and estimation](../good-estimation-techniques/_index.md) of the product backlog usually occurs in sprint planning meetings or at regularly intervals during ongoing sprints. Depending on how fast the Program Manager / Project Manager adds user stories, more frequent, maybe even daily estimation sessions might be needed. The GitLab Implementation Team and the Customer Development Team and Program Manager / Project Manager must work together to estimate the backlog items, may that be in sprint planning meetings or during ongoing regular sessions.
......@@ -47,7 +47,7 @@ The GitLab Implementation Team and the Customer Development Team are responsible
The Program Manager / Project Manager communicates with stakeholders to determine the priorities and constantly refines the backlog.
In GitLab, there are dynamically generated issue lists which users can view to track their backlog. Labels can be created and assigned to individual issues, which then allows you to filter the issue lists by a single label or multiple labels. This allows for further flexibility. Priority labels can be used to also order the issues in those lists. See "[How to Use CPR to Manage Engagements](../cpr/_index.md)" for more information.
In GitLab, there are dynamically generated issue lists which users can view to track their backlog. Labels can be created and assigned to individual issues, which then allows you to filter the issue lists by a single label or multiple labels. This allows for further flexibility. Priority labels can be used to also order the issues in those lists. See "[How to Use CPR to Manage Engagements](../cp/_index.md)" for more information.
## Product – Release – Sprint Backlogs
......@@ -57,19 +57,19 @@ Many efforts require you to manage three backlogs:
2. The **Release Backlog**, which is the subset of functionality that will have to be delivered in a specific release (consisting of a set of sprints), according to the product roadmap and release plan – active for a specific release
3. The **Sprint Backlog**, which represents the work to be done for the upcoming sprint – active for the sprint duration
![Product Backlog](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/backlog-management/Agile-Release-Planning.jpg){width="767" height="518"}
![Product Backlog](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/backlog-management/Agile-Release-Planning.jpg){width="767" height="518"}
Labels can be used to tag user stories / issues.
![Release Labels](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/backlog-management/Release-Label.jpg){width="330" height="45"}
![Release Labels](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/backlog-management/Release-Label.jpg){width="330" height="45"}
Using such tagging lets you easily view relevant information about the specific user story and what state it is in.
Usually the next upcoming sprint is sized and estimated in detail using Estimation Poker, with the following two to three sprints and their contents being sized and estimated using either Estimation Poker or T-Shirt Sizing. Remember that once a sprint is committed to by the team, the scope should not change any longer as you are "in-flight" - changing stories "in-flight" causes unnecessary context switching, which is costly in terms of productivity. Future sprints can still be adjusted and items can be reshuffled as the Product Owner and Development Team agree on.
![Release Backlog](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/backlog-management/Agile-Release-Planning-Sprint.jpg){width="767" height="518"}
![Release Backlog](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/backlog-management/Agile-Release-Planning-Sprint.jpg){width="767" height="518"}
![Sprint Backlog](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/backlog-management/Sprint-Backlog.jpg){width="753" height="251"}
![Sprint Backlog](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/backlog-management/Sprint-Backlog.jpg){width="753" height="251"}
Product Backlog Items and Sprint Backlog Items may contain more than just user stories, but regardless what exactly is in the specific backlog, it is supposed to represents all work items that consume team capacity. This includes the actual user story describing the engagement feature to be implemented, defects, research, and other technical tasks.
......@@ -93,7 +93,7 @@ The single most important artifact impacting the success or failure of your enga
Agile is a simple process, with 6 roles, 5 events, and 9 artifacts.
![Roles Events Artifacts](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/backlog-management/Roles-Events-Artifacts.png)
![Roles Events Artifacts](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/backlog-management/Roles-Events-Artifacts.png)
Only 8 artifacts are shown above - the working system left behind is implicitly considered the 9th.
......
......@@ -13,13 +13,13 @@ The Product Backlog is essentially the project's To-Do list, or requirements rep
All items that are deemed in scope for the project, regardless of level of detail, are in the Product Backlog, and they are ordered, not just prioritized – meaning the one on top is more important than the one in 5th position, which is more important than the one in 23rd position. Order is decided by the Program Manager / Product Manager and usually driven by business value – in consultation with the Customer Development Team.
![Example Backlog](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/definition-of-done/Backlog.png)
![Example Backlog](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/definition-of-done/Backlog.png)
What is known of the projects scope, is written down and documented in the form of user stories, with the expectation that discovery will lead to change. The Product Backlog is a living repository and is owned by the Program Manager / Project Manager.
The Product Backlog is the source for the Sprint Backlog. Whereas the Product Backlog represents the requirements repository for the project / engagement, the Sprint Backlog is the agreed upon scope for the next upcoming sprint and as such represents the GitLab Implementation and Customer Development Team's deliverable commitment. The GitLab Implementation Team does not operate in a vacuum, it close coordinates priorities with the Customer Development Team.
![Iteration Cycle](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/definition-of-done/IterationCycle.jpg)
![Iteration Cycle](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/definition-of-done/IterationCycle.jpg)
Once agreed upon and committed to, the Sprint Backlog usually does not change in order to ensure the GitLab Implementation Team and the Customer Development Team can deliver against their commitment.
......
......@@ -13,13 +13,13 @@ The Product Backlog is essentially the project's To-Do list, or requirements rep
All items that are deemed in scope for the project, regardless of level of detail, are in the Product Backlog, and they are ordered, not just prioritized – meaning the one on top is more important than the one in 5th position, which is more important than the one in 23rd position. Order is decided by the Program Manager / Product Manager and usually driven by business value – in consultation with the Customer Development Team.
![Example Backlog](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/definition-of-ready/Backlog.png)
![Example Backlog](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/definition-of-ready/Backlog.png)
What is known of the projects scope, is written down and documented in the form of user stories, with the expectation that discovery will lead to change. The Product Backlog is a living repository and is owned by the Program Manager / Project Manager.
The Product Backlog is the source for the Sprint Backlog. Whereas the Product Backlog represents the requirements repository for the project / engagement, the Sprint Backlog is the agreed upon scope for the next upcoming sprint and as such represents the GitLab Implementation and Customer Development Team's deliverable commitment. The GitLab Implementation Team does not operate in a vacuum, it close coordinates priorities with the Customer Development Team.
![IterationCycle.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/definition-of-ready/IterationCycle.jpg)
![IterationCycle.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/definition-of-ready/IterationCycle.jpg)
Once agreed upon and committed to, the Sprint Backlog usually does not change in order to ensure the GitLab Implementation Team and the Customer Development Team can deliver against their commitment.
......
......@@ -3,7 +3,7 @@ title: "Discovery"
description: "Learn about the best practices of performing discovery sessions with a Customer."
---
![Discovery.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/discovery/Discovery.jpg)
![Discovery.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/discovery/Discovery.jpg)
## How Will Discovery be Conducted?
......
......@@ -25,7 +25,7 @@ When working on a feature branch and adding new commits, run tests right away. I
You can also have these [displayed in each Merge Request](https://docs.gitlab.com/ee/user/application_security/#view-security-scan-information-in-merge-requests).
![MR widget test results](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/gitlab-best-practices/MR-UI-Results.png){width="624" height="220"}
![MR widget test results](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/gitlab-best-practices/MR-UI-Results.png){width="624" height="220"}
## 4. Perform code reviews before merging into the main branch
......@@ -122,9 +122,9 @@ Scenarios in which the final approver might not merge an MR:
* Approver doesn't realize that they are the final approver.
* Approver sets auto-merge but it is un-set by GitLab.
If any of these scenarios occurs, an MR author may merge their own MR if it has all required approvals and they have merge rights to the repository. This is also in line with the GitLab [bias for action](../../../../../values/_index.md#operate-with-a-bias-for-action) value.
If any of these scenarios occurs, an MR author may merge their own MR if it has all required approvals and they have merge rights to the repository. This is also in line with the GitLab [bias for action](../../../../values/_index.md#operate-with-a-bias-for-action) value.
This policy is in place to satisfy the CHG-04 control of the GitLab [Change Management Controls](/handbook/security/change-management-policy/).
This policy is in place to satisfy the CHG-04 control of the GitLab [Change Management Controls](../../../../security/security-and-technology-policies/change-management-policy.md).
To implement this policy in gitlab-org/gitlab, we have enabled the following settings to ensure MRs get an approval from a top-level CODEOWNERS maintainer:
......@@ -218,7 +218,7 @@ The [default branch](https://docs.gitlab.com/ee/user/project/repository/branches
It might be a good idea to have an [environment](https://about.gitlab.com/blog/2023/07/27/gitlab-flow-duo/) that is automatically updated to the staging branch. Only, in this case, the name of this environment might differ from the branch name. Suppose you have a staging environment, a pre-production environment, and a production environment:
![GitLab Flow](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/gitlab-best-practices/gitlab-flow.png){width="356" height="340"}
![GitLab Flow](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/gitlab-best-practices/gitlab-flow.png){width="356" height="340"}
In this case, deploy the staging branch to your staging environment. To deploy to pre-production, create a merge request from the staging branch to the pre-prod branch. Go live by merging the pre-prod branch into the production branch. This workflow, where commits only flow downstream, ensures that everything is tested in all environments.
......@@ -240,7 +240,7 @@ Another important part of compliance is knowing it is actually happening in your
Audit Events allows GitLab owners and administrators to track important events such as who performed certain actions and the time they occurred.
![Audit events](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/gitlab-best-practices/audit-events.png){width="496" height="322"}
![Audit events](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/gitlab-best-practices/audit-events.png){width="496" height="322"}
Audit Events records different events per group and per project, which can be seen in the [audit events](https://docs.gitlab.com/ee/administration/audit_event_reports.html) documentation. Audit Events can be accessed by going to Security & Compliance \> Audit Events Some examples include:
......@@ -254,7 +254,7 @@ Audit Events can also be sent to an HTTP endpoint using Audit Event Streaming. I
Compliance Report gives you the ability to see a group's merge request activity. It provides a high-level view for all projects in the group.
![Compliance report](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/gitlab-best-practices/compliance-report.png){width="524" height="339"}
![Compliance report](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/gitlab-best-practices/compliance-report.png){width="524" height="339"}
You can use the report to:
......
......@@ -47,7 +47,7 @@ As you go through different project phases and you learn more about the actual w
**Estimation variability decreases the closer we get to completing the project.**
![ConeOfUncertainty.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/ConeOfUncertainty.jpg)
![ConeOfUncertainty.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/ConeOfUncertainty.jpg)
The only exception to this is if you are working on a process that is 100% understood – a production line is a good example, you know exactly how long the piece will move through different stages on the production line and you can estimate exactly how long it will take to finish one instance of your product.
......@@ -69,17 +69,17 @@ On the other hand, if I am trying to plan for something 5 months out, the best I
For estimation of software projects, this translates into the traditional "Planning Onion" as follows:
![PlanningOnion.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/PlanningOnion.jpg)
![PlanningOnion.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/PlanningOnion.jpg)
This "Planning Onion" basically works from the outside in to provide ever increasing levels of detail; as such it is closely related to the concept presented in the Cone of Uncertainty.
To reflect the timing aspect and estimation detail, you can think of the "Planning Onion" like this:
![PlanningOnionTiming.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/PlanningOnionTiming.jpg)
![PlanningOnionTiming.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/PlanningOnionTiming.jpg)
Finally, in terms of Agile / Scrum estimation time horizons, you can think of Long Term vs. Short Term planning horizons as follows:
![ShortLongHorizon.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/ShortLongHorizon.jpg)
![ShortLongHorizon.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/ShortLongHorizon.jpg)
Vision and Roadmap planning are Long Term Horizon activities, whereas Sprint planning falls into the Short Term Horizon activities.
......@@ -97,13 +97,13 @@ The following picture shows a traditional Waterfall process with three imaginary
2. Customer Management Turnover – your customer / client management or key stakeholders changed and the "new team" wants to provide input (read "new direction") on the project which causes a reset
3. Technology Innovation – new technologies allow for better ways to deliver the project, which forces the team to re-evaluate existing analysis, design, and code and start over
![WaterfallModel.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/WaterfallModel.jpg)
![WaterfallModel.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/WaterfallModel.jpg)
**On waterfall projects, this happens all the time! You reset without delivering value.**
Using Agile on the other hand, you are able to deliver small product increments rapidly. Your planning horizons are shorter, and the Agile team basically commits to delivering a working increment at the end of every sprint.
![AgilePlanning Model.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/AgilePlanning_Model.jpg)
![AgilePlanning Model.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/AgilePlanning_Model.jpg)
Even if requirements change mid sprint, the product increment at the end of that sprint will be delivered. New requirements make it into the product backlog to be prioritized for later sprints.
......@@ -127,7 +127,7 @@ One key thing to keep in mind is that Agile / Scrum teams use relative estimatio
The following picture tries to clarify the differences:
![Absolute-Relative](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/Absolute-relative.jpg)
![Absolute-Relative](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/Absolute-relative.jpg)
The _absolute_ measure here is milliliters (ml), which is an International System of Units fluid measure. There is no interpretation as to what it means. It is absolute. Wine bottles are classified accordingly.
......@@ -135,11 +135,11 @@ The _relative_ measure might be the small, medium, large classification used i
The following table compares and contrasts absolute vs. relative estimation techniques:
![Absolute-Relative-Table](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/Absolute-relative-table.jpg){width="544" height="380"}
![Absolute-Relative-Table](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/Absolute-relative-table.jpg){width="544" height="380"}
## Estimation Poker
![Estimation Poker](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/Estimation-poker.jpg){width="523" height="285"}
![Estimation Poker](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/Estimation-poker.jpg){width="523" height="285"}
As mentioned before, Estimation Poker is a relative estimation technique that favors accuracy over precision. It commonly uses the Fibonacci number sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, …) [^2].
......@@ -200,7 +200,7 @@ All for one, and one for all!
## T-Shirt Sizing and Affinity Estimation
![T-Shirt Sizing](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/T-shirt-sizing.jpg){width="521" height="326"}
![T-Shirt Sizing](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/T-shirt-sizing.jpg){width="521" height="326"}
T-Shirt Sizing (aka Affinity Estimation) is based upon the need to estimate things quickly without necessarily having all the details available that you usually might require. Here are some examples of how T-Shirt Sizing can be use:
......@@ -240,7 +240,7 @@ This 4 step process allows the Development Team to tackle many hundreds of user
Regardless if you are using Estimation Poker, or T-Shirt Sizing, the Cone of Uncertainty still applies. Be aware that using T-Shirt Sizing early in the process will produce estimates with higher variability.
![ConeTShirtPoker.jpg](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/ConeTShirtPoker.jpg)Depending on what you are challenged with estimating, choose the right estimation method:
![ConeTShirtPoker.jpg](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/ConeTShirtPoker.jpg)Depending on what you are challenged with estimating, choose the right estimation method:
* Roadmap Planning =\> Use T-Shirt Sizing
* Release Planning =\> Use T-Shirt Sizing or Estimation Poker, depending on the number of user stories
......@@ -254,7 +254,7 @@ The estimation team size is determined by the Agile Implementation Team size, wh
Sometimes organizations think that adding more people to the estimation effort will make the estimate better, but that is a commonly accepted fallacy. Larger teams do not produce better estimates:
![Estimation Accuracy](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/EstimateAccuracy.jpg){width="600" height="377"}
![Estimation Accuracy](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/EstimateAccuracy.jpg){width="600" height="377"}
**Estimation accuracy actually decreases with increasing team size.**
......@@ -264,7 +264,7 @@ It is worthwhile pointing out, that sports teams are organized around this size
What is important to understand, both for estimation efficiency as well as team dynamics, is the following:
![Team Dynamics](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/TeamDynamics.jpg)
![Team Dynamics](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/TeamDynamics.jpg)
The bigger the team, the harder it is to effectively communicate, estimate, and come to consensus. The bigger the team, the more likely something will fall through the cracks because of miscommunication. Because most of our PS engagements are conducted remotely, this problem is amplified even more.
......@@ -274,13 +274,13 @@ This challenge of ever increasing communication paths with larger teams is also
Velocity is the rate at which the Development Team can reliably deliver story points (usually packaged into time boxed sprints and resulting in a working product increment).
![Velocity Table](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/Velocity.jpg)
![Velocity Table](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/Velocity.jpg)
## Estimates Self-Correct
Using Estimation Poker, estimation variability decreases usually over the course of the first 4 to 6 sprints. I have rarely seen stable teams that did not achieve fairly accurate estimates after working together for 5 to 6 sprints.
![Estimation Accuracty](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/EstimationAccuracySelfCorrect.jpg)
![Estimation Accuracty](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/EstimationAccuracySelfCorrect.jpg)
Pleases note that "stable teams" is key here – teams need to be stable, meaning team members need to know each other, have worked with each other, and successfully formed a team – following the standard "forming–storming–norming–performing" model of group development, first proposed by [Bruce Tuckman in 1965](https://en.wikipedia.org/wiki/Tuckman's_stages_of_group_development).
......@@ -290,7 +290,7 @@ These phases are all necessary and inevitable in order for the team to grow, to
Once a Implementation Team has gone through the "forming–storming–norming–performing" process, team velocity is established. Estimation accuracy and predictable velocity allow for longer term forecasting.
![Velocity Over Time](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/good-estimation-techniques/Velocity-Forecast.jpg)
![Velocity Over Time](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/good-estimation-techniques/Velocity-Forecast.jpg)
**Simply put, if your product backlog contains 450 user stories representing 2,400 story point and your Development Team is delivering at a steady velocity of 60 story points for every 2 week sprint, you are able to predict that the rest of the project will take another 40 sprints, which equals 80 weeks, or roughly 1 ½ years.**
......
......@@ -10,9 +10,9 @@ description: "Learn about the core pieces to iteration 0 of a GitLab PS engageme
3. Agree on working cadences.
4. Align on vision, scope, and goals for your specific team.
[Iteration 0 Fundamentals](iteration-0-fund.png)
![Iteration-0-Fundamentals.png](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/iteration-0-fundamentals/iteration-0-fund.png)
[Iteration Execution](iterative-exec-delivery.png)
![Iteration-Execution.png](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/iteration-0-fundamentals/iterative-exec-delivery.png)
## Engagement Planning
......@@ -23,9 +23,9 @@ Starts at the EM>PS Delivery Transition and continues through the Stakeholder Pl
3. Define [Definition of Done (DoD)](../definition-of-done/_index.md) and, if needed, the [Definition of Ready (DoR)](../definition-of-ready/_index.md).
4. Understand constraints, impediments and risks for your specific team.
[Team Norms](align-team-norms.png)
![Team-Norms.png](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/iteration-0-fundamentals/align-team-norms.png)
[Orient Team](orient-roles-responsibilities.png)
![Orient-Team.png](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/iteration-0-fundamentals/orient-roles-responsibilities.png)
## Setup of Technical and Business Foundation
......
......@@ -9,7 +9,7 @@ A reminder to [think big in discovery](../discovery/_index.md) and consider [tea
For **Transformational planning** throughout iterations, please [reference here.](../iteration-planning-per-service-offering/_index.md).
[Guidelines for PSDM management](../../_index.md#guidelines-for-psdm)
[Guidelines for PSDM management](../_index.md#guidelines-for-psdm)
## EM>PS Transition
......@@ -57,10 +57,10 @@ If you do not have ZenDesk light (Read-Only) open an [Access Request](https://gi
### Creating a ZenDesk Note for Support
1. Find the relevant org `.yaml` find in the [Repository](https://gitlab.com/gitlab-com/support/zendesk-global/organizations/-/tree/master/organizations) by [Searching](https://gitlab.com/search?search=&nav_source=navbar&project_id=27675679&group_id=78867384&search_code=true&repository_ref=master) for the Customer Name (It will be a hash, followed by the name in Salesforce).
![image](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/iteration-0/Zen-search.png)
![image](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/iteration-0/Zen-search.png)
1. Create a new Merge Request by Selecting the YAML from Search. Then `Edit > Open in Web IDE`
![image](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/iteration-0/edit-yaml.png)
![image](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/iteration-0/edit-yaml.png)
1. Add the block below after notes starting with a pipe "|" (this Character indicates a multi line entry). The fields should be spaced 1 tab from notes.
Include the details below and anything else that would be helpful for support to know when engaging the customer. If notes content already exists append this to it to include both.
......@@ -82,7 +82,7 @@ Include the details below and anything else that would be helpful for support to
```
1. Commit your changes by clicking the Source Control Button (noted with 1 change) > The drop down arrow > Create new branch and commit.
![image](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/iteration-0/newmr.jpg)
![image](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/iteration-0/newmr.jpg)
1. Hit Enter to accept the default branch name (Should by a combination with your user name)
......
......@@ -5,9 +5,9 @@ description: "Learn about how to schedule iterations in a PS engagement."
## Cadence Planning
![1 week iteration](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/iteration-scheduling/one-week-iteration.png)
![1 week iteration](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/iteration-scheduling/one-week-iteration.png)
![2 week iteration](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/iteration-scheduling/two-week-iteration.png)
![2 week iteration](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/iteration-scheduling/two-week-iteration.png)
Although the above pictures show a one-week and two-week sprint (aka iteration) it is assumed that iteration duration can be adjusted based on customer needs - as long as the duration stays consistent.
......@@ -21,9 +21,9 @@ _2 week iterations are a good target duration to use unless the customer insists
What do you do if you just cannot make it work? Between various stakeholders, locations, time zones, and other challenges, coordination can be difficult. Ultimately, the specific customer situation dictates what needs to be done. For example, working in different time zones might necessitate a flexible approach who works at what hours.
![Time Zone Distributed](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/iteration-scheduling/iteration-timezone-distributed.png)
![Time Zone Distributed](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/iteration-scheduling/iteration-timezone-distributed.png)
![Sample Iteration Calendar](/images/customer-success/professional-services-engineering/processes/professional-services-delivery-methodology/iteration-scheduling/iteration-calendar.png)
![Sample Iteration Calendar](/images/customer-success/professional-services-engineering/professional-services-delivery-methodology/iteration-scheduling/iteration-calendar.png)
It is important to point out that certain meetings really, really, really need to be attended - iteration reviews for example demonstrate to the customer the tangible progress that has been achieved, so it is important that both GitLab and customer stakeholders attend in order to see that progress.
......
---
title: "Professional Services Pre-Sales Methodology"
description: “Discover how GitLab Scopes Professional Services can fit into the Customer Journey during the presales cycle.”
---
## PS Process & Methodology Mapped to the Customer Journey
The Professional Services process and methodology fits within the Customer journey that is supported by Customer Success.Professional Services contributes to the customer journey from the point of **SOW Close** through the **Project Close** phase.
![PS Delivery Customer Journey Flow](/images/professional-services/customer-journey-mapped-ps-process.png)
[Source, GitLab Team Members Only](https://docs.google.com/presentation/d/1eC_ocJkzNkH4Vw3v4Vkd3S58a0NALYxXtnb6BZ7pJdc/edit?usp=sharing)
## PS Process Methodology Stages
The above diagram (slide 4) is meant to describe the Directly Responsible Individuals (DRIs), Activities, Outcomes, and Tools/Collateral for each stage of the methodology. We can also see clear categorization of stages in pre-sales and post-sales phases.
In the linked pages below, you can see a detailed drill down into the steps within each stage that individuals use to perform activities to deliver desired outcomes per each stage. These pages are split by the Phase of the selling process (Pre-sales vs Post-sales).
![Pre-Sales Stages & Steps](/images/professional-services/professional-services-scoping-workflow.png)
## Pre-Sales Overview
The purpose of this page is to document the sales-assisted selling motion used by Professional Services Engagement Managers and Regional Delivery Managers. If you're on a GitLab sales account team looking for information, try these pages on [positioning professional services](/handbook/customer-success/professional-services-engineering/positioning) or [selling professional services](/handbook/customer-success/professional-services-engineering/selling/#custom-scoped-services).
This page will help outline the when and how to get involved with positioning and scoping services, how to estimate, how to use SOW generation software, and the processes to gain approval.
> *Note: Services engagements can take [two forms](/handbook/customer-success/professional-services-engineering/selling). This will focus on the **custom SOW scoping** process, not the Standard SKU process.*
For custom SOWs, the [workflow for SOW creation](/handbook/customer-success/professional-services-engineering/selling/#custom-scoped-services) involves a partnership between the Account Team and the Professional Services Team.
[Source, GitLab Team Members Only](https://docs.google.com/presentation/d/1TOI2aoseBoyWYQC6-xpJVMknEncCNreSFfMvOHO7EBA/edit#slide=id.gbfb62d0c00_0_58)
## 1. Positioning
- **DRI**: Account Team (SAE/AE, SA, CSM)
- **Supported By**: Engagement Manager
### MEDDPICC
Professional services can be positioned when a prospect becomes a customer (e.g. the Land of a new deal) or when an already existing customer is growing their staff or interesting in adopting new features of GitLab (e.g. expansion). The SA, SAE, AE, or CSM (e.g. "Account Team") is primarily responsible for this process, following the [Command of the Message](/handbook/sales/command-of-the-message/) and [MEDDPICC](../../../sales/meddppicc.md) messaging frameworks.
For the larger, more strategic customers PS Engagement Managers tend to get involved earlier in the selling process to help with discovery and provide lessons learned on rollout from past engagements. For the medium sized customers, Engagement managers tend to get involved with account teams when the SFDC stage 4 (Proposal) is achieved.
### PS Opp Qualification
As the overall subscription deal is progressing, the account team should begin to qualify in or out an attached professional services opportunity. They can do this with some [simple scripts](/handbook/customer-success/professional-services-engineering/positioning/#value-of-gitlab-professional-services) to first establish value of professional services. Next they should ask qualifying questions like:
1. How do you plan to execute the upcoming transition onto the GitLab platform?
1. Who will manage this, both from a technical perspective and a change management standpoint?
1. What will that person or people be de-prioritizing to drive this?
1. Have those people worked with the intricacies of such a transition in the past?
1. How do you plan to surface and manage risks throughout the transition period?
If the customer is uncertain to any of these questions, you can assert that it might make sense to bring in the PS Engagement Manager in to scope the engagement as an option to help derisk the rollout of GitLab and maximize the value/impact of the subscription purchase.
### AE Creates PS Only Opp in SFDC
Once its identified that the customer will likely want to engage with professional services, its the responsibility of the Account Team to [get in touch with the Engagement Manager](/handbook/customer-success/professional-services-engineering/engagement-mgmt/#how-to-contact-or-collaborate-with-us).
## 2. Scoping
- **DRI**: Engagement Manager
- **Supported By**: PS Practice, Account Team (SAE/AE, SA, CSM)
### Gather Data
After the [services calculator](https://services-calculator.gitlab.io/) is run by the Account Team, scoping issues and Project Scheduling Intake issues are automatically created and land in the [PS Plan](https://gitlab.com/gitlab-com/customer-success/professional-services-group/ps-plan/-/issues) Project. Using this customer scoping issue and Project Scheduling Intake issue, the engagement manager gathers data asynchronously from the account team. Questions about the potential engagement can sometimes be answered by the Account Team from the discovery that was done already. We want to make sure we avoid asking duplicate questions to the customer. In some cases when the account team cannot provide the level of detail to create an egagement, the EM will meet with the Account team and Customer to ask additional discovery questions to get to a level of detail needed. Once the data has been gathered, the EM will populate the answers to the Project Scheduling Intake issue.
### Create Engagement Estimate
A PS Engagement Estimate spreadsheet used for scoping services. The Engagement Manager uses the [PS engagement estimate spreadsheet](https://docs.google.com/spreadsheets/d/1wkmKhhGyLoxqWCXFtiI99tNgVaEJ-hTQJRwTOsU0j_Y/edit#gid=1815139260) to define the services in scope and estimate the amount of time for each activity. There is a catalog of activities in the [SOW generation automation](https://gitlab.com/services-calculator/services-calculator.gitlab.io) project or a list of services can be found at our [offerings framework](/handbook/customer-success/professional-services-engineering/framework) page.
### Iterate / Review Engagement Estimate
After the first iteration of building detail into the straw-man, the Engagement manager posts a request for review in the [professional services slack channel](/handbook/customer-success/professional-services-engineering/working-with/#slack) to the Account team. Often the Engagement Manager will get on a zoom call with the customer and provide context and gather feedback from the customer.
### Generate SOW
Once the Engagement Manager can get buy in from the account team and/or customer on the size and activities included in the services engagement, the [SOW generation automation](https://gitlab.com/services-calculator/services-calculator.gitlab.io) can be run using the straw-man as an input. The engagement manager is responsible for running this automation which can be done by following the instructions on the readme in the above project.
### Iterate/Review SOW Data
Once the SOW is generated, it is ready for review by the account team. Iteration can occur here but should be minimized if the proper iteration was done on the Straw-man Steps.
### SOW Review/Approval
After one or more rounds of iteration on feedback from the account team, the SOW will be ready for Review and Approval by Sr. Director of Professional Services. The review processes are signaled in the [professional services slack channel](/handbook/customer-success/professional-services-engineering/working-with/#slack) and **at-mention** the GitLab engagement stakeholders.
## 3. Delivery Prep
- **DRI**: Project Manager
- **Supported By**: EM, PM, PSE, TA, Account Team
Once the engagement moves to stage 6, `awaiting signature` in salesforce, the engagement manager schedules an intro meeting between the PM and the customer stakeholder to discuss "how we manage projects at GitLab". During this call, the PM will also discuss resource assignment, and scheduling details. Simultaneously, the PM will schedule an internal transition meeting with the EM, PM, PSE, TA, and Account Team to review the technical discussions that occurred during the customer scoping meetings. This is a opportunity for the entire team to discuss and disclose the inner workings and dynamics of the customer project team.
### PM Introduction
Engagement managers introduce the PS Project Manager as they are in contract with the customer during the scoping exercise and are perfectly positioned to do so.
### Resource Identification
The PS Proejct Coodinator, working closely with the Regional Delivery Manager, will identify the best resource to deliver the project based on skillset, timezone, personality, tenure, and availability.
### Project Prep call
This is a call between the customer stakeholder and the PS Project Manager to discuss HOW we work. Where we track project progress, what status report will look like, what the meeting cadence might be, a review of the contract terms that affect how we work such as minimum hours per week, expiration dates, delay language, and most importantly, how to achieve mutual agreement with the customer on a preliminary project schedule, prior to the kick-off call which includes the entire project team.
Check out the PS Delivery methodology to understand the details around pre-sales handoff to the delivery team, to ensure a successful relationship and productive engagement.
### 4. SOW Execution/Close
- **DRI** Engagement Manager
- **Supported By**: PS Leader, Sr. PSE, SAE/AE, Legal, Finance, Deal Desk
Finance Approval
The engagement manager can kick off the finance approval process in Salesforce. TODO: Add more details.
### Legal Approval
The Engagement Manager is responsible for creating a Legal Approval Case in Salesforce from the associated opportunity. This process often involves reviewing and accepting redlines from the customer and from our legal team. The source of truth for the latest SOW is managed in the SFDC legal case. The EM should coordinate who "holds the pen" to ensure we maintain version control of the SOW with the latest redlines.
### Customer Signature
Once the SOW has been approved by PS leadership, Legal and Revenue, the account team is owns the process of executing the SOW. They should take the approved SOW from the legal case and route it for signature with the customer.
### Deal Desk updates SFDC
Once the SOW is fully executed, the deal desk team updates the Salesforce PS-Only opportunity to `closed-won`.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment