Delivery guide
- Frank Louwerse (Deactivated)
Pending work to be done
What is it?
This article provides a concrete approach for 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 and general understanding of client’s business is there. This article assumes the project products (hereafter: Epics) are defined and the project plan is made.
Get a new concern in place
Starting point of getting our hands dirty in the system is to get a new MXTS concern in place, both a Live and Acceptance environment. This is purely an internal task, but in order to smoothen the process and kickstart the setup it is wise to consider the following during this step:
Tailor the internal request already to the new client (add correct languages, currencies, base currency, default language etc)
Add as much default configuration already for future use, if not already added via the new-concern-script. This refers to basic configuration required for an MVP-level system, but which is often only stumbled upon when things are not working as expected immediately (fiscal year, internet payment methods, cash account, front office configuration, reservation manager configuration)
Add default email templates so user flows can be setup and validated end2end including guest communication
Add default user roles and rights to easily explain the concept and provide a plug&play standard setup
By including the above mentioned items in this step of the implementation, a high quality setup is ensured reducing disturbances down the road.
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!
