Tradeshift Shiftology - Project Implementation
Tradeshift Professional Services has prepared this document to provide an overview of thestandard implementation model that is employed for the delivery of the Tradeshift solutions

Restricted Use
This document is of restricted use and must not be copied, reproduced, distributed, passed or cited (in whole or inpart) to any other parties at any time without prior consent from Tradeshift.

Tradeshift Shiftology - Project Implementation

Table of Contents
Revision History

4

1 Introduction

5

1.1 Audience

6

2 The Shiftology Way

6

2.3 Implementation Releases

11

2.3.1 What does this really mean?

12

2.4 Implementation Release - Phases & Milestones

13

2.4.1 Plan

16

2.4.2 Define & Design17

2.4.3 Build & Configure

18

2.4.4 Test & Train

18

UAT Issue Severity:19

2.4.5 Launch

22

2.4.6 Hypercare

22

2.5 Tradeshift Engage as our first Implementation

23

2.6 Project Deliverables

25

2.6.1 Project Plan

26

2.6.2 Solution Description Document26

2.6.3 Training Materials

26

2.6.4 Sign-off Documents

27

3 Tradeshift Project Team27

3.1 Project Delivery Team27

3.1.0 Project Advisor

27

3.1.1 Engagement Manager

28

3.1.2 Solution Architects

28

3.1.3 Solution Consultants

29

4 Your Project Team

Restricted Use

30

Page 2 of 37

Tradeshift Shiftology - Project Implementation

4.1 Project Sponsor

30

4.2 Project Manager

30

4.3 Business Subject Matter Expert(s)30

4.4 Seller Workflow Owners

31

4.5 ERP Subject Matter Expert(s)31

4.6 Technical Lead(s)31

5 Responsibilities, Governance, Risk & Budget Management
5.1 RACI Matrices

32
32

RACI - Project Professional Services Team - Activities and Deliverables

32

5.2 Governance Model36

5.3 Tradeshift Risk Management36

5.4 Tradeshift Project Budget

37

6 Change Request Process

37

7 New Product Feature Process

38

8 Bug Process

38

9 CSAT Process

38

10 Lessons Learned

39

11 Collaboration with other Customer facing teams

39

12 Questions

41

Restricted Use

Page 3 of 37

Tradeshift Shiftology - Project Implementation

1 Introduction

This document provides a detailed overview of Tradeshift’s Implementation Methodology, the “Tradeshift
Shiftology”. Tradeshift’s Shiftology is a robust blend of best practices well-known methodologies including
PRINCE2©, PMI’s PMBOK©, Scrum and Half Double, supplemented by the assessment of institutions like
Technology Services Industry Association (TSIA) and input from Tradeshift’s experienced Project Managers(Engagement Managers) and Solution Architects and Consultants. As a result we have a methodology that
adapts and embraces change as required by forces such as Tradeshift vision, dynamic supply chains andmarket conditions.
Our Project Management Office works closely with our Professional Services and Customer Value teams
globally to gather feedback and lessons from previous projects to ensure there is continual process
improvement. This ensures we are building maturity in our approaches and capability to deliver successfulprojects with our Customers. Recent iterations have resulted in a focus around process excellence andscalability which are correlated with improved results from our Customer Satisfaction Surveys (CSAT)
across our ongoing projects.
Below we will describe in more detail our Shiftology with a focus on the release strategy, phases, roles,deliverables, governance, and activities carried out over the course of a successful deployment.

Restricted Use

Page 4 of 37

Tradeshift Shiftology - Project Implementation

1.1 Audience

The primary audience is potential and existing customers (understood as the company that uses Tradeshift
Platform and Solutions) with an interest to learn more about how Tradeshift delivers successful projects.
The secondary audience is Tradeshift’s partners and Tradeshift teams outside the customer-facing teams.

2 The Shiftology Way
Tradeshift Shiftology focuses on delivering real value with impact within your organization while balancing
speed, quality, and risk. With this approach Tradeshift Professional Services can:
●
●
●
●
●
●
●

Deliver initial value within first few weeks
Fulfill business case in manageable releases
Prioritize value, speed & quality over scope
Reduce focus on deliverables and enhance focus on impact
Provide production experience early & keep forward momentum
Build success and confidence strategically within your organization
Run multiple releases simultaneously and provide best practices leadership

Restricted Use

Page 5 of 37

Tradeshift Shiftology - Project Implementation

2.1 The Tradeshift Shiftology Core Principles
Our Shiftology is aligned with key principles that drive our Professional Services strategy, represented by
the following four main pillars:
●

●

●

●

Project & Process Excellence○ Promoting standardization and aligning expectations across different regions, projects andCustomers by using best practices and continually challenging the status quo.
○ Demonstrate strong project leadership, and focus on the people to ensure valuable impact isachieved.
Scalability○ Adding value quicker, with greater consistency and achieving improved outcomes byleveraging existing knowledge and optimizing tools & templates from previous successful
implementations.
○ Maintain project flow through clear and frequent interaction.
Visibility○ Collaboratively reviewing and discussing results, risks & issues as early as possible internallyas with Customers.
○ Align the outcomes with the business objectives so results are visible to the stakeholders.
Success○ Nurture the feeling of accomplishment, ensuring that the teams are successful in what they
are doing and that project outcomes and objectives are achieved and celebrated.

Restricted Use

Page 6 of 37

Tradeshift Shiftology - Project Implementation

2.1 Project & Process Excellence
Our concept of excellence is represented by how much we are capable of bringing a positive impact to ourcustomer, quickly. We want to drive behavioral change and business impact by understanding (andsometimes challenging!) the current business processes. To reduce focus on just deliverables and enhance
focus on outcomes is part of our philosophy. To gather a project team that can bring the right mix ofleadership and business expertise to the field is a vital part of building a successful project.
In this line, Tradeshift recommends focusing on simplifying and standardizing processes as much as
possible across your organization to truly support supplier adoption and train users in the value ofTradeshift as early as possible. With this there is opportunity to provide improved experiences and help toboost digital change.
As an example and to support and standardized delivery, Tradeshift has developed implementation
playbooks that serve as a detail-oriented recipe for implementation success. They comprise allconfiguration and integration tasks and follow our best practice recommendations. Our Playbook
approach puts focus not just on achieving a successful Go-Live of the solutions, but is also a key building
block to support forthcoming Time-to-Value in operations. Time-to-value is a measure of our capability totruly engage with your suppliers via the Tradeshift Network and smartly collaborate with them to drive
network success.
2.2 Scalability
While the Tradeshift Shiftology provides the project controls and rigor required to manage successprojects, the Tradeshift Implementations Playbooks are the work breakdown structure that drives ourdelivery. These have been positioned as project artifacts that our Professional Services teams will tailor toyour implementation ensuring key details of the design and configuration considers the best practicerecommendations and document where any required or chosen deviations that might exist in the design.
These playbooks allow us to efficiently and concisely step through the design and configuration ensuring
the consistency and predictability of projects and their outcomes.

Restricted Use

Page 7 of 37

Tradeshift Shiftology - Project Implementation

In addition to our playbooks, Tradeshift will leverage an extensive catalog of project templates, which aremaintained by Professional Services following Customer implementations. Project templates are regularly
shared and reviewed across our global professional services teams to ensure the content and approaches
support and promote project success across the regions we support our Customers in.
During Customer projects, the Tradeshift Professional Services will maintain a Lesson Learned document
capture insights gained during the project that can be usefully applied on to our project approach, tools,
documents to better support future roll-outs. The Lesson Learned document is in most cases created,shared and discussed with our Customers before we close a Release.
2.3 Visibility
Throughout the project the Tradeshift Project Manager (Engagement Manager) will work closely with your
Project Manager to ensure good visibility of the progress of the project with specific focus on costs andprogression and deliverables and the plan. Weekly meetings and supporting status reports provide a
consistent and timely view of project progress and ensure that any risks or issues are identified andmitigated or resolved in a timely manner.
To further support these project status reports, Tradeshift utilizes a Professional Service Automation (PSA)
tool - built on top of Salesforce - which enforces high project excellence and maintains the key project data
elements to provide visibility to all project stakeholders. Project financials, project tasks, resources andtimelines are entered and managed within the tool so that at regular intervals, the Tradeshift Engagement
Manager will analyze the budgeted costs (based on estimated number of hours for scoped tasks) with theactual costs (based on the actual hours spent on the project). A cost to completion forecast can then be
calculated based on remaining scheduled activities and their associated cost estimate for each activity.

Restricted Use

Page 8 of 37

Tradeshift Shiftology - Project Implementation

2.4 SuccessFirstly, we believe that project success is highly correlated with personal and team success. From Shiftology weencourage our project team members to “own their shift”, in other words, to show ownership and leadership nomatter the role in the project organization. Every voice in the team matters and we invest in empowering our
project team members by giving them the elements to succeed in their project execution, from learning anddeveloping opportunities to the availability of scalability tools. We strive to have them engage every day andlove what they do, and be vocal about their project successes and challenges.

Secondly, Project success is best determined through measurement of outcomes against the goals of the
project. Often this success might come in stages where phases or releases implement the system in new
regions or expands the breadth of features available to users. Therefore it is important to be able to trackprogress against these outcomes over time as the project progresses. To support this the Tradeshift
Shiftology leverages our Value Ladder to represent your organizations digital journey and align theavailable business outcomes associated with each step of the ladder.

…

Restricted Use

Page 9 of 37

Tradeshift Shiftology - Project Implementation

2.3 Implementation Releases
Since the philosophy of Tradeshift Professional Services is to establish a forward progression and deliver
impact as quickly as possible, the complete scope of functionality and solutions may be segmented into
Releases. A Release can be composed of certain modules, countries, or solutions, but the general concept
is to deliver and focus efforts on a subset of the entire solution into smaller chunks.
Any proposed release strategy would be collaborated and agreed jointly between Tradeshift and thecustomer. The Release strategy is closely related to the business value and outcomes contained within thebusiness case and your position on the Value Ladder. In all cases, the implementation of the Tradeshift
Engage Core Release marks the project starting point.

Restricted Use

Page 10 of 37

Tradeshift Shiftology - Project Implementation

2.3.1 What does this really mean?
If for instance the entire scope of delivering a Tradeshift Pay (Payment Automation) solution spanned
multiple countries and regions, a certain release strategy may be agreed as of to group, order andprioritize countries that have high volumes and business readiness to use the solution, after deploying thevalue of Tradeshift Pay (Engage functionality) globally first.
● Release 1 - Tradeshift Pay (Engage functionalities) - Global outreach● Release 2 - Tradeshift Pay - European Countries● Release 3 - Tradeshift Pay - North America● Release 4 - Tradeshift Pay - Asia Pacific● Release X ...

Each implementation is tailored to you since the overall goal is to align the implementation plan to yourorganization’s requirements and goals.
Our releases are in turn divided by phases, which are completed by milestones. As we progress in oursolution implementation journey, we phase it in a way it is methodologically compliant and more
importantly, brings value to your network first. For example, we deliver our core PAY release (featuring theEngage functionality) in an accelerated manner via a fast track wave. In parallel, we make space toaccommodate the following regular releases to fulfill their scope in the smarter way possible.

Restricted Use

Page 11 of 37

Tradeshift Shiftology - Project Implementation

2.4 Implementation Release - Phases & Milestones
Every defined Release within the Tradeshift implementation will contain a structured methodology toproperly plan and collaborate regarding the proposed functionality for production usage. The phases
follow a typical project approach and consist of the following phases:● Plan● Define & Design● Build & Configure● Test & Train● Launch● Hypercare

Within these Phases, every project will have pre-defined milestones. Key milestones are signed off by
Tradeshift and Customer and will secure alignment, expectation management and documentation to build
the foundation for a successful project.
The process for sign off is preceded by a review meeting. We would usually take one of our weekly
meetings to celebrate it. During this meeting all phase deliverables are reviewed and assessed forcompleteness. Where anything is outstanding the respective project managers would agree a plan toresolve. This might result in one of 2 outcomes:

Restricted Use

Page 12 of 37

Tradeshift Shiftology - Project Implementation

1. Project delay and a focus on resolving the outstanding work. In which case, we would not be submitted
any deliverables for sign off.
2. Project proceeds with the outstanding deliverables subject to a work off plan agreed between theparties.
So come the time for sign off, either through successful completion of all deliverables or through #2, bothparties will understand what is being signed off and what is not.
These milestones also serve as an important internal tool to articulate Customer and Sellers
implementation project plans, leverage knowledge and prepare other parts of Tradeshift - like Tradeshift
Support, Network Value, Customer Success as well as the product teams - once the project is live andmoved into operation.

Restricted Use

Page 13 of 37

Tradeshift Shiftology - Project Implementation

Tradeshift uses these Milestones:
Milestone

Description

Acceptance Criteria

M0

Release Start - Sales HandoverStatement of Work (SoW) is signed. Commencementof Project Release and mobilization of project teams
after internal Hand Over

M1

Release Kicked Off

End of Mobilisation is signaled by the Kick-Off
Workshop

M2

Release Defined and Designed

Customer Sign-off of Solution Description. Completionof Define & Design Phase

M3

Release Build & Configure
Completed

Completion of Build & Configure Phase

M4

Release UAT and Training
Completed

Customer Sign-off of User Acceptance Test (UAT)M5

Release Go-Live

Production migration and readiness completed
Customer Sign-off of Release Go-live (1st. production
transaction is Live)

M6

Release Closure

Customer Sign- off of Hypercare period ended andRelease completion sign off by Customer.

2.4.1 Plan
Upon execution of contracts and commencement of the project, the assigned Tradeshift
Engagement Manager will start the basic framework of planning the structure of the solutiondelivery. Within this phase initial preparations of kick-off dates and resource plans will be alignedby both Parties. Any necessary team introductions, project tools, documents, and frequency of
meetings will be established and confirmed for the project duration. Additional data collection or
project prerequisites may be collected during this planning and preparation period if necessary.
Key activities:● Appointment of project sponsors, steering group and project team
● Develop detailed project plan
● Initiate risk assessment process
Deliverables:● Expected project plan
● Project kick-off
Restricted Use

Page 14 of 37

Tradeshift Shiftology - Project Implementation

Your contribution:● Provision of sufficient Customer project resources● Availability of management resources for Steering Group secured● Preparation of data and scope review
Main Objective: Introduce team members, plan the project structure jointly, and start the project.

2.4.2 Define & Design
The Define & Design phase of the release focuses on specifying the detailed configuration structurethat will be established to achieve the desired business results. Within this phase, our team
activates our Implementation Playbooks that, in accordance with the value proposition andsolutions we are working on, follow a recipe-like model that pursues implementation accuracy andrepeatability. There will also be recurring integration meetings to discuss file formats, mappings,
and connection options. The end result of the conversations will be documented in the core solution
and integration deliverables. Additional impact on any project scope, resourcing, or timelines will bejointly assessed by the respective Project Managers. Sign-off and approvals are mandatory for thesolution and integration design in order to proceed to the next phase within the release.
Key activities:● Finalize implementation design● Complete final version of solution description document● Review and agree on project plan baseline● Create Test Plan (SIT & UAT)
Deliverables:● Execute Design Workshops● Signature on solution description documentation● Setting the final project schedule as baseline for project● Share standard Test scenariosYour contribution:● Provision of sufficient phase project resource● Clear internal alignment and decision-making process to guarantee Design
Main Objective: Validate scope, and identify action and execution list, Finalize open items,
document solution & integration(s), obtain sign-off of M2 Milestone and, in certain cases, as when
implementing Buy, start Supplier Onboarding.

Restricted Use

Page 15 of 37

Tradeshift Shiftology - Project Implementation

2.4.3 Build & Configure
In the Build & Configure phase, Tradeshift and the Customer will execute the agreed-upon tasks inthe project plan to configure the solution and integrations. Any technical configurations or setups
are established while the Customer functional teams prepare any relevant test scripts for execution
in the testing phases. Throughout this period, the respective teams may establish certain
checkpoints to validate the configured solution against the approved documented specifications.
After successful completion of the defined work activities, the system will have the necessary data
loaded to prepare for testing in the next phase.
Key activities:● Implementation of agreed design documented in the solution description document● Preparation of test plan, test documents and testing team
Deliverables:● Implementation on Tradeshift and customer side completed● All systems and components ready for testing● Shared test plan finalizedYour contribution:● Provision of sufficient phase project resources● Complete and approve set of test data provided● List of test team users

Main Objective: Deliver a Test system per the documented, signed-off specifications and sign-off ofM3 Milestone.

2.4.4 Test & Train
As part of Test preparation, Tradeshift and the Customer will go through the scope of testing andTradeshift will provide suggested test cases (also referred to as scenarios) to the Customer. The test
objectives will be defined based on the agreed project deliveries out of the Statement of Work andfor the defined Release.

Restricted Use

Page 16 of 37

Tradeshift Shiftology - Project Implementation

Within the Test phase of the project, there are several types of testing that will occur. The first typeof testing that is performed by Tradeshift and the Customer is referred to as Unit Testing, that
happens during the Build phase. During the Unit Testing period, the Tradeshift team will test theindividual components of the solution to ensure the desired business result is captured anddocumented. In the event any bugs are found, the Tradeshift team will follow the bug process
defined in this document.
After the completion of Unit Testing, the Tradeshift Integration Architect along with the Customer
ERP Subject Matter Expert and/or Technical Lead will perform the identified integration tests
against the test plan. During this period of Systems Integration Testing (SIT), connection and datatransfer will be validated against the documented specifications. The completion of Unit Testing
and System Integration Testing then marks the system readiness and initiation for training to occur.
Training will be given as indicated by the scope of work either on-site or remotely for the modules
included in the release. The users will gain the knowledge and experience needed to execute thelast period of testing which is User Acceptance Testing or UAT.
During User Acceptance Testing, the Customer will be able to test the system and validate test
cases. In this period, the Customer UAT users will report any issues to the Tradeshift Engagement
Manager by adding them to a shared issue log where the Engagement Manager can track open
items. The Engagement Manager will then report on the progress of these items in the UAT
meetings so that resolution dates, workarounds, and risks can be jointly tracked. After items areresolved there will be a short period of regression testing required by the users to validate
functionality. Successful completion of UAT is then initiated by Customer sign-off so that the
preparations for production cutover can commence. A UAT signed milestone represents then theofficial “Definition of Ready” - the system is cleared to be migrated to Production

UAT Issue Severity:
The table below describes the issue severity that will be assigned to issues related to
implementation that are raised during UAT, in the event we find implementation defects to solve.
Note that Product Bugs and Product Feature Requests are not implementation defects by nature,thus will be handled via their respective processes and times.

Severity Level

Description

Critical / Blocker (S1)

A defect that prevents theaccomplishment of an essential systemcapability. Jeopardizes / breaches
security. It can imminently cause

Restricted Use

Examples*Page 17 of 37-

Integration channel
broken, no protocols
transmission orTradeshift Shiftology - Project Implementation

economic loss or commercial damage tothe customer. There is no workaroundavailable to guarantee normal
operations or with a workaround, butwith an unacceptable additional cost ofownership. The defect causes total
failure of the implementation or
unrecoverable data loss.
Go Live justification:
The existence of just one (1) of theseissues prevents M5: Go Live sign off.

-

-

-

High (S2)A defect that does not prevent theaccomplishment of an essential systemcapability. It has a known acceptedworkable workaround. The system isfunctional but a major component orfunction is missing or fails to function.
Go Live justification:
An accumulation of these issues might
prevent Go Live and/or require a
Mitigation plan.

--

Medium (S3)A defect that does not affect the system
operation but is required to be fixed. In
general a workaround exists and if not,the impairment is slight.
Go Live justification:
There is no association with preventing
Go LiveLow (S4)

None of the above. A “nice to have”
addition that is required to be logged as
it can resurface down the road andcould add additional business value.

Restricted Use

Page 18 of 37

documents flow
Broken App, App logic
failure or feature that
affects all documents
flow
Mandatory document
information not
mapped correctly in all
scoped businessdocuments
Platform security
breach
Product Bug that
impairs critical function
Product Feature thatprovides critical
function

Mapping failure, with aworkaround.
Non mandatory
business firewall rules
validation, with aworkaroundSome documents fails
to integrate, with aworkaround
Product Bug that
impairs major function
Product Feature thatprovides major function
is not available

Tradeshift Shiftology - Project Implementation

Go Live justification:
There is no association at all withpreventing Go Live* For illustration purposes only, not an exhaustive list.
Important notes to consider:● Issue severity to be applied to the issues resulting from approved UAT test cases only.
● Severity is not applied unilaterally. It demands an agreement between Customer andTradeshift.
● Resolution times provided are aligned with the issue severity and the proposed resolution
plan. These discussions and any prioritization of focus will be agreed between Customer
and Tradeshift.
● Issues that turn out to be identified as Product Bugs or Feature Requests are subject to betreated by their correspondent processes.
Finally during this phase, preparations for handing over to the Tradeshift’s post-implementation
teams are intensified.
Key activities:● Enablement of test teams● Training and test team handover● Tradeshift support user acceptance test utilizing Tradeshifts agreed cooperation platforms● Preparation of system cutover/launch
Deliverables:● Successful completion of all test cases● Signed UAT test acceptance based on agreed test plan
● Post Implementation teams official intro (Customer Success / Support)● Agreed Cutover Plan and Hypercare Plan
● Completion of Milestone M4
Your contribution:● Availability of test team● Sharp eye to perform any relevant business case to be included in this release

Main Objective: Internally test the system, train the identified users, and execute and sign-off on
UAT and the M4 Milestone.

Restricted Use

Page 19 of 37

Tradeshift Shiftology - Project Implementation

2.4.5 Launch
After the completion of UAT, both Parties will identify any configurations or data that needs to be
migrated to the production environment(s) and agree on a cutover date. Upon successful migrationof the items, the business will be enabled for production usage of the system. As an example for
PAY, the go-live milestone is signaled by the first successful end-to-end transaction created in
Tradeshift and interfaced to the Customer’s ERP.
Key activities:● Sandbox to production Migration● Go Live
Deliverables:● Successful system launch● Signature of project launched (Go Live)Your contribution:● Move your internal components to production● Sign Go Live
Main Objective: Go-live and process transactions in the system

2.4.6 Hypercare
During the period of Hypercare, the Tradeshift Project Delivery team will remain engaged alongside
Tradeshift Support and Customer Success teams to resolve any reported issues. In addition,
Hypercare ends automatically after the agreed period in the Statement of Work (typically 4 weeks
for the First Release - Global Solution, but can be modified upon agreement during project
execution and signed off together upon Cutover/Go Live). At that time the solution is expected to bestable, transactions flowing and also expected that the post-implementation teams have obtained
full ownership and control of the relationship with our customer. The Project team will also
disengage when this happens.

Key activities:● Hypercare issues handling● Handover to Tradeshift post-implementation teams while professional services
accompanied project hypercare● Customer is assisted on Tradeshift support and customer success processes

Restricted Use

Page 20 of 37

Tradeshift Shiftology - Project Implementation

Deliverables:● Hypercare monitoring documentation log, with no blocker / critical issues identified(according with same definitions presented in table UAT Issue Severity)● Handover to post hypercare / operations mode
● Sign off hypercare end
Your contribution:● Post project process owner and main contact persons● Close a project release
Main Objective: Technical solution is stable according to use cases implemented, Operations teams
take control and the project release is closed

2.5 Tradeshift Engage as our first Implementation
We start every Tradeshift project implementing Tradeshift Engage.
Our aim is to bring Engage live as early as within 9-10 weeks from project kick off, as depicted in the indicative
project timeline below. Note that this timeline considers that the 3 first weeks are devoted to a Full project (multiple
releases/multiple products) Plan phase.
The timeframe will however depend on several factors such as:- The Project Plan modeling, where Engage is part of a multi-product mix implementation- The Customer chosen Integration method,- The Engage related topics and assumptions stated in the Statement of Work (SoW),- The accurate project governance, and- A strong Customer executive mandate to drive Engage as priority.

The TS Engage fast track delivery accelerates within our Shiftology phases, encompassing the following elements:
Phase

Key Activities

Deliverables

Expected Impact

Plan - Kick Off

Tradeshift and Customer
Appointment of Project

Kick Off Preparation call

Project kicked off

Restricted Use

Page 21 of 37

Tradeshift Shiftology - Project Implementation

team

M1: Kick Off session(remote when only Engage
is in Scope)

Tradeshift draftProject
Plan

Customer SMD in good
shape

Customer SMD v1

Proposed Tradeshift
Standard Solution is
feasible and without
critical roadblocks*Customer Integration
Self Serviced Model:

5 design sessions (Up to 4
hours each)

Solution is defined sobuilders can build

Design Workshop

M2: Solution Description
signed off

Expect to see interface
validation beginning in 2
weeks

M3: System (Integrations
and Configurations) ready

Solution is built andbusiness can now test

Tradeshift draft Solution
description with
Integration Requirements,
mappings and systemarchitecture

Solution Description v1

Tradeshift Receive andreview Customer SMD
DataDefine & Design

Customer Produces Mockup files in Tradeshift UBL
Tradeshift offers Solution
Design Advisory / Q&A
Tradeshift Prepare
Sandbox Environment andstart account setup
creation
Customer to start build
integrations*Tradeshift as Integrator
Model
Design Workshop
Collaborating andCompleting the Integration
Specs
Customer’s Sample files
verifications
Build & Configure

Tradeshift to setup
application configurations
Customer to complete
integrations
Tradeshift marks System

Restricted Use

Page 22 of 37

Tradeshift Shiftology - Project Implementation

configuration complete insandbox

Test & Train

Tradeshift and Customer
team to test the end to
end connectivity SIT

System Integration Test
(SIT) signed off“Train the Trainer”
deliveredComplete UAT and
Cutover activities

M4: User Acceptance Test
(UAT) signed off

Customer to provide
cleansed historical data
and SMD Data

Transactions with realbusiness data flow end to
end in Sandbox
environment
First suppliers contacted

Tradeshift to Conduct“Train the Trainer” Session
LaunchMoving System to
Production

M5: Go Live!

1st Supplier adopts
Engage (clicks email in
Campaign and has accessto the product)

M6: Release Closure

Suppliers using Engage
ramping up

Complete upload of
historical data in
Production
Campaigns are sent
Hypercare

Project team to provide
support for Hypercare
periodNetwork team execute
Supplier Onboarding PlanEngage Release handed
over to operations

No showstoppers related
to the Business Cases
included in Signed Off
UAT.

In order to successfully deliver TS Engage, we allocate the right resources mix to our dedicated Engage
workstream during the project set up. Moreover, we will guide your team using our Playbook collateral Engage Edition, specifying the implementation tasks, resources to consult and recommended practices,from both the project management and the technical perspectives.

2.6 Project Deliverables
For the defined project, the following deliverables are documented and utilized for executing during thecourse of the implementation and ultimately transitioned to the relevant teams for support of the solution.

Restricted Use

Page 23 of 37

Tradeshift Shiftology - Project Implementation

2.6.1 Project Plan
The project plan will contain the specific work breakdown and task details for both Tradeshift and yourorganization, for your Tradeshift implementation. Initially, a draft project delivery plan is utilized as a basis
point for discussion, planning, and estimating. Once the project starts, the respective project leaders will
work to finalize the plan with the specific dates and tasks that each party needs to execute. The level ofdetail will depend on the mutual agreement and we will always strive to focus on business case impact
instead of only plain deliverables. The project plan will be a living document throughout theimplementation since tasks may need to be added, changed, or updated. Being said that, the overall
Milestones and scope are locked by the agreement in the M2 Milestone, including the Baseline plan.

2.6.2 Solution Description Document
One of the main artifacts that outlines the functional, technical and business processes is the Solution
Description Document (SDD). The SDD will provide essential solution information to Tradeshift Support,
Tradeshift Seller Onboarding, Tradeshift Customer Success team and for you.
During the Define and Design phase, the SDD is updated at each milestone, shared with the customer andsigned off. Once the project has been delivered successfully and moved to operations, the SDD is updated
once again and shared with all relevant stakeholders. The ownership of the SDD will then move from
Tradeshift’s Professional Services Team to Tradeshift’s Service Delivery Managers.
The SDD consists of core information on how the solution is configured and what are the processes,
validations, and rules. The SDD will hold essential information on the following areas:● Installed apps and modules in scope● Account Setups● Business firewall rules● Configurations and Coding● Documents in scope, e.g. invoices, purchase orders, goods receipts, etc.
● Error handling processes● Supplier onboarding and information● Reporting● The technical specifics for data mappings, formats, and transfer protocols. This is the guide for both
Tradeshift and your organization to document and agree for building integrations between thein-scope Tradeshift solution and your business systems.

2.6.3 Training Materials
Tradeshift typically utilizes a “Train -the -Trainer” approach and standard training materials for thedelivered solution. This training content is reviewed jointly in advance of training with the Customer ProjectManagement team and updated as agreed. The specifics will be listed with the issued Statement of Work.
We will also heavily rely on our Tradeshift University courses (TSU) to be made available within your
Tradeshift platform account. Other Training options are available based on your organization’s needs.

Restricted Use

Page 24 of 37

Tradeshift Shiftology - Project Implementation

2.6.4 Sign-off Documents
Selected milestones will include a sign-off document explaining the deliverables and signed by Tradeshift
and Customer. This secures alignment in the project and documents the momentum and the flow in the
project.

3 Tradeshift Project TeamThe Tradeshift Professional Services’ project team consists of a core group of people who deliver thein-scope solution.

3.1 Project Delivery TeamThe assigned Project Delivery Team is focused on delivering value to the Buyer side applications andfunctionality. These functions include providing project management, solution design, configuration,
testing, and data integration as applicable for the solution scope. The details of each of the roles andresponsibilities of this team can be found below.

3.1.0 Project Advisor

With each project, Tradeshift provides a Project Advisor (PA) - typically with many years ofexperience in the industry as well as Tradeshift - who is assigned to monitor the project progression

Restricted Use

Page 25 of 37

Tradeshift Shiftology - Project Implementationand team dynamics. The identified individual will be involved in any Steering Group meetings andadditionally act as an escalation point if there are any concerns or issues that need to be raised.
The Project Advisor will partner with your identified stakeholders to ensure alignment on executive
support, leadership, and overall confidence with the solution deployment.

3.1.1 Engagement Manager
The provided Tradeshift Engagement Manager (EM) maintains overall responsibility for ensuring
successful delivery and deployment of the project scope. The Engagement Manager will manage
the Tradeshift Project delivery team resources, focus on project execution, and communications
with your assigned Project Manager.
Additional responsibilities and deliverables are listed below:
●
●
●
●
●
●
●
●
●
●
●
●

Plan and prepare material for the Kick-off workshops
Prepare communications and discussions with Customer assign project team members
Present status and progress to stakeholders and process owners
Setup and define meeting cadences for project team meetings
Manage Tradeshift resources and coordinate activities between team(s)Guide and report results from the testing cycles
Obtain proper approval and sign-offs for documented solution and change orders
Identifies risks, bottlenecks, or concerns through the course of deployment
Facilitates the process and discussion in any raised Change Requests
Facilitates and supports Tradeshift education sessions
Ensures project deliverables, milestones, and objectives are met
Deliverables:○ Workshop Agenda(s)○ Project Plan
○ Production Cutover Plan
○ Risk and Issue Log○ UAT logs
○ Status Reports○ Sign Off documentation

3.1.2 Solution Architects
The Tradeshift Solution Architect (SA) provides process and solution subject matter expertise forthe functional and business teams. Their role is to provide solution options, facilitate conversations
on matters related to business outcomes, and architect the configuration and integration elements
for the Tradeshift solution. Furthermore, the SA will lead implementation technical conversations
related to security, architecture, or authentication protocols.
Additional responsibilities and deliverables are listed below:

Restricted Use

Page 26 of 37

Tradeshift Shiftology - Project Implementation

●
●
●
●
●
●

Provide best in class solution options and knowledge for business processes
Prepare solution material for any defined workshops
Document any required data mappings required for implementation
Provides training education services based on the solution set in scope
Facilitates and remedies any reported defects during UAT
Deliverables:○ Design Workshop presentation(s)○ Solution Description Document○ Integration Documentation

3.1.3 Solution Consultants
The Solution Consultants (SC) supply systems integration and configuration expertise for the dataand parameters required to support the business solution. This role provides direction in
configuration, mapping, conversions, and extraction of data to or from the Tradeshift platform. In
addition to supporting integration discussions, the Solution Consultant is also prepared to be
involved with any surrounding technical conversations related to security, architecture, orauthentication protocols.
Additional responsibilities and deliverables are listed below:
●
●
●
●
●
●
●

Restricted Use

Engage in necessary technical conversations to enable data flows
Perform Unit tests and System Integration testing to validate data fields
Enable and configure integration configuration for the approved data specification(s)Configures the solution(s) to the documented and approved specifications
Resolve configuration, data or integration issues reported during UAT
Promotes and migrates solution configurations for the defined go-live(s) and releases
Deliverables:○ Solution Configuration(s)○ System Integration(s)Page 27 of 37

Tradeshift Shiftology - Project Implementation

4 Your Project Team

4.1 Project Sponsor
The appointed Customer Project sponsor will be engaged to oversee high-level progress of the
deployment, attend steering committee meetings as defined, and help reduce any identified risks orchallenges within the Customer’s organization. The identified individual(s) will partner with theTradeshift Project Sponsor to jointly solve any escalated items or concerns.

4.2 Project Manager
The appointed Project Manager will be the primary point of contact for the project operational tasks
and management of the Customer engaged resource(s). The Tradeshift Engagement Manager will
work closely together with the identified individual to review the project plan(s), report on status,and obtain any necessary approvals.

4.3 Business Subject Matter Expert(s)The appointed Business Subject Matter Expert(s) will help validate and refine the scope of the
future state processes and provide the Tradeshift Project Delivery team the necessary direction forthe desired business outcome(s). These individuals will answer any presenting questions by the

Restricted Use

Page 28 of 37

Tradeshift Shiftology - Project Implementation

Tradeshift team and may be involved with creating test scripts or ultimately testing the solution as
jointly documented.

4.4 Seller Workflow Owners
The Seller Workflow Owners will help provide data and information to the Tradeshift team for any
related vendor processes or relations that are relevant for implementing or enrolling the suppliers to
the Tradeshift platform. Activities may include providing Supplier Master Data, assisting withrequested webinars or communications, and providing support based on suppliers that do notrespond to any communications.

4.5 ERP Subject Matter Expert(s)ERP Subject Matter Expert(s) provide system knowledge either functionally or technically to enable
solution decisions raised throughout the course of the implementation. These resources will validate
the business scenarios and ensure data availability from or to the respective system in regards tobusiness rules or processes that need to be established. These resources may be identified during
the testing cycles to validate the integrity of data within the ERP or business system.

4.6 Technical Lead(s)Technical Lead(s) provide information related to architecture, security, user provisioning, or any
other type of technical expertise that would be needed to validate a process, integration, or
question that was identified or raised. Depending on the solution scope and your departmental
structure, this role may be part of a previously defined role.

Restricted Use

Page 29 of 37

Tradeshift Shiftology - Project Implementation

5 Responsibilities, Governance, Risk & Budget Management
Tradeshift Shiftology delivers real value while ensuring that all project costs are kept under control andthat risks are identified, logged, monitored and/or managed effectively. This is established with thefollowing models listed below:

5.1 RACI Matrices
The matrices below provide the typical, informative, high-level example of responsibilities between
Tradeshift (Project Implementation Team) and our Customer. Other arrangements and discussions aroundthese areas will be further discussed when planning the implementation. Notably, the RACIs below do not
explicitly include delivering via our Partners. In the cases Tradeshift works together with partners for a
Customer delivery, the Customer will be provided with its specific breakdown of partners’ roles andresponsibilities during the sales and implementation cycles.
The acronym RACI stands for:
●

●

●
●

Responsible: The person who does the work to achieve the task. They have responsibility forgetting the work done or decision made. As a rule this is one person; examples might be a businessanalyst, application developer or technical architect.
Accountable: The person who is accountable for the correct and thorough completion of the task.
This must be one person and is often the project executive or project sponsor. This is the role that
responsible is accountable to and approves their work.
Consulted: The people who provide information for the project and with whom there is two-way
communication. This is usually several people, often subject matter experts.
Informed: The people kept informed of progress and with whom there is one-way communication.
These are people that are affected by the outcome of the tasks, so need to be kept up-to-date.

RACI - Project Professional Services Team - Activities and Deliverables
Activity/
Deliver
able

Phase

Activity / Task

RACI
R A C I

Plan

Restricted Use

D

Governance Model and Terms of Reference (Tradeshift)

T C C CD

Governance Model and Terms of Reference (Customer)

C C T TD

Establish Project Management Tools, collaboration means and document repository

T C C CA

Establish cadence of meetings

T C C CA

Coordination and ramp-up of Customer project teamC C T T

Page 30 of 37

Tradeshift Shiftology - Project Implementation

Define & Design

Restricted Use

A

Coordination and ramp-up of Tradeshift project team

T T C CA

Prepare Kick-off agenda and slide deck

T T C CD

Organize and staff project team- Tradeshift

T T C CD

Organize and staff project team - Customer

C C T T

A

Draft project plan - Tradeshift Solution related activities

T C C CATeam Introductions & Kick Off Agenda review

T T C CD

Creation of Risk and Issue Log

C T T TA

Initiate change management and communication activities for transition from current
processes to future
C C T TD

Share standard Tradeshift integration specifications

T T C CA

Prepare process & integration requirements documents (Customer)

C C T T

D

Sandbox environment available

T T C CA

Customer Team review Tradeshift documentationC C T T

A

Customer Internal Communications of program

C C T TD

Share Current “as is” business flows

C C T T

D

Kick-off project with a Kick-off workshop

T C C CD

Project Release Start/Mobilization Milestone Sign Off

T C C CD

Project Change Control execution (Customer)

C T T TA

Conduct Design & Technical Integration Workshop

T C C CD

Creation of Solution Description (including Integration Interface Specification andConfiguration sheet) Documents

T C C CD

Solution Description Design and Execution

T C C CA

Review Solution Description and provide feedback

C T T T

A

Collect and provide completed Master Data for Account Design

C T T TA

Develop Future-State Company system set-up and configuration

T C C CA

Design Future-State approval rules and authorization levels

T C C CA

Define integration design and detailed setup

T C C CD

Updates to Change Management Transition Log

C C T T

D

Updates to Risk & Issue log

C T T T

D

Definition of performance levels & Go Live success criteria

C C T TD

Approval of Change management transitions

C C T T

D

Create Test plan strategy and sign off

C T T T

A

Solution & Integration Sign-off - Solution Description finalised

C T T T

Page 31 of 37

Tradeshift Shiftology - Project Implementation

Build &
Configure

Test & Train

Restricted Use

D

Training plan and strategy sign off

C T T T

D

Baseline Tradeshift Solution Project Plan Sign Off

C T T T

A

Execute Design Exit Steering Committee

T C C CD

M2 Milestone Sign-off

C T T TA

Set-up of Tradeshift Test environment

T T C CA

Prepare and execute Early Hand Overs sessions (when applies)

T T T CA

Configure of Tradeshift according to Signed Off Solution Description

T C C CA

Setup data integration processes per specification within Tradeshift

T C C CA

Setup data integration processes per specification within Customer Environments

C T T T

D

Provide standard test scripts

T T C CA

Provide complete list of User Acceptance Test UAT test cases and final UAT test plan

C T T T

A

Setup integrations Customer (where applicable)

T T C CA

Internal Tradeshift Unit Test

T T C CA

Define and Plan Systems Integration tests (SIT)T C C CD

M3 Milestone Sign-off

C T T T

D

Provide master data for test scenarios

C T T T

A

Validate Training and Testing Scenarios

T C C CAUAT Cases confirmed

C C T T

A

Systems integration testing (SIT) conducted

T C C CD

Conduct "train-the-trainer" training

T C C C

D

Localised End User Training Materials

C T T TA

End User Training Delivery

C T T TA

Own User Acceptance Test (UAT)C T T T

A

Support UAT in Issue Resolution

T C C CD

Business Readiness CheckpointC T T TA

Creation and validation of production migration plans

C T T T

D

Hypercare and Business as Usual (Operations) PlanT C C CA

Operations (Support and Customer Success) organization introductions & transitions

T C C CD

M4 Milestone Sign-off

C T T TA

Migration of Tradeshift configurations to production

T T C CA

Migration of Buyer system configurations to production

C T T T

Page 32 of 37

Tradeshift Shiftology - Project Implementation

LaunchHypercare

Wave
Rollouts

Restricted Use

A

Tradeshift Internal HandOvers

T T T CA

Production data loads for go-live

T C C CA

Confirm readiness for Go Live and Hypercare (Tradeshift)

T

A

Confirm readiness for Go Live and Hypercare (Customer)C C C CA

Smoke Test in Production: First dummy documentT/
C C C CAFirst Production transaction confirmed

T/ T/ T/ T/
C C C CD

M5 Milestone Sign-off

C T T T

A

Support during hypercare

T C C CA

Finalize project documentation

T C C CA

Evaluate success of deployment and Lessons Learnt

C T T T

D

Wave Planning revisited and Project Plan updated

T C C CD

Project Team Resource (Tradeshift)

T T C CD

Project Team Resource (Customer)

C C T T

A

Business Gap analysis versus Core Model, requirements gathering

C C C T

D

Updated Functional & Design Specification *including output of gap analysis

T T C CD

Updated Solution Description Sign Off

C C T TA

Build (Configure and Integrate) according with Updated Solution Description

T C C CA

Supplier onboarding kick off

T C C CA

Updated Solution Configuration Complete

T C C CD

Test materials updated

C C T TD

Training materials updated

C C T T

A

Integration configuration and tests completed - Tradeshift

T T C CA

Integration configuration and tests completed - Customer

C C T TA

UAT materials updated

C C T TD

Release Sign Off

C T T T

A

Cutover plan and release hypercare executed

T C C CA

Communications as per Communications & Change Management planC C T T

Page 33 of 37

T T T

Tradeshift Shiftology - Project Implementation

5.2 Governance Model
The typical governance model established for Tradeshift projects implementations is based on three levels
which provide the necessary support, perspective, and hierarchy to execute and adapt during the courseof the delivery and beyond. These levels are:●●●Level 1 - Operational○ Project Delivery Team members with a specific role or task (Functional, Technical, or Hybrid)
Level 2 - Tactical○ Project and/or Program Management
Level 3 - Strategical○ Sponsor level that helps drive key changes or resolve escalated issues.

5.3 Tradeshift Risk Management
Tradeshift proactively manages Risk throughout the project lifecycle. All projects (including Tradeshift)experience events that may cause unexpected and unanticipated effects. These may be both positive or
negative. These events are logged, tracked, monitored and controlled on a risk register - built into
Tradeshift’s project management tool.

Restricted Use

Page 34 of 37

Tradeshift Shiftology - Project Implementation

This risk register is made available to the customer project team to be reviewed and updated during
project meetings.
We classify risks based on Likelihood and Impact, in a scale from 1 (minimum) to 5 (maximum) and ranked
by the summatory of them

5.4 Tradeshift Project Budget
Great project financial / budgetary control starts with accurate estimates centered on clearly defined scope
and assumptions. All Tradeshift Professional Services projects are carefully estimated using tools andcalculators that have been refined and tuned based on the deep experience of our Professional Services
team and delivery of other Tradeshift projects. Once professional services have been purchased by a
Customer, a project is created in our Professional Services management tool.
From within the tool, project financials, project tasks, resources and timelines are entered and managed.
Throughout the project, at regular intervals, the Tradeshift Engagement Manager will analyse thebudgeted costs (based on estimated number of hours for scoped tasks) with the actual costs (based on
the actual hours spent on the project). A cost to completion can then be calculated based on remaining
scheduled activities and their associated cost estimate for each activity.

6 Change Request Process
Change is a natural course of a project or after the successful deployment of the solution to further
organizational efficiencies and/or maximize return. As part of Tradeshift’s methodology a formal process
exists to request changes to the solution or scope.
The process in summary is as follows, while in Project mode:
1. When a Customer has a change to what is stated scope or previously delivered solution, theTradeshift Engagement Manager and the Customer will fill out the Change Request (CR) Form
2. The Tradeshift Engagement Manager will then talk to relevant resources within Tradeshift, fill theinformation in the request and then jointly decide to move forward with the request or not.
3. If the Request is accepted and Customer accepts the associated effort and any applicable impact
to the timeline, budget and scope, both Parties will execute the Change Request Form and schedulethe necessary deployment. A PSO (Professional Service Order) will be required to define the legal
and cost terms associated with the CR.
4. The Change Request effort is included in our Professional Services management tool to trigger
resourcing and control on execution.

Restricted Use

Page 35 of 37

Tradeshift Shiftology - Project Implementation

7 New Product Feature Process
Any change requests for Product Enhancements will be raised to the Tradeshift Product Change Request
Portal and will be subject to review by Product for fit with the longer term Tradeshift strategy. Such change
requests are not guaranteed to be implemented/accepted. The Tradeshift Release process includes thefollowing processes and phases:--

Customer Ideas Portal Ideation Phase: This covers the input mechanism of requests initiatedexternally via the Customer Ideas Portal
Product Change Request Ideation Phase: This covers the input mechanism of requests initiatedinternally via the Product Change Request portal
Release Process Input & Prioritisation Phase: This covers the aligned / centralised Strategic andPrioritisation activities applicable to both input mechanisms (the Customer Ideas Portal and theProduct Change Request portal) that feed the backlog delivery planning and Go-To-Market
activities.
Release Execution
Release internal Training and Communications to Customers

Starting 2021, Tradeshift is conducting 2 major releases per year. Please reach out to your Tradeshift
Representative for information on major release dates and Product official release information, for the
release that impacts your implementation.

8 Bug Process
When a Tradeshift bug is identified during the project test cycle, the Engagement Manager will enter the
bug in the Tradeshift ticketing system. If a bug is found post go-live in production, the Customer should
create a ticket with the Tradeshift Support team through the agreed ticketing process. The support teamwill then follow the same process of creating a bug in the Tradeshift ticketing system. As part of the bugprocess, the Professional Services, Customer Success and Support teams meet on a weekly basis toreview and prioritize all bugs. The next day the same teams meet with the Product team to review allprioritized bugs and receive updates.

9 CSAT Process
Although we will have regular project meetings, technical meetings, supplier onboarding meetings,
steering group meetings etc. through the project implementation phases, it is still important for Tradeshift
to receive structured feedback from our customers during implementation.
We approach you in a simple survey with four questions sent out at selected milestones. The key benefit
with the CSAT is that it is based on a “here and now” reaction to a customers’ satisfaction with theimplementation. Measuring CSAT allows us to understand potential risks before they turn into Issues. This
Restricted Use

Page 36 of 37

Tradeshift Shiftology - Project Implementation

also gives valuable insight into how we can improve. Expect to receive one CSAT every quarter, providing
a key milestone has been accomplished.

10 Lessons Learned
As default in Tradeshift’s Shiftology, Tradeshift Professional Services will create a Lesson Learned
document with the purpose of bringing together any insights gained during the project that can be usefully
applied on future roll-outs. The Lesson Learned document is in most cases created, shared and discussedwith our Customers before we close a Release.

11 Collaboration with other Customer facing teams
During the sales and project implementation, you’ll be introduced to our different other Tradeshift teams(for example Customer Success, Support, Network) and be guided in their roles and responsibilities during
project execution. This will also include the different documentation assets they provide as well as their
expected collaboration with your Professional Service team. Please reach out to your contact in Tradeshift
in order to get more information about the topic.

12 Questions
If you have any questions about this document, please reach out to your contact in Tradeshift and you will
be directed to the right person or team.
Thanks for reading,Your Tradeshift Professional Services Team.

Restricted Use

Page 37 of 37