...
Category | Added by | Date | Lesson learned | Best practice or issue? | Advice | Follow up |
|---|---|---|---|---|---|---|
Delivery phase | Jochem | 7-1-2025 | Clients push to include other topics within the scope of the project because it is important to them. This broadens the scope and can slow down the implementation | BEST PRACTICE | Be keen on what the scope is, what the planning is, and push back on topics that will broaden the scope and therefore mess with the planning | Discussed internally |
Project approach | Jochem | 7-1-2025 | During an implementation, there will be third party dependencies which might slow down the project and implementations | ISSUE | At the start of the project map all third party dependencies and involve them early on in the project. This can be an accountant, Ingenico/Worldline, or any TO | Discussed internally |
Getting started | Jochem | 7-1-2025 | The knowledge level of MXTS of the implementation team is low at the start of the implementation causing unnecessary delays | BEST PRACTICE | When the client is very likely to sign the contract and move to MXTS, start including key people in the client’s implementation team in demo sessions of MXTS. | Discussed internally |
Project approach | Jochem | 7-1-2025 | The roles and responsibilities of the people in the client team should be clear to know what is expected from whom. | BEST PRACTICE | In the kick-off meeting assign the project project products to team members (with back-up) and make clear what the responsibilities of the project manager and work stream leads are | List down roles and responsibilities in the project |
Project approach | Jochem | 7-1-2025 | Be strict towards the new clients about deadlines and information provision. This avoids that we will compensate for the lack of time/effort on the client side | BEST PRACTICE | Comminucate clear deadlines on when input is expected from the client upfront and mention the consequences (delay) when it is not on time | Discussed internally |
Getting started | Jochem | 7-1-2025 | The project scope should be entirely clear and set before the project is started. Otherwise the scope can expand easily | ISSUE | Do not start the implementation with involvement of the client before the contract is signed | Discussed internally |
Getting started | Jochem | 7-1-2025 | The client shares a lot of information twice and it is not clear what is in scope and what is not from the start for the implementation team | BEST PRACTICE | Plan a handover meeting between the Sales team and the Implementation team to discuss basic client information and the scope of the contract | Discuss internally |
Getting started | Frank | 27-5-2024 | Setup new concern continuous disrupting. Not only configurations, but also backend settings like authentication tokens and MXTS user log-out time | ISSUE | Improve generic process. Setup & test configurations before introducing client to it. | Discussed internally |
Getting started | Frank | 27-5-2024 | Put testable configuration in place on ACC to introduce new users, rather than starting up from zero. | BEST PRACTICE | Setup testable configuration based on Maxxton advice, so new users can experience the system and validate / confirm suggested configuration. | Add in implementation guide |
Data migration | Frank | 27-5-2024 | Always have scripted data imports validated via script as well on test environments, before importing on Live. (Does imported data matches source data). | ISSUE | Avoid surprises and complex corrections, of which time spend easily exceed effort to create validation scripts. | Add in implementation guide |
Project approach | Frank | 27-5-2024 | Agile mindset enables successful projects; hit deadlines, reduce scope if needed, customer doesn't need everything | BEST PRACTICE | Explore to what extent an agile approach can be used for a project (Agilometer) | Add in implementation guide |
Project approach | Frank | 27-5-2024 | Consider using new features (meaning not elsewhere in live use) by default as 'increased risk'. Only consider these features 'done' when used in Production (in bulk if applicable). | ISSUE | Put new features in Live use as soon as possible. Either via testing on Production or putting a small scope in live use early (pilot). | Add in implementation guide |
System | Frank | 27-5-2024 | Bugs reduce confidence. This leads to quite some (ineffective) time spend to test, reproduce, report, discuss, monitor bugfix, and regaining confidence. | ISSUE | When targeting shorter durations of implementations, a bugfree system is essential. Or if bugs are present these should prioritized for fixing rather then postponing. | Discuss internally |
Configuration | Frank | 27-5-2024 | It is essential to have documentation of implications for configuring resources at parent level or location level, as well as the implications of multiple levels in location hierarcy. | ISSUE | Create documentation with benefits, limitations and implications of configuration options. This improves velocity in decisionmaking for configuration setup. | Create infographic |
Project approach | Frank | 27-5-2024 | High priority and update-rythm for critical path 'products' where uncertainty is. | ISSUE | For any project critical products where uncertainty is present, an ongoing weekly focus should be present to avoid worries and late / overdue delivery. | Add in implementation guide |
Project approach | Frank | 27-5-2024 | Availability of use cases for user training. | ISSUE | There should be a default list of use cases which can be used to quickly create a scope for testing / user training. | Add in implementation guide |
...