Delivery guide

Pending work to be done

Create best practice page with solution and configuration advises
Improve setup new concern process based on MOL-6 + identified improvements based on other insights (journals, journal periods, DC hierarchy, default scripts to run, default roles & rights, default templates etc)
Review standardized ticket list and add all kind of detailed small knowledgable tasks which you run into during implementation, if they cannot be included/improved in the setup new concern process (configuration of internet user, enable cleanup script initial bookings, enable customer deduplication, enable cash register toggle at addon type level, TS plus accounts if needed etc)
Create library of standardized data migration + validation scripts. Could entail customers, owners, reservations. (Or re-develop / improve MXTS Implementation Manager now content manager team is mature?)

What is it?

This article provides concrete tips & tricks when the project must be delivered. For this article to be useful, it is relevant the project is approached and prepared in accordance with the tools provided by the overarching implementation framework. This article assumes the project products (hereafter: Epics) are defined and the project plan is made.

General delivery approach

Because the project is broken down into epics and phased over time based on priority, for each epic the same process can be followed as visualized above. This means, different epics can be implemented in parallel and epics can be in different steps of the process.

Step	To do
Know the client’s business	In addition to the general understanding of client’s business documented in the business profile, now focus on the epic specifics to make sure the advised approach can be accepted by the client. Update the detailed knowledge and target goal in Epic description.
Setup functioning prototype on test environment	Setup the functioning solution on a test environment for the client to experience and validate. Make as much as possible use of default MXTS import sheets where available, so they can be handed over to the client as part of user training. Embed Maxxton’s best practices rightaway in the advised setup needed to deliver the epic.
Solution refinement for client acceptance	Validate, refine and confirm the solution on test environment to meet client’s acceptance criteria.
Data entry on Live environment	Get the required data on Live environment. Handover and/or re-use any earlier created importsheets to the client for Live population.
End2end testing	Take a holistic approach when testing met (typically) MXTS configurations. Identify, clarify and conclude any impact on related relevant solutions like Guest Environment, guest communication, API
Go Live	Take epic into live usage

Focus on project products

Closing tickets in itself does not lead to a successful implementation

Implementing is all about making sure the solutions can and will be used in Live production by the client. It would not be the first time all Jira tickets are closed, we think we are done and some time later the client gets back at Maxxton about something missing, not working as expected, not really clear etcetera. Avoid this situation by continuously making sure the proposed solution is complete, understood and accepted by the client.

So don’t forget to zoom out every now and then and take a birds-eye view on the defined project products to validate if the project is still on track to support the required needs. It helps to define a few ‘focus-phases’ (let’s say 2 phases for 1-6 month and 3 phases for 12+ month projects) and take a moment with the client to reflect on the coöperation, delivered products and gained insights and experience. Use the Phase-end report to add some structure to this session and make sure you learn from the experience or implement improvements for the next phase. If generic lessons can be learned for the benefit of future projects, add them in the Lessons Learned Register!

Data Migration

Inseparable with implementing a new system is the task of migrating data. This obviously entails the list and hierarchy of locations and accommodationtypes, but often also the descriptive data like descriptions, amenities, images. Other items which are often in scope for moving to a new system are existing reservations for the upcoming season, customer data and/or owner data.

Data migration can take place via different ways! It’s not always a database script. Simply determine per data-piece the best fitting approach

Data migration method	When
MXTS Import sheets	Quickly and easily importing large datasets during a new setup with the benefit of re-using the information for future re-use (different environment, new content etcetera)
Manual (includes Batch Update feature)	Small volume, unreliable / polluted datasource, high complexity. Best approach when no MXTS Import sheet is in place and/or when the task can be finalized within 10-20 hours and/or when the manual task adds to the user’s knowledge and hence serves the purpose of user training as well
Database script	Only to consider when the effort for (developing,) testing, executing and validating the script outweighs the manual effort. Appropriate for large data volumes, easy to understand / robust logics with little complexity.
API put-endpoints?	What can be added via API during a live setup? Or is nothing from a basic setup in scope?

In any case, make sure you consider the Data Migration Guidelines for a process as smooth as possible!

Key-principles-data-migration-insights-1 (1).png